« Execution via MS VisualStudio Pre/Post Build Events Execution via Microsoft DotNet ClickOnce Host »
Elastic Docs ›Elastic Security Solution [8.16] ›Detections and alerts ›Prebuilt rule reference

Execution via MSSQL xp_cmdshell Stored Procedure

edit

Execution via MSSQL xp_cmdshell Stored Procedure

edit

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.forwarded*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-system.security*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-crowdstrike.fdr*

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

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: System
  • Data Source: Microsoft Defender for Endpoint
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Crowdstrike

Version: 313

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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).

Rule query

edit
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")
  )

Framework: MITRE ATT&CKTM

« Execution via MS VisualStudio Pre/Post Build Events Execution via Microsoft DotNet ClickOnce Host »