SQL Server engine spawning an operating system process

Siemphony@siemphonymediumT1505.001unverified

AN0511's observable at the only point where it reaches Windows telemetry: a process-creation record whose parent is sqlservr.exe. Both mechanisms the analytic names run inside the database engine's own process, so whatever they execute is created by it — `xp_cmdshell` shells out through cmd.exe, and a CLR assembly registered UNSAFE and invoked by a stored procedure launches its helper directly. sqlservr.exe has almost no legitimate reason to create a child, which is why the parent alone is the selector rather than a list of child images that an operator can trivially change. The two children the engine does spawn on its own — sqldumper.exe on a crash or non-yielding scheduler, and fdlauncher.exe when full-text search starts — are filtered by name only, so a payload dropped under either of those names is not caught. What this rule cannot see is the persistence itself. Creating or altering the malicious stored procedure, registering the CLR assembly, and flipping `xp_cmdshell` on via sp_configure are all statements inside the database; they appear in SQL Server's own audit or error log and never in Windows process creation. This rule therefore fires when the implanted procedure runs, not when it is planted, and a procedure that only reads or exfiltrates data through T-SQL spawns nothing and stays invisible. The rule is written in the Sysmon EventID 1 vocabulary (Image, ParentImage) named by the analytic; where the same Sigma category is fed by Security EventID 4688, that channel needs *Audit Process Creation* and a field mapping to NewProcessName and ParentProcessName first. AN0512's Linux leg — the mysqld/postgres UDF and `COPY ... PROGRAM` equivalents — is a different log source and is not covered here. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0181, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (InitiatingProcessFolderPath endswith "\\sqlservr.exe" and not ((FolderPath endswith "\\sqldumper.exe" or FolderPath endswith "\\fdlauncher.exe")))

Splunk · SPL

Run this as a search.

index=* (ParentImage="*\\sqlservr.exe" AND NOT ((Image="*\\sqldumper.exe" OR Image="*\\fdlauncher.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.parent.executable) LIKE "*\\\\sqlservr.exe" AND NOT ((TO_LOWER(process.executable) LIKE "*\\\\sqldumper.exe" OR TO_LOWER(process.executable) LIKE "*\\\\fdlauncher.exe")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="ParentImage" type="pcre2">(?i)\\sqlservr\.exe$</field>    <field name="Image" negate="yes" type="pcre2">(?i)(\\sqldumper\.exe$|\\fdlauncher\.exe$)</field>    <description>SQL Server engine spawning an operating system process</description>    <mitre>      <id>T1505.001</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 0cd861d9-ee1f-469c-8ab4-42c8980a9b72

ATT&CKT1505.001

T1505.001SQL Stored Procedures

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

"SQL Server engine spawning an operating system process" is the Windows leg of DET0181, grounded in analytic AN0511. It fires when sqlservr.exe creates a child process. Both mechanisms the analytic names run inside the database engine's own process, so whatever they execute is created by it: xp_cmdshell shells out through cmd.exe, and a CLR assembly registered UNSAFE that shells out launches its helper directly. Read a hit carefully — this catches an implanted procedure running, not the moment it was planted.

02 · Telemetry you need

Sysmon EventID 1, mapped to the process_creation / windows logsource copied verbatim from AN0511. The rule reads ParentImage and Image only, so no command-line capture is required. It is written in Sysmon vocabulary; a process_creation feed sourced from Security 4688 needs Audit Process Creation enabled and a field mapping to NewProcessName and ParentProcessName before it matches anything. What it does not need is any SQL-side auditing — and that is also its blind spot. CREATE PROCEDURE, CREATE ASSEMBLY and sp_configure 'xp_cmdshell', 1 are statements inside the database. They appear in SQL Server Audit or the engine's error log and never in Windows process creation, so the persistence event itself is invisible here.

03 · How the logic works

Two blocks. selection is a single condition, ParentImage|endswith: '\sqlservr.exe', and that is the whole detection idea: the engine has almost no legitimate reason to create a child, so the parent alone is a stronger selector than a list of child images an operator can trivially change. The second block, filter_engine_children, removes the two children the engine spawns on its own — sqldumper.exe on a crash or non-yielding scheduler, and fdlauncher.exe when full-text search starts. The condition is selection and not filter_engine_children. The filter matches on image name only, so a payload written to disk anywhere as sqldumper.exe is excluded outright — path-constraining it is the obvious hardening, though a negated AND-group is refused by at least one backend, so validate before keeping it. The other escape is structural: an UNSAFE assembly that opens a socket, reads files or loads shellcode entirely in-process creates no child, and the rule sees nothing.

04 · Common false positives

Mostly in estates that turned xp_cmdshell on deliberately and built around it. T-SQL job steps and stored procedures that call robocopy, dir or a batch file to move, verify or prune backup files run on a schedule and are the same shape as the abuse — the difference is which procedure issued the call, which this event does not carry. Vendor SQLCLR assemblies in reporting, ETL and document-conversion products legitimately launch helper executables. A DBA running xp_cmdshell from Management Studio to test a path or permissions appears identically. Note that maintenance plans and Agent CmdExec steps are not noise here: they run under sqlagent.exe, not the engine.

05 · Detection maturity

tier_1: Lowest tier. The rule has never been executed against a log line, so its volume, its false-positive rate and whether your Sysmon config even records sqlservr.exe lineage are all unmeasured. Run it over historical data first, then decide.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE names three mutable elements on AN0511: an xp_cmdshell_invocation_threshold, a CLRAssemblyNameWhitelist, and a TimeWindow for correlating procedure creation with execution. Only the second maps cleanly onto this rule — extend filter_engine_children with the specific helper executables your vendor assemblies launch, path-constrained. The threshold and time-window knobs need aggregation and correlation this Sigma cannot express; realise them in your SIEM instead, ideally by joining these child-process events against SQL Server Audit so a hit carries the procedure name. level: medium assumes xp_cmdshell is off in your estate. Where it is on, drop it.

Declared by the author

Estates that have deliberately enabled xp_cmdshell and built maintenance around it: T-SQL job steps and stored procedures that call out to robocopy, dir or a batch file to move, verify or prune backup files. These run on a schedule, are the loudest source of matches wherever they exist, and are the same shape as the abuse — the difference is which procedure issued the call, which this event does not carry.
Vendor applications shipping signed SQLCLR assemblies that legitimately launch a helper executable — reporting, ETL and document-conversion products are the common ones — producing a child of sqlservr.exe every time that feature is used.
A DBA running xp_cmdshell interactively from Management Studio to check a path, test permissions or read a directory while troubleshooting a failed job.
SQL Server maintenance plans and third-party backup or monitoring agents that reach the filesystem through xp_cmdshell rather than through their own service account, appearing as a fixed-interval cmd.exe child.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1505.001, evaluated against their process_creation events.

Share this rule

/u/siemphony/0cd861d9-ee1f-469c-8ab4-42c8980a9b72

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

SQL Server engine spawning an operating system process

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it