LAB-12Medium
DLL Import & Load Order
Analyze a binary's DLL imports and identify a DLL search-order hijacking opportunity.
15 min4 prerequisites5 tools
Investigate
Hints
Hint 1
VERSION.dll is a small utility DLL often loaded from the application directory.
Hint 2
The search order checks the application directory first.
Hint 3
A DLL in the app directory wins over the system copy.
Submit Findings
Solution
DLL Import & Load Order — Solution
- VERSION.dll is the small, app-local library most vulnerable to placement attacks (it's often not a protected system DLL and loads from the app directory).
- WININET.dll provides the
InternetOpenWnetwork API. - ADVAPI32.dll provides
RegCreateKeyExW(registry). - Dropping a malicious VERSION.dll next to the EXE is DLL hijacking — the loader finds the local copy first and maps the attacker's code.
Methodology: identify which DLL is the weak link, then which directory it loads from.
Prerequisites
- w4-dlls-loader
- sa2-imports-exports
- DLL search order (SafeDllSearchMode)
- KnownDLLs, AppDir, System32, PATH
Methodology
Investigation Methodology
1. Enumerate All Imports
- Ghidra: Window → Imports
- PE-bear / CFF Explorer → Import Table
- List: DLL name + function names
2. Categorize DLLs by Trust Level
| Category | Examples | Hijack Risk |
|---|---|---|
| KnownDLLs | kernel32.dll, ntdll.dll, user32.dll, advapi32.dll | None (loaded from System32 only) |
| System DLLs | wininet.dll, crypt32.dll, ws2_32.dll | Low (SafeDllSearchMode) |
| App-local / Optional | version.dll, msvcp140.dll, custom.dll | High (app dir searched first) |
| Delay-loaded | (marked in Delay Import) | Medium (on first call) |
3. DLL Search Order (SafeDllSearchMode = ON, default)
- Application directory
- System directory (System32)
- 16-bit System directory (System)
- Windows directory
- Current working directory
- PATH directories
KnownDLLs bypass this entirely — always from System32.
4. Identify Hijack Candidates
- Not in KnownDLLs registry key
- Small, simple API surface (easy to proxy)
- Loaded early (high impact)
- Optional / version-specific
Classic targets: VERSION.DLL, DWMAPI.DLL, UXTHEME.DLL, PROPSYS.DLL, MSVCR*.DLL
5. Verify Attack Surface
- Check if binary uses
LoadLibrary("version.dll")(no path) → searches - Check if binary uses
LoadLibraryExwithLOAD_WITH_ALTERED_SEARCH_PATH - Check manifest for
dependency→ may pin version
6. Mitigations
SetDllDirectory("")/AddDllDirectory/SetDefaultDllDirectories- Manifest with
<dependency>for side-by-side - Code signing + AppLocker / WDAC
- SafeDllSearchMode (default ON since XP SP2)
Common Pitfalls
- Assuming all system DLLs are in KnownDLLs — many are not (wininet.dll, etc.)
- Overlooking delay-loaded DLLs — also search on first call
- Confusing `LoadLibrary` (searches) with `LoadLibraryEx` flags
- Missing that CWD is searched *after* System32 in SafeDllSearchMode
- Not checking for absolute paths in imports (rare but possible)
Tools
- Ghidra (Imports, Decompiler for LoadLibrary calls)
- PE-bear / CFF Explorer (Import Table, Delay Import)
- Process Monitor (Procmon) — filter Load Image, see actual path
- ListDLLs (Sysinternals) — runtime loaded DLLs
- DLL Hijack Auditor (tool)
References
- Lesson W4: DLLs & Loader
- Lesson SA2: Imports & Exports
- Microsoft: Dynamic-Link Library Search Order
- KnownDLLs Registry: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
- MITRE ATT&CK: T1574.001 (DLL Search Order Hijacking)
Extensions & Challenges
- Write a script to auto-identify hijackable imports in a PE
- Test: Drop a proxy VERSION.dll that logs calls and forwards to real one
- Research: Phantom DLL hijacking (DLLs imported but not in KnownDLLs)
- Analyze: How does `App Paths` registry key affect search order?
- Build a detector for DLL hijacking via Procmon trace analysis