Application binary rewritten outside a package installer

Siemphony@siemphonymediumT1565.003unverified

Matches an executable or DLL under Program Files being created or overwritten by a process other than a recognised installer or servicing component — the file-write half of AN1097's "application binaries used to display data" behaviour. AN1097 also asks for API-hooking detection and hash-baseline comparison, but neither produces a discrete Sigma-expressible event, so only the write itself is captured. This is deliberately not the parent T1565's shape, which watches a *data* file (database, ledger) written by a script host; T1565.003 targets the rendering application's own binary, which is what separates Runtime from Stored Data Manipulation. Written in the Sysmon EventID 11 vocabulary (`TargetFilename`, `Image`) rather than AN1097's Security EventID 4657 or Sysmon EventID 15 alternatives, which carry the same fact through different fields this rule does not map. MITRE's `MonitoredPaths` knob is approximated here as Program Files; the installer allowlist is authored, not sourced, and MITRE's `HashBaseline` knob — a binary-integrity comparison — has no Sigma equivalent, so a match means "written by an unexpected process," not "content diverged from baseline." UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0391, 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.

DeviceFileEvents| where (((FolderPath contains "\\Program Files\\" or FolderPath contains "\\Program Files (x86)\\") and (FolderPath endswith ".exe" or FolderPath endswith ".dll")) and not ((InitiatingProcessFolderPath endswith "\\msiexec.exe" or InitiatingProcessFolderPath endswith "\\TrustedInstaller.exe" or InitiatingProcessFolderPath endswith "\\TiWorker.exe" or InitiatingProcessFolderPath endswith "\\wusa.exe" or InitiatingProcessFolderPath endswith "\\setup.exe")))

Splunk · SPL

Run this as a search.

index=* (((TargetFilename="*\\Program Files\\*" OR TargetFilename="*\\Program Files (x86)\\*") AND (TargetFilename="*.exe" OR TargetFilename="*.dll")) AND NOT ((Image="*\\msiexec.exe" OR Image="*\\TrustedInstaller.exe" OR Image="*\\TiWorker.exe" OR Image="*\\wusa.exe" OR Image="*\\setup.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((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")) AND NOT ((TO_LOWER(process.executable) LIKE "*\\\\msiexec.exe" OR TO_LOWER(process.executable) LIKE "*\\\\trustedinstaller.exe" OR TO_LOWER(process.executable) LIKE "*\\\\tiworker.exe" OR TO_LOWER(process.executable) LIKE "*\\\\wusa.exe" OR TO_LOWER(process.executable) LIKE "*\\\\setup.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="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetFilename" type="pcre2">(?i)(\\Program Files\\|\\Program Files \(x86\)\\)</field>    <field name="TargetFilename" type="pcre2">(?i)(\.exe$|\.dll$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(\\msiexec\.exe$|\\TrustedInstaller\.exe$|\\TiWorker\.exe$|\\wusa\.exe$|\\setup\.exe$)</field>    <description>Application binary rewritten outside a package installer</description>    <mitre>      <id>T1565.003</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: medium
Category: impact_destruction
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 74b647ec-ac81-4f91-8282-edba7e738037

ATT&CKT1565.003

T1565.003Runtime Data Manipulation

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.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

AN1097 describes three signals: application-binary modification, API hooking, and hash-baseline mismatches, correlated with registry edits and process creation. This rule captures one piece of that — a Sysmon EventID 11 write or overwrite of an .exe/.dll under Program Files, by a process other than a recognized installer. It's the write-instant precursor to "a rendering binary was manipulated," not proof manipulation occurred. The scope is deliberately narrow: T1565.003 targets the rendering application's own binary, distinct from the parent T1565, which watches a data file (database, ledger) written by a script host.

02 · Telemetry you need

Sysmon EventID 11 (file_event/windows), keyed on TargetFilename and Image. AN1097 also offers Security EventID 4657 (registry_set) or Sysmon EventID 15 as alternates carrying the same underlying fact, but this rule stays in the file_event vocabulary because that's what actually captures a binary write — those alternates carry it through different fields this rule doesn't map. Three of translations.json's four backends render this cleanly (Splunk, Elastic ESQL, Wazuh); Sentinel refuses outright because it has no table modeled for file_event/windows — a genuine coverage gap, not a rule defect.

03 · How the logic works

selection_binary ANDs two contains terms on TargetFilename (\Program Files\, \Program Files (x86)\) with two endswith terms (.exe, .dll). filter_installers excludes writes where Image ends with one of five installer/servicing binaries: msiexec.exe, TrustedInstaller.exe, TiWorker.exe, wusa.exe, setup.exe. The condition, selection_binary and not filter_installers, is a single-field negation — why Wazuh's translation stays a clean negated pcre2 field. MITRE's MonitoredPaths knob is approximated here as the two Program Files fragments — an authored choice, not MITRE's. MITRE's HashBaseline knob (binary-integrity comparison) has no Sigma equivalent at all, so a match means "written by an unexpected process," never "content diverged from a known-good baseline."

04 · Common false positives

The rule names its own top offender: self-updating browsers, chat clients, and update agents rewriting their own .exe/.dll under Program Files outside msiexec.exe, described as "the highest-volume match on any actively used workstation." That self-admission is the central tuning lesson — level is set to medium, technically clearing the bar for demotion, but a self-described dominant, near-universal false positive is arguably better calibrated at low. Behind it: SCCM/Intune/RMM agents pushing binary updates through custom updaters, and AV/EDR engines overwriting their own DLLs on a signature-update schedule.

05 · Detection maturity

tier_1: .** Machine-derived from a MITRE scaffold and never executed against real telemetry. The self-flagged FP dominance and the per-user-path blind spot were both found by static review, not observed hit volume — treat neither as a real-world noise or coverage estimate until this runs read-only against actual endpoint activity.

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

Reconsider level: drop to low to match the rule's own admission that
Close the coverage gap the review flagged: selection_binary only fires
Treat any write outside the two hardcoded path fragments as invisible

Declared by the author

Self-updating applications (browsers, chat clients, update agents) that rewrite their own .exe or .dll under Program Files outside of msiexec.exe — the highest-volume match on any actively used workstation.
Enterprise patch and software-distribution agents (SCCM, Intune management extension, third-party RMM) that push binary updates through a custom updater process rather than msiexec.exe.
Antivirus and EDR engine or signature updates that overwrite DLLs inside their own Program Files installation directory 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 T1565.003, evaluated against their file_event events.

Share this rule

/u/siemphony/74b647ec-ac81-4f91-8282-edba7e738037

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.

Application binary rewritten outside a package installer

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it