Keypoints
- DLL hijacking abuses Windows’ DLL search order so a malicious DLL is loaded instead of the intended legitimate DLL.
- Windows evaluates special search locations first (e.g., DLL redirection, API sets, manifests, known DLLs) and then standard locations (application directory, System32, Windows, current directory, PATH), and attackers exploit the standard order most often.
- Three common implementations are DLL side-loading (malicious DLL dropped with a vulnerable executable), DLL search-order hijacking (placing a malicious DLL in a higher-priority searched location or modifying PATH), and phantom DLL loading (planting a DLL that a process expects but normally doesn’t have).
- Real-world cases: ToneShell used triple DLL side-loading across legitimate binaries, PlugX used a malicious Acrobat.dll loaded from a USB drop, AsyncRAT was delivered via renamed EHttpSrv.exe and http_dll.dll, CatB used phantom loading by writing oci.dll to System32 and relaunching msdtc.exe, and Dridex used AtomBombing + DLL side-loading for persistence.
- Detection focuses on anomalies in DLLs (missing/stolen signatures, unusual size/entropy, rare hashes, newer compile times), the vulnerable application (unexpected signed binaries or uncommon install locations), and loading events (first-time loads, unexpected single-DLL loads).
- Mitigations include specifying fully qualified DLL paths, using manifests or DLL redirection, limiting writable permissions on system directories, and monitoring for the indicators and behaviors described.
MITRE Techniques
- [T1574] Hijack Execution Flow – used to describe the overall DLL hijacking concept: ‘DLL hijacking tricks an operating system into running a malicious binary instead of a legitimate DLL.’
- [T1574.001] DLL Side-Loading – the specific side-loading implementation: ‘In this most commonly used DLL-hijacking technique, an attacker obtains a legitimate executable that loads a specifically named DLL without specifying the DLL file’s full directory path.’
- [T1053] Scheduled Task/Job – used by PlugX for persistence: ‘To achieve persistence, this PlugX sample creates a scheduled task named InternetUpdateTask, which it sets to run every 30 minutes.’
- [T1055] Process Injection – code injection technique used by Dridex: ‘When executed, the Dridex loader has used AtomBombing to inject code into the process space used by explorer.exe.’
- [T1543] Create or Modify System Process (Windows Service) – phantom DLL loading via a system service: ‘When msdtc.exe launches, it attempts to load a DLL named oci.dll… When msdtc.exe relaunches, it loads the malicious oci.dll, which is the ransomware payload.’
Indicators of Compromise
- [File Hashes] hashes of payloads and loaders – example: 26fc0efa8458326086266aae32ec31b512adddd1405f4dd4e1deed3f55f7b30d (AsyncRAT ZIP), 12c584a685d9dffbee767d7ad867d5f3793518fb7d96ab11e3636edcc490e1bd (PlugX loader), and dozens more hashes listed in the article.
- [File Names] malicious DLL/EXE filenames observed in attacks – example: http_dll.dll (AsyncRAT campaign), Acrobat.dll (PlugX side-loading), oci.dll (CatB phantom DLL).
- [LNK & Drop Artifacts] shortcut and drop filenames used to start infections – example: a malicious LNK folder/shortcut and 3.exe renamed Acrobat executable (PlugX USB drop); LNK hash 515fd058af3dfd2d33d49b7c89c11c6ef04c6251190536ca735a27e5388aa7e7.
- [Persistence artifacts] scheduled task names and registry/startup entries – example: InternetUpdateTask scheduled every 30 minutes (PlugX), various Run key entries and startup shortcuts used by Dridex.
Attackers exploit Windows’ DLL search order by placing a malicious DLL where Windows will locate it before the legitimate copy. The simplest and most common approach is DLL side-loading: an attacker supplies a legitimate executable that implicitly loads a DLL by filename (no full path), drops a malicious DLL with that filename into the same directory, and then runs the executable so Windows resolves the local malicious DLL first. Variations include placing malicious DLLs in directories that are earlier in the PATH or writable install directories (for example, Python install folders added to PATH with relaxed permissions), which implements DLL search-order hijacking.
Phantom DLL loading targets executables that attempt to load a DLL that normally does not exist; the attacker creates that expected-but-missing DLL in a searched location (e.g., System32) so when the service or process restarts it loads the attacker’s payload. Practical examples: CatB writes oci.dll to C:WindowsSystem32 then restarts msdtc.exe to have the service load the ransomware DLL; PlugX used a USB drop with a renamed Acrobat.exe and Acrobat.dll to side-load the PlugX loader; AsyncRAT archives contained a renamed EHttpSrv.exe and http_dll.dll so execution of the renamed server binary triggered in-memory unpacking and loading of AsyncRAT.
Effective detection and response focus on the DLL (unsigned or mismatched signature, unusual size/entropy, rare hash, compilation time newer than the host executable), the hosting application (unexpected signed vendor binary or unusual install path), and the loading event (first-seen DLL loads, unexpected single-DLL loads, or creation of persistence like scheduled tasks). Mitigations include using fully qualified DLL paths, application manifests or DLL redirection, tightening permissions on system and PATH directories, and alerting on behaviors such as side-loading patterns, phantom DLL loads into privileged services, or AtomBombing/process injection attempts.
Read more: https://unit42.paloaltonetworks.com/dll-hijacking-techniques/