Hijack Execution Flow: Dynamic Linker Hijacking

Adversaries may execute their own malicious payloads by hijacking environment variables the dynamic linker uses to load shared libraries. During the execution preparation phase of a program, the dynamic linker loads specified absolute paths of shared libraries from environment variables and files, such as LD_PRELOAD on Linux or DYLD_INSERT_LIBRARIES on macOS. Libraries specified in environment variables are loaded first, taking precedence over system libraries with the same function name.[1][2][3] These variables are often used by developers to debug binaries without needing to recompile, deconflict mapped symbols, and implement custom functions without changing the original library.[4]

On Linux and macOS, hijacking dynamic linker variables may grant access to the victim process's memory, system/network resources, and possibly elevated privileges. This method may also evade detection from security products since the execution is masked under a legitimate process. Adversaries can set environment variables via the command line using the export command, setenv function, or putenv function. Adversaries can also leverage Dynamic Linker Hijacking to export variables in a shell or set variables programmatically using higher level syntax such Python’s os.environ.

On Linux, adversaries may set LD_PRELOAD to point to malicious libraries that match the name of legitimate libraries which are requested by a victim program, causing the operating system to load the adversary's malicious code upon execution of the victim program. LD_PRELOAD can be set via the environment variable or /etc/ld.so.preload file.[1][2] Libraries specified by LD_PRELOAD are loaded and mapped into memory by dlopen() and mmap() respectively.[5][6] [7][8]

On macOS this behavior is conceptually the same as on Linux, differing only in how the macOS dynamic libraries (dyld) is implemented at a lower level. Adversaries can set the DYLD_INSERT_LIBRARIES environment variable to point to malicious libraries containing names of legitimate libraries or functions requested by a victim program.[9][10][11]

ID: T1574.006
Sub-technique of:  T1574
Platforms: Linux, macOS
Permissions Required: User
Version: 2.0
Created: 13 March 2020
Last Modified: 27 April 2021

Procedure Examples

ID Name Description
G0096 APT41

APT41 has configured payloads to load via LD_PRELOAD.[12]

S0377 Ebury

Ebury has injected its dynamic library into descendent processes of sshd via LD_PRELOAD.[13]

S0394 HiddenWasp

HiddenWasp adds itself as a shared object to the LD_PRELOAD environment variable.[14]

S0601 Hildegard

Hildegard has modified /etc/ld.so.preload to intercept shared library import functions.[15]

G0106 Rocke

Rocke has modified /etc/ld.so.preload to hook libc functions in order to hide the installed dropper and mining software in process lists.[16]


XCSSET adds malicious file paths to the DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH environment variables to execute malicious code.[17]


ID Mitigation Description
M1038 Execution Prevention

Adversaries may use new payloads to execute this technique. Identify and block potentially malicious software executed through hijacking by using application control solutions also capable of blocking libraries loaded by legitimate software.

M1028 Operating System Configuration

When System Integrity Protection (SIP) is enabled in macOS, the aforementioned environment variables are ignored when executing protected binaries. Third-party applications can also leverage Apple’s Hardened Runtime, ensuring these environment variables are subject to imposed restrictions.[18] Admins can add restrictions to applications by setting the setuid and/or setgid bits, use entitlements, or have a __RESTRICT segment in the Mach-O binary.


ID Data Source Data Component
DS0017 Command Command Execution
DS0022 File File Creation
File Modification
DS0011 Module Module Load
DS0009 Process Process Creation

Monitor for changes to environment variables and files associated with loading shared libraries such as LD_PRELOAD and DYLD_INSERT_LIBRARIES, as well as the commands to implement these changes.

Monitor processes for unusual activity (e.g., a process that does not use the network begins to do so). Track library metadata, such as a hash, and compare libraries that are loaded at process execution time against previous executions to detect differences that do not correlate with patching or updates.