Executable written into a protected program directory

Siemphony@siemphonylowT1554unverified

Matches the binary-modification half of AN0949: a file create or overwrite of an .exe, .dll, .sys or .ocx underneath the system directories or the Program Files trees, by a writer that is not part of the Windows servicing or antimalware update path. The rule is written in the Sysmon-shaped `file_event` vocabulary (`TargetFilename`, `Image`); the brief also lists Security 4688 for the execution half of the same analytic, which is a different feed with a different field set and is not authored here. Path terms use `contains` rather than `startswith` so the rule is not pinned to the C: drive. Three limits worth stating: Sysmon EventID 11 fires on create and overwrite, so patching an existing binary in place — IAT hooking or an entry-point patch — may produce no event at all; the excluded-writer list includes msiexec.exe because it is the loudest legitimate writer, which also removes MSI-delivered tampering from view; and the correlation MITRE describes, a write followed by execution of an anomalously signed image inside the `TimeWindow` knob, needs both a join and a signature attribute that Sigma has neither of. Sysmon file-create logging is scoped entirely by your Sysmon configuration, and the common public configs filter most writes under System32 — confirm .exe and .dll creation in these paths is included before reading silence as clean. UNVERIFIED — derived from MITRE ATT&CK DET0336 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.

DeviceFileEvents| where (((FolderPath contains "\\Windows\\System32\\" or FolderPath contains "\\Windows\\SysWOW64\\" or FolderPath contains "\\Program Files\\" or FolderPath contains "\\Program Files (x86)\\") and (FolderPath endswith ".exe" or FolderPath endswith ".dll" or FolderPath endswith ".sys" or FolderPath endswith ".ocx")) and not ((InitiatingProcessFolderPath endswith "\\TiWorker.exe" or InitiatingProcessFolderPath endswith "\\TrustedInstaller.exe" or InitiatingProcessFolderPath endswith "\\poqexec.exe" or InitiatingProcessFolderPath endswith "\\msiexec.exe" or InitiatingProcessFolderPath endswith "\\wusa.exe" or InitiatingProcessFolderPath endswith "\\MsMpEng.exe" or InitiatingProcessFolderPath endswith "\\MpSigStub.exe")))

Splunk · SPL

Run this as a search.

