From a behavioral perspective the Windows© operating system is constantly writing dll files to disk at a fairly high volume per host and process. It's rare for the rate of dll's written to disk to be low and slow, and is almost always the result of user behaviour or a threat. Therefore, it's possible to identify such threats as Nobelium, various dll search order hijacking scenarios as well as any persistence where a dll is written to disk using Sysmon eid 11, Splunk and the eventstats search command.
Back in May Microsoft provided a great report on Nobelium which detailed the use of rundll32.exe to execute a dll that was Cobalt Strike beacon loader. This past week Red Canary dropped another great threat intel report https://redcanary.com/blog/grief-ransomware/ on Dridex and Grief ransomware in which they detailed the use of dynamic link library (dll) search order hijacking. If you're not familiar with this these threats, head over to the ATT&CK framework to read up on these two techniques, T1574.001 or T1218.011.
In a nutshell this threat is primarily used for defense evasion in order to execute a malicious dll with the help of a benign executable. Typically the benign binary is introduced into the victim environment alongside the malicious dll like in the case of the Red Canary report, however the dll file can also be dropped without any binary and just executed via rundll32 like in the case of Nobelium.
However this is not the only way the threat can be realized. More mature threat actors will also leverage this technique to not only gain execution but also persistence once within the victim network by only dropping a malicious dll to disk where it will be loaded by an existing binary or application that runs at startup/user logon. This way there's no need to introduce any additional binaries into the environment whose execution has a much greater chance of being logged and scrutinized by the Blue team.
All that said, the threat or scenario this blog post will focus on the more difficult task of trying to identify when an adversary has decided to introduce a single lonely dll to disk to order to gain execution and persistence after gaining an initial foothold on a workstation.
To begin, in order to ever detect such a threat, you'll need to be using some form a endpoint data source that can provide insight into dll's either being loaded into the memory of a process or when dll files are being written to disk. This could be a commercial EDR or System Monitor (Sysmon) from Sysinternals. The benefit of Sysmon is that is free and has a full customizable configuration, for which there are many great example configurations online. Here is a sample config snippet specifically for logging any file with a extension of .dll using Sysmon event id 11 which logs file create operations.
<TargetFilename name="Any .dll file written to disk" condition="end with">.dll</TargetFilename>
With this configuration deployed we can shift focus to Splunk and write a search that looks for any process that writes X number of .dll files within X minutes of time using the eventstats search command.
For this search, I'm going to scope the detection to any process that writes a dll file to disk within the C:\users\, C:\ProgramData\ and C:\Windows\System32\ directories as these are either user writable directories or the default location of vulnerable binaries, where an adversary will be likely write their malicious dll. This scope of course can be changed based on your needs.
Here is what the search looks like:
You can find a copy of this search in my Github repo here: T1574/MaliciousDLLs
This search can be used for hunting retroactively or even better can be deployed as a correlation search with very low false negatives given the broad scope and very manageable false positives based on my testing. I hope you find it useful :)