Non-installer process writes an executable into System32 or SysWOW64

Siemphony@siemphonymediumT1574.010unverified

AN1211 describes a service binary being overwritten because the file or its containing directory has weak permissions, then that binary running under the service's own elevated context. Sysmon EID 11 (file_event, the logsource used here) can see only the write half of that story — it has no service name, no ACL and no privilege field — so this rule is a coarse proxy: an executable or DLL created or modified under System32 or SysWOW64, the two directories that host the large majority of built-in Windows service binaries, by a process outside a short allowlist of legitimate servicing tools (Windows Installer, TrustedInstaller, the servicing worker and the standalone update installer). It cannot confirm the written file backs a registered service, and it cannot see the later execution under elevated privileges that AN1211's second half describes — that is a Sysmon EID 11-to-EID 1 join on path and time window, which lib/sigma has no construct for. MITRE's MonitoredServices and HashBaseline knobs (a specific service list and known-good hashes) are not populated at all, because neither is something this pipeline can source generically; PrivilegedAccounts becomes the filter_trusted_writer allowlist below, authored here rather than taken from MITRE. Prerequisite: this fires only where the Sysmon configuration in use actually captures EID 11 for these paths — a config that filters file events by extension or excludes system directories produces zero rows here regardless of what is happening on disk. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0436, 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 endswith ".exe" or FolderPath endswith ".dll") and (FolderPath contains "\\System32\\" or FolderPath contains "\\SysWOW64\\")) and not (((InitiatingProcessFolderPath startswith "C:\\Windows\\System32\\msiexec.exe" or InitiatingProcessFolderPath startswith "C:\\Windows\\servicing\\TrustedInstaller.exe" or InitiatingProcessFolderPath startswith "C:\\Windows\\System32\\wusa.exe") or InitiatingProcessFolderPath endswith "\\TiWorker.exe")))

Splunk · SPL

Run this as a search.