index=* (((TargetFilename="*\\Windows\\System32\\*" OR TargetFilename="*\\Windows\\SysWOW64\\*" OR TargetFilename="*\\Program Files\\*" OR TargetFilename="*\\Program Files (x86)\\*") AND (TargetFilename="*.exe" OR TargetFilename="*.dll" OR TargetFilename="*.sys" OR TargetFilename="*.ocx")) AND NOT ((Image="*\\TiWorker.exe" OR Image="*\\TrustedInstaller.exe" OR Image="*\\poqexec.exe" OR Image="*\\msiexec.exe" OR Image="*\\wusa.exe" OR Image="*\\MsMpEng.exe" OR Image="*\\MpSigStub.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(file.path) LIKE "*\\\\windows\\\\system32\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\windows\\\\syswow64\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\program files\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\program files (x86)\\\\*") AND (TO_LOWER(file.path) LIKE "*.exe" OR TO_LOWER(file.path) LIKE "*.dll" OR TO_LOWER(file.path) LIKE "*.sys" OR TO_LOWER(file.path) LIKE "*.ocx")) AND NOT ((TO_LOWER(process.executable) LIKE "*\\\\tiworker.exe" OR TO_LOWER(process.executable) LIKE "*\\\\trustedinstaller.exe" OR TO_LOWER(process.executable) LIKE "*\\\\poqexec.exe" OR TO_LOWER(process.executable) LIKE "*\\\\msiexec.exe" OR TO_LOWER(process.executable) LIKE "*\\\\wusa.exe" OR TO_LOWER(process.executable) LIKE "*\\\\msmpeng.exe" OR TO_LOWER(process.executable) LIKE "*\\\\mpsigstub.exe")))

Wazuh · XML rule

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

<group name="sigma,windows,file_event,">  <!-- 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="TargetFilename" type="pcre2">(?i)(\\Windows\\System32\\|\\Windows\\SysWOW64\\|\\Program Files\\|\\Program Files \(x86\)\\)</field>    <field name="TargetFilename" type="pcre2">(?i)(\.exe$|\.dll$|\.sys$|\.ocx$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(\\TiWorker\.exe$|\\TrustedInstaller\.exe$|\\poqexec\.exe$|\\msiexec\.exe$|\\wusa\.exe$|\\MsMpEng\.exe$|\\MpSigStub\.exe$)</field>    <description>Executable written into a protected program directory</description>    <mitre>      <id>T1554</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: low
Category: trusted_software_tampering
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 3 Sept 2026
Rule ID: 393c050a-eab2-4223-909d-257aea69ea24

ATT&CKT1554

T1554Compromise Host Software Binary

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 tamperingAI draft — unreviewed

01 · What this rule detects

AN0949 asks for unexpected modification of system or application binaries, correlated with subsequent unsigned or anomalously signed execution. This rule implements the write half only: a Sysmon file-create event for an .exe, .dll, .sys or .ocx underneath System32, SysWOW64 or either Program Files tree, by a process that is not on a short list of Windows servicing and antimalware writers. Understand the scope honestly. This is a superset gate: it detects executable writes into protected trees, of which replacing an existing host binary — the technique it is filed under — is one case. Nothing in the logic separates an overwrite of a binary that was already there from a first-time drop, so many true positives will be generic payload staging. Meanwhile the technique's own hallmark, IAT hooking or an entry-point patch applied to a binary opened for write rather than recreated, may produce no EventID 11 at all.

02 · Telemetry you need

category: file_event / product: windows, copied from AN0949's first log source. Coverage is bounded entirely by your Sysmon configuration, and the widely used public configs filter most writes under System32 — confirm .exe and .dll creation in these paths is included before reading silence as clean.
The brief also lists Sysmon EventID 2 (file_change) and Security 4688 for the execution half; both are separate feeds and are not authored here.

03 · How the logic works

selection ANDs two lists on the same field. TargetFilename|contains holds four path fragments: \Windows\System32\, \Windows\SysWOW64\, \Program Files\ and \Program Files (x86)\. contains rather than startswith is deliberate — the rule is then not pinned to the C: drive. TargetFilename|endswith holds the four PE extensions. filter_servicing_writers subtracts on Image|endswith: TiWorker.exe, TrustedInstaller.exe, poqexec.exe, msiexec.exe, wusa.exe, MsMpEng.exe, MpSigStub.exe. Two consequences follow. Excluding msiexec.exe removes MSI-delivered tampering from view — the price of dropping the loudest legitimate writer. And because the exclusion matches leaf names with no path or signer constraint, a dropper copied to C:\Users\Public\msiexec.exe inherits the pass. That is a free bypass, and masquerading as a servicing binary is precisely what an actor tampering with system binaries is already doing.

04 · Common false positives

Third-party application updaters are the largest source by a wide margin: browsers, conferencing clients, PDF readers and language runtimes all write fresh .exe and .dll into their Program Files subdirectory on every release, as a continuous fleet-wide stream.
Behind them, servicing performed by writers not on the list — svchost-hosted components, and DISM or setup during a feature-on-demand, language-pack or in-place upgrade — legitimately creates binaries in System32. Non-MSI installer bootstrappers (NSIS, Inno Setup, vendor setup.exe stubs) unpack straight into Program Files without ever calling msiexec. Endpoint agents self-update and overwrite their own binaries on a schedule. And driver installation through pnputil writes .sys into System32\DriverStore and System32\drivers under service accounts nobody excluded — on server fleets running driver campaigns that is the burst you meet first. level: low is what the first entry supports.

05 · Detection maturity

tier_1: , and it stays there until it has been run against real data. It is machine-derived from a MITRE scaffold that ships no query logic and has never been executed against a log line.
tier_2: run read-only, rank hits by `Image`, and convert the top writers into path-anchored exclusions.
tier_3: ** build what MITRE actually described — the write joined to execution of an anomalously signed image inside the TimeWindow knob, plus a prior-existence or hash baseline. That baseline is the piece Sigma cannot express, and it is what would turn this superset gate into a detection of binary replacement.

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 the knob MonitoredPaths; the four values in it here are the
Re-anchor the writer exclusions by location — a \Windows\-resident group and
Add \DriverStore\ to an exclusion, or accept driver campaigns as known
MITRE's SignatureValidation knob has no Sigma expression: EventID 11 carries

Declared by the author

Third-party application updaters replacing their own binaries in place — browser, conferencing, PDF reader and language-runtime updaters all write fresh .exe and .dll into their Program Files subdirectory on every release. On a fleet this is a continuous stream and by a wide margin the largest source of matches, which is why MITRE's MonitoredPaths knob is the first thing to tighten: dropping the two Program Files prefixes and keeping only System32 and SysWOW64 raises precision sharply.
Windows servicing performed by writers other than the excluded ones, in particular svchost.exe-hosted service components and DISM or setup running during a feature-on-demand, language-pack or in-place upgrade, all of which legitimately create binaries directly in System32.
Non-MSI installer bootstrappers — setup.exe stubs, NSIS and Inno Setup packages, and vendor bundle installers — which unpack their payload straight into Program Files without ever invoking msiexec.exe.
Endpoint agents that self-update without an installer, such as EDR, backup and monitoring products that download a new build and overwrite their own .exe and .dll under Program Files on a schedule.

Noise check0 of 3 fired

Fires on none of the 3 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 3 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 T1554, evaluated against their file_event events.

Share this rule

/u/siemphony/393c050a-eab2-4223-909d-257aea69ea24

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.

Executable written into a protected program directory

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it