Detect MSBuild spawning a script interpreter or signed-binary proxy

Siemphony@siemphonyhighT1127.001unverified

Matches msbuild.exe becoming the parent of one of the high-risk children MITRE enumerates in AN1535 — the analytic's SuspiciousChildList knob, whose values (powershell.exe, rundll32.exe, regsvr32.exe, cmd.exe, wscript.exe, mshta.exe) MITRE spells out, extended here with cscript.exe, pwsh.exe and certutil.exe. AN1535 is a scored chain across seven event sources: anomalous msbuild invocation, then a payload write, an unsigned module load, a remote thread and egress inside a correlation window. Sigma has no cross-event join, no timeframe and no signature field on process creation, so only the child-spawn leg is expressed and the UnsignedOrInvalidSignatureOnly, RarePathRegex and NetworkReputationThreshold knobs have no equivalent in one event. The inline task itself is invisible here: what an inline task compiles and runs lives in the XML project file, not on the command line, so this rule sees the consequence rather than the abuse. Note the analytic's process source is Security 4688, which requires the Audit Process Creation subcategory to be enabled; without it this rule returns nothing at all. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0556, 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 "\\msbuild.exe" and (FolderPath endswith "\\powershell.exe" or FolderPath endswith "\\pwsh.exe" or FolderPath endswith "\\cmd.exe" or FolderPath endswith "\\wscript.exe" or FolderPath endswith "\\cscript.exe" or FolderPath endswith "\\mshta.exe" or FolderPath endswith "\\rundll32.exe" or FolderPath endswith "\\regsvr32.exe" or FolderPath endswith "\\certutil.exe"))

Splunk · SPL

Run this as a search.

