T1574.007: Path Interception by PATH Environment Variable
Adversaries may execute their own malicious payloads by hijacking environment variables used to load libraries. The PATH environment variable contains a list of directories (User and System) that the OS searches sequentially through in search of the binary that was called from a script or the command line.
Adversaries can place a malicious program in an earlier entry in the list of directories stored in the PATH environment variable, resulting in the operating system executing the malicious binary rather than the legitimate binary when it searches sequentially through that PATH listing.
For example, on Windows if an adversary places a malicious program named "net.exe" in `C:\example path`, which by default precedes `C:\Windows\system32\net.exe` in the PATH environment variable, when "net" is executed from the command-line the `C:\example path` will be called instead of the system's legitimate executable at `C:\Windows\system32\net.exe`. Some methods of executing a program rely on the PATH environment variable to determine the locations that are searched when the path for the program is not given, such as executing programs from a Command and Scripting Interpreter.[1]
Adversaries may also directly modify the $PATH variable specifying the directories to be searched. An adversary can modify the `$PATH` variable to point to a directory they have write access. When a program using the $PATH variable is called, the OS searches the specified directory and executes the malicious binary. On macOS, this can also be performed through modifying the $HOME variable. These variables can be modified using the command-line, launchctl, Unix Shell Configuration Modification, or modifying the `/etc/paths.d` folder contents.[2][3][4]
Analyst context for executives and security teams
This technique matters because it turns a normal operating system lookup behavior into an execution opportunity. If a script, user, service, or admin tool calls a program by name instead of full path, an adversary may cause a malicious lookalike binary to run first by abusing the PATH environment variable or related path configuration. For leaders, the risk is not just malware execution; it is uncertainty about whether routine administrative commands, automation, or shell activity can be trusted across Windows, Linux, and macOS systems.
Executive priority
Prioritize this where business-critical endpoints, servers, developer systems, or administrative workstations rely heavily on scripts and command-line tooling. The control question is whether users and processes can write to directories that are searched before trusted system locations, and whether the organization can prove this through audit evidence. This is relevant to incident readiness because responders may need to determine whether a familiar command name actually launched the expected executable.
Technical view
ATT&CK lists this as a sub-technique of Hijack Execution Flow under stealth and execution for Linux, macOS, and Windows. SOC and IR teams should validate visibility into environment variable changes, PATH or $PATH contents, launchctl-based changes on macOS, Unix shell configuration modifications, changes under /etc/paths.d, and process launches where the executable path differs from the expected trusted location. Because official ATT&CK detection text is not provided, detection engineering should use the related DET0004 strategy as a starting point and test local assumptions around command execution, script behavior, and writable directories in PATH order.
Likely telemetry
- Process creation events including command name, resolved executable path, parent process, user, and working directory
- Environment variable change evidence, especially PATH, $PATH, and on macOS HOME where relevant
- File creation or modification events in directories included early in PATH search order
- Permission and ownership data for directories referenced by User and System PATH entries
- Shell configuration file changes on Unix-like systems
Detection direction
- Baseline approved PATH entries by operating system, user role, and server/workstation class, then alert on unexpected additions or reordering that place writable locations earlier in search order.
- Correlate suspicious PATH changes with creation of binaries that reuse common system or administrative command names.
- Tune for legitimate developer, package manager, and administrative tooling behavior to reduce false positives, especially on Linux and macOS systems where PATH customization is common.
- Investigate process executions where a common command name resolves outside expected trusted directories such as system locations on Windows or standard system paths on Unix-like systems.
- Do not assume command-line logging alone is sufficient; the decisive evidence is often the resolved executable path plus the PATH context at execution time.
Mitigation priorities
- Restrict file and directory permissions so standard users and untrusted processes cannot write to directories that appear early in PATH search order.
- Use execution prevention controls to limit unauthorized code execution from untrusted or user-writable locations.
- Audit PATH, $PATH, shell configuration, launchctl, and /etc/paths.d changes on systems where command-line automation or administrative scripts are important.
- Encourage or require scripts and scheduled automation to call trusted binaries by full path where operationally feasible.
- Include PATH-order and writable-directory checks in hardening reviews, compliance evidence collection, and incident response triage procedures.
Analyst notes and limits
The relationship context shows this behavior is used by multiple software entries, including PowerSploit, Empire, DarkGate, and BRICKSTORM, but that should be treated as context for defensive prioritization rather than proof of activity in any environment. The most practical validation is a configuration-and-telemetry review: which PATH directories are writable, which command executions are resolved from unexpected locations, and whether changes are retained in logs long enough for investigation.
MITRE does not provide official detection text for this object in the supplied fields. The take is therefore based on the technique description, platforms, tactics, external references, and listed relationships. Local operating system builds, shell behavior, endpoint logging, and administrative practices will determine actual detectability and control effectiveness.
Path Interception by PATH Environment Variable
Adversaries may execute their own malicious payloads by hijacking environment variables used to load libraries. The PATH environment variable contains a list of directories (User and System) that the OS searches sequentially through in search of the binary that was called from a script or the command line.
Adversaries can place a malicious program in an earlier entry in the list of directories stored in the PATH environment variable, resulting in the operating system executing the malicious binary rather than the legitimate binary when it searches sequentially through that PATH listing.
For example, on Windows if an adversary places a malicious program named "net.exe" in `C:\example path`, which by default precedes `C:\Windows\system32\net.exe` in the PATH environment variable, when "net" is executed from the command-line the `C:\example path` will be called instead of the system's legitimate executable at `C:\Windows\system32\net.exe`. Some methods of executing a program rely on the PATH environment variable to determine the locations that are searched when the path for the program is not given, such as executing programs from a Command and Scripting Interpreter.[1]
Adversaries may also directly modify the $PATH variable specifying the directories to be searched. An adversary can modify the `$PATH` variable to point to a directory they have write access. When a program using the $PATH variable is called, the OS searches the specified directory and executes the malicious binary. On macOS, this can also be performed through modifying the $HOME variable. These variables can be modified using the command-line, launchctl, Unix Shell Configuration Modification, or modifying the `/etc/paths.d` folder contents.[2][3][4]
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
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]
S9015: BRICKSTORM
BRICKSTORM is a cross-platform backdoor with variants written in Go and Rust that facilitates command and control, the ingress transfer of other malware, and the exfiltration of data.[1][2][3][4] BRICKSTORM has also been created from a .NET application using ahead-of-time (AOT) compilation to blend in within victim environments.[1] BRICKSTORM was first observed in April 2024.[5] BRICKSTORM has previously been leveraged by People's Republic of China (PRC) state-nexus actors identified as UNC6201, UNC5221, WARP PANDA, PunyToad, and SYLVANITE.[6][7][1][8][9][10][3][4]
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]
S1111: DarkGate
DarkGate first emerged in 2018 and has evolved into an initial access and data gathering tool associated with various criminal cyber operations. Written in Delphi and named "DarkGate" by its author, DarkGate is associated with credential theft, cryptomining, cryptotheft, and pre-ransomware actions.[1] DarkGate use increased significantly starting in 2022 and is under active development by its author, who provides it as a Malware-as-a-Service offering.[2]
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 | 2f2c68eea038… |
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]
ExpressVPN PATH env Windows 2021
ExpressVPN Security Team. (2021, November 16). Cybersecurity lessons: A PATH vulnerability in Windows. Retrieved September 28, 2023.
Open source URL -
[2]
uptycs Fake POC linux malware 2023
Nischay Hegde and Siddartha Malladi. (2023, July 12). PoC Exploit: Fake Proof of Concept with Backdoor Malware. Retrieved September 28, 2023.
Open source URL -
[3]
nixCraft macOS PATH variables
Vivek Gite. (2023, August 22). MacOS – Set / Change $PATH Variable Command. Retrieved September 28, 2023.
Open source URL -
[4]
Elastic Rules macOS launchctl 2022
Elastic Security 7.17. (2022, February 1). Modification of Environment Variable via Launchctl. Retrieved September 28, 2023.
Open source URL -
[5]
mitre-attack T1574.007Open 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.