index=* (((TargetFilename="*.exe" OR TargetFilename="*.dll") AND (TargetFilename="*\\System32\\*" OR TargetFilename="*\\SysWOW64\\*")) AND NOT (((Image="C:\\Windows\\System32\\msiexec.exe*" OR Image="C:\\Windows\\servicing\\TrustedInstaller.exe*" OR Image="C:\\Windows\\System32\\wusa.exe*") OR Image="*\\TiWorker.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(file.path) LIKE "*.exe" OR TO_LOWER(file.path) LIKE "*.dll") AND (TO_LOWER(file.path) LIKE "*\\\\system32\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\syswow64\\\\*")) AND NOT (((TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\system32\\\\msiexec.exe*" OR TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\servicing\\\\trustedinstaller.exe*" OR TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\system32\\\\wusa.exe*") OR TO_LOWER(process.executable) LIKE "*\\\\tiworker.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)(\.exe$|\.dll$)</field>    <field name="TargetFilename" type="pcre2">(?i)(\\System32\\|\\SysWOW64\\)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(^C:\\Windows\\System32\\msiexec\.exe|^C:\\Windows\\servicing\\TrustedInstaller\.exe|^C:\\Windows\\System32\\wusa\.exe)</field>    <field name="Image" negate="yes" type="pcre2">(?i)\\TiWorker\.exe$</field>    <description>Non-installer process writes an executable into System32 or SysWOW64</description>    <mitre>      <id>T1574.010</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 5de03204-020d-42c2-bd23-a633c0a73376

ATT&CKT1574.010

T1574.010Services File Permissions Weakness

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.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

AN1211 describes a service binary getting overwritten because the file or its containing directory has weak permissions, and the replaced binary then running under the service's own elevated context. This rule watches only the write half of that story: an executable or DLL created or modified under System32 or SysWOW64 — the two directories that host the large majority of built-in Windows service binaries — by a process that isn't on a short allowlist of legitimate servicing tools.

02 · Telemetry you need

Sysmon EventID 11 (file_event, product windows), fields TargetFilename and Image. This is a file-write signal only; it has no service name, no ACL state and no privilege field, so it cannot confirm the written file actually backs a registered service.

03 · How the logic works

selection_target matches TargetFilename|endswith on .exe or .dll. selection_service_dir matches TargetFilename|contains on \System32\ or \SysWOW64\. The exclusion side is two filters combined with 1 of filter_trusted_writer*: filter_trusted_writer allowlists msiexec.exe, TrustedInstaller.exe and wusa.exe by full Image|startswith path, and filter_trusted_writer_tiworker matches Image|endswith: '\TiWorker.exe' separately — this split exists because TiWorker.exe actually runs from a versioned WinSxS servicing-stack subdirectory, never from System32, so a startswith path for it would silently never match. The condition is selection_target and selection_service_dir and not 1 of filter_trusted_writer*. MITRE's MonitoredServices and HashBaseline knobs — a specific service list and known-good hashes — are not populated at all, because neither is something this pipeline can source generically; PrivilegedAccounts becomes the filter_trusted_writer allowlist, authored here rather than taken from MITRE.

04 · Common false positives

The biggest source, and the one an earlier review caught as a live gap: routine Windows Update servicing. TiWorker.exe hardlinks updated components from the WinSxS store into System32 and SysWOW64 on every patch cycle, on every patched Windows host — that's now filtered by process name via the endswith check, but it remains the highest-volume legitimate writer this rule will ever see. Beyond that, non-Microsoft installers or portable deployment tools mis-packaged to drop DLLs directly into System32/SysWOW64 instead of their own Program Files directory will match, as will endpoint security, backup or RMM agents updating helper DLLs through their own vendor updater rather than through Windows Installer or servicing, and OEM or third-party signed driver installers copying support files in during hardware setup through their own setup binary rather than msiexec.

05 · Detection maturity

tier_1: This rule has never been executed against a log line and sits at the lowest DeBMM tier — an authored scaffold for a human to test, not a deployable detection. Promote it past experimental status only after confirming EID 11 coverage in a real environment and tuning the trusted-writer allowlist against actual observed traffic.

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

This rule fires only where the active Sysmon configuration actually captures EID 11 for these paths — a config that filters file events by extension or excludes system directories entirely produces zero rows here regardless of what's happening on disk, and zero rows reads as quiet when it may mean blind. Confirm EID 11 coverage for System32/SysWOW64 before trusting silence. The filter_trusted_writer allowlist is this pipeline's own, not MITRE's — extend it with your environment's actual vendor updaters (EDR agent, backup client, RMM tool) once you've confirmed which ones legitimately write there, rather than accepting their noise as signal. Because this rule can't see the file-write-to-elevated-execution join AN1211 actually asks for, treat any hit as a lead for manual correlation against a later EID 1 execution from the same path, not as a standalone verdict.

Declared by the author

Routine Windows Update or cumulative-update servicing: TiWorker.exe hardlinks updated components from the WinSxS store into System32 and SysWOW64 on every patch cycle, on every Windows host — this is filtered by process name only, since TiWorker.exe itself runs from a versioned WinSxS servicing-stack subdirectory rather than System32, so no fixed startswith path for it is reliable.
Non-Microsoft installers or portable deployment tools that are mis-packaged to drop DLLs directly into System32 or SysWOW64 instead of their own Program Files directory, writing through a process outside the msiexec/TrustedInstaller/TiWorker/wusa allowlist.
Endpoint security, backup or RMM agents that legitimately update helper DLLs placed in System32 or SysWOW64 through their own vendor updater process rather than through Windows Installer or servicing.
OEM or third-party signed driver package installers that copy .dll or support-file executables into System32 or SysWOW64 during hardware setup, run by the vendor's own setup binary rather than msiexec.

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 T1574.010, evaluated against their file_event events.

Share this rule

/u/siemphony/5de03204-020d-42c2-bd23-a633c0a73376

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.

Non-installer process writes an executable into System32 or SysWOW64

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it