Hijack Execution Flow (T1574) is the parent of a family of techniques in the stealth and execution tactics. The adversary does not break into a program. They change how the operating system finds and runs things, so their code runs instead. Platforms: Linux, macOS and Windows.
MITRE says this can serve persistence, because a hijacked path keeps firing every time the program runs. It can also raise privileges, or evade defenses such as application control and other restrictions on execution.
How attackers use it
MITRE points to a few places where the hijack can happen:
- How the OS locates programs. If a program is named without a full path, the OS searches directories in order. Put something earlier in that order and it wins.
- How the OS locates libraries. The same idea applies to the libraries a program loads.
- Where the OS looks. Directories, and on Windows the Registry, can be poisoned to include a malicious payload.
Each variant has its own sub-technique page, and this family is large. The ones in this series:
- DLL (T1574.001) on Windows
- Dylib Hijacking (T1574.004) on macOS
- Executable Installer File Permissions Weakness (T1574.005)
- Dynamic Linker Hijacking (T1574.006) on Linux and macOS
- Path Interception by PATH Environment Variable (T1574.007)
- Path Interception by Search Order Hijacking (T1574.008)
- Path Interception by Unquoted Path (T1574.009)
- Services File Permissions Weakness (T1574.010)
- Services Registry Permissions Weakness (T1574.011)
- COR_PROFILER (T1574.012)
- KernelCallbackTable (T1574.013)
- AppDomainManager (T1574.014)
The shared root cause is that the system trusts a location or a name, and an attacker found a way to write there.
How to detect it
MITRE's detection strategy for the parent technique describes each platform.
Windows. Unusual changes to service binary paths, registry keys or DLL load paths that lead to an alternate execution flow. Look for registry key modifications, suspicious file writes into system directories, and processes loading libraries from abnormal paths.
Linux. Manipulation of shared library paths or environment variables, or replacement of service binaries. MITRE specifically mentions suspicious modifications in /etc/ld.so.preload, service configuration changes, and file writes that replace existing executables.
macOS. Abuse of DYLD_INSERT_LIBRARIES or hijacked framework paths used to load malicious libraries. Look at processes invoking abnormal dylibs, modified plist files, and persistence entries pointing to altered binaries.
The common thread is a diff against a known good state. File integrity monitoring on system and service directories, registry change auditing and module load telemetry all answer the same question: did something change that should not have?
How to reduce the risk
MITRE lists these mitigations for the family.
- User Account Control. On Windows, MITRE describes denying elevation requests for standard users and enabling installer detection for all users, so installers prompt for credentials.
- Behavior prevention on endpoint. Some endpoint products can block behaviors tied to process injection and memory tampering, based on common sequences of indicators such as specific API calls.
- Restrict library loading. Disallow loading of remote DLLs. MITRE notes this is the default on Windows Server 2012 and later. Enable Safe DLL Search Mode so system directories are searched before local ones such as a user's home directory.
- Audit. Use auditing tools that can find hijacking opportunities and fix them. MITRE mentions PowerUp modules from the PowerSploit toolkit for exploring weaknesses, and the sxstrace.exe program included with Windows to check manifest files for side-loading problems.
- Application developer guidance. Include hash values in manifest files where possible to help prevent side-loading of malicious libraries.
Check your own environment
Read-only checks:
# Linux: is a global preload file present, and does it have content?
ls -l /etc/ld.so.preload
cat /etc/ld.so.preload
# macOS: look for linker injection variables in the current environment
env | grep DYLD_
# Windows cmd: Safe DLL Search Mode setting (absent means the OS default applies)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode
Then work through this list:
- Who can write to the directories your services and scheduled tasks run from?
- Do you alert on new or changed files in system directories?
- Are installers and applications installed in write-protected locations?
- Do you collect module load events, or only process creation?
- Which of your own in-house applications call helpers without a full path?
That last one matters for developers. If your own code launches a helper by bare name or loads a library without an absolute path, it can be a hijack target. Fully qualified paths close the door.
Quick check
Why is hijack execution flow useful for persistence?
Because the hijacked lookup or load path is used again whenever the legitimate program runs, so the attacker's code runs repeatedly without a separate startup entry.
What does Safe DLL Search Mode change?
It forces Windows to search system directories, such as the system root, before local directories like a user's home folder, per the MITRE mitigation text.
Which Linux file does MITRE call out for monitoring?
/etc/ld.so.preload, where unexpected changes can mean library hijacking.
