T1574.008: Path Interception by Search Order Hijacking
Adversaries may execute their own malicious payloads by hijacking the search order used to load other programs. Because some programs do not call other programs using the full path, adversaries may place their own file in the directory where the calling program is located, causing the operating system to launch their malicious software at the request of the calling program.
Search order hijacking occurs when an adversary abuses the order in which Windows searches for programs that are not given a path. Unlike DLL search order hijacking, the search order differs depending on the method that is used to execute the program. [1] [2] [3] However, it is common for Windows to search in the directory of the initiating program before searching through the Windows system directory. An adversary who finds a program vulnerable to search order hijacking (i.e., a program that does not specify the path to an executable) may take advantage of this vulnerability by creating a program named after the improperly specified program and placing it within the initiating program's directory.
For example, "example.exe" runs "cmd.exe" with the command-line argument net user. An adversary may place a program called "net.exe" within the same directory as example.exe, "net.exe" will be run instead of the Windows system utility net. In addition, if an adversary places a program called "net.com" in the same directory as "net.exe", then cmd.exe /C net user will execute "net.com" instead of "net.exe" due to the order of executable extensions defined under PATHEXT. [4]
Search order hijacking is also a common practice for hijacking DLL loads and is covered in DLL.
Analyst context for executives and security teams
This Windows technique matters because a legitimate program can unintentionally run an attacker-controlled executable when it calls another program without a full path. For leaders, the business risk is not the search-order detail itself; it is that trusted software locations and weak directory permissions can become an execution path that looks like normal program behavior.
Executive priority
Prioritize this where Windows applications, administrative tools, or business-critical software run from directories that non-administrative users or service accounts can write to. The key governance question is whether the organization can prove that sensitive application directories are permissioned, audited, and protected by execution controls. This supports resilience, incident response triage, and compliance evidence because the technique depends on preventable configuration and monitoring gaps.
Technical view
ATT&CK lists this as a Windows sub-technique of Hijack Execution Flow under stealth and execution. SOC and IR teams should validate whether they can identify child processes launched from unexpected local application directories, especially when the invoked executable name overlaps with common Windows utilities and the parent process did not use a fully qualified path. Because the official ATT&CK object does not provide detection text, teams should use the related DET0564 detection strategy as a starting point and test coverage in their own environment. Review writable directories near initiating programs, executable extension behavior such as PATHEXT, and cases where process lineage makes an unusual executable path appear to be launched by trusted software.
Likely telemetry
- Windows process creation events with parent process, child image path, command line, current working directory, and user context
- File creation or modification events for executable files in application or program directories
- File and directory permission/ACL inventory for sensitive software locations
- Execution prevention or application control allow/block events
- Environment configuration evidence relevant to executable extension search behavior, such as PATHEXT
Detection direction
- Validate DET0564-style logic against local Windows process and file telemetry rather than assuming ATT&CK provides a complete analytic.
- Look for trusted parent processes launching executables from their own directory or other unexpected writable locations instead of Windows system paths.
- Correlate new or recently modified executable files with subsequent process execution from the same directory.
- Tune carefully for legitimate software updaters, portable applications, developer tools, and administrative scripts that may create or run local executables.
- Identify blind spots where endpoint logging lacks parent-child process relationships, command line capture, file-write telemetry, or directory permission context.
Mitigation priorities
- Start with M1022: restrict file and directory permissions so ordinary users and unnecessary service accounts cannot write executable content into sensitive application directories.
- Apply M1038 execution prevention so only authorized code can run, with special attention to non-standard application paths and writable directories.
- Use M1047 auditing to record and review permission changes, executable file writes, and suspicious process launches in trusted software locations.
- Require software and internal scripts to call executables using full paths where feasible, and include this in secure build or configuration review practices.
- Periodically review Windows application directories for weak ACLs and unexpected executable files, especially on systems supporting critical business operations.
Analyst notes and limits
The supplied relationships show this technique is detected by DET0564, mitigated by Restrict File and Directory Permissions, Execution Prevention, and Audit, and used by PowerSploit and Empire. Those software relationships indicate the behavior is represented in public offensive/post-exploitation tooling, but they do not by themselves prove activity in any specific environment.
Official ATT&CK detection text is not provided for this object. The take is therefore based on the official description, Windows platform scope, tactic mapping, external references, and stated relationships. Local validation is required to determine whether specific applications are vulnerable, whether directories are writable, and whether telemetry is sufficient for detection.
Path Interception by Search Order Hijacking
Adversaries may execute their own malicious payloads by hijacking the search order used to load other programs. Because some programs do not call other programs using the full path, adversaries may place their own file in the directory where the calling program is located, causing the operating system to launch their malicious software at the request of the calling program.
Search order hijacking occurs when an adversary abuses the order in which Windows searches for programs that are not given a path. Unlike DLL search order hijacking, the search order differs depending on the method that is used to execute the program. [1] [2] [3] However, it is common for Windows to search in the directory of the initiating program before searching through the Windows system directory. An adversary who finds a program vulnerable to search order hijacking (i.e., a program that does not specify the path to an executable) may take advantage of this vulnerability by creating a program named after the improperly specified program and placing it within the initiating program's directory.
For example, "example.exe" runs "cmd.exe" with the command-line argument net user. An adversary may place a program called "net.exe" within the same directory as example.exe, "net.exe" will be run instead of the Windows system utility net. In addition, if an adversary places a program called "net.com" in the same directory as "net.exe", then cmd.exe /C net user will execute "net.com" instead of "net.exe" due to the order of executable extensions defined under PATHEXT. [4]
Search order hijacking is also a common practice for hijacking DLL loads and is covered in DLL.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1574 | Hijack Execution Flow | This object subtechnique of Hijack Execution Flow. |
Groups, software, and campaigns
S0363: Empire
Empire is an open-source, cross-platform remote administration and post-exploitation framework that is publicly available on GitHub. While the tool itself is primarily written in Python, the post-exploitation agents are written in pure PowerShell for Windows and Python for Linux/macOS. Empire was one of five tools singled out by a joint report on public hacking tools being widely used by adversaries.[1][2][3]
S0194: PowerSploit
PowerSploit is an open source, offensive security framework comprised of PowerShell modules and scripts that perform a wide range of tasks related to penetration testing such as code execution, persistence, bypassing anti-virus, recon, and exfiltration. [1] [2] [3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | a091548a5ed5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Microsoft CreateProcess
Microsoft. (n.d.). CreateProcess function. Retrieved September 12, 2024.
Open source URL -
[2]
Windows NT Command Shell
Tim Hill. (2014, February 2). The Windows NT Command Shell. Retrieved December 5, 2014.
Open source URL -
[3]
Microsoft WinExec
Microsoft. (n.d.). WinExec function. Retrieved September 12, 2024.
Open source URL -
[4]
Microsoft Environment Property
Microsoft. (2011, October 24). Environment Property. Retrieved July 27, 2016.
Open source URL -
[5]
mitre-attack T1574.008Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.