index=* (ParentImage="*\\msbuild.exe" AND (Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\cmd.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe" OR Image="*\\certutil.exe"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.parent.executable) LIKE "*\\\\msbuild.exe" AND (TO_LOWER(process.executable) LIKE "*\\\\powershell.exe" OR TO_LOWER(process.executable) LIKE "*\\\\pwsh.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.executable) LIKE "*\\\\wscript.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cscript.exe" OR TO_LOWER(process.executable) LIKE "*\\\\mshta.exe" OR TO_LOWER(process.executable) LIKE "*\\\\rundll32.exe" OR TO_LOWER(process.executable) LIKE "*\\\\regsvr32.exe" OR TO_LOWER(process.executable) LIKE "*\\\\certutil.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="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="ParentImage" type="pcre2">(?i)\\msbuild\.exe$</field>    <field name="Image" type="pcre2">(?i)(\\powershell\.exe$|\\pwsh\.exe$|\\cmd\.exe$|\\wscript\.exe$|\\cscript\.exe$|\\mshta\.exe$|\\rundll32\.exe$|\\regsvr32\.exe$|\\certutil\.exe$)</field>    <description>Detect MSBuild spawning a script interpreter or signed-binary proxy</description>    <mitre>      <id>T1127.001</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: high
Category: signed_binary_proxy
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: a36895e4-2e2e-4579-978f-2c50384ff605

ATT&CKT1127.001

T1127.001MSBuild

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.

Lessonsigned binary proxy

signed binary proxyAI draft — unreviewed

01 · What this rule detects

msbuild.exe becoming the parent of a script interpreter or a signed-binary proxy — PowerShell, cmd, WScript, mshta, rundll32, regsvr32, certutil. Notice what that does not say. The canonical form of T1127.001 — an inline <Task> element in an XML project file, which MSBuild compiles and executes in-process — is the entire reason MSBuild is a LOLBIN, and it creates no child process at all. This rule covers MSBuild-as-launcher: the noisier adjacent behaviour, not the technique's signature form. The description concedes that; the title and level: high do not, and a learner reads those first.

02 · Telemetry you need

AN1535's process source is Security 4688, needing the Audit Process Creation subcategory — off in a clean install and in the MS and CIS baselines. Sysmon EventID 1 is the practical alternative and populates the same Sigma field names.
For the in-process variant this rule cannot see, use the other sources the brief lists under the same analytic: Sysmon EventID 7 (an unsigned or user-writable module loading inside msbuild.exe) and PowerShell 4104. That is where an inline task shows up.

03 · How the logic works

Two selections, ANDed:

The child list is MITRE's SuspiciousChildList knob — MITRE spells out powershell, rundll32, regsvr32, cmd, wscript and mshta — extended by the author with cscript, pwsh and certutil. The same LOLBin set appears in the corpus's T1203, T1204 and T1210 rules, so the parent is the only thing that tells those four alerts apart: when one fires, read ParentImage before Image. And the parent is a weak handle. dotnet build and dotnet msbuild run the build engine inside dotnet.exe, so ParentImage is \dotnet.exe and nothing matches. A copied or renamed MSBuild binary is documented by LOLBAS as working, and neither feed offers a rename-resistant parent field: Sysmon EID 1 carries OriginalFileName for the child only, and 4688 not at all. A quiet result here is not evidence of absence.

04 · Common false positives

This is the lesson worth carrying out of this rule. Its own first false positive says that on a build host, msbuild spawning cmd or PowerShell "is the normal case, not the exception" — pre- and post-build events shell out through cmd on almost every non-trivial project, SDK targets call PowerShell to sign and publish, NuGet packages ship install.ps1. The rule ships at level: high.
A rule whose loudest false positive is "this fires on every build" cannot be high. What happens next is predictable and is not tuning: the CI agents page the on-call analyst, someone suppresses the whole rule, and it detects nothing forever. A muted rule is worse than no rule — it occupies a slot on the ATT&CK heatmap while returning nothing. Compare the corpus's own calibration: T1046 at medium, T1018 at low, both levelled down for exactly this reason.
Two further sources: installer and setup projects whose custom actions register components with regsvr32 or rundll32, and — unlisted — certutil.exe in code-signing pipelines, where certificate imports, CRL refreshes and certutil -hashfile checksums are ordinary post-build actions. The author added certutil beyond MITRE's set and wrote no false positive for it.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from MITRE ATT&CK DET0556 and never executed against logs, or against a single build.
tier_2: is a volume measurement, and here that measurement is the tuning: count the hits from your build estate over a week, then set the level to what the survivors support.
tier_3: needs the file-write, module-load and egress legs correlated inside MITRE's TimeWindow — and, for the technique's real signature, an EID 7 rule watching what loads inside msbuild.exe.

Tuning & false positivesexperimental · 3 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

Scope by host first — MITRE's DeveloperHosts knob exists precisely for this rule's problem. Tag your CI agents and developer workstations and either exclude them or route them to a lower-severity stream. What is left is MSBuild running somewhere it has no business running, which is worth paging on.
Then add \dotnet.exe to the parent list, and reconsider the level: low or medium until the host scoping exists, or keep high only with a further constraint — the child's command line not referencing the solution, .nuget or obj paths.
MITRE's other AN1535 knobs — UnsignedOrInvalidSignatureOnly, RarePathRegex, NetworkReputationThreshold, BehaviorRiskScoreThreshold, TimeWindow — describe a scored correlation across seven event sources. Sigma has no cross-event join, no timeframe and no signature field on process creation, so none of them has a form here. That gap is the shape of the distance between an analytic and a rule.

Declared by the author

Ordinary builds on developer workstations and CI agents. MSBuild Exec tasks, pre-build and post-build events shell out through cmd.exe on almost every non-trivial project, and many SDK targets call powershell.exe to sign, package or publish output. On a build host this pair is the normal case, not the exception, which is what MITRE's DeveloperHosts knob exists to scope away.
Visual Studio and NuGet package install and restore scripts, which are PowerShell by design and run with msbuild.exe as the parent whenever a package ships an install.ps1 or a targets file that invokes one.
Installer and setup projects whose custom actions register components with regsvr32.exe or rundll32.exe as part of a legitimate build or deployment step, producing the exact parent-child pair the rule keys on with no command-line difference to separate it from proxy execution.

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.

Verification2 runs

Not verified

Security Datasets — MSBuild proxy execution
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.
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 T1127.001, evaluated against their process_creation events.

Share this rule

/u/siemphony/a36895e4-2e2e-4579-978f-2c50384ff605

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.

Detect MSBuild spawning a script interpreter or signed-binary proxy

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it