LiveActive security incident?Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1574.008Sub-techniqueObject v2.0Modified
Discuss defensive coverageBack to ATT&CK
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceHigh

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.
Additional 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.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
DomainIDNameRelationship / procedure
EnterpriseT1574Hijack Execution FlowThis object subtechnique of Hijack Execution Flow.
Associated objects

Groups, software, and campaigns

ToolEnterprise

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]

LinuxmacOSWindows
ToolEnterprise

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]

Windows
Relationship explorer

All related ATT&CK context

detects · Detection StrategyDET0564: Detection Strategy for Hijack Execution Flow using Path Interception by Search Order HijackingEnterprisemitigates · MitigationM1038: Execution PreventionEnterprisemitigates · MitigationM1022: Restrict File and Directory PermissionsEnterpriseuses · ToolS0363: EmpireEnterpriseuses · ToolS0194: PowerSploitEnterprisemitigates · MitigationM1047: AuditEnterprisesubtechnique of · TechniqueT1574: Hijack Execution FlowEnterprise
Mitigations

Mitigation direction

MitigationEnterprise

M1038: Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:

Application Control:

- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)

Script Blocking:

- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)

Executable Blocking:

- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.

Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.

MitigationEnterprise

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

MitigationEnterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Change history

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.

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
a091548a5ed59c12...
Imported snapshots across ATT&CK releases(1)
ReleaseBundle importedObject versionModifiedStatusRaw hash
19.12.0Current bundlea091548a5ed5…
Raw source

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.

