System tool name executed from outside its expected system directory

Siemphony@siemphonymediumT1574.007unverified

Matches the Windows leg of AN0009: a Sysmon process creation whose `Image` file name matches a fixed system tool but whose path is not System32, SysWOW64 or WinSxS. That name-plus-location mismatch is the payoff of PATH hijacking — an earlier entry in the PATH environment variable resolves to an attacker's binary of the same name before the real one is ever reached, so the process that actually launches carries the right file name and the wrong path. `net.exe` and `powershell.exe` are MITRE's own SuspiciousBinaryList examples; `net1.exe`, `ipconfig.exe`, `whoami.exe`, `systeminfo.exe`, `tasklist.exe`, `netstat.exe`, `reg.exe`, `sc.exe`, `schtasks.exe` and `cmd.exe` are added here as tools that, like `net.exe`, ship from a single fixed OS location and are common targets for exactly this hijack. MITRE's other named example, `python.exe`, is deliberately excluded: Windows does not ship Python, so there is no fixed system directory to filter against, and without that anchor the selection would reduce to "any python.exe launch" with no location discriminator at all — the same test this rule relies on for every other entry. This rule sees only the effect (the wrong binary ran under the right name); it cannot see the cause, a PATH environment variable or registry PATH key that puts a writable directory ahead of System32, so it says nothing about how the directory got there. Requires Sysmon with process creation logging enabled; this is not native Windows telemetry and is absent without the Sysmon driver installed and configured to capture EventID 1. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0004, 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.

DeviceProcessEvents| where ((FolderPath endswith "\\net.exe" or FolderPath endswith "\\net1.exe" or FolderPath endswith "\\ipconfig.exe" or FolderPath endswith "\\whoami.exe" or FolderPath endswith "\\systeminfo.exe" or FolderPath endswith "\\tasklist.exe" or FolderPath endswith "\\netstat.exe" or FolderPath endswith "\\reg.exe" or FolderPath endswith "\\sc.exe" or FolderPath endswith "\\schtasks.exe" or FolderPath endswith "\\cmd.exe" or FolderPath endswith "\\powershell.exe") and not ((FolderPath contains ":\\Windows\\System32\\" or FolderPath contains ":\\Windows\\SysWOW64\\" or FolderPath contains ":\\Windows\\WinSxS\\")))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\net.exe" OR Image="*\\net1.exe" OR Image="*\\ipconfig.exe" OR Image="*\\whoami.exe" OR Image="*\\systeminfo.exe" OR Image="*\\tasklist.exe" OR Image="*\\netstat.exe" OR Image="*\\reg.exe" OR Image="*\\sc.exe" OR Image="*\\schtasks.exe" OR Image="*\\cmd.exe" OR Image="*\\powershell.exe") AND NOT ((Image="*:\\Windows\\System32\\*" OR Image="*:\\Windows\\SysWOW64\\*" OR Image="*:\\Windows\\WinSxS\\*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*\\\\net.exe" OR TO_LOWER(process.executable) LIKE "*\\\\net1.exe" OR TO_LOWER(process.executable) LIKE "*\\\\ipconfig.exe" OR TO_LOWER(process.executable) LIKE "*\\\\whoami.exe" OR TO_LOWER(process.executable) LIKE "*\\\\systeminfo.exe" OR TO_LOWER(process.executable) LIKE "*\\\\tasklist.exe" OR TO_LOWER(process.executable) LIKE "*\\\\netstat.exe" OR TO_LOWER(process.executable) LIKE "*\\\\reg.exe" OR TO_LOWER(process.executable) LIKE "*\\\\sc.exe" OR TO_LOWER(process.executable) LIKE "*\\\\schtasks.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.executable) LIKE "*\\\\powershell.exe") AND NOT ((TO_LOWER(process.executable) LIKE "*:\\\\windows\\\\system32\\\\*" OR TO_LOWER(process.executable) LIKE "*:\\\\windows\\\\syswow64\\\\*" OR TO_LOWER(process.executable) LIKE "*:\\\\windows\\\\winsxs\\\\*")))

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="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\net\.exe$|\\net1\.exe$|\\ipconfig\.exe$|\\whoami\.exe$|\\systeminfo\.exe$|\\tasklist\.exe$|\\netstat\.exe$|\\reg\.exe$|\\sc\.exe$|\\schtasks\.exe$|\\cmd\.exe$|\\powershell\.exe$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(:\\Windows\\System32\\|:\\Windows\\SysWOW64\\|:\\Windows\\WinSxS\\)</field>    <description>System tool name executed from outside its expected system directory</description>    <mitre>      <id>T1574.007</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 41bf002c-6463-4f7d-83f4-bb06c9a053c3

