PATH Interception (T1574.007): Detection and Mitigation

Path Interception by PATH Environment Variable (T1574.007) is a technique in the stealth and execution tactics on Linux, macOS and Windows. The adversary hijacks the PATH environment variable, which controls where the operating system looks for programs.

How attackers use it

PATH holds a list of directories, user and system, that the OS searches in order when a script or command line calls a program without a full path. The first match wins.

MITRE describes two ways to abuse this.

Plant a program earlier in the list. MITRE's Windows example: an adversary puts a program named net.exe in a directory such as C:\example path, which by default comes before C:\Windows\system32\net.exe in PATH. When someone runs net from the command line, the planted file runs instead of the real utility. Many ways of launching programs rely on PATH when no full path is given, including running programs from a command and scripting interpreter (T1059).

Change PATH itself. The adversary edits the PATH variable to include a directory they can write to. The next time a program uses PATH to find a binary, the OS searches that directory and runs the malicious one. On macOS this can also be done by modifying the HOME variable. MITRE lists ways to change these variables: the command line, launchctl, Unix shell configuration modification (T1546.004), and editing system configuration files.

The attractive part for an attacker is that nothing looks broken. A familiar command runs and returns something plausible.

How to detect it

MITRE's analytics cover each platform.

Windows. Abnormal changes to the PATH variable or the registry keys that control system paths, combined with execution of binaries named after legitimate system tools from user-writable directories. Correlate registry modifications, creation of suspicious binaries and process execution paths that differ from the baseline system directories.

Linux. Changes to $PATH in shell configuration files, or at runtime, followed by execution of binaries from user-controlled directories. MITRE points to edits of ~/.bashrc, ~/.profile and /etc/paths.d, and process execution that resolves to unexpected binary locations.

macOS. Changes to PATH or HOME through shell config files, launchctl or /etc/paths.d entries, combined with execution from attacker-controlled directories. Correlate file changes in /etc/paths.d with processes that resolve to malicious binaries.

A strong, cheap signal across all three: a process with a well-known name, such as net, whose image path is not the system directory.

How to reduce the risk

MITRE lists three mitigations.

1. Restrict file and directory permissions. Deny users the ability to write files to the top-level directory C: and system directories such as C:\Windows, to reduce the places where malicious files could be placed. Require that executables be placed in write-protected directories.
2. Execution prevention. Adversaries need to put new binaries somewhere to run them. Use application control such as Windows Defender Application Control, AppLocker or Software Restriction Policies to block execution of binaries from unexpected locations.
3. Audit. Find and remove path interception weaknesses in configuration files, scripts, the PATH variable, services and shortcuts. Surround PATH entries with quotation marks where the function allows. Know the search order Windows uses and use fully qualified paths wherever appropriate. MITRE also advises cleaning up old Registry keys when software is uninstalled, so references to missing files are not left behind.

For script authors, the plain rule is: call tools by full path in anything that runs with privilege.

Check your own environment

# Linux or macOS: show PATH one directory per line, in search order
echo "$PATH" | tr ':' '\n'

# Linux or macOS: show directories where the current user can write, from PATH
for d in $(echo "$PATH" | tr ':' ' '); do [ -w "$d" ] && echo "writable: $d"; done

# macOS: extra PATH entries
ls -l /etc/paths.d

# Windows PowerShell: PATH entries in search order
$env:PATH -split ';'

Checklist:

• Is any user-writable directory ahead of a system directory in PATH?
• Can standard users write to the root of the system drive?
• Do privileged scripts and scheduled tasks call tools by full path?
• Do you track edits to shell profiles and /etc/paths.d?
• Is application control enforced from user-writable locations?

Quick check

Sources

• MITRE ATT&CK T1574.007: Path Interception by PATH Environment Variable