T1038: DLL Hijacking / Injection
When an application needs to use any DLL file, it has to search for it. If an attacker replaces own DLL file with the name that the application is searching for, then it may lead to DLL Injection.
Last updated
When an application needs to use any DLL file, it has to search for it. If an attacker replaces own DLL file with the name that the application is searching for, then it may lead to DLL Injection.
Last updated
As per ATT&CK, Windows systems use a common method to look for required DLLs to load into a program. [1] Attacker can take the advantage of the Windows DLL search order and programs that ambiguously specify DLLs to gain privilege escalation and persistence.
Attacker can perform DLL preloading, also called binary planting attacks, [2] by placing a malicious DLL with the same name as an ambiguously specified DLL in a location that Windows searches before the legitimate DLL. Often this location is the current working directory of the program. Remote DLL preloading attacks occur when a program sets its current directory to a remote location such as a Web share before loading a DLL. [3] Attacker can use this behavior to cause the program to load a malicious DLL.
Attacker can also directly modify the way a program loads DLLs by replacing an existing DLL or modifying a .manifest or .local redirection file, directory, or junction to cause the program to load a different DLL to maintain persistence or privilege escalation. [4] [5] [6]
If a search order-vulnerable program is configured to run at a higher privilege level, then the attacker-controlled DLL that is loaded will also be executed at the higher level. In this case, the technique could be used for privilege escalation from user to administrator or SYSTEM or from administrator to SYSTEM, depending on the program.
Programs that fall victim to path hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace.
Application can load the DLL from below possible windows locations:
C:\Windows\System32\ (System Directory)
Current Directory
Installed Directory
Directory which is listed in PATH ENV variables.
Requirements:
Procmon: Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. [Download Link]
msfvenom: MSFvenom is a combination of Msfpayload and Msfencode, putting both of these tools into a single framework instance. [Download Link]
rundll32.exe: The rundll32.exe program exists to run programs held in DLL files. [Already available in windows 10 by default]
We can generate a malicious DLL using msfvenom using below command which will pop up the calculator from default windows directory:
msfvenom -f dll -p windows/exec CMD="C:\windows\system32\calc.exe" -o runcalc.dll
We can check if out malicious DLL is working properly using the below command in windows:
rundll32.exe runcalc.dll,1
Using procmon, we can find that how many DLL(s) were called by the Windows Application from which windows directory to perform the attack.
First, we will setup the procmon filter (Ctrl+L) as below to make our work easier:
Process Name is "Application's Process Name"
Result is NAME NOT FOUND
Path ends with .dll
Now, once the filter will be applied. Procmon will show the location of all the DLL(s) which were called by application during runtime but not found.
We can see that application tried to open a missing DLL using (QueryOpen) as highlighted below:
Now if we rename our malicious DLL (runcalc.dll) to missing DLL (DWrite.dll) and put it under the defined PATH (D:\New\OneDrive...). So, when the application or system will be restarted our calculator will be pop up.
As you can see below our malicious DLL is successfully executed by the application and calculator will be pop up.
We can see the DLL Injection is very easy to be exploited by an attacker. Attacker can also gain shell and escalate privileges using the method. We can also create reverse shell using msfvenom to take a step further.
Mitigation
Description
Use auditing tools capable of detecting DLL search order hijacking opportunities on systems within an enterprise and correct them. Toolkits like the PowerSploit framework contain PowerUp modules that can be used to explore systems for DLL hijacking weaknesses.[7]
Adversaries may use new DLLs to execute this technique. Identify and block potentially malicious software executed through search order hijacking by using application whitelisting solutions capable of blocking DLLs loaded by legitimate software.
Disallow loading of remote DLLs. This is included by default in Windows Server 2012+ and is available by patch for XP+ and Server 2003+. Path Algorithm
Enable Safe DLL Search Mode to force search for system DLLs in directories with greater restrictions (e.g. %SYSTEMROOT%)to be used before local directory DLLs (e.g. a user's home directory)
The Safe DLL Search Mode can be enabled via Group Policy at Computer Configuration > [Policies] > Administrative Templates > MSS (Legacy): MSS: (SafeDllSearchMode) Enable Safe DLL search mode. The associated Windows Registry key for this is located at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDLLSearchMode[8][1]
