Creating coverage for hypothetical adversary behaviors may not seem like the best use of time when there are so many known evils for which we could improve detection, but occasionally those hypothetical detection ideas pay off.
My buddy Mike Haag (who is now at Splunk) is arguably the best threat hunter out there. When Mike was finding evil on a daily basis here at Red Canary, he’d frequently find adversaries using techniques that our existing analytics did not detect, and he’d write up a coverage gap issue to be addressed. One of the recurring issues he’d write up was related to DLL Search Order Hijacking (T1574.001). One manifestation of that technique involves moving legit system binaries into unusual directories along with malicious dynamic link libraries (DLL), effectively gaming the natural DLL search order (more on this in a moment). Adversaries would frequently switch up the binaries they were abusing, subverting detection logic built around our expectations about those binaries, and resulting in a cat-and-mouse game.
DLL and search order refresher
From a very high level, a dynamic link library (DLL) is essentially a resource that can be used by multiple binaries, reducing the need for duplicative or unnecessary code. If a binary needs to use a function within one of these DLLs, it can load the DLL into memory and inherit the ability to execute that function. In practice, DLLs usually contain an export table that includes a list of functions that are available for import by executables.
When a binary loads a DLL, it has to know where the DLL exists on disk, but it can reference the DLL in a number of ways. One of the most common ways is to reference the DLL’s name within the executing binary, causing the operating system to enumerate through a number of locations in a predefined order to locate and load any DLL by that name. As you might have guessed, this DLL search order process is ripe for abuse. More details on the exact DLL search order are available directly from Microsoft.
DLL Search Order Hijacking
With enough development knowledge, an adversary can craft a malicious DLL that shares its name and exported functions with a legitimate one, but which actually contains a custom payload. The adversary can then place this malicious DLL in an appropriate directory and cause the executing binary to load the custom DLL payload. For example, an adversary can move a legitimate system binary to an unusual directory and place a malicious DLL that shares its name with a legitimate one in that same directory. When the relocated binary goes looking for the legitimate DLL, it will find and run the malicious one that’s in the same directory first.
Typically, we don’t see adversaries overwrite existing DLLs on disk, for a number of reasons. One of the main reasons is that it may cause the endpoint to become unstable, resulting in the malicious DLL being identified, the host being re-imaged, and the adversary losing their foothold. Instead of conspicuously overwriting the legit DLL with a malicious one, adversaries write these system binaries somewhere else on disk along with a malicious DLL in the same directory as the system binary, allowing the malicious DLL to be loaded into memory when the relocated binary executes.
Depending on your level of visibility into your environment, you may only see the process executing from an obscure directory. From our perspective, DLL Search Order Hijacking seems to be gaining popularity, in part because it can be difficult to detect but also because blocking suspect binaries outright can cause serious issues on a host. Trying to actively identify all of the DLLs being written to disk is also extremely difficult at scale, and attempting to identify every binary that loads a DLL from the same directory requires a large amount of processing for very little reward.
DLL Search Order Hijacking seems to be gaining popularity, in part because it can be difficult to detect but also because blocking suspect binaries outright can cause serious issues on a host.
We’ve tried a few different approaches to detecting DLL Search Order Hijacking, but the one that’s been most successful for us involves monitoring for relocated instances of system binaries. In the example below, we’re examining a native Windows binary called the Share Creation Wizard (shrpubw.exe), and the detection logic for alerting on process path deviations is essentially as follows:
process_is_likely?('shrpubw') &&
process_path_is_unexpected?('shrpubw.exe')The above pseudocode represents an analytic that’s designed to look for the execution of shrpubw.exe from a path that we do not typically expect it to execute from. Our understanding of expected paths (i.e., the normal file path for a given executable) is based on a library that we’ve been developing over a period of many years.
This library is basically a list of processes and some of their respective metadata. Both process_is_likely? and process_path_is_unexpected? are what we call “helper detectors,” and they rely on this library to make determinations about the true identity of a given executable. We expand the list to incorporate new processes as needed.
The following is a partial example of the metadata we store for the Share Creation Wizard:
'shrpubw' => {
'expected_process_names' => [
'shrpubw.exe'
],
'expected_internal_names' => [
'shrwiz'
],
'expected_process_paths' => [
'windows\system32\shrpubw.exe',
'windows\winsxs'
],
'expected_process_publishers' => [
'Microsoft Corporation'
],
'expected_file_description' => [
'share creation wizard'
],...
We can leverage this library as a source of truth to identify when adversaries rename legitimate binaries—or even when adversaries attempt to masquerade suspect binaries as legitimate ones. In addition to masquerading, this library of known process metadata has also given us the ability to capture Search Order Hijacking, and by chance, techniques like AppDomainManager injection, along with instances where adversaries are otherwise dropping system binaries onto disk for further exploitation.
This kind of detection logic has helped us identify malicious activity like the following (notice the space in windows \):
Implementing the detection logic
Back to the cat-and-mouse game… after multiple hunts that led to the identification of subversive binaries performing malicious actions for which we didn’t have coverage, Mike finally decided that he’d had enough, and, instead of waiting to ad hoc threat hunt his way into the next bad binary, he began baselining binaries within System32 and Syswow64 to explore the possibility of creating bulk coverage.
Initially, he compared LOLBAS with our known process information helper to confirm coverage parity. Then, we asked the question “why not just add binary metadata for all binaries in system32?” Mike wrote a simple PowerShell script to list all the binaries from Windows 10 and Server 2016 to perform a comparison of Syswow64 and System32.
$system32 = Get-ChildItem -Path C:\windows\System32\ -Include '*.exe' -Recurse -ErrorAction SilentlyContinue |
% {
[PSCustomObject] @{
exe_name = $_.FullName
InternalName = $_.VersionInfo.InternalName
fileDescription = $_.VersionInfo.FileDescription
Product = $_.VersionInfo.Product
}
}
$system32 | Export-Csv -Path C:\users\research\Desktop\data.csv
After we ran the PowerShell script and gathered the binary metadata, we leveraged each binary’s hash to query our existing binary metadata library and added any metadata that our PowerShell script turned up that hadn’t been in the store previously. From there, we updated our detection logic around expected file paths and binary internal names to include that metadata for every binary in System32.
Of course, we don’t just send these detectors into production immediately. We typically subject them to a tuning process that ensures the detection logic we are putting into production is effective. In general, we want to avoid putting an analytic into production that might light up our analysis queue. However, due to the large number of detectors we created during this process, manually checking each one of these wasn’t really an option.
Part of our usual process for getting a detection analytic into production involves simulating the activity we’re trying to detect in an instrumented test environment. In this case, we copied every System32 binary and moved them into a different System32 directory on a virtual machine and launched them via an elevated PowerShell session. This provided our telemetry to validate the activity, and, from there, we made some tweaks to the logic as needed. Through a number of iterations, we set a maximum number of tuning exclusions per detector and events per piece of detection logic and rolled them out in an automated fashion once they met a set criteria.
Happy hunting
Not all of the System32 binaries met our criteria and made it into production, but as of today we were able to implement detection logic for 483 binaries. The logic is nearly identical to the Share Creation Wizard logic we described earlier in this blog, although some binaries include slight tweaks, such as parent process exclusions and the occasional process path exclusion. Since implementing this bulk detection coverage, we have identified adversaries abusing 114 unique binaries (listed below) to perform DLL Search Order Hijacking or other malicious activity.
Appendix
The following is a list of 114 System32 binaries we have identified being abused with this technique:
alg.exe
applicationframehost.exe
applysettingstemplatecatalog.exe
bde.exe
bdechangepin.exe
bdeuisrv.exe
bdeunlock.exe
bitlockerwizard.exe
changepk.exe
cloudnotifications.exe
compmgmtlauncher.exe
computerdefaults.exe
conhost.exe
consent.exe
credwiz.exe
cscunpintool.exe
ctfmon.exe
cttune.exe
dccw.exe
ddodiag.exe
devicepairingwizard.exe
dfsvc.exe
dialer.exe
diskpart.exe
dism.exe
dmnotificationbroker.exe
dpapimig.exe
dpnsvr.exe
dvdplay.exe
dxgiadaptercache.exe
dxpserver.exe
easeofaccessdialog.exe
ehstorauthn.exe
eudcedit.exe
eventvwr.exe
filehistory.exe
fontdrvhost.exe
fvenotify.exe
fveprompt.exe
gamepanel.exe
genvalobj.exe
gfxdownloadwrapper.exe
hvax64.exe
hvix64.exe
ie4ushowie.exe
isoburn.exe
licensingui.exe
logoff.exe
lpksetup.exe
mdeserver.exe
mdmagent.exe
mdmappinstaller.exe
mfpmp.exe
mousocoreworker.exe
msdt.exe
msra.exe
musnotificationux.exe
netplwiz.exe
netsupport.exe
nltest.exe
node-renamed.exe
odbcad32.exe
omadmclient.exe
optionalfeatures.exe
passwordonwakesettingflyout.exe
perfmon.exe
presentationsettings.exe
printfilterpipelinesvc.exe
proximityuxhost.exe
quickassist.exe
rasphone.exe
rdpclip.exe
rdpinput.exe
rdpsa.exe
rdpsauachelper.exe
rdvghelper.exe
recdisc.exe
recoverydrive.exe
regedt32.exe
rrinstaller.exe
rstrui.exe
rurat.exe
sdiagnhost.exe
securityhealthsystray.exe
sessionmsg.exe
shrpubw.exe
sihost.exe
sppextcomobj.exe
sppsvc.exe
susp-dir.exe
sysreseterr.exe
systempropertiesadvanced.exe
systempropertiescomputername.exe
systempropertiesdataexecutionprevention.exe
systempropertieshardware.exe
systempropertiesperformance.exe
systempropertiesprotection.exe
systempropertiesremote.exe
systemreset.exe
systemsettingsremovedevice.exe
tabcal.exe
tpminit.exe
ttdinject.exe
tttracer.exe
upfc.exe
upgraderesultsui.exe
usocoreworker.exe
vmcompute.exe
wfs.exe
windowsactiondialog.exe
wlrmdr.exe
wmpdmc.exe
wpcmon.exe
wsatconfig.exeRelated Articles
The Trainman’s Guide to overlooked entry points in Microsoft Azure