|T1574.001||DLL Search Order Hijacking|
|T1574.005||Executable Installer File Permissions Weakness|
|T1574.006||Dynamic Linker Hijacking|
|T1574.007||Path Interception by PATH Environment Variable|
|T1574.008||Path Interception by Search Order Hijacking|
|T1574.009||Path Interception by Unquoted Path|
|T1574.010||Services File Permissions Weakness|
|T1574.011||Services Registry Permissions Weakness|
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. 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.
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
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
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. Libraries specified by
LD_PRELOAD are loaded and mapped into memory by
mmap() respectively. 
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.
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. 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||Detects|
Monitor executed commands and arguments associated with modifications to variables and files associated with loading shared libraries such as LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on macOS.
Monitor for newly constructed files that are added to absolute paths of shared libraries such as LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on macOS.
Monitor for changes to environment variables and files associated with loading shared libraries such as LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on macOS.
Monitor 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.
Monitor for newly executed processes for unusual activity (e.g., a process that does not use the network begins to do so).