Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2022.

Why do adversaries use DLL Search Order Hijacking?

DLL search order hijacking offers adversaries a reliable and discrete method for persisting, elevating their privileges, and evading defensive controls. Fundamentally, the main reason that DLL search order hijacking is so popular among adversaries is that it allows adversaries to introduce malicious binaries to a host system in a way that can be exceedingly difficult to detect. Search order hijacking enables an adversary to load a malicious DLL into a process that is hosted by an otherwise legitimate, high-reputation executable. Our blog on System32 profiling offers insight into just how difficult it can be to gain visibility into and detect DLL search order hijacking. Some of this analysis is derived from that article.

How do adversaries use DLL Search Order Hijacking?

DLL search order hijacking is a complex technique whereby an adversary games the DLL search order process of the Windows operating system. Put briefly, in order for a Windows system or third-party binary to load a DLL, it has to know where that DLL exists on disk. There can be multiple versions or copies of the same DLL on any given host machine, so there are different ways that an executable can reference, locate, or load a DLL.

In many cases, an application will specify the location of the DLL it wants to run, obviating the need for the search order process altogether. The search order process is also unnecessary if the DLL is already loaded into the memory of a process. However, if an application or executable does not specify the location of the DLL it wants to load and the DLL has not been loaded into memory, then there’s a specific order of operations that an application or executable will follow to locate the DLL. This is known as the DLL search order process, which Microsoft explains in depth in its documentation.

For our purposes, all you really need to know is that the process calling the DLL will search in the directory it’s executing from before iterating through other locations in a predefined order to locate the DLL in question. In other words, if process.exe is executing from the Program Files directory and it wants to call module.dll, it’ll search through the Program Files directory before looking elsewhere.

Adversaries mostly abuse this search order process by moving legitimate system binaries into non-standard directories that include malicious DLLs that are named after legitimate ones. Sticking with the example above, if process.exe and module.dll are located in the System32 directory, then process.exe will search through that directory, find the legitimate module.dll, and run it. However, an adversary can put a malicious version of module.dll in the temp directory and move process.exe to the temp directory as well. When process.exe executes and goes looking for module.dll, it’ll grab the malicious version in the temp directory rather than the original version in the system32 directory.

The DLL search order hijacking that we detect almost exclusively follows this pattern, although there is a lot of variation in the processes that are abused, the directories they’re moved into, and the DLLs that are loaded.

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

The most reliable data sources for observing DLL search order hijacking are process monitoring and DLL load monitoring (in that order). These sources will allow you to observe when trusted processes deviate from ordinary, benign behavior, which, in turn, allows you to track the cause of bad behaviors to specific DLLs. The following telemetry sources are available via EDR and other security tooling.

Process monitoring

Process execution is an important optic for observing and developing detection analytics for DLL search order hijacking activity because search order abuse always occurs in tandem. That said, developing robust detection coverage for DLL search order hijacking will require defenders to incorporate other data sources as well.

File monitoring

Since DLL search order hijacking typically involves the relocation of system binaries, monitoring file activity for the execution or creation of processes from or in unexpected file paths is an important source of visibility. You’ll want to monitor for the execution of processes from unexpected file paths.

Module monitoring

Last but not least, module load monitoring will offer visibility into the execution of the actual malicious DLLs. Given the volume of module loads on a given machine, this can be a voluminous data source to inspect on its own, but it can provide incredible value in combination with other telemetry.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Sysmon Event ID 1: Process creation

Yet again, process creation events are among the best sources of visibility into DLL search order hijacking. The telemetry logged by this Sysmon event is valuable for capturing context related to process executables that load from non-standard directories.

Sysmon Event ID 7: Image loaded

Image load events are extremely valuable in supplying evidence of DLL search order hijacking as well. This log needs to be enabled, but it will record all processes that load DLLs along with corresponding hashes, signatures, and other information.

Windows Security Event ID 4688: Process Creation

Process Creation (4688) events with command-line argument logging enabled is a great source of telemetry for process starts and commands lines—or, as is often the case with process injection, a lack thereof.

Weeding out false positives

Looking for any generic process loading a DLL from its same folder sounds like a good idea. Unfortunately, this will create tons of false positives from Windows System32 and Program Files folders. Target your detection toward user-writable folders like temp or appdata/roaming for the best results.

We have nearly 600 detection analytics mapped to DLL Search Order Hijacking, nearly all of which are conceptually identical. Detection for this technique is relatively easy to describe but incredibly difficult to operationalize: Alert whenever a process executes from a file path other than the one you would expect it to in your environment. This, of course, is easier said than done because it requires you to track expected file paths and compare them to file paths of processes as they execute in real time.

Execution from unexpected file paths

Detection of DLL search order hijacking is based primarily on process executions that deviate from their expected file paths. The following pseudo-analytic is just one example using an arbitrary process. You can adjust the logic to apply to nearly any process that’s a common proxy for DLL search order hijacking.

Start testing your defenses against DLL Search Order Hijacking using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View Atomic tests for T1574.001: DLL Search Order Hijacking. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using Command Prompt:

Useful telemetry will include: