DLL (T1574.001) is a Windows sub-technique of Hijack Execution Flow, in the stealth and execution tactics. Adversaries abuse dynamic-link library files for persistence, privilege escalation and defense evasion. MITRE is careful to say DLLs are not malicious by nature. A DLL is a library of code and data that several programs can share. The abuse comes from how programs find and load them.
MITRE names three mechanisms: side-loading, search order hijacking and phantom DLL hijacking.
How attackers use it
DLL side-loading. The adversary hijacks which DLL a program loads by planting their own payload next to a legitimate application, then running that application. Victim application and malicious payload sit side by side. MITRE explains why this is attractive: the actions are masked under a legitimate, trusted and possibly elevated process. A benign executable used for side-loading may not be flagged on delivery or execution, and the payload may be encrypted, packed or otherwise obfuscated until it is loaded into the memory of the trusted process. MITRE also notes BPLs (Borland Package Library files) can be side-loaded the same way.
Chained loading. Adversaries may chain side-loading several times to fragment functionality and slow analysis. A main DLL can load export functions from other DLLs, or a malicious DLL can exist only to load a second one. Analysts need every file to understand the behavior.
Search order hijacking and phantom DLLs. These abuse where Windows looks for a library, or a library a program asks for that is not actually present.
The pattern: the process is signed and familiar, and the malicious code rides inside it.
How to detect it
MITRE's strategy centers on module loads and the file system around them. Behaviors to watch include:
- DLLs loaded from non-standard directories
- Replacement of existing DLLs
- Phantom DLL insertion
- Creation of redirection files
- Substitution of legitimate DLLs
The defender correlates file system changes, registry changes and module load telemetry to spot abnormal DLL behavior inside trusted processes.
In practice that means three data streams. File creation events tell you a DLL appeared. Module load events tell you which process pulled it in and from which path. Registry changes cover settings that alter load behavior. Any one alone is noisy. Together they are specific: a well-known application, started from an unusual folder, loading a DLL that was written minutes ago.
Useful questions for hunting:
- Is a signed, well-known executable running from a user-writable folder such as a download or temp directory?
- Is it loading a library from its own folder rather than the system directory?
- Is the library unsigned, or newly created?
How to reduce the risk
MITRE lists these mitigations.
- Execution prevention. Use application control that can block DLLs loaded by legitimate software, such as the controls AppLocker provides for DLL rules.
- Restrict library loading. Disallow loading of remote DLLs (default on Windows Server 2012 and later). Enable Safe DLL Search Mode so the current folder is searched later in the order. It is on by default in modern Windows, and the registry key sits under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager.
- Update software. Patch applications regularly, since updates fix side-loading weaknesses.
- Audit. Use tools that detect DLL search order hijacking opportunities and correct them. MITRE mentions PowerUp from the PowerSploit toolkit and the sxstrace.exe program included with Windows, plus manual inspection of manifest files.
- Application developer guidance. Include hash values in manifest files where possible to help prevent side-loading of malicious libraries.
Developers can do the most about this. Load libraries by absolute path, and ship with manifests that pin what you expect.
Check your own environment
# Windows cmd: Safe DLL Search Mode (absent means the OS default applies)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode
# Windows PowerShell: list loaded modules of one process, with paths (replace the name)
Get-Process -Name notepad | Select-Object -ExpandProperty Modules | Select-Object ModuleName,FileName
Checklist:
- Is application control enforced for DLLs, or only for executables?
- Do you collect module load events (Sysmon event ID 7, if you deploy Sysmon)?
- Which applications on your build images ship with their DLLs in user-writable folders?
- Do your own applications load libraries by absolute path?
- Are third-party applications patched on a regular schedule?
Quick check
Why is side-loading attractive to an adversary?
The malicious code runs under a legitimate, trusted and possibly elevated process, and the benign host executable may not be flagged on delivery or execution.
Which three event types does MITRE suggest correlating?
File system modifications, registry changes and module load telemetry.
What is a phantom DLL?
A library a program tries to load that does not actually exist on the system, so an attacker can supply one under that name. MITRE lists phantom DLL hijacking as one of the abuse mechanisms.
