DLL hijacking is a cyberattack where an adversary tricks a Windows application into loading a malicious Dynamic Link Library (DLL) instead of the legitimate one. This allows the attacker to execute arbitrary code within the security context of a trusted application.
DLL hijacking exploits the way Windows searches for and loads DLLs, often prioritizing directories that are writable by users or attackers. If a malicious DLL with the same name as a legitimate library is placed in a directory searched before the actual DLL, the application will load and execute the attacker's code.
The consequences of DLL hijacking can be severe. Since many applications run with elevated privileges, a hijacked DLL can give attackers a foothold to escalate privileges, steal sensitive data, or install persistent malware. The attack does not require exploiting a software bug in the traditional sense; instead, it abuses the default DLL search order and developer oversight. This makes DLL hijacking a prevalent and persistent threat, particularly in enterprise environments.
Common variants of DLL hijacking:
In this article:
DLL hijacking can affect systems in several ways, depending on the privileges of the targeted application and the attacker's objectives. Below are common risks and impacts associated with this technique:
DLL hijacking takes advantage of the way Windows locates DLL files when an application starts. Many Windows programs rely on external DLLs to provide functions such as networking, graphics rendering, file handling, or authentication. When an application requests a DLL, Windows searches for the file in a specific order. If an attacker places a malicious DLL with the same name in a directory searched earlier, the application loads the attacker's DLL.
This is the standard Windows DLL search order (with safe DLL search mode enabled):
C:\Windows\System32.C:\Windows\System.C:\Windows.A typical DLL hijacking attack follows these steps:
Attackers often target directories where users have write access, such as download folders, temporary directories, or application installation paths with weak permissions. Portable applications and software running from network shares are also common targets because they often rely on local DLL searches.
DLL hijacking vulnerabilities are usually caused by insecure application design, unsafe DLL loading behavior, or improper system configuration.
The table below summarizes common causes that make applications vulnerable to DLL hijacking attacks, with quick tips to prevent each of them.
| Cause | Description | Mitigation Tips |
|---|---|---|
| Unsafe DLL search order | Windows may load a DLL from an untrusted location before the legitimate one. | Enable Safe DLL Search Mode; use full DLL paths. |
| Missing or unspecified DLL paths | Applications rely on the default DLL search order. | Load DLLs using absolute paths. |
| Writable application directories | Attackers can place malicious DLLs in searched folders. | Restrict write permissions on application directories. |
| Side-loading vulnerabilities | Applications load DLLs from the executable’s directory. | Validate DLLs and use application allowlisting. |
| Insecure third-party software | Outdated software may use unsafe DLL loading methods. | Update or replace vulnerable software. |
| Improper use of LoadLibrary() | DLLs are loaded without secure flags or validation. | Use secure loading APIs and flags. |
| Portable applications | DLLs are stored in local, user-accessible directories. | Store DLLs in protected locations. |
| Missing signature verification | Applications do not verify DLL integrity. | Validate digital signatures or hashes. |
| Weak file permissions | Unauthorized users can add or replace DLLs. | Harden file and directory permissions. |
| Legacy compatibility behavior | Older applications use insecure loading mechanisms. | Modernize applications and secure loading logic. |
DLL hijacking is widely practiced by attackers and there are several variants. Let’s review the most common attack types.
Search order hijacking takes advantage of the default DLL search sequence in Windows. When an application does not use a fully qualified path to load a DLL, Windows searches in a predefined order, starting with the application’s directory and moving through system and environment variable paths. Attackers place a malicious DLL in a directory that is searched before the legitimate DLL’s location.
This technique is effective against applications that run with elevated privileges or are executed by privileged users. Search order hijacking remains a common method for achieving DLL hijacking in both legacy and modern Windows environments.
DLL redirection occurs when the normal DLL loading process is modified so that an application loads a DLL from a different location than originally intended. This behavior can be enabled through registry settings or the use of a DLL redirection file. Attackers can abuse DLL redirection by configuring an application to load a malicious DLL from an alternative directory under their control.
Unlike search order hijacking, which relies on Windows finding a malicious DLL earlier in the search sequence, DLL redirection explicitly changes where Windows looks for the library. This allows attackers to execute malicious code within a trusted process while maintaining the appearance of normal application behavior.
DLL substitution involves replacing a legitimate DLL with a malicious DLL that uses the same filename and occupies the same location as the original file. When the application attempts to load the expected library, Windows loads the attacker's DLL instead, allowing malicious code to execute within the application's process.
This technique can be difficult to detect because the malicious DLL may also load the legitimate DLL it replaced and forward function calls to it. As a result, the application continues to operate normally while the attacker's code runs in the background, supporting persistence, privilege escalation, or defense evasion.
DLL side-loading involves placing a malicious DLL alongside a legitimate application or in its working directory. The attacker relies on the application to load the malicious DLL instead of the intended one, exploiting the search order. This technique is often used with signed or trusted applications, as it can help bypass security controls. Attackers may package a malicious DLL with a copy of the legitimate executable, leading users or automated processes to run the compromised program.
Side-loading relies on user trust in the legitimate application. Since the executable is signed and appears unmodified, users are less likely to suspect malicious activity. Side-loading is observed in targeted attacks, where adversaries use trusted applications to achieve code execution on high-value systems.
Remote DLL hijacking occurs when an application sets its current working directory to a remote location, such as a network share, before loading a DLL. If an attacker controls the remote location, they can place a malicious DLL there and have it loaded by the application during execution.
Because the DLL is loaded from a remote path rather than a local directory, attackers may be able to achieve code execution without directly modifying files on the target system. The malicious DLL runs with the same privileges as the application that loads it, making remote DLL hijacking useful for persistence and privilege escalation.
Phantom DLL hijacking occurs when an application attempts to load a DLL that does not exist in the expected location. Attackers exploit this by creating a malicious DLL with the required name in a directory that appears early in the search path. The application loads and executes the malicious code.
This variant often goes unnoticed because the application functions as expected while the attacker’s code runs in the background. Attackers use this method to establish persistence or escalate privileges without drawing attention.
DLL proxying is a technique in which an attacker creates a malicious DLL that exports the same functions as the legitimate one. The proxy DLL executes the attacker’s code and then passes control to the real DLL, allowing the application to continue functioning.
By acting as an intermediary, the proxy DLL can capture data, inject payloads, or alter application logic while maintaining normal operation.
Applications should load DLLs using absolute paths instead of relying on the default Windows search order. Functions such as LoadLibrary() can accept a complete path to the required DLL, ensuring Windows loads the intended file from a trusted location.
For example, loading C:\Program Files\App\library.dll is safer than loading only library.dll. Using full paths prevents attackers from placing malicious DLLs in searched directories such as the current working directory or temporary folders.
Developers should also avoid dynamically constructing DLL paths from user-controlled input. Restricting DLL loading to known, trusted directories significantly reduces the risk of hijacking.
Safe DLL search mode changes the Windows DLL search order to reduce the risk of loading malicious libraries from unsafe locations. When enabled, Windows searches trusted system directories before the current working directory.
Modern Windows systems enable SafeDllSearchMode by default, but administrators should verify the setting through the Windows Registry or Group Policy. Disabling this mode increases the likelihood of DLL hijacking attacks.
Applications can further improve security by calling functions such as SetDllDirectory("") or SetDefaultDllDirectories() to remove unsafe directories from the search process. These APIs help prevent DLL loading from attacker-controlled locations.
Application control and allowlisting restrict which executables and DLLs are allowed to run on a system. Windows native tools such as AppLocker and Windows Defender Application Control (WDAC) (now officially named App Control for Business), and utilities such as Microsoft Defender for Endpoint can block unauthorized DLLs from loading by allowing only software that meets defined trust criteria
Allowlisting policies can require DLLs to be digitally signed, originate from trusted publishers, or reside in approved directories. This prevents attackers from introducing malicious DLLs even if they gain write access to a system.
However, native controls or isolated allowlisting rules may not provide sufficient consistency or scalability in complex environments. More mature approaches focus on enforcing permitted execution across the environment in a consistent, operationally manageable way.
Restricting write access to application directories is one of the most effective defenses against DLL hijacking. Standard users should not have permission to modify files in protected locations such as C:\Program Files or system directories.
Administrators should review permissions on shared folders, temporary directories, and network locations where applications are executed. Weak permissions can allow attackers to place malicious DLLs in searched paths.
Regular permission audits help identify misconfigured directories that could be abused for DLL hijacking attacks.
Developers should design applications with secure DLL loading behavior from the beginning. This includes using secure APIs, validating DLL integrity, and avoiding deprecated loading methods.
Applications should verify digital signatures or hashes of critical DLLs before loading them. Code signing helps ensure the library has not been modified or replaced.
Security testing should include DLL hijacking assessments during development and penetration testing. Utilities such as Windows Process Monitor and other dependency analysis utilities can help identify insecure DLL loading patterns.
Windows includes a security mechanism called KnownDLLs, which defines a list of trusted system DLLs loaded directly from protected system directories. Applications using these DLLs bypass the standard search order, reducing the risk of hijacking.
The KnownDLLs list is managed by Windows and stored in the registry. Attackers generally cannot replace these protected DLLs without administrative or system-level access.
While KnownDLLs protection mainly applies to core Windows libraries, developers and administrators should understand its role in limiting DLL hijacking opportunities involving critical system components.
DLL hijacking succeeds because Windows can be tricked into loading an attacker's library inside a trusted process. Airlock Digital closes this gap by enforcing a Deny by Default model that permits only trusted applications, scripts, and processes to execute. Because Airlock Digital applies trust at the level of an application and its associated components, a malicious DLL planted in a search path is treated as untrusted code and blocked before it can run — neutralizing search order hijacking, side-loading, phantom DLL, and proxying techniques alike. This gives security and IT teams precision control over exactly what runs across their endpoint estate, at enterprise scale.
Key capabilities of Airlock Digital Application Allowlisting:
Discover how proactive execution control can stop DLL hijacking before it starts —