Common system utility name executed from a non-standard directory

Siemphony@siemphonymediumT1574.008unverifiedPlaybook · Persistence established

Search order hijacking works because some launcher calls a utility by name rather than full path, so the OS resolves it from whatever directory it finds first — AN1560 frames this as a binary named after a legitimate system utility running from a non-standard or application-specific directory. This rule catches only that half: a process whose Image ends in one of a small set of frequently-hijacked utility names, launched from outside the directories Windows and mainstream installers actually keep them in. AN1560 also asks for a correlated file-write (Sysmon EID 11/15) that placed the planted binary and for parent-lineage deviation from a baseline; neither is attempted here, because joining a file_event to a later process_creation event on a shared path and time window is a cross-event correlation lib/sigma cannot express, and "deviates from ParentProcessBaseline" needs a per-environment baseline this corpus has no source for. MITRE's SuspiciousBinaryList knob is populated here with net.exe, net1.exe, findstr.exe, cmd.exe and python.exe — utilities commonly invoked without a full path by other programs — and MonitoredDirectories becomes its inverse: an allowlist of System32, SysWOW64 and the two Program Files roots. A binary under either of those five listed names running from anywhere else, such as a user profile, a temp folder or an unrelated application directory, is what this rule flags; it says nothing about why the file got there. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0564, 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

1title: Common system utility name executed from a non-standard directory2id: 0ee1d7d9-b266-48dd-be5c-9fbd261d33c93status: experimental4description: |5  Search order hijacking works because some launcher calls a utility by name6  rather than full path, so the OS resolves it from whatever directory it finds7  first — AN1560 frames this as a binary named after a legitimate system8  utility running from a non-standard or application-specific directory. This9  rule catches only that half: a process whose Image ends in one of a small10  set of frequently-hijacked utility names, launched from outside the11  directories Windows and mainstream installers actually keep them in. AN156012  also asks for a correlated file-write (Sysmon EID 11/15) that placed the13  planted binary and for parent-lineage deviation from a baseline; neither is14  attempted here, because joining a file_event to a later process_creation15  event on a shared path and time window is a cross-event correlation16  lib/sigma cannot express, and "deviates from ParentProcessBaseline" needs a17  per-environment baseline this corpus has no source for. MITRE's18  SuspiciousBinaryList knob is populated here with net.exe, net1.exe,19  findstr.exe, cmd.exe and python.exe — utilities commonly invoked without a20  full path by other programs — and MonitoredDirectories becomes its inverse:21  an allowlist of System32, SysWOW64 and the two Program Files roots. A binary22  under either of those five listed names running from anywhere else, such as23  a user profile, a temp folder or an unrelated application directory, is what24  this rule flags; it says nothing about why the file got there.25  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0564, not hand-written and not tested by its author. Any lab result is on this rule's own page.26references:27  - https://attack.mitre.org/techniques/T1574/00828  - https://attack.mitre.org/detectionstrategies/DET056429author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)30date: 2026-08-1731tags:32  - attack.defense-evasion33  - attack.execution34  - attack.t1574.00835logsource:36  category: process_creation37  product: windows38detection:39  selection_binary:40    Image|endswith:41      - '\net.exe'42      - '\net1.exe'43      - '\findstr.exe'44      - '\cmd.exe'45      - '\python.exe'46  filter_legit_dir:47    Image|startswith:48      - 'C:\Windows\System32\'49      - 'C:\Windows\SysWOW64\'50      - 'C:\Program Files\'51      - 'C:\Program Files (x86)\'52  condition: selection_binary and not filter_legit_dir53falsepositives:54  - "Portable or vendor-bundled copies of net.exe, findstr.exe or python.exe shipped inside an application's own install directory — backup agents, RMM tools and embedded Python runtimes routinely keep a private copy of these names outside System32 and Program Files."55  - "Developers or CI runners launching a per-project python.exe from a virtual environment or a user-profile toolchain path such as AppData\\Local\\Programs\\Python instead of an approved Program Files install."56level: medium

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where ((FolderPath endswith "\\net.exe" or FolderPath endswith "\\net1.exe" or FolderPath endswith "\\findstr.exe" or FolderPath endswith "\\cmd.exe" or FolderPath endswith "\\python.exe") and not ((FolderPath startswith "C:\\Windows\\System32\\" or FolderPath startswith "C:\\Windows\\SysWOW64\\" or FolderPath startswith "C:\\Program Files\\" or FolderPath startswith "C:\\Program Files (x86)\\")))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\net.exe" OR Image="*\\net1.exe" OR Image="*\\findstr.exe" OR Image="*\\cmd.exe" OR Image="*\\python.exe") AND NOT ((Image="C:\\Windows\\System32\\*" OR Image="C:\\Windows\\SysWOW64\\*" OR Image="C:\\Program Files\\*" OR Image="C:\\Program Files (x86)\\*")))

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 "*\\\\findstr.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.executable) LIKE "*\\\\python.exe") AND NOT ((TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\system32\\\\*" OR TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\syswow64\\\\*" OR TO_LOWER(process.executable) LIKE "c:\\\\program files\\\\*" OR TO_LOWER(process.executable) LIKE "c:\\\\program files (x86)\\\\*")))

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$|\\findstr\.exe$|\\cmd\.exe$|\\python\.exe$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(^C:\\Windows\\System32\\|^C:\\Windows\\SysWOW64\\|^C:\\Program Files\\|^C:\\Program Files \(x86\)\\)</field>    <description>Common system utility name executed from a non-standard directory</description>    <mitre>      <id>T1574.008</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: 0ee1d7d9-b266-48dd-be5c-9fbd261d33c9

