Analysis
Rising from 75 to eight, DLL Search Order Hijacking is the most ascendant technique across our customer base. This increase is likely the result of improved detection abilities on our end rather than a distinct rise in prevalence.
Why do adversaries use DLL Search Order Hijacking?
DLL Search Order Hijacking offers adversaries a reliable and often discreet method for persisting, elevating their privileges, and evading defensive controls. Rather than overtly installing a malicious binary, the adversary can introduce a malicious DLL masquerading under a legitimate filename into the same subdirectory as a given legitimate process.
When that process needs to conduct a specific action, it searches for the DLL with the legitimate name, first looking in the folder in which it lives. Finding the malicious DLL in the same folder, it will load that library, thus giving the attacker code execution from within the legitimate host process. Most often, we observe a legitimate executable known to be vulnerable to hijacking dropped by the adversary along with the malicious DLL.
DLL Search Order Hijacking is elusive, and it’s something we’ve historically struggled to detect—both specifically here at Red Canary and more generally as an industry. However, as its rise in prevalence suggests, we made a lot of progress expanding our detection coverage for the threat in 2019.
Threat Volume
How do adversaries use DLL Search Order Hijacking?
There are multiple ways that a DLL Search Order Hijack might unfold. One particularly common method involves the establishment of a scheduled task that launches a seemingly legitimate executable that then loads the malicious DLL.
Sighted with
DLL Search Order Hijacking occurs most frequently in conjunction with Scheduled Task (T1053) and Process Injection (T1055), both likely the result of Emotet activity that often precedes a TrickBot infection. Slightly less often, we also see the technique associated with Remote File Copy (T1105), Windows Admin Shares (T1077), and Domain Trust Discovery (T1482), techniques that are more concretely linked to TrickBot. As such, we see the latter three techniques occurring in conjunction with DLL Search Order Hijacking slightly less often than the former two because we frequently detect and mitigate Emotet before it loads TrickBot.
We also see the technique occur with Process Hollowing (T1093), which is likely the result of Dridex activity.
Customers Affected
Definition
Detection
MITRE’s data sources
- File monitoring
- DLL monitoring
- Process monitoring
- Process command-line parameters
Collection requirements
The most reliable data sources for observing DLL Search Order Hijacking are process monitoring and DLL load monitoring (in that order). These sources will allow you to observe when trusted processes deviate from ordinary, benign behavior, allowing you to track the cause of bad behaviors to specific DLLs.
Detection suggestions
Again, DLL Search Order Hijacking presents detection and prevention challenges to our entire industry, primarily because the technique proxies the execution of malicious content through a signed, trusted binary. The most helpful patterns we’ve seen so far are:
- Signed Microsoft binaries being written by cmd.exe to
ProgramDataor userAppDatafolders - Signed, trusted binaries executing from User
AppDataorProgramDatafolders loading a single unsigned DLL from the same folder - Scheduled task creation to execute binaries from User
AppDataorProgramDatafolders - Trusted DLLs located in normal system paths such as
kernel32.dllorntdll.dlllocated in abnormal folders - Frequency analysis on the least commonly found DLLs located outside of normal system folders
- Unsigned DLLs written to suspicious folders such as
TemporAppData
You’ll want to look for DLL loads emanating from apparently unusual locations and and figure out if these are normal in your environment.
Weeding out false positives
Looking for any generic process loading a DLL from its same folder sounds like a good idea. Unfortunately, this will create tons of false positives from Windows System32 and Program Files folders. Target your hunts to user-writable folders for the best results.
Testing
Start testing your defenses against Process Injection using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View Atomic tests for T1038: DLL Search Order Hijacking. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using Command Prompt:
copy %windir%\System32\windowspowershell\v1.0\powershell.exe %APPDATA%\updater.exe copy %windir%\System32\amsi.dll %APPDATA%\amsi.dll %APPDATA%\updater.exe -Command exit
Useful telemetry will include:
| Data source | Telemetry |
|---|---|
| Data source: Process monitoring | Telemetry: powershell.exe |
| Data source: DLL Monitoring | Telemetry: amsi.dll with incorrect filepath |
| Data source: Process command line | Telemetry: powershell.exe renaming itself |
| Data source: File monitoring | Telemetry: binary metadata discrepancies for updater.exe and amsi.dll |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.