DLL Search Order Hijacking
DLL Search-Order Hijacking is a technique that exploits the specific sequence Windows uses to locate and load Dynamic Link Libraries (DLLs). Attackers manipulate this sequence to ensure that their malicious DLLs are loaded instead of legitimate ones, allowing them to execute arbitrary code within the context of the targeted application. Here’s a detailed breakdown of how this hijacking works:
Understanding DLL Search Order in Windows
When an application requires a DLL, Windows follows this search order to locate it:
Application Directory: Windows first looks in the directory from which the application is loaded.
System Directory: If not found in the application directory, Windows searches in the system directories such as System32.
Windows Directory: The Windows directory is next in line for the search.
Current Directory: The current working directory of the application is then checked.
Directories listed in the PATH environment variable: Lastly, Windows searches directories listed in the PATH environment variable.
Exploiting the Vulnerability
Attackers exploit this predictable search order by placing a malicious DLL in a directory that is searched before the legitimate DLL’s location. This can be done in several ways:
Placing Malicious DLLs in Application Directories: Attackers place a malicious DLL in the same directory as the application executable or in a directory that is searched first. This ensures that Windows loads the malicious DLL before the legitimate one.
Hijacking Known DLLs: Attackers replace or mimic commonly used DLLs such as user32.dll or kernel32.dll with their malicious versions. These DLLs are often targeted because they are loaded by many applications.
Using Unsigned or Improperly Signed DLLs: Exploiting the absence or improper use of digital signatures on DLLs, attackers can replace legitimate DLLs with malicious ones.
Modifying the PATH Environment Variable: Attackers can modify the PATH environment variable to include directories they control. This manipulation ensures their malicious DLLs are found and loaded before legitimate ones from other locations.
DLL Preloading (Binary Planting): This involves placing a malicious DLL with the same name as an ambiguously specified DLL in a directory that Windows searches before the legitimate DLL’s directory.
Steps in a DLL Search-Order Hijacking Attack
Identify Vulnerable Applications: Attackers first identify applications that load DLLs using relative paths or have writable directories in the search path.
Create a Malicious DLL: A malicious DLL is crafted to mimic a legitimate one, often using the same filename, version information, and exported functions. This is known as DLL mimicking.
Plant the Malicious DLL: The malicious DLL is placed in a directory that will be searched before the directory containing the legitimate DLL. Common targets include the application directory, directories in the PATH environment variable, or exploiting writable directories.
Execute the Application: When the vulnerable application is launched, it attempts to load the required DLLs. Due to the manipulated search order, Windows loads the malicious DLL first, leading to the execution of the attacker's code.
Indicators of DLL Search-Order Hijacking
File System Indicators
Unusual DLL Load Paths: Monitoring for DLLs loaded from non-standard directories is critical. Typical directories for legitimate DLLs include C:\Windows\System32 or C:\Windows\SysWOW64. When DLLs are found in user directories, temporary folders, or network shares, it may indicate an attempt to hijack the DLL search order. For example, if a DLL is found in C:\Users\<username>\AppData\Local\Temp, this should raise suspicion as this directory is not standard for critical DLLs.
Unexpected Creation or Modification of DLLs in Application Directories: Detecting unauthorized changes to DLL files in directories where legitimate applications are installed is essential. Tools like file integrity monitoring systems can alert when new DLLs are created or existing ones are modified in application directories. For instance, if a DLL in C:\Program Files\<application>\ is changed outside of normal update cycles, it could be a sign of hijacking.
DLLs Loaded from Writable Directories: Writable directories are particularly vulnerable because attackers can place malicious DLLs there. Monitoring for DLLs loaded from directories writable by non-administrative users, such as C:\Users\<username>\, helps identify potential hijacking attempts. Attackers may exploit these writable locations to insert malicious DLLs into the search order.
Unsigned or Improperly Signed DLLs: Legitimate DLLs are typically signed by their publishers to verify authenticity. Identifying DLLs lacking proper digital signatures or having signatures that do not match the legitimate vendor can signal malicious activity. Tools that verify digital signatures can help detect and block unsigned or improperly signed DLLs from loading.
Registry Indicators
Changes to Known DLLs Registry Keys: The registry keys controlling DLL loading are critical points of monitoring. Keys like HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs dictate which DLLs the system uses. Unauthorized modifications to these keys can redirect the system to load malicious DLLs. Regular monitoring of these keys for any changes is essential.
PATH Environment Modifications: The registry settings that influence the DLL search order or load paths, such as changes to the PATH environment variable (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path), are crucial to monitor. Unauthorized changes to these settings can ensure malicious DLLs are prioritized over legitimate ones.
Process Monitoring Indicators
Processes Loading DLLs Not Typically Associated with Them: Detecting when processes load DLLs not normally used by that process can highlight hijacking attempts. Each process typically has a set of DLL dependencies. Deviations from these known dependencies should trigger investigations to determine if a malicious DLL is being loaded.
Multiple Applications Loading the Same Unexpected DLL: Instances where the same potentially malicious DLL is loaded by various applications suggest widespread hijacking. For example, if several unrelated applications start loading a DLL from a new directory simultaneously, this pattern indicates that the DLL may have been strategically placed to affect multiple applications.
Processes Operating with Elevated Privileges After Loading DLLs: Identifying instances where processes gain higher privileges after loading DLLs can indicate hijacking for privilege escalation. Malicious DLLs may exploit vulnerabilities to increase their privileges within the system, making this a critical indicator to monitor.
Command Line Indicators
Suspicious Command-Line Arguments: Analyzing command lines for commands that load or manipulate DLLs is crucial. Commands involving the copying, registration, or manipulation of DLLs, especially those pointing to user-writable or non-standard directories, should be flagged. For example, a command like regsvr32 /s /i:<DLL path> in an unusual context can be suspicious.
Behavioral Indicators
Sudden Changes in Application Behavior After Loading DLLs: Monitoring for unexpected changes in application behavior, functionality, or performance immediately after loading DLLs helps identify hijacking. Sudden crashes, unexpected errors, or altered functionalities post-DLL load can be indicative of malicious activity.
Abnormal Network Activity After DLL Loads: Unexpected network connections or data transfers initiated by processes immediately after loading DLLs are critical to watch. Malicious DLLs often attempt to communicate with external servers or exfiltrate data, making network activity a key indicator of hijacking.
Memory and Metadata Indicators
Discrepancies Between Loaded DLLs and On-Disk DLLs: Comparing DLLs loaded into memory with their on-disk counterparts helps detect in-memory tampering. Mismatched hashes, sizes, or other properties between loaded DLLs and their on-disk versions can indicate the presence of a malicious DLL.
DLLs with Mismatched File Metadata: Checking DLL file properties, such as creation dates, modification times, or author information, for inconsistencies can help detect tampering. Mismatched metadata between expected and actual values may indicate a malicious DLL.
Processes Loading DLLs with Unusual Export Functions: Analyzing the exported functions of loaded DLLs for unexpected or suspicious names, parameters, or functionalities can indicate hijacking. Malicious DLLs often export functions that deviate from the legitimate ones.
Last updated