Windows Persistence Mechanics – DLL Search Order Hijacking – Marcus Edmondson | Threat Hunting

Today I was thinking about persistence as it relates to threat hunting, and I have come to the conclusion, attackers adding persistence to your environment is the perfect chokepoint to find attacker activity. In this blog post, part 1 in a series I will be doing on Window’s persistence I am going to give you my reasoning, why I believe this to be true, and will detail DLL Search Order Hijacking and how you can detect it. This detection will assume your environment audit capabilities have been enhanced with certain Group Policy Objects (GPO’s) and Sysmon. If you do not know where to start, this website is a great start: https://www.malwarearchaeology.com. The series will include these five techniques:

DLL Search Order Hijacking
Run Keys/Startup Folder
Userinit Key
PowerShell Profile
LNK Shortcut files

First, lets define what persistence is. Persistence is a set of techniques an adversary will use to maintain access to an environment that will survive reboots or other types of disturbances that could cut off their connection to your network. Now, why do I believe it to be the perfect chokepoint to find adversary activity in your environment. All attackers, in order to complete their actions on objective must persist in an environment. Whether they want to drop ransomware, sell their access to someone else, or steal your secret sauce they must maintain access. In this post I will describe DLL Search Order Hijacking, with an example of how it is performed and then I will cover how you would detect it.

What is DLL Search Order Hijacking? According to MITRE ATT&CK, DLL Search Order Hijacking consists of, “Adversaries executing their own malicious payloads by hijacking the search order used to load DLLs. Windows systems use a common method to look for required DLLs to load into a program. Hijacking DLL loads may be for the purpose of establishing persistence as well as elevating privileges and/or evading restrictions on file execution. There are many ways an adversary can hijack DLL loads. Adversaries may plant trojan dynamic-link library files (DLLs) in a directory that will be searched before the location of a legitimate library that will be requested by a program, causing Windows to load their malicious library when it is called for by the victim program. Adversaries may also perform DLL preloading, also called binary planting attacks, 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. Adversaries may 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. If a search order-vulnerable program is configured to run at a higher privilege level, then the adversary-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.” Now that we have a solid understanding of what DLL Search Order Hijacking is lets see how it is performed.

In this example, we have an executable named example.exe that when launched will also execute our malicious DLL named winspool.drv, this is the name of a legitimate file that our example.exe relies on.

Inside our malicious DLL it will launch our payload Windows Media Player. In real life it would launch something more nefarious like Cobalt Strike’s Beacon payload.

Also the way our malicious DLL works is that it will also load the DLL’s example.exe needs to work. In this type of situation the user may not recognize malware has been executed, especially if the malware runs in a hidden window, which in all likelihood it will. In the following screenshot you can see our malicious winspool.drv and right above it is the actual winspool.drv file renamed to winshlp.dll. This is what gives example.exe its functionality to still work while also running our malicious payload.

Here is a side by side of our evil winspool.drv next to the the actual winspool.drv that has been renamed winshlp.dll in order for our example.exe to keep full functionality.

Now that we understand some of the basics of how this technique is performed lets get into some of the ways we can detect this type of activity. Some of the sources that can be utilized for this are these data sources provided by MITRE:

File Monitoring
DLL Monitoring
Process Monitoring
Process CommandLine Parameters

Looking for any type of signed or trusted binaries executing from user folders such as Downloads, AppData or ProgramData should be investigated further. DLL’s located outside of System32 or SysWow64 can also be another good indicator. My go to when investigating this type of hunt is going into the event logs. We will be looking at some Sysmon logs to see what it looks like, Event ID 7 – Image Load, in particular. Note, in an enterprise environment you would want to use something like PowerShell to collect these events at scale or have them shipped to some sort of central repository such as Elasticsearch or Splunk.

In the following screenshot you can clearly see that our example.exe file loaded our helper DLL named winshlp.dll and Sysmon informs you that it’s OriginalFileName was winspool.drv. What is also suspicious is that a Microsoft binary that usually runs from SysWow64 folder, because example.exe is 32-bit, is running from the users Desktop folder.

This next screenshot shows our evil DLL being loaded by example.exe. Seeing an unsigned DLL being loaded from user space is definitely eye catching here.