SQL Server engine spawning an operating system process

1title: SQL Server engine spawning an operating system process2id: 0cd861d9-ee1f-469c-8ab4-42c8980a9b723status: experimental4description: |5  AN0511's observable at the only point where it reaches Windows telemetry: a6  process-creation record whose parent is sqlservr.exe. Both mechanisms the7  analytic names run inside the database engine's own process, so whatever they8  execute is created by it — `xp_cmdshell` shells out through cmd.exe, and a CLR9  assembly registered UNSAFE and invoked by a stored procedure launches its10  helper directly. sqlservr.exe has almost no legitimate reason to create a11  child, which is why the parent alone is the selector rather than a list of12  child images that an operator can trivially change. The two children the13  engine does spawn on its own — sqldumper.exe on a crash or non-yielding14  scheduler, and fdlauncher.exe when full-text search starts — are filtered by15  name only, so a payload dropped under either of those names is not caught.16  What this rule cannot see is the persistence itself. Creating or altering the17  malicious stored procedure, registering the CLR assembly, and flipping18  `xp_cmdshell` on via sp_configure are all statements inside the database; they19  appear in SQL Server's own audit or error log and never in Windows process20  creation. This rule therefore fires when the implanted procedure runs, not21  when it is planted, and a procedure that only reads or exfiltrates data22  through T-SQL spawns nothing and stays invisible. The rule is written in the23  Sysmon EventID 1 vocabulary (Image, ParentImage) named by the analytic; where24  the same Sigma category is fed by Security EventID 4688, that channel needs25  *Audit Process Creation* and a field mapping to NewProcessName and26  ParentProcessName first. AN0512's Linux leg — the mysqld/postgres UDF and27  `COPY ... PROGRAM` equivalents — is a different log source and is not covered28  here.29  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.30references:31  - https://attack.mitre.org/techniques/T1505/00132  - https://attack.mitre.org/detectionstrategies/DET018133author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)34date: 2026-08-1735tags:36  - attack.persistence37  - attack.t1505.00138logsource:39  category: process_creation40  product: windows41detection:42  selection:43    ParentImage|endswith: '\sqlservr.exe'44  filter_engine_children:45    Image|endswith:46      - '\sqldumper.exe'47      - '\fdlauncher.exe'48  condition: selection and not filter_engine_children49falsepositives:50  - "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."51  - "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."52  - "A DBA running xp_cmdshell interactively from Management Studio to check a path, test permissions or read a directory while troubleshooting a failed job."53  - "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."54level: medium