One Chokepoint, Three Loaders

From Normal DLL Loading to DLL Hijacking

A Windows application rarely contains every function it needs. Instead, it can use dynamic-link libraries, or DLLs, that provide reusable code and data. An application might rely on DLLs for graphics, cryptography, networking, or retrieving file-version information. This allows multiple programs to use common functionality without implementing all of it independently.

Applications commonly use DLLs through load-time or run-time linking.

Load-time linking

With load-time linking, information about required DLLs and imported functions is placed in the executable's Portable Executable, or PE, structure when the program is built. The PE Import Directory identifies these dependencies. When Windows starts the program, the loader resolves the required DLLs and imported functions. It then places the resolved functions' memory addresses into the Import Address Table, or IAT. The program uses those addresses when it calls the imported functions.

In simple terms, the Import Directory is a list of contacts the program expects to need, while the IAT becomes the completed address book that tells the program where those contacts can be reached in memory. This analogy is simplified, but it gives us enough context to understand the loading process. Microsoft describes these structures in its PE format specification.

Run-time linking

Run-time linking happens after the program has already started. When the program needs a DLL, it can call LoadLibrary or LoadLibraryEx. Windows attempts to locate the requested module and map it into the program's virtual address space. If the operation succeeds, the function returns a handle representing the loaded module.

An exported function is a function that a DLL intentionally makes available for other code to call. The program can pass the DLL handle and the exported function's name to GetProcAddress, which returns the function's memory address. The program then uses that address to call the function. If the requested module is already loaded under the applicable conditions, Windows may return a handle to the existing module rather than mapping another copy. Microsoft explains this process in Run-Time Dynamic Linking.

Once a DLL is mapped into a process, its code does not run as a separate program. If a newly loaded DLL defines an entry point, Windows calls it with a DLL_PROCESS_ATTACH notification. This entry-point function is commonly named DllMain and gives the DLL an opportunity to perform limited initialization. DLL code can also execute later when the application calls one of its exported functions.

In either case, the code executes inside the loading process and under that process's existing security context. Mapping a DLL does not automatically give the process additional privileges. Microsoft documents this behavior in its LoadLibrary and DllMain documentation.

How Windows identifies the requested DLL

Now that we understand how a DLL becomes part of a process, the next question is how Windows decides which DLL file to load.

An application can identify a DLL in three basic ways:

• Full pathC:\Program Files\Example\version.dll
• Relative pathplugins\version.dll
• Bare filenameversion.dll

A full path normally directs Windows to a particular location. A relative path still requires interpretation using directory context. A bare filename identifies the requested module but does not specify where its file is located.

When an application does not provide a fully qualified path, Windows may need to resolve the DLL's location. This does not mean that every application follows one universal folder list. Depending on the loading context, Windows may consider DLL redirection, API sets, side-by-side manifests, modules already loaded into the process, KnownDLLs, package dependencies, loader configuration, and eligible search directories.

The result can also depend on whether the application is packaged or unpackaged and whether it uses functions or flags that modify the default search behavior. For an analyst, the important question is not simply, “What is the DLL search order?” It is, “Which resolution rules applied to this particular load, and which file did Windows ultimately select?” Microsoft documents these factors in Dynamic-link library search order.

Where side-by-side loading fits

Side-by-side loading is one legitimate factor that can influence DLL resolution. Windows uses side-by-side assemblies to support applications that require different versions of shared components. An application manifest identifies the assemblies and versions to which the application should bind at run time. This helps prevent one application's installation from replacing a component required by another application.

For an analyst, this means that a simple directory search may not explain every DLL selection. If the observed DLL path appears unusual, the application's manifest may help explain why Windows selected that component. Side-by-side loading is legitimate Windows behavior and should not be confused with the attacker technique known as DLL side-loading. Microsoft explains the legitimate mechanism in its documentation on application manifests and side-by-side assembly sharing.

How normal DLL loading becomes an attack opportunity

These normal loading decisions can create opportunities for abuse. Suppose an application requests a DLL without fully identifying its intended location. If an attacker can write to an eligible location, they may place a malicious DLL there using the filename the application expects.

When the application runs, Windows applies the resolution rules relevant to that load. If Windows selects the attacker-controlled file, it maps the DLL into the application's address space. Code from the DLL can then execute inside the application's process context. Microsoft describes this risk in Dynamic-Link Library Security.

However, placing a DLL somewhere on disk is not enough by itself. Several conditions must come together before DLL hijacking can succeed.

What must be true for DLL hijacking to work?

First, the application must request or resolve a DLL in a way that gives an attacker-influenced file a chance to be selected. The attacker must be able to place or replace a DLL in an eligible location and cause the susceptible application to run.

The supplied DLL must also be compatible with the loading process. For example, a 32-bit process cannot load a 64-bit DLL, and a 64-bit process cannot load a 32-bit DLL. Depending on how the application uses the library, the attacker-controlled DLL may need to provide expected exports or preserve enough legitimate functionality for the application to continue running.

If the DLL is selected successfully, its code executes within the host process's existing security context. This does not automatically create persistence or elevate privileges. Persistence requires a repeatable execution trigger. Privilege escalation depends on whether the host process runs with privileges the attacker does not already possess and whether the attacker can satisfy the other conditions required for the DLL to load. (Microsoft: DLL Security; Microsoft: Process Interoperability; MITRE ATT&CK T1574.001)

The stronger defensive signal is the relationship between file placement, process execution, DLL selection, module loading, and subsequent behavior.

DLL search-order hijacking

DLL search-order hijacking occurs when an attacker influences which matching DLL Windows finds during resolution. If an application requests a DLL without a fully qualified path, Windows applies the rules and eligible directory order relevant to that load.

An attacker who can write to an earlier eligible location may place a DLL there using the requested filename. If Windows encounters that file before the intended library, it may select and load the attacker-controlled copy.

MITRE ATT&CK describes this behavior as planting a trojan DLL in a location prioritized over the legitimate library. Microsoft independently documents how control of a searched directory can allow an attacker to supply a matching DLL. (MITRE ATT&CK T1574.001; Microsoft: DLL Security)

Search-order behavior can also play a role in the next technique, but DLL side-loading describes a more recognizable attacker setup.

DLL side-loading

DLL side-loading uses a legitimate application to load an attacker-controlled DLL. The attacker commonly places a legitimate executable and malicious DLL together and then runs the executable. When the executable requests its expected DLL, normal loader behavior may cause Windows to select the nearby attacker-controlled copy.

The executable may be correctly signed, but that signature applies to the executable. It does not automatically authenticate the separate DLL or make the combined behavior trustworthy.

Analysts should determine whether the executable is running from its expected installation directory, whether the executable and DLL arrived together, and whether the process normally loads that DLL from that location. MITRE describes side-loading as positioning a legitimate application and malicious payload together so that the application loads the payload. (MITRE ATT&CK T1574.001)

Search-order hijacking and side-loading can overlap. Search-order hijacking describes the loader behavior that causes an unintended DLL to be selected. Side-loading describes the attacker's setup: pairing a legitimate executable with an attacker-controlled DLL.

Phantom DLL hijacking

Phantom DLL hijacking targets an application's reference to a DLL that is not normally present. The application may attempt to find an optional, removed, or otherwise missing DLL in several eligible locations. If an attacker identifies that behavior and can write to a suitable location, they may provide a DLL using the missing module's expected name. The application may then load the attacker-supplied file during a later execution.

Procmon might reveal the original searches as NAME NOT FOUND events. These events are common and show only that a file lookup failed. They do not independently prove that the application is exploitable or that an attack occurred.

Stronger evidence would connect the failed searches to the later creation and successful loading of the matching DLL. MITRE's detection strategy follows the same principle by correlating file creation, process creation, and module-load telemetry rather than treating one failed lookup as proof. (MITRE ATT&CK T1574.001; MITRE Detection Strategy DET0201)