When a process is executed, its associated DLLs are loaded into the process memory (either via an import table or as a result of the process calling the LoadLibrary() API). The Windows operating system searches for the DLL to be loaded in a specific order in the predefined locations. The search order sequence is documented in the MSDN here: http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx.

In short, if any DLL has to be loaded, the operating system first checks if the DLL is already loaded in the memory. If yes, it uses the loaded DLL. If not, it checks if the DLL is defined in the KnownDLLs registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs). The DLLs listed here are system DLLs (located in the system32 directory), and they are protected using Windows file protection to ensure that these DLLs are not deleted or updated except by the operating system updates. If the DLL to be loaded in is in the list of KnownDLLs, then the DLL is always loaded from the System32 directory. If these conditions are not met, then the operating system looks for the DLL in the following locations in sequential order:

1. The directory from where the application was launched.
2. The system directory (C:\Windows\System32).
3. The 16-bit system directory (C:\Windows\System).
4. The Windows directory (C:\Windows).
5. The current directory.
6. Directories defined in the PATH variables.

Adversaries can take advantage of how the operating system searches for the DLL to escalate privilege and to achieve persistence. Consider the malware (Prikormka dropper) used in Operation Groundbait (http://www.welivesecurity.com/wp-content/uploads/2016/05/Operation-Groundbait.pdf). This malware, upon execution, drops a malicious DLL called samlib.dll in the Windows directory (C:\Windows), as follows:

[CreateFile] toor.exe:4068 > %WinDir%\samlib.dll

On a clean operating system, a DLL with the same name (samlib.dll) resides in the C:\Windows\System32 directory and this clean DLL is loaded by explorer.exe, which resides in the C:\Windows directory. The clean DLL is also loaded by few other processes which reside in the system32 directory, as shown here:

Since the malicious DLL is dropped in the same directory as explorer.exe (which is C:\Windows), as a result, when the system reboots, the malicious samlib.dll is loaded by explorer.exe from the C:\Windows directory instead of the legitimate DLL from the system32 directory. The following screenshot, taken after rebooting the infected system, displays the malicious DLL loaded by explorer.exe as a result of DLL search order hijacking:

The DLL search order hijack technique makes forensic analysis much harder and evades traditional defenses. To detect such attacks, you should consider monitoring the creation, renaming, replacing, or deletion of DLLs and look for any modules (DLLs) loaded by the processes from abnormal paths.