DLL Search Order Hijacking is a technique where a program loads a malicious DLL from an earlier search location instead of the intended library. Attackers use it for code execution and persistence, so defenders should use safe DLL search settings, signed libraries where possible, and monitor for unexpected DLL loads in application directories.
How DLL search order hijacking works
dll search order hijacking happens when a program loads a library from the wrong location because Windows checks search paths in sequence. The technique is simple, but it is effective because many applications assume the first matching DLL is the intended one.
Attackers usually place a malicious DLL where the application will look before the legitimate copy, such as the current working directory or another writable location. That turns a normal load operation into code execution without changing the executable itself.
Why it is dangerous
The security problem is not the DLL format itself, but the trust placed in path resolution. When an application loads libraries without strict path control, an attacker can influence what code runs inside a trusted process, often with the process’s own privileges.
This makes the technique attractive for stealthy persistence and for blending into legitimate application activity. The malicious DLL can run whenever the host application starts, so the compromise may look like an ordinary program launch unless defenders inspect the load chain closely.
Where defenders should look for exposure
Exposure is highest where applications load DLLs from directories that users can write to, or where software relies on relative paths and incomplete library names. The risk increases when legacy applications, third-party tools, or loosely configured plugins search broad directories before system locations.
Defenders should review software inventory, identify writable application paths, and compare expected DLL load behavior against what the process actually loads at runtime. Vendor advisories and threat research on search order abuse provide useful guidance for spotting applications that are especially sensitive to this issue.
Controls and detection priorities
Safe library loading begins with reducing ambiguity in the search path. Applications should use secure DLL search settings, prefer explicit full paths for trusted libraries, and avoid loading from user-writable directories unless there is a strong design reason to do so.
Signed libraries help, but signature checks alone do not solve path hijacking if the application still accepts the wrong file from the wrong place. Defenders should also watch for unexpected DLL loads in program directories, unusual child processes that appear alongside library loading, and new files that match common library names but do not belong to the installed software.
Post-incident review should include the host process, the load path, and any persistence mechanism the attacker used to keep the malicious library in place. The MITRE ATT&CK DLL search order hijacking technique is a useful reference point for mapping observed behavior to adversary tradecraft, and the Persistence Techniques Guide helps place this abuse within the broader persistence landscape.
Risk and Threat Considerations
DLL search order hijacking is dangerous because it converts routine application loading into a local code execution path. If the targeted program runs with elevated rights or starts automatically, the attacker can gain persistence and a reliable execution foothold without exploiting a memory corruption bug.
Failure mechanism: An attacker drops a malicious DLL in a location that the application searches before the legitimate library, causing the program to load attacker-controlled code.
Impact: The malicious DLL executes in the context of the trusted application, which can enable persistence, privilege abuse, and follow-on compromise of the host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1574.001 — DLL Search Order Hijacking | Directly names this technique as an adversary persistence and execution method |
| Recommendation — Map suspicious DLL loads to T1574.001 and hunt for writable search-path abuse in the affected host process. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Supports secure handling of library loading and path-control flaws in software |
| SI-7 — Software, Firmware, and Information Integrity | Covers integrity monitoring for unexpected code and tampered libraries | |
| Recommendation — Test application loading behavior to prevent unsafe DLL search paths before release. Monitor for unexpected DLL replacements and alert on integrity changes in application directories. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Supports detection of malicious libraries and suspicious execution from trusted processes |
| CIS-8 — Audit Log Management | Useful for tracking anomalous library loads and host execution patterns | |
| Recommendation — Scan for and quarantine malicious DLLs loaded from nonstandard or writable locations. Log DLL load events and review abnormal module paths during incident investigation. | ||
Practitioner Guidance
Why practitioners should care: This technique is often missed when teams focus only on executable hashes or traditional startup items. The real control point is library resolution, so software review needs to include where DLLs are searched for and whether those locations are writable by untrusted users.
What to watch for: Repeated library loads from unexpected directories, DLL names that mirror legitimate system components, and application-specific folders that suddenly contain executable library files are all strong signals worth investigating.
Practitioner takeaway: Treat unexpected DLL loading as both a prevention and detection problem, because once the wrong library is chosen, the application itself becomes the attacker’s delivery mechanism.
Related resources from NHI Mgmt Group
- Why do attacker packages that abuse DLL search order hijacking create such a high-risk execution path?
- How should security teams eliminate DLL search-order hijacking in Windows services that run with elevated privileges?
- Why does DLL search-order hijacking create such serious risk in services that run as SYSTEM?
- What are the signs that a Windows service is vulnerable to DLL search-order hijacking?