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
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
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.