System binary masquerading
A binary carrying the NAME of a Windows system executable ran from somewhere other than a real system directory.
What it detects
A binary carrying the NAME of a Windows system executable ran from somewhere other than a real system directory.
Two distinct techniques produce this, and both matter:
**Directory mocking.** Windows resolves some auto-elevating binaries by name, and a path like C:\Windows \System32\ — note the trailing space after Windows — is a DIFFERENT directory that a user can create and write to. Dropping a payload named winSAT.exe there gets it launched with an auto-elevated token. The path looks correct to a human reading a log and is not correct to the filesystem; the rule requires the exact \Windows\System32\ sequence, which the mocked path does not contain.
**Name masquerading.** A payload called svchost.exe, lsass.exe or mmc.exe sitting in \Temp\ or a user profile is trying to look ordinary in a process list. Corpus captures show …\AppData\Local\Temp\system32\mmc.exe and …\Temp\DNeruK\system32\Clipup.exe — both built a fake system32 folder so the path would read plausibly.
These names exist in exactly one or two places on a real system. Anywhere else is the finding, regardless of what the file does.
MITRE ATT&CK mapping
False positives and triage
A handful of these names appear legitimately outside System32: dism.exe ships in the Windows ADK under Program Files, mmc.exe and rundll32.exe have SysWOW64 and WinSxS copies (both allowed here), and some installers stage a signed copy under their own directory during setup.
To confirm: look at the path character by character, not at a glance — a trailing space, a double space, or a Unicode lookalike in Windows or System32 is deliberate and conclusive. Then check the signature and hash: a genuine Microsoft binary copied elsewhere is a different problem from an unsigned payload wearing the name. If the path contains a user profile, \Temp\, or \ProgramData\, treat it as malicious and find what wrote the file.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 85%. Source: rules/windows/system_binary_masquerading.yaml, licensed under the Apache License 2.0.
id: windows.defense_evasion.system_binary_masquerading
version: 1.0.0
status: stable
severity: critical
confidence: 0.85
platforms: [windows]
mitre_techniques: [T1036.005, T1548.002]
description: |
A binary carrying the NAME of a Windows system executable ran from somewhere other
than a real system directory.
Two distinct techniques produce this, and both matter:
**Directory mocking.** Windows resolves some auto-elevating binaries by name, and a
path like `C:\Windows \System32\` — note the trailing space after `Windows` — is a
DIFFERENT directory that a user can create and write to. Dropping a payload named
`winSAT.exe` there gets it launched with an auto-elevated token. The path looks
correct to a human reading a log and is not correct to the filesystem; the rule
requires the exact `\Windows\System32\` sequence, which the mocked path does not
contain.
**Name masquerading.** A payload called `svchost.exe`, `lsass.exe` or `mmc.exe`
sitting in `\Temp\` or a user profile is trying to look ordinary in a process list.
Corpus captures show `…\AppData\Local\Temp\system32\mmc.exe` and
`…\Temp\DNeruK\system32\Clipup.exe` — both built a fake `system32` folder so the
path would read plausibly.
These names exist in exactly one or two places on a real system. Anywhere else is
the finding, regardless of what the file does.
match:
process_name_any:
- svchost.exe
- lsass.exe
- services.exe
- winlogon.exe
- csrss.exe
- smss.exe
- spoolsv.exe
- conhost.exe
- dllhost.exe
- taskhostw.exe
- sihost.exe
- ctfmon.exe
- wuauclt.exe
- mmc.exe
- winsat.exe
- clipup.exe
- dism.exe
- rundll32.exe
- regsvr32.exe
- mshta.exe
- certutil.exe
- schtasks.exe
- wsmprovhost.exe
- msdtc.exe
process_path_not_contains_any:
- '\Windows\System32\'
- '\Windows\SysWOW64\'
- '\Windows\WinSxS\'
- '\Windows\servicing\'
- '\Windows\assembly\'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
A handful of these names appear legitimately outside System32: `dism.exe` ships in
the Windows ADK under `Program Files`, `mmc.exe` and `rundll32.exe` have SysWOW64
and WinSxS copies (both allowed here), and some installers stage a signed copy under
their own directory during setup.
To confirm: look at the path character by character, not at a glance — a trailing
space, a double space, or a Unicode lookalike in `Windows` or `System32` is
deliberate and conclusive. Then check the signature and hash: a genuine Microsoft
binary copied elsewhere is a different problem from an unsigned payload wearing the
name. If the path contains a user profile, `\Temp\`, or `\ProgramData\`, treat it as
malicious and find what wrote the file.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.