Execution via MSSQL xp_cmdshell Stored Procedure


Execution via MSSQL xp_cmdshell Stored Procedureedit

Identifies execution via MSSQL xp_cmdshell stored procedure. Malicious users may attempt to elevate their privileges by using xp_cmdshell, which is disabled by default, thus, it’s important to review the context of it’s use.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.process-*
  • logs-windows.*
  • endgame-*
  • logs-system.security*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100



  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend

Version: 111

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guideedit

Triage and analysis

Investigating Execution via MSSQL xp_cmdshell Stored Procedure

Microsoft SQL Server (MSSQL) has procedures meant to extend its functionality, the Extended Stored Procedures. These procedures are external functions written in C/C++; some provide interfaces for external programs. This is the case for xp_cmdshell, which spawns a Windows command shell and passes in a string for execution. Attackers can use this to execute commands on the system running the SQL server, commonly to escalate their privileges and establish persistence.

The xp_cmdshell procedure is disabled by default, but when used, it has the same security context as the MSSQL Server service account, which is often privileged.

Possible investigation steps

  • Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
  • Investigate other alerts associated with the user/host during the past 48 hours.
  • Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
  • Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
  • Examine the command line to determine if the command executed is potentially harmful or malicious.
  • Inspect the host for suspicious or abnormal behavior in the alert timeframe.

False positive analysis

  • This mechanism can be used legitimately, but it brings inherent risk. The security team must monitor any activity of it. If recurrent tasks are being executed using this mechanism, consider adding exceptions — preferably with a full command line.

Response and remediation

  • Initiate the incident response process based on the outcome of the triage.
  • Isolate the involved hosts to prevent further post-compromise behavior.
  • Remove and block malicious artifacts identified during triage.
  • Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
  • Ensure that SQL servers are not directly exposed to the internet. If there is a business justification for such, use an allowlist to allow only connections from known legitimate sources.
  • Disable the xp_cmdshell stored procedure.
  • Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
  • Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
  • Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).



If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define event.ingested and default fallback for EQL rules was not added until version 8.2. Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate event.ingested to @timestamp. For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html

Rule queryedit

process where host.os.type == "windows" and event.type == "start" and process.parent.name : "sqlservr.exe" and
   (process.name : "cmd.exe" and
    not process.args : ("\\\\*", "diskfree", "rmdir", "mkdir", "dir", "del", "rename", "bcp", "*XMLNAMESPACES*",
                        "?:\\MSSQL\\Backup\\Jobs\\sql_agent_backup_job.ps1", "K:\\MSSQL\\Backup\\msdb", "K:\\MSSQL\\Backup\\Logins")) or

   (process.name : "vpnbridge.exe" or ?process.pe.original_file_name : "vpnbridge.exe") or

   (process.name : "certutil.exe" or ?process.pe.original_file_name == "CertUtil.exe") or

   (process.name : "bitsadmin.exe" or ?process.pe.original_file_name == "bitsadmin.exe")