.NET compiler launched from a non-development parent process

Siemphony@siemphonylowT1027.004unverified

Matches AN1381's "compilation activity using csc.exe, ilasm.exe... initiated by user-space processes outside typical development environments" in the single event Sigma can carry: the compiler as Image, gated on a ParentImage that is a shell, scripting host or file-explorer process rather than an IDE or build tool. MITRE's ParentProcessName knob is populated here with cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe and explorer.exe — the brief names the knob, this list is authored, not MITRE's. msbuild.exe is deliberately left out of both the compiler and parent lists: it is already the subject of the published T1127.001 rule, which matches msbuild.exe spawning a script interpreter — the opposite direction from this rule's csc.exe/ilasm.exe-as-child pattern — and folding it in here would blur the two into one indistinguishable observable. The brief's OutputDirectoryPath and TimeWindow knobs (where the compiled binary lands, and whether it runs or calls out shortly after) have no equivalent in a single process-creation event. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0501, 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 ((FolderPath endswith "\\csc.exe" or FolderPath endswith "\\ilasm.exe") and (InitiatingProcessFolderPath endswith "\\cmd.exe" or InitiatingProcessFolderPath endswith "\\powershell.exe" or InitiatingProcessFolderPath endswith "\\pwsh.exe" or InitiatingProcessFolderPath endswith "\\wscript.exe" or InitiatingProcessFolderPath endswith "\\cscript.exe" or InitiatingProcessFolderPath endswith "\\mshta.exe" or InitiatingProcessFolderPath endswith "\\rundll32.exe" or InitiatingProcessFolderPath endswith "\\explorer.exe"))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\csc.exe" OR Image="*\\ilasm.exe") AND (ParentImage="*\\cmd.exe" OR ParentImage="*\\powershell.exe" OR ParentImage="*\\pwsh.exe" OR ParentImage="*\\wscript.exe" OR ParentImage="*\\cscript.exe" OR ParentImage="*\\mshta.exe" OR ParentImage="*\\rundll32.exe" OR ParentImage="*\\explorer.exe"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*\\\\csc.exe" OR TO_LOWER(process.executable) LIKE "*\\\\ilasm.exe") AND (TO_LOWER(process.parent.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\powershell.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\pwsh.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\wscript.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\cscript.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\mshta.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\rundll32.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\explorer.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="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\csc\.exe$|\\ilasm\.exe$)</field>    <field name="ParentImage" type="pcre2">(?i)(\\cmd\.exe$|\\powershell\.exe$|\\pwsh\.exe$|\\wscript\.exe$|\\cscript\.exe$|\\mshta\.exe$|\\rundll32\.exe$|\\explorer\.exe$)</field>    <description>.NET compiler launched from a non-development parent process</description>    <mitre>      <id>T1027.004</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: obfuscated_payloads
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: bbbfc949-e612-4be1-b8a7-d87fa534c597

ATT&CKT1027.004

T1027.004Compile After Delivery

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.

Lessonobfuscated payloads

obfuscated payloadsAI draft — unreviewed

01 · What this rule detects

This rule catches one precursor of Compile After Delivery: a .NET compiler (csc.exe or ilasm.exe) launched with a parent process that is a shell, scripting host, or Explorer rather than a development tool. MITRE's AN1381 describes a fuller behavior — compilation "followed by execution or network activity from newly written binaries" — but Sigma here has no aggregation or time-window support, so the rule can only match the single compile event, not the compile-then-run chain. That's normal for this corpus: read it as "a compiler ran somewhere it shouldn't have," not "a dropped payload executed."

02 · Telemetry you need

logsource is category: process_creation, product: windows — Sysmon EventID 1. You need Image and ParentImage populated on that event, which Sysmon provides by default once it's installed.

03 · How the logic works