ATT&CKT1574.008

T1574.008Path Interception by Search Order Hijacking

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.

Evidence

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

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.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1574.008, evaluated against their process_creation events.

Using it

Tuning & false positivesexperimental · 2 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

The five-name list and the four-directory allowlist are both this pipeline's own values, not something copied from a MITRE-supplied enumeration — the brief names the knobs (SuspiciousBinaryList, MonitoredDirectories) but does not populate them, so treat both lists as starting points to expand or narrow for your environment. If your org standardizes Python installs under a specific approved path (a company-wide venv root, for example), add it to filter_legit_dir rather than accepting matches from every user profile. Conversely, if cmd.exe from non-standard locations is rare in your environment and net.exe/net1.exe account for most of the noise, consider splitting them into separate rules with different level values so the higher-signal binaries aren't drowned by the noisier ones. Adding the missing file-write correlation, even as a manual pivot rather than automated logic, would meaningfully cut false positives by confirming the binary was actually planted rather than legitimately installed.

Declared by the author

Portable or vendor-bundled copies of net.exe, findstr.exe or python.exe shipped inside an application's own install directory — backup agents, RMM tools and embedded Python runtimes routinely keep a private copy of these names outside System32 and Program Files.
Developers or CI runners launching a per-project python.exe from a virtual environment or a user-profile toolchain path such as AppData\Local\Programs\Python instead of an approved Program Files install.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

Search order hijacking works when a launcher calls a utility by bare name and the OS resolves it from whatever directory it searches first — if an attacker can plant a same-named binary somewhere earlier in that search path, it runs instead of the real one. This rule catches one narrow signal of that: a process image whose filename matches one of five commonly-hijacked system utility names, running from a directory outside the ones Windows and mainstream installers actually keep them in.

02 · Telemetry you need

Sysmon EventID 1 (process_creation, product windows), specifically the Image field. No command-line parsing, hashing or parent-lineage logic is used — just where the binary lives on disk when it launches.

03 · How the logic works

selection_binary matches Image|endswith against five names: net.exe, net1.exe, findstr.exe, cmd.exe and python.exe — MITRE's SuspiciousBinaryList knob, populated here with utilities frequently invoked without a full path by other programs. filter_legit_dir is the inverse of MITRE's MonitoredDirectories knob: an allowlist of C:\Windows\System32\, C:\Windows\SysWOW64\, C:\Program Files\ and C:\Program Files (x86)\, matched with Image|startswith. The condition is selection_binary and not filter_legit_dir — any of those five names launching from anywhere outside those four roots fires. A copy of python.exe in a temp folder or a user profile trips it; the same binary in Program Files\Python311\ does not.

04 · Common false positives

AN1560, the analytic this rule scaffolds, actually asks for two more things: a correlated file-write event (Sysmon EID 11/15) showing the planted binary landing on disk, and parent-lineage deviation from a per-environment baseline. Neither is attempted here — joining a file_event to a later process_creation event on shared path and time window is a cross-event correlation lib/sigma cannot express, and "deviates from ParentProcessBaseline" needs a baseline this pipeline has no source for. So the rule is a coarse proxy for half of what MITRE describes, and it will fire on legitimate causes as often as malicious ones: portable or vendor-bundled copies of net.exe, findstr.exe or python.exe shipped inside an application's own install directory are routine for backup agents, RMM tools and embedded Python runtimes. Developers and CI runners launching a per-project python.exe from a virtualenv or a user-profile toolchain path (AppData\Local\Programs\Python, for instance) will also match, since that path sits outside the allowlist entirely.

05 · Detection maturity

tier_1: This rule has never been run against a log line and sits at the lowest DeBMM maturity tier by definition — an authored scaffold, not a validated detection. It should be treated as a starting point for a human analyst to test against real EID 1 data, tune the two lists against actual environment inventory, and only then consider promoting past experimental status.

Related detections6 nearby

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/0ee1d7d9-b266-48dd-be5c-9fbd261d33c9

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.

Common system utility name executed from a non-standard directory

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it