Detection of Unsigned DLL Side-Loading Mimicking Microsoft
Adversaries utilize unsigned DLLs masquerading as Microsoft-signed libraries within non-standard directories to achieve code execution, persistence, and privilege escalation via DLL side-loading.
This detection analytic targets the abuse of DLL side-loading, a technique where attackers force a legitimate process to load a malicious, unsigned DLL instead of the intended library. By mimicking Microsoft signatures and utilizing libraries that attempt to resolve from the application's local directory, adversaries evade traditional signature-based detection. This behavior has been observed in campaigns associated with high-profile threat actors, including APT29, to facilitate the execution of loaders like WINELOADER. The activity is significant because it allows for arbitrary code execution within the context of a trusted process, potentially enabling persistent access, privilege escalation, and exfiltration of sensitive information from the host. Defenders should prioritize monitoring for file-load events originating from unconventional directory structures.
Attack Chain
- The attacker gains initial access to the target endpoint.
- The attacker identifies a target application that performs unsafe DLL resolution (e.g., searching the current application directory before system paths).
- The attacker drops a malicious, unsigned DLL that mimics the name and version metadata of a legitimate Microsoft DLL into the application's local directory.
- The target process is executed by the user or as a service, prompting the lookup for the legitimate library.
- The process loads the malicious DLL from the local directory instead of the intended system location (System32 or SysWOW64).
- Malicious code within the DLL is executed under the context of the parent application process.
- The attacker establishes persistence or initiates further malicious activity, such as command and control communications or credential theft.
Impact
Successful exploitation allows for arbitrary code execution, bypassing host-based security controls. This can result in full system compromise, the establishment of persistent backdoors, and the exfiltration of sensitive data. Threat actors like APT29 have utilized this technique in campaigns targeting diplomatic and political entities to maintain long-term access to compromised environments.
Recommendation
- Deploy the Sigma rule below to detect unsigned library loads from non-standard directories using Sysmon.
- Enable Sysmon Event ID 7 (Image Loaded) across the environment.
- Audit and restrict write permissions to application installation directories to prevent the placement of malicious DLLs.
- Investigate instances where processes outside of 'System32' or 'SysWOW64' load libraries that claim to be signed by 'Microsoft Corporation' but lack a valid signature.
Immediate actions
Deploy the provided Sigma rule to detect unsigned Microsoft-mimicking DLLs.
Mitigations
Enforce code signing policies and restrict non-admin write access to application directories.
T1574.001
Detection coverage 1
Detect Unsigned Microsoft DLL Side-Loading
highDetects instances where an unsigned or invalidly signed DLL claiming to be from Microsoft is loaded by a process from a non-system directory.
Detection queries are available on the platform. Get full rules →