T1129
Shared Modules
Linux · macOS · Windowsnothing on this site yetT1129 on attack.mitre.org
Adversaries may execute malicious payloads via loading shared modules. Shared modules are executable files that are loaded into processes to provide access to reusable code, such as specific custom functions or invoking OS API functions (i.e., Native API). Adversaries may use this functionality as a way to execute arbitrary payloads on a victim system.
If this is happening now
Checklists and playbooks to open while the alert is still live.
Playbook for this stage
Suspicious execution on an endpoint
An EDR alert, an unexplained process, or a user reporting something odd.
how MITRE says to see it
Behavior-chain, platform-aware detection strategy for T1129 Shared Modules
- A process (often LOLBin or user-launched program) loads a DLL from a user-writable/UNC/Temp path or unsigned/invalid signer. Within a short window the DLL is (a) newly written to disk, (b) spawned as follow-on execution (rundll32/regsvr32), or (c) establishes outbound C2.
- A process loads a shared object (.so) via dlopen/LD_PRELOAD/open from non-standard or temporary locations (e.g., /tmp, /dev/shm), especially shortly after that.so is written or fetched, or linked via manipulated environment variables (LD_PRELOAD/LD_LIBRARY_PATH).
- A process loads a non-system.dylib/.so via dyld (dlopen/dlsym) from user-writable locations (~/Library, /tmp) or after the library was recently created/downloaded, often followed by network egress or persistence.
what reduces it
- M1038 Execution Prevention. Identify and block potentially malicious software executed through this technique by using application control tools capable of preventing unknown modules from being loaded.