DLL Side-Loading

To avoid crashing the host application and revealing the intrusion, attackers typically use a proxy DLL rather than a simple replacement. The malicious DLL:

• Exports the exact same function names as the legitimate DLL it replaces
• Intercepts calls to functions the attacker wants to hook
• Forwards all other function calls to the original, renamed legitimate DLL

This ensures the application continues to function normally while the malicious code executes silently in the background. Tools like SharpDllProxy automate this forwarding stub generation.

Attackers deliberately target signed, trusted Microsoft or third-party binaries to evade application allowlisting and endpoint detection. The executable itself is legitimate and has a valid digital signature, so it passes initial trust checks.

Commonly exploited hosts include:

• OneDrive.exe: Known to load FileSyncShell.dll from its local directory
• Teams.exe: Historically vulnerable to loading msvcp140.dll or vcruntime140.dll
• Java Runtime (java.exe): Loads msvcr100.dll from the working directory
• WinRAR.exe: Loads rarext.dll from its installation path

The malicious code inherits the reputation and process integrity of the signed binary.

DLL side-loading is not just a code execution vector; it is a robust persistence mechanism. Attackers establish long-term access by:

• Identifying a legitimate application that auto-starts via a registry Run key or scheduled task
• Writing a malicious DLL to the application's directory
• Modifying the %PATH% environment variable or the application's working directory

Every time the legitimate application launches—often at user login or system boot—the malicious DLL is loaded into memory. This bypasses traditional persistence detection that scans for new registry entries or startup folder items.

A variant of the attack exploits applications that attempt to load DLLs that do not exist on the system. An attacker enumerates missing DLLs using tools like Process Monitor, then places a malicious DLL with the expected name in a writable directory within the search path.

This is particularly effective because:

• The application explicitly calls LoadLibrary on a DLL that is absent
• No legitimate file needs to be replaced or proxied
• The attack leaves no trace of file tampering
• Many legacy applications have hardcoded references to obsolete or optional DLLs

This technique is often used for privilege escalation when the vulnerable application runs with higher integrity.

DLL side-loading is notoriously difficult to detect because the malicious code runs inside a trusted, signed process. However, defensive measures include:

• Dev/Signed DLL Load Rules: Configuring Windows Defender Application Control (WDAC) to only allow DLLs signed by specific certificates to load into specific processes
• Safe DLL Search Mode: Enabling the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode to prioritize system directories over the application directory
• Process Integrity Monitoring: Alerting on unsigned DLLs loaded by signed binaries, especially from user-writable paths
• Attack Surface Reduction (ASR) Rules: Blocking executable content creation in commonly abused directories

A stealth technique where the malicious DLL forwards all legitimate function calls to the original, renamed DLL after executing its payload. This ensures the host application continues to function normally, making detection significantly harder.

• The attacker renames the legitimate DLL (e.g., legit.dll → legit_orig.dll)
• The malicious DLL exports the same function table and passes calls through to legit_orig.dll
• This maintains application stability while the payload executes silently in the background

The primary defense against DLL side-loading. Authenticode digital signatures cryptographically verify the publisher and integrity of a binary. Applications should validate signatures on all loaded modules.

• WinVerifyTrust(): The Windows API function that performs signature validation against the system trust store
• Catalog-signed files: Some Microsoft files are signed via security catalog files rather than embedded signatures
• Limitation: Attackers can use validly signed, vulnerable legitimate applications as loaders for their unsigned malicious DLLs

A defensive strategy that restricts execution to a pre-approved set of applications and libraries. Solutions like Windows Defender Application Control (WDAC) and AppLocker enforce policies based on file hash, path, publisher, or product name.

• WDAC: Kernel-mode enforcement that can restrict which DLLs a process may load
• DLL Rules: AppLocker can define rules specifically for DLL loading, but requires careful tuning to avoid system instability
• Bypass Risk: Whitelisting is only as strong as its rule set; signed, trusted loaders remain exploitable

Both are code execution techniques, but they differ in approach. Process hollowing creates a legitimate process in a suspended state and replaces its memory with malicious code. DLL side-loading leverages a legitimate, running application to load malicious code.

• Process Hollowing: Requires process creation, memory unmapping, and thread resumption
• DLL Side-Loading: Requires no process creation; exploits the loader's trust in the file system
• Detection: Process hollowing leaves memory artifacts; DLL side-loading leaves file system and module load event artifacts

A system-wide security setting that changes the default DLL search order to prioritize system directories over the current working directory, reducing the attack surface for side-loading.

• Enabled by default on Windows Server and after specific security updates
• Registry Key: HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode
• Effect: Moves the current directory lower in the search order, making it harder for attackers to place a malicious DLL where it loads first