One stage in the attack life cycle is evading solutions that the defender has in place to detect or protect against an intrusion. One method for accomplishing this on Windows systems is DLL search order hijacking.
What is DLL search order hijacking?
Windows executables often implement good object-oriented programming (OOP). Each standalone application may have its own individual functionality built in, but common functionality is encoded in libraries called DLLs. When an object wants to access this shared functionality, it loads the appropriate DLL into its memory space. However, these executables may not always be aware of the exact location of the DLL on the file system. To deal with this, Windows has implemented a search order of different directories where these DLLs can be found. The search order depends on whether or not the app originated from the Windows store. DLLs for Windows Store apps are searched for:
Based on the application’s package dependency graph In the directory of the calling progress
In the directory of the calling module if an alternative search path is requested
The System directory (Windows/system32)
DLLs for desktop applications not from the Windows Store are searched for in directories in the following order (if SafeDLLSearch is enabled):
Directory from which the application loaded The System directory (retrieved using GetSystemDirectory) The 16-bit System directory The Windows directory (retrieved using GetWindowsDirectory) The current directory
This is searched second if SafeDLLSearch is disabled by the user
Directories listed in the system path
DLL search order hijacking takes advantage of this load process to load malicious DLLs in place of legitimate ones. If an application uses Windows’ DLL search to find a DLL and the attacker can place an identically-named DLL higher in the order than the legitimate one, the malicious DLL will be loaded by the application. This allows the attacker to run malicious code within a trusted process and may enable privilege escalation if the vulnerable application is running with higher privileges than the attacker has.
Examples of DLL search order hijacking
Many different malware variants either actively use DLL search order hijacking or have the built-in capability to search for and exploit applications that are vulnerable to this attack. One example is Empire, an open-source framework for remotely controlling and expanding the attacker’s footprint on systems after the initial compromise. The source code of Empire is freely available on Github and is in use by several different APTs and hacking groups. As a post-exploitation framework, Empire has several different modules designed to perform data collection and further exploitation on compromised systems. One of these modules is designed to scan for and exploit opportunities to perform DLL search order hijacking.
Detection and mitigation
DLL search order hijacking is designed to hide malicious code within the memory space of legitimate processes. The means of accomplishing this is simple, and there are several different techniques for detecting and protecting against this attack.
Enable SafeDLLSearch
SafeDLLSearch is a feature that changes the order in which Windows will search directories for a particular DLL. Enabled by default, SafeDLLSearch moves the current directory down the list of locations to search until after the application’s load directory and the Windows and System directories. Since these directories are more protected than the current directory, this decreases the attacker’s ability to place a malicious DLL high enough in the search order.
Scan for vulnerable applications
Several malware variants and tools have the ability to search for applications that are vulnerable to DLL search order hijacking. Using one of these tools, like the Powersploit framework, can help with the detection of potentially vulnerable applications. Once these applications are located, additional monitoring or protections can be put in place to prevent them from being exploited.
Scan for file and directory modifications
DLL search order hijacking relies on the attacker’s ability to place a malicious DLL higher in the search order than legitimate ones. Monitoring for changes in the directories included in the search list, especially the creation of files with the same names as existing DLLs, can help to detect attempts to exploit this vulnerability. Some attackers may attempt to force an application to load a malicious DLL by replacing the legitimate version or changing the application’s redirection file to point to the malicious DLL. Monitoring file hashes can help with detection of either of these two techniques.
Monitor for changes in loaded DLLs
A successful DLL hijacking attempt results in a malicious DLL being loaded into an application in place of a legitimate one. Monitoring of the file hashes and locations of the DLLs loaded into an application can help to detect this switch.
Disallow loading of remote DLLs
One option in the Windows DLL search order hierarchy is the current directory. Since this is under the attacker’s control, it is possible for the attacker to point it to a remote location where a malicious DLL file is saved. This saves them the trouble of saving the DLL on the device but can be prevented by disallowing loading of remote DLLs.
Protecting against DLL search order hijacking
DLL search order hijacking is a simple but effective attack that takes advantage of how Windows handles DLLs to allow an attacker to load malicious code into a legitimate process. A successful attack conceals the malicious code and may allow the attacker to escalate privileges on the system if the targeted process has elevated privileges. The ability to scan for and exploit this functionality is included in a variety of different malware variants. However, it can be easily detected by monitoring for attempts to place the malicious DLL high in the search order.
Sources
DLL Search Order Hijacking, MITRE Dynamic-Link Library Search Order, Microsoft Empire, MITRE