Open mirrored raw JSONOpen MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Microsoft CreateProcess

    Microsoft. (n.d.). CreateProcess function. Retrieved September 12, 2024.

    Open source URL
  2. [2]
    Windows NT Command Shell

    Tim Hill. (2014, February 2). The Windows NT Command Shell. Retrieved December 5, 2014.

    Open source URL
  3. [3]
    Microsoft WinExec

    Microsoft. (n.d.). WinExec function. Retrieved September 12, 2024.

    Open source URL
  4. [4]
    Microsoft Environment Property

    Microsoft. (2011, October 24). Environment Property. Retrieved July 27, 2016.

    Open source URL
  5. [5]
    SANS Application Whitelisting

    Beechey, J.. (2014, November 18). Application Whitelisting: Panacea or Propaganda?. Retrieved November 18, 2014.

    Open source URL
  6. [6]
    Microsoft Windows Defender Application Control

    Gorzelany, A., Hall, J., Poggemeyer, L.. (2019, January 7). Windows Defender Application Control. Retrieved July 16, 2019.

    Open source URL
  7. [7]
    Windows Commands JPCERT

    Tomonaga, S. (2016, January 26). Windows Commands Abused by Attackers. Retrieved February 2, 2016.

    Open source URL
  8. [8]
    NSA MS AppLocker

    NSA Information Assurance Directorate. (2014, August). Application Whitelisting Using Microsoft AppLocker. Retrieved March 31, 2016.

    Open source URL
  9. [9]
    Microsoft Application Lockdown

    Corio, C., & Sayana, D. P.. (2008, June). Application Lockdown with Software Restriction Policies. Retrieved November 18, 2014.

    Open source URL
  10. [10]
    Microsoft Using Software Restriction

    Microsoft. (2012, June 27). Using Software Restriction Policies and AppLocker Policies. Retrieved April 7, 2016.

    Open source URL
  11. [11]
    Github PowerShell Empire

    Schroeder, W., Warner, J., Nelson, M. (n.d.). Github PowerShellEmpire. Retrieved April 28, 2016.

    Open source URL
  12. [12]
    GitHub PowerSploit May 2012

    PowerShellMafia. (2012, May 26). PowerSploit - A PowerShell Post-Exploitation Framework. Retrieved February 6, 2018.

    Open source URL
  13. [13]
    PowerSploit Documentation

    PowerSploit. (n.d.). PowerSploit. Retrieved February 6, 2018.

  14. [14]
    Microsoft Dynamic-Link Library Security

    Microsoft. (n.d.). Dynamic-Link Library Security. Retrieved July 25, 2016.

    Open source URL
  15. [15]
    Vulnerability and Exploit Detector

    Kanthak, S.. (2016, July 20). Vulnerability and Exploit Detector. Retrieved February 3, 2017.

    Open source URL
  16. [16]
    Microsoft CreateProcess

    Microsoft. (n.d.). CreateProcess function. Retrieved September 12, 2024.

    Open source URL
  17. [17]
    Microsoft CreateProcess

    Microsoft. (n.d.). CreateProcess function. Retrieved September 12, 2024.

    Open source URL
  18. [18]
    Microsoft Environment Property

    Microsoft. (2011, October 24). Environment Property. Retrieved July 27, 2016.

    Open source URL
  19. [19]
    Microsoft Environment Property

    Microsoft. (2011, October 24). Environment Property. Retrieved July 27, 2016.

    Open source URL
  20. [20]
    Microsoft WinExec

    Microsoft. (n.d.). WinExec function. Retrieved September 12, 2024.

    Open source URL
  21. [21]
    Microsoft WinExec

    Microsoft. (n.d.). WinExec function. Retrieved September 12, 2024.

    Open source URL
  22. [22]
    Windows NT Command Shell

    Tim Hill. (2014, February 2). The Windows NT Command Shell. Retrieved December 5, 2014.

    Open source URL
  23. [23]
    Windows NT Command Shell

    Tim Hill. (2014, February 2). The Windows NT Command Shell. Retrieved December 5, 2014.

    Open source URL
  24. [24]
    mitre-attackT1574.008
    Open source URL
  25. [25]
    mitre-attackT1574.008
    Open source URL
  26. [26]
    mitre-attackT1574.008
    Open source URL
  27. [27]
    Microsoft Application Lockdown

    Corio, C., & Sayana, D. P.. (2008, June). Application Lockdown with Software Restriction Policies. Retrieved November 18, 2014.

    Open source URL
  28. [28]
    Microsoft Using Software Restriction

    Microsoft. (2012, June 27). Using Software Restriction Policies and AppLocker Policies. Retrieved April 7, 2016.

    Open source URL
  29. [29]
    Microsoft Windows Defender Application Control

    Gorzelany, A., Hall, J., Poggemeyer, L.. (2019, January 7). Windows Defender Application Control. Retrieved July 16, 2019.

    Open source URL
  30. [30]
    NSA MS AppLocker

    NSA Information Assurance Directorate. (2014, August). Application Whitelisting Using Microsoft AppLocker. Retrieved March 31, 2016.

    Open source URL
  31. [31]
    SANS Application Whitelisting

    Beechey, J.. (2014, November 18). Application Whitelisting: Panacea or Propaganda?. Retrieved November 18, 2014.

    Open source URL
  32. [32]
    Windows Commands JPCERT

    Tomonaga, S. (2016, January 26). Windows Commands Abused by Attackers. Retrieved February 2, 2016.

    Open source URL
  33. [33]
    Github PowerShell Empire

    Schroeder, W., Warner, J., Nelson, M. (n.d.). Github PowerShellEmpire. Retrieved April 28, 2016.

    Open source URL
  34. [34]
    GitHub PowerSploit May 2012

    PowerShellMafia. (2012, May 26). PowerSploit - A PowerShell Post-Exploitation Framework. Retrieved February 6, 2018.

    Open source URL
  35. [35]
    PowerSploit Documentation

    PowerSploit. (n.d.). PowerSploit. Retrieved February 6, 2018.

  36. [36]
    Microsoft CreateProcess

    Microsoft. (n.d.). CreateProcess function. Retrieved September 12, 2024.

    Open source URL
  37. [37]
    Microsoft CreateProcess

    Microsoft. (n.d.). CreateProcess function. Retrieved September 12, 2024.

    Open source URL
  38. [38]
    Microsoft Dynamic-Link Library Security

    Microsoft. (n.d.). Dynamic-Link Library Security. Retrieved July 25, 2016.

    Open source URL
  39. [39]
    Vulnerability and Exploit Detector

    Kanthak, S.. (2016, July 20). Vulnerability and Exploit Detector. Retrieved February 3, 2017.

    Open source URL
Source and licensing

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.

Official MITRE ATT&CK siteOfficial STIX data repositoryMITRE ATT&CK terms of use