Keypoints
- DLL sideloading abuses Windows DLL search order by placing a malicious DLL with the same name where an application will load it before the legitimate one.
- DLL Search order hijacking is mapped to MITRE T1574.001 and is widely used to execute code in trusted, signed processes to evade signature-based defenses.
- Real-world campaigns using this technique include SEO#LURKER (python311.dll with pythonw.exe), PlugX (wsc.dll with AvastSvc.exe), and DarkGate (dbgeng.dll with Wndbg.exe), among many others.
- Securonix demonstrates a practical TCPView attack using a custom malicious dwmapi.dll built with function stubs that call LoadLibraryEx to load Sliver-generated shellcode in-memory.
- Detection is most effective with DLL-load telemetry (EDR or Sysmon Event ID 7), supplemented by process creation logs (Sysmon Event ID 1 / Windows 4688), EDR heuristics, and application logs.
- A pragmatic detection rule is to alert when known system DLLs (e.g., dwmapi.dll) are loaded from non-standard locations (anything other than C:WindowsSystem32 or SysWOW64).
- Securonix provides example hunting queries and a list of provisional Securonix detections to identify potential sideloading activity in enterprise telemetry.
MITRE Techniques
- [T1574.001] DLL Search Order Hijacking – DLL sideloading by placing a malicious DLL where the application searches first. [‘DLL Search order hijacking (T1574.001) is one of the most common methods of DLL sideloading that occurs when an attacker places a malicious DLL with the same name as a legitimate DLL in a location that is searched before arriving at the legitimate DLL’s path.’]
- [T1105] Ingress Tool Transfer – Attackers drop or download malicious DLLs and helper binaries into a victim environment for execution. [‘the dropped malicious DLL (with the same name but in the executable’s folder) is executed first rather than the legitimate DLL’ and ‘downloaded and executed the legitimate WinSCP installer.’]
- [T1218] Signed Binary Proxy Execution – Using digitally signed, trusted executables to load attacker-controlled DLLs to bypass signature-based controls. [‘Since these applications are often signed and trusted, the malicious activity initiated by the sideloaded DLL can bypass security software that relies on signature-based detection mechanisms.’]
- [T1055] Process Injection (Execution via DLL Load) – Executing malicious code in the context of a legitimate process by loading a malicious DLL into its memory. [‘the malicious DLL file is loaded into memory and executed which kicks off further stages of the PlugX attack chain.’]
- [T1036] Masquerading – Distributing fake installers and binaries that appear legitimate (e.g., fake MSI or renamed binaries) to trick users and security controls. [‘sites hosted fake Microsoft software installers (.MSI) masquerading as legitimate applications but contained a sideloaded DLL to decrypt and deploy the main DarkGate malware payload.’]
Indicators of Compromise
- [DLL filenames] examples of DLLs used for sideloading – dwmapi.dll (malicious sideload in TCPView POC), python311.dll (SEO#LURKER), dbgeng.dll (DarkGate), and many others such as wsc.dll, UNITYPLAYER.dll, WindowsCodecs.dll, libcrypto-1_1.dll, mpsvc.dll (and 8 more DLL names).
- [Executables/Processes] target binaries observed – tcpview64.exe (sideloaded dwmapi.dll in POC), pythonw.exe renamed to setup.exe (SEO#LURKER), MsMpEng.exe (REvil supply-chain target), AvastSvc.exe (PlugX), and other renamed/legitimate signed binaries used to proxy execution.
- [Vulnerability/CVE] exploited vulnerability – CVE-2024-21412 was leveraged in DarkGate campaigns to distribute sideloading installers via phishing and compromised sites.
DLL sideloading abuse centers on Windows’ default DLL search order: when an executable imports a DLL by name (not by full path), Windows will search the executable’s directory before system directories. To build a reliable malicious sideload, an operator first enumerates the legitimate DLL’s exported functions (for example using dumpbin.exe /exports) to learn required ordinals and function names; omitting these will likely crash the host executable. The attacker then compiles a drop-in malicious DLL that implements “stubs” for each expected export, where the stubs either forward to legitimate implementations or call LoadLibraryEx/LoadLibrary to map malicious code into the process, allowing payloads (e.g., Sliver shellcode) to execute in memory under the trusted process context.
In the TCPView proof-of-concept the workflow was: identify target imports in dwmapi.dll with dumpbin, implement matching exported functions in a custom C# DLL that preserves expected symbols, embed or load runtime shellcode (Sliver) via those stubs (using LoadLibraryEx or similar), and place the malicious dwmapi.dll alongside tcpview64.exe so Windows loads it from the local directory. This technique ran successfully on a fully patched Windows 11 host with Windows Defender enabled because the malicious code executed inside a legitimate, signed process.
Detection and hunting should prioritize DLL-load telemetry (EDR or Sysmon Event ID 7) and correlate with process creation context (Sysmon Event ID 1 / Windows Event 4688), unusual parent/child relationships, and application error spikes. Practical detections include rules that alert when known system DLLs (e.g., dwmapi.dll) are loaded from non-standard locations (not C:WindowsSystem32 or C:WindowsSysWOW64), and combining EDR heuristics, application logs, and the provided hunting query to find loads where resource paths do not contain the expected system directories.
Read more: https://www.securonix.com/blog/detecting-dll-sideloading-techniques-in-malware-attack-chains/