selection_compiler matches Image|endswith against \csc.exe or \ilasm.exe. selection_parent matches ParentImage|endswith against eight names: cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, explorer.exe. The condition is selection_compiler and selection_parent — both must be true on the same event. Notably, msbuild.exe — one of the three compiler binaries AN1381 explicitly names — is excluded from selection_compiler. The rule's description justifies this by pointing at the already-published T1127.001 rule (msbuild.exe spawning a script interpreter). Review flagged that justification as conflating two different mechanisms: T1127.001 catches msbuild running an inline task fileless, while AN1381's msbuild case is msbuild compiling a dropped .csproj/.cs file — the same compile-after- delivery pattern this rule targets for csc.exe. That reasoning doesn't hold up, so as written, msbuild.exe-as-compiler is a real, unaddressed coverage gap here, not something handled by another rule.

04 · Common false positives

Three false positives, each tied to a specific selection_parent value:
1. PowerShell's Add-Type cmdlet compiles inline C# via CSharpCodeProvider, spawning csc.exe under ParentImage=powershell.exe or pwsh.exe. The rule's own description calls this the likely dominant source of matches. 2. CI/build agents that shell out to csc.exe directly from a cmd.exe or PowerShell wrapper script instead of msbuild.exe or devenv.exe. 3. An installer or bootstrapper double-clicked from Explorer that JIT-compiles a helper assembly with ilasm.exe during setup. Review flagged this third entry as weaker and speculative: in practice explorer.exe is usually the grandparent of such a subprocess (installer.exe is the direct parent), and ilasm.exe isn't a binary GUI installers typically invoke directly. Weight this one less than the first two.

05 · Detection maturity

tier_1: UNVERIFIED — the lowest tier. This rule has never been run against real logs. It parses, renders across four backends, and cleared adversarial review as usable-as-scaffold, but none of that is evidence it fires correctly or at a manageable volume in a live environment. Treat it as a draft to test, tune, and decide on msbuild.exe coverage for — not a deployable detection.

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

MITRE names ParentProcessName as the tuning knob in AN1381 ("filter for unexpected users launching compilers"); the eight-name parent list is the rule author's own choice, not a value MITRE supplied — narrow or extend it for your environment. The brief also names OutputDirectoryPath and TimeWindow as knobs, but neither has an equivalent here: both would need correlating file_event and network_connection logsources over a time window, which a single process_creation selection can't do.
A concrete next step: CommandLine exists on Sysmon EID1 but is unused. Add-Type-driven compiles have a recognizable command-line shape (a randomly-named temp .cs response file) that could suppress the dominant FP above. Also know the Image|endswith gate is trivially evaded — renaming or copying the compiler binary, routing through the persistent VBCSCompiler.exe compiler server, or compiling in-process via the Roslyn/CodeDom API (no separate process spawned) all leave nothing for this rule to see.

Declared by the author

PowerShell's Add-Type cmdlet, which compiles inline C# through csc.exe under a CSharpCodeProvider call whenever a script or module defines a helper type — a routine pattern in administrative tooling, DSC resources and defensive scripts alike, and the most likely dominant source of matches wherever such scripts run.
Build agents and CI runners that shell out to csc.exe directly from a cmd.exe or PowerShell wrapper batch/script instead of invoking msbuild.exe or devenv.exe, common on lightweight or self-hosted build machines.
A user double-clicking a self-contained .NET installer or first-run bootstrapper launched from explorer.exe that JIT-compiles a helper assembly with ilasm.exe during setup.

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 T1027.004, evaluated against their process_creation events.

Share this rule

/u/siemphony/bbbfc949-e612-4be1-b8a7-d87fa534c597

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.

2 threads

@priya-raman
21 Aug 2026
Add-Type is going to be 95% of this anywhere that has real PowerShell tooling, and the false-positive list says so plainly, which I appreciate more than I expected to. What made it usable for us was pairing it with where csc.exe writes: Add-Type lands a randomly named dll in %TEMP%, and an operator compiling a payload puts it somewhere they chose. That is the OutputDirectoryPath knob the description says has no single-event equivalent — it does not, and it is still worth building as a two-event correlation if your platform can join.
Deleted by its author.

.NET compiler launched from a non-development parent process

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it

2 threads