Database process spawned shell
A database engine process started a command shell or interpreter.
What it detects
A database engine process started a command shell or interpreter. A database answers queries; it does not run operating-system commands as part of its job.
On SQL Server this is xp_cmdshell, and it is the standard escalation from "I have database credentials" to "I have code execution on the server" — which is why a compromised sa account is treated as host compromise. The database service often runs with high privilege, so the shell inherits it.
The process tree is the evidence: sqlservr.exe as the PARENT of cmd.exe is conclusive in a way the database's own logs are not. This matters practically, because the SQL Server events that name the configuration change (15457) and the execution (33205) carry their text in a provider message resource that an exported log does not include — so the Application-log route to this detection is closed and the process tree is the one that works.
MITRE ATT&CK mapping
False positives and triage
Legitimate uses exist and are worth knowing about before you escalate: some backup and maintenance jobs shell out from SQL Agent, and a few vendor applications use xp_cmdshell by design — a genuinely bad practice, but not an intrusion.
To confirm: read the command line. Reconnaissance (whoami, net user, ipconfig, set), anything writing to a web directory, or an encoded PowerShell command is the finding; a scripted backup path to a known location on a schedule is not. Then check whether xp_cmdshell was ENABLED shortly beforehand — it is off by default, so the configuration change is itself part of the intrusion. Treat the database service account as compromised, and check what else connected to the database around that time, because the entry point is usually SQL injection or a weak sa password.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 90%. Source: rules/windows/database_process_spawned_shell.yaml, licensed under the Apache License 2.0.
id: windows.execution.database_process_spawned_shell
version: 1.0.0
status: stable
severity: critical
confidence: 0.9
platforms: [windows]
mitre_techniques: [T1505.001, T1059.003]
description: |
A database engine process started a command shell or interpreter. A database answers
queries; it does not run operating-system commands as part of its job.
On SQL Server this is `xp_cmdshell`, and it is the standard escalation from "I have
database credentials" to "I have code execution on the server" — which is why a
compromised `sa` account is treated as host compromise. The database service often
runs with high privilege, so the shell inherits it.
The process tree is the evidence: `sqlservr.exe` as the PARENT of `cmd.exe` is
conclusive in a way the database's own logs are not. This matters practically,
because the SQL Server events that name the configuration change (15457) and the
execution (33205) carry their text in a provider message resource that an exported
log does not include — so the Application-log route to this detection is closed and
the process tree is the one that works.
match:
parent_process_name_any:
- sqlservr.exe
- mysqld.exe
- postgres.exe
- oracle.exe
- mongod.exe
process_name_any:
- cmd.exe
- powershell.exe
- pwsh.exe
- wscript.exe
- cscript.exe
- bash.exe
- net.exe
- net1.exe
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Legitimate uses exist and are worth knowing about before you escalate: some backup
and maintenance jobs shell out from SQL Agent, and a few vendor applications use
`xp_cmdshell` by design — a genuinely bad practice, but not an intrusion.
To confirm: read the command line. Reconnaissance (`whoami`, `net user`, `ipconfig`,
`set`), anything writing to a web directory, or an encoded PowerShell command is the
finding; a scripted backup path to a known location on a schedule is not. Then check
whether `xp_cmdshell` was ENABLED shortly beforehand — it is off by default, so the
configuration change is itself part of the intrusion. Treat the database service
account as compromised, and check what else connected to the database around that
time, because the entry point is usually SQL injection or a weak `sa` password.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.