Installer or updater process spawning a shell, script host or downloader

Siemphony@siemphonylowT1195.002unverified

MITRE's Windows analytic for a compromised software supply chain is a four-stage chain: installer runs, binaries are written into program paths, the first run spawns unexpected children or loads unsigned modules, and the host beacons to something that is not an approved update endpoint. Stage three is the only part that is one event, so this rule matches process creation where the parent is an installer, updater or setup binary and the child is a shell, script host or download utility. Read it as a hunt, not as supply-chain detection. The dominant real-world form of this technique never creates a process at all: a payload compiled into a signed vendor assembly, or a malicious DLL side-loaded by the signed application, runs in-process and produces zero events here. The leg that carries that is the brief's driver_load (Sysmon 6) and image_load (Sysmon 7) sources, where Signed, Signature and SignatureStatus let an unsigned or unexpectedly-signed module loading into a vendor process be scored — none of which this rule sees. The child list is a starting set taken from the analytic's wording ("spawns scripts/shells"), not an exhaustive interpreter inventory, and a tampered installer that runs its payload as its own child EXE never touches it. The write-to-first-run-to-egress correlation MITRE specifies needs a 90-minute join across file, module and network telemetry, which Sigma cannot express, and the ApprovedSigners and ApprovedUpdateHosts knobs are list lookups rather than field tests, so neither is modelled here. UNVERIFIED — derived from MITRE ATT&CK DET0309 and never executed against logs.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 "\\msiexec.exe" or InitiatingProcessFolderPath endswith "\\setup.exe" or InitiatingProcessFolderPath endswith "\\install.exe" or InitiatingProcessFolderPath endswith "\\installer.exe" or InitiatingProcessFolderPath endswith "\\update.exe" or InitiatingProcessFolderPath endswith "\\updater.exe" or InitiatingProcessFolderPath endswith "\\upgrade.exe") and (FolderPath endswith "\\cmd.exe" or FolderPath endswith "\\powershell.exe" or FolderPath endswith "\\pwsh.exe" or FolderPath endswith "\\wscript.exe" or FolderPath endswith "\\cscript.exe" or FolderPath endswith "\\mshta.exe" or FolderPath endswith "\\bitsadmin.exe" or FolderPath endswith "\\certutil.exe" or FolderPath endswith "\\curl.exe" or FolderPath endswith "\\regsvr32.exe"))

Splunk · SPL

Run this as a search.

