Shared Modules
Shared Modules [T1129]
Last updated
Shared Modules [T1129]
Last updated
Name: Shared Modules
ID: T1129
Tactics:
Shared Modules is a technique described under the MITRE ATT&CK framework (Technique ID: T1129), categorized within the Execution tactic. Attackers leverage shared modules, such as DLLs (Dynamic-Link Libraries) in Windows or shared object libraries (.so files) in Linux, to execute malicious code. These modules contain reusable code and resources that multiple programs can utilize, enabling adversaries to inject or load malicious payloads into legitimate processes. By exploiting shared modules, attackers can achieve persistence, privilege escalation, defense evasion, and execution of malicious activities, often while avoiding detection through standard security measures.
Shared modules, such as DLL files on Windows or shared objects (.so) on Linux systems, are dynamically loaded libraries containing reusable code. Attackers exploit these modules by:
DLL Injection (Windows):
Injecting malicious DLL files into legitimate running processes to execute malicious code within trusted processes.
Techniques include:
Using the Windows API calls such as CreateRemoteThread, LoadLibrary, or SetWindowsHookEx.
Exploiting search order hijacking (DLL hijacking) by placing malicious DLLs in directories searched before legitimate ones.
Shared Object Injection (Linux):
Injecting or preloading malicious .so files into Linux processes using environment variables (LD_PRELOAD) or modifying configuration files.
Techniques include:
Setting LD_PRELOAD environment variable to load malicious shared objects before legitimate ones.
Overwriting or replacing legitimate .so files with malicious ones.
DLL Side-Loading:
Placing malicious DLLs in directories where legitimate applications load DLLs without proper validation.
Attackers often exploit trusted applications vulnerable to DLL side-loading to execute malicious payloads silently.
DLL Search Order Hijacking:
Exploiting the Windows DLL search order by placing malicious DLLs in directories searched by applications before legitimate DLL locations.
Common vulnerable directories include:
Application directory
System directories
Current working directory
Directories specified in the system PATH environment variable
Attackers commonly use these mechanisms because they allow execution within trusted processes, making detection and attribution difficult.
Attackers commonly use Shared Modules at various stages of the cyber kill chain, including:
Initial Access and Execution:
Gaining initial foothold by exploiting applications vulnerable to DLL side-loading or search-order hijacking.
Leveraging malicious DLLs or shared objects to execute malicious payloads upon initial execution.
Persistence:
Maintaining presence by injecting malicious modules into processes that automatically run on system startup or user login.
Ensuring malicious code execution persists through system reboots or user logoff/logon cycles.
Privilege Escalation:
Loading malicious modules into processes running with elevated privileges to escalate privileges from standard user to administrator or root.
Defense Evasion:
Injecting malicious code into trusted processes to evade detection by antivirus, endpoint detection and response (EDR), and other security tools.
Leveraging legitimate processes to mask malicious activities and avoid triggering alerts.
Credential Access and Lateral Movement:
Using injected modules to capture credentials from memory or network traffic.
Facilitating lateral movement across networks through compromised modules loaded into trusted processes.
Detection of Shared Modules involves monitoring and analyzing process behavior, file system changes, and network activities. Common detection methods include:
Monitoring Process Injection:
Detecting unusual DLL or shared object loads into processes.
Tools such as Sysmon (Windows), Process Monitor, and EDR solutions can monitor module loads and injections.
File Integrity Monitoring (FIM):
Detecting unauthorized changes or additions of DLL and shared object files on critical systems.
Tools such as OSSEC, Tripwire, or commercial EDR solutions track file changes and generate alerts.
Behavioral Analysis:
Identifying abnormal process behaviors, such as unexpected module loading or processes loading modules from unusual paths.
Endpoint detection solutions and SIEM tools can correlate events to identify suspicious activities.
Network Monitoring:
Observing unexpected outbound connections initiated by processes loading suspicious modules.
Network Intrusion Detection Systems (NIDS) and network traffic analysis tools can detect anomalous activities indicative of malicious module usage.
Indicators of Compromise (IoCs):
Unusual DLL or shared object file names or locations, such as:
Files placed in temporary directories or user directories.
Files mimicking legitimate DLL names but located in suspicious directories.
Registry modifications or environment variable changes (LD_PRELOAD) indicative of shared module injection.
Unusual process relationships or injection patterns, such as a process injecting code into unrelated processes.
Detecting Shared Modules is crucial due to the severe potential impacts on systems and networks, including:
Persistence and Long-term Compromise:
Attackers can maintain prolonged unauthorized access by embedding malicious code into legitimate processes.
Early detection prevents attackers from establishing persistent footholds.
Privilege Escalation and System Compromise:
Malicious modules loaded into privileged processes can escalate attacker privileges, leading to complete system compromise.
Timely detection mitigates risk of extensive damage and unauthorized administrative access.
Defense Evasion and Difficulty of Detection:
Attackers leveraging legitimate processes complicate detection and attribution.
Early identification reduces attacker dwell time and limits damage.
Credential Theft and Data Exfiltration:
Malicious modules can capture sensitive data and credentials, facilitating lateral movement and data breaches.
Detecting module injection prevents unauthorized data access and exfiltration.
Operational Disruption and Business Impact:
Malicious code execution can disrupt critical business operations, cause system instability, or lead to data loss.
Early detection and response minimize operational downtime and associated financial impact.
Real-world examples of attacks leveraging Shared Modules include:
APT41 (Winnti Group):
Utilized DLL side-loading techniques extensively.
Exploited legitimate applications vulnerable to DLL search order hijacking to execute malicious payloads silently.
Commonly used signed legitimate binaries to load malicious DLLs, evading detection.
PlugX Malware:
Frequently employs DLL side-loading to execute malicious payloads.
Attackers place malicious DLLs in directories alongside legitimate executables, causing legitimate binaries to load malicious modules.
Resulted in persistent compromise, data exfiltration, and espionage activities.
Carbanak/FIN7 Group:
Leveraged DLL injection techniques to inject malicious code into legitimate processes, enabling credential theft, lateral movement, and financial fraud.
Injected malicious DLLs into banking applications and point-of-sale (POS) systems to capture sensitive financial data.
Operation ShadowHammer (ASUS Supply Chain Attack):
Attackers compromised ASUS Live Update Utility by injecting malicious DLL modules into legitimate software updates.
Resulted in widespread compromise, enabling attackers to selectively target specific users for further exploitation.
NotPetya Ransomware:
Utilized DLL hijacking techniques to load malicious DLL modules into legitimate processes.
Spread rapidly across networks, encrypting systems and causing significant operational disruption and financial impact worldwide.
These examples highlight the severity and impact of Shared Modules exploitation, underscoring the importance of effective detection and prevention measures.