ATT&CKT1574.007

T1574.007Path Interception by PATH Environment Variable

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

This rule matches the Windows leg of AN0009 in MITRE's PATH Interception detection strategy (DET0004): a Sysmon process creation whose Image file name matches a fixed system tool but whose path is not System32, SysWOW64 or WinSxS. That name-plus-location mismatch is the payoff of PATH hijacking — a directory placed earlier in the PATH environment variable resolves to an attacker's binary of the same name before the real one is reached, so the process that launches carries the right file name and the wrong path.

02 · Telemetry you need

Sysmon EventID 1 (process creation) on Windows, which is not native Windows telemetry and requires the Sysmon driver installed and configured. AN0009 also names Security 4657 (registry key modification) and Sysmon 11 (file creation) as log sources for correlating a PATH change with the subsequent execution; neither is used here, so this rule only implements the execution-side observable, not the modification-side one.

03 · How the logic works

selection_system_tool_name matches Image ending in one of twelve tool names: net.exe and powershell.exe are MITRE's own SuspiciousBinaryList examples; net1.exe, ipconfig.exe, whoami.exe, systeminfo.exe, tasklist.exe, netstat.exe, reg.exe, sc.exe, schtasks.exe and cmd.exe are added here as tools that, like net.exe, ship from a single fixed OS location and are common hijack targets. MITRE's other named example, python.exe, is deliberately excluded: Windows does not ship Python, so there is no fixed system directory to filter against, and without that anchor the selection would collapse to "any python.exe launch" with no location discriminator — the same test every other entry relies on. filter_system_paths excludes any Image containing System32\, SysWOW64\ or WinSxS\. The condition is selection_system_tool_name and not filter_system_paths.

04 · Common false positives

Deployment and packaging tools that bundle a private helper copy of a common-named utility such as reg.exe or sc.exe inside their own Program Files install directory, for use during setup or repair, are indistinguishable from a hijack by this logic alone. Portable IT and helpdesk toolkits carried on removable media or a network share — a technician running whoami.exe, ipconfig.exe, netstat.exe or systeminfo.exe from a USB drive for offline triage — will match. Backup, recovery and security-vendor agents that ship a private signed copy of cmd.exe or reg.exe under their own install directory are the third source. More fundamentally: this signal alone is not diagnostic of PATH interception specifically. It fires identically whether the binary was reached by an unqualified command resolving through a hijacked PATH, or simply double-clicked or launched by full path from an arbitrary folder — every alert it raises is at least as well explained by Masquerading (T1036.005) as by PATH hijacking, since the rule carries zero PATH-specific evidence.

05 · Detection maturity

tier_1: This rule has never been run against a log line. It sits at the lowest DeBMM maturity tier — authored, unexecuted, unvalidated — until it is run against real Sysmon data, its overlap with Masquerading alerts is measured against a live estate, and a correlating rule on the PATH registry keys is built alongside it.

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

MITRE's SuspiciousBinaryList knob is populated here with the twelve names above; an estate can trim or extend that list against its own baseline of legitimately bundled tools. This rule does not implement MITRE's MonitoredRegistryKeys knob at all — pairing this rule's output with a separate one against Security 4657 on the PATH-related registry keys would supply the correlating evidence that turns "wrong-path binary ran" into "PATH was actually hijacked," which lib/sigma cannot express as a single rule's condition. Until that pairing exists, treat every alert as Masquerading-or-PATH-hijack, not PATH-hijack specifically.

Declared by the author

Deployment and packaging tools that bundle a private helper copy of a common-named utility such as reg.exe or sc.exe inside their own Program Files install directory for use during setup or repair, distinct from the real system binary.
Portable IT and helpdesk toolkits carried on removable media or a network share, where a technician runs whoami.exe, ipconfig.exe, netstat.exe or systeminfo.exe directly from a USB drive or file share for offline triage.
Backup, recovery and security-vendor agents that ship a private signed copy of cmd.exe or reg.exe under their own install directory for use inside a recovery environment or repair mode.

Noise check0 of 30 fired

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

Share this rule

/u/siemphony/41bf002c-6463-4f7d-83f4-bb06c9a053c3

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.

System tool name executed from outside its expected system directory

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it