index=* ((ParentImage="*\\msiexec.exe" OR ParentImage="*\\setup.exe" OR ParentImage="*\\install.exe" OR ParentImage="*\\installer.exe" OR ParentImage="*\\update.exe" OR ParentImage="*\\updater.exe" OR ParentImage="*\\upgrade.exe") AND (Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\bitsadmin.exe" OR Image="*\\certutil.exe" OR Image="*\\curl.exe" OR Image="*\\regsvr32.exe"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.parent.executable) LIKE "*\\\\msiexec.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\setup.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\install.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\installer.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\update.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\updater.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\upgrade.exe") AND (TO_LOWER(process.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.executable) LIKE "*\\\\powershell.exe" OR TO_LOWER(process.executable) LIKE "*\\\\pwsh.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 "*\\\\bitsadmin.exe" OR TO_LOWER(process.executable) LIKE "*\\\\certutil.exe" OR TO_LOWER(process.executable) LIKE "*\\\\curl.exe" OR TO_LOWER(process.executable) LIKE "*\\\\regsvr32.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="ParentImage" type="pcre2">(?i)(\\msiexec\.exe$|\\setup\.exe$|\\install\.exe$|\\installer\.exe$|\\update\.exe$|\\updater\.exe$|\\upgrade\.exe$)</field>    <field name="Image" type="pcre2">(?i)(\\cmd\.exe$|\\powershell\.exe$|\\pwsh\.exe$|\\wscript\.exe$|\\cscript\.exe$|\\mshta\.exe$|\\bitsadmin\.exe$|\\certutil\.exe$|\\curl\.exe$|\\regsvr32\.exe$)</field>    <description>Installer or updater process spawning a shell, script host or downloader</description>    <mitre>      <id>T1195.002</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: trusted_software_tampering
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 3 Sept 2026
Rule ID: ffc1e08b-50bf-400e-87b1-dca3bfb6800b

ATT&CKT1195.002

T1195.002Compromise Software Supply Chain

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.

Lessontrusted software tampering

trusted software tampering

01 · What this rule detects

The software supply and servicing chain used as the delivery vehicle: a package manager's lifecycle hook spawning a script host or downloader, an installer or updater spawning a shell, or an executable landing in a protected program directory from a writer that is not the servicing stack.

02 · Telemetry you need

Process creation with parent image and full command lines — the parent-child pair is the observable
File creation events under the system and Program Files trees (Sysmon Event ID 11), with the writing image
Code-signing and publisher information, resolved downstream — the discriminator MITRE's own analytic names, and one no process or file event carries
Egress logs against the approved update endpoints, for the beacon that follows a compromised component's first run

03 · How the logic works

Three stages of one story. At dependency-install time: a package manager — node, python, pip, dotnet, choco, cargo, or cmd.exe running an npm/yarn shim — spawning PowerShell, a script host or a download utility is a lifecycle hook doing something hooks legitimately do and attackers do identically. At software-install time: msiexec, setup, install or an updater spawning a shell, script host or downloader. At rest: an .exe, .dll, .sys or .ocx created under System32, SysWOW64 or the Program Files trees by a writer outside the Windows servicing set (TrustedInstaller, TiWorker, msiexec, wusa and the antimalware updaters). Read all three as hunt-grade rather than alert-grade, and be honest about why: the dominant real-world form of a supply-chain compromise never creates a process at all — the payload is compiled into the signed vendor binary, and the discriminators that matter are the publisher's signature and the destination of the first beacon, neither of which these events carry.

04 · Common false positives

Chocolatey doing its job: every package it installs or upgrades runs its install script through PowerShell, so the pair fires on every choco upgrade all across the estate
MSI custom actions and installer frameworks (Inno, NSIS, InstallShield) shelling out to cmd or PowerShell for service registration and post-install cleanup — the dominant installer-child match, and legitimate for most vendors
Application self-updaters overwriting their own binaries under Program Files on every release — browsers, conferencing clients, runtimes — a continuous fleet-wide stream on the file-write arm
Native-module builds on developer machines and CI: node-gyp, dotnet and gradle routinely shell out to locate toolchains and unpack archives, matching on every dependency restore

05 · Detection maturity

Tier 1 — starting point: Matches the parent-child pairs and protected-path writes fleet-wide, with only the Windows servicing writers excluded.
Tier 2 — tuned: Separates developer and CI hosts from the general fleet, suppresses known packages by child command line, and narrows the write arm to the system directories.
Tier 3 — correlated: Joins the chain end to end — install, unexpected child, protected write, first egress — and resolves publisher signatures so an unsigned or newly-signed writer in a vendor's directory outranks everything else.

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

Suppress package-manager matches by the package and script path carried in the child's command line, package by package — the parent-child pair alone cannot be separated from abuse
On the file-write arm, dropping the two Program Files prefixes and keeping only System32 and SysWOW64 raises precision sharply; put the difference into a hunt query instead of an alert
Alert louder when the spawned child itself egresses — curl, certutil, bitsadmin — than on a bare cmd.exe: post-install cleanup rarely needs the network
Baseline developer endpoints and CI agents separately from the general fleet; the same pair that is noise on a build agent is signal on a finance workstation

Declared by the author

MSI custom actions, which routinely shell out to cmd.exe or PowerShell to register services, patch configuration files or run post-install checks. This is the dominant match by a wide margin and it is legitimate for most vendors — the separation is which publisher signed the parent, which is MITRE's ApprovedSigners knob and not a field this log source carries. It is why the level here is low.
Third-party installer frameworks — Inno Setup, NSIS, InstallShield — whose setup.exe runs cmd /c for post-install cleanup, service registration or PATH edits. On developer and end-user workstations this is the single commonest instance of this exact parent-child pair.
Enterprise software deployment (SCCM, Intune, Chocolatey, WinGet) whose packages wrap the vendor installer in a PowerShell or batch wrapper, so the parent-child pair appears on every managed host during a rollout wave.
Application self-updaters — Squirrel-packaged apps run theirs as Update.exe — invoking cmd.exe to move files or clean up old versions on each release.
Driver and runtime redistributables that call certutil to verify a hash or install a certificate as part of a supported install sequence.

Noise checkfires on 2 of 30

Fires on 2 of 30 ordinary behaviours the baseline holds for this log type. Each is something a managed estate does on purpose, so each is a false positive an analyst would have to close.

pc-regsvr32-install
An installer registering a COM component. regsvr32 is flagged constantly and is also how software installs itself.
pc-bitsadmin-updater
A vendor updater transferring a package over BITS, which is what BITS is for.

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
0 true · 2 false · 100.0% noise

Test it yourselfin your browser

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

Recordings of T1195.002, evaluated against their process_creation events.

Share this rule

/u/siemphony/ffc1e08b-50bf-400e-87b1-dca3bfb6800b

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.

Installer or updater process spawning a shell, script host or downloader

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it