DLL hijacking happens when attackers sneak a malicious DLL file into a place where Windows applications look for required files. The system then loads their code instead of the real DLL, giving attackers a foothold in your environment.
DLL hijacking is a classic technique for exploiting how Windows applications search for and load Dynamic Link Library (DLL) files. Attackers use this weak spot to escalate privileges, steal data, or run stealthy payloads. Even though it dates back to Windows 2000, DLL hijacking remains a real threat for enterprises, red teams, and anyone defending a Windows environment.
DLL hijacking is when a Windows application loads a malicious DLL (Dynamic Link Library) instead of a legitimate one, because the attacker has placed their DLL where the system expects to find the original. This trick works because many applications don’t specify the full, trusted path to their needed DLLs. Instead, they rely on Windows’ default search order, which isn’t always secure. The result? The attacker’s code runs with the same privileges as the application, opening doors for bad actors.
Gain unauthorized access or control
Escalate user privileges
Maintain stealthy persistence
Deploy malware while evading detection
Want to know how attackers pull off DLL hijacking? Here’s how it typically goes down:
Find a target: Attackers look for applications that load DLLs without specifying where to find them.
Craft a malicious DLL: They write a bad version of the DLL, often mimicking the real DLL’s name and exports.
Place the DLL: The attacker drops the malicious DLL into a directory Windows will check (like the app’s own folder).
Launch or trigger the App: When the application starts, Windows searches for the DLL and finds the attacker’s copy first.
Code execution: Boom. The attacker’s code runs, often with the same permissions as the application itself.
A lot of software, especially older or poorly coded apps, doesn’t use fully qualified paths for DLLs. This means Windows has to hunt for the file, following a set search order. If the attacker can get their file in early in the search list, the system loads up the malicious code without a second thought.
DLL stands for Dynamic Link Library. These files are like toolkits for Windows applications, packed with functions and resources apps need to work.
DLL files usually end in .dll, but sometimes you’ll see variants like .drv or even .exe.
They can’t be launched directly; they get called by apps as needed.
One DLL can serve many programs, meaning a single bad DLL can infect multiple apps if hijacked.
For Microsoft’s take, see their official docs.
DLL hijacking is more than just sneaky; it’s effective.
Privilege escalation: Malicious code can run with system or admin privileges if the hijacked app runs at a high level.
Code Execution: Attackers can execute any code they want within your environment.
Persistence & stealth: Since many Windows apps auto-start, DLL hijacking can persist through reboots.
It’s stealthy, too. Often, defenders see only legitimate processes running.
Attackers have used DLL hijacking in the wild for years, including in high-profile attacks.
Stuxnet: This industrial sabotage worm used DLL hijacking to bypass detection and spread within nuclear facilities.
WannaCry: While best known for its ransomware, variants also exploited DLL search order flaws.
SolarWinds Attack: The notorious 2020 breach saw attackers slip in a weaponized DLL digitally signed (see CISA’s alert.)
CVE-2016-3213, CVE-2020-1300: Multiple CVEs track DLL hijacking bugs in high-profile software, including Microsoft Office and Adobe products.
Public Proof-of-Concepts: Tools and scripts on GitHub, like DLLSpy, can demonstrate or test DLL hijacking potential.
Defenders have several options for spotting this classic threat:
Process Monitor: Use Process Monitor (part of Sysinternals Suite) to track DLL loads.
Filters: Apply filters for “NAME NOT FOUND” or DLLs loaded from non-standard directories.
Endpoint Detection and Response (EDR) Platforms: Modern EDRs can spot suspicious loads and block unknown DLLs.
Review Logs: Look for applications suddenly loading DLLs from directories not used before.
Pro tip: Establish a baseline for normal DLL activity so you’re more likely to catch anomalies.
Attackers (and sometimes red teamers or bug hunters) scope out apps for hijacking vulnerabilities by:
Monitoring DLL search paths: They look for missing or insecure paths.
Reverse engineering: Dissecting app binaries to see how and where they load DLLs.
Fuzzing: Automated tools can inject test DLLs into various app directories and see what sticks.
Reading public reports: Security advisories often detail which apps are at risk, making them easy prey.
Prevention takes teamwork:
Use fully qualified paths: Always specify the full path to required DLLs.
Sign DLLs: Use digital signatures so only trusted files get loaded.
Secure coding practices: Explicitly load libraries, avoid relative paths, and review code for unsafe loading.
Application whitelisting: Only allow known-good applications and DLLs to run.
File integrity monitoring: Alert on changes to DLLs in sensitive directories.
Education & policy: Train users on the dangers of phishing and social engineering to prevent DLL drop-offs.
Vendor risk management: Ensure third-party software follows best practices.
For more defense info, check out NIST’s guidance on secure software development (NIST SP 800-218).
Absolutely. While more apps use safer coding practices, DLL hijacking:
Remains a go-to method for red teams and real attackers alike
Is actively leveraged in sophisticated Advanced Persistent Threat (APT) operations
Pops up in bug bounties, CTFs, and legit vulnerability research
Still impacts both legacy and surprisingly modern applications
DLL Hijacking
Exploits how an app finds and loads a DLL.
The attacker relies on the application (not the attacker) to launch the malicious DLL.
Uses the search order weakness.
DLL Injection
Actively forces a process to load a new DLL (often via tools or code).
Can target running processes.
Technique is different and sometimes noisier.
DLL hijacking is almost exclusively a Windows problem because DLLs are a Windows-native feature. Other platforms may have similar library loading issues (think .so files on Linux or .dylib on macOS), but “DLL hijacking” proper is a Windows-specific beast. See CISA’s library loading advisory for more context.
DLL hijacking is a time-honored attack that continues to pose a risk to Windows environments everywhere. Even well-mannered organizations have fallen victim. Prevention is key! Prevention includes strong deployment practices, vigilant monitoring, and regular user education. Detection relies on understanding DLL loading behavior and watching for oddities.
