Petition: Hey Microsoft, help us detect LOLBAS usage!
Summary: Can we just update the LOLBAS to log when they get executed instead of having to monitor every single process across the whole network? And preferably have them log their parsed parameters too.
So I continue my journey down the rabbit hole of detection coverage. For this post, I started with a simple question, what data source should you use to detect usage of Living Off The Land Binaries, Scripts and Libraries (LOLBAS) and realised this might be a bit more complicated than what I initially thought.
The Problem
Let’s say that you want to detect malicious usage of rundll32.exe as an example. The obvious data source for this would be something like Event ID 4688 (Process Creation), and hopefully you already see the problem. Monitoring process creation across all your network results in a lot of data. I’ve seen enough examples where companies choose to monitor this only on critical servers, if at all, simply due to the volume involved.
But your problems don’t stop there. Renaming native Windows binaries to avoid detection is quite common, and while you may be able to deduce the real name of the executable from the parameters it is using in some cases, the most reliable method of detecting a renamed executable is to use the version info on the file (see Sigma rule here for an example). But since Event ID 4688 does not contain the version info in the event, you will need to install Sysmon and use Sysmon ID 1 instead. This means that you also need to roll out Sysmon to whatever subset of your network you feel comfortable monitoring.
The last problem is a little different. Most parameters on most executables can be represented in different ways. This means that any detection rule you write needs to handle these differences (see Sigma rule here for example).
Even ignoring parsing issues, there are parameters that you cannot parse from the command line input alone. For example, to know what DLL is being executed by the rundll32.exe –sta <CLSID_GUID> command, you would need to check the [\HKEY_CLASSES_ROOT\CLSID\<GUID>] registry. This is not information you have when you get your ID 4688 or Sysmon 1 events.
Note: Microsoft’s documentation of rundll32.exe is woefully lacking. You should refer to Nasreddine Bencherchali post here instead:
That is a lot of work just to detect rundll32.exe. To be fair, collecting process creation logs helps beyond just detecting usage of rundll32.exe, and there is always the cop out solution of using an EDR and let it handle the complexity for you. But regardless of who does the work, this is still a lot of work to detect one binary.
The Solution
Hear me out, what if, instead of monitoring every process across your whole network, Microsoft agrees to create a new special Event ID for whenever a LOLBAS gets executed. That is, whenever these binaries get called, the binary itself would log to Windows Security Auditing that they got executed.
You have questions, so let me answer them:
How does this solution help with the scale of the data? Monitoring the usage of a subset of binaries is obviously going to be way less than monitoring every process execution across the whole network. It is true that you may choose to monitor every process created for some sections of your network, but this gives you a lighter weight option of larger portions of your network.
How does this solution help with coverage? Since the binary itself is logging when it gets used, this logging would be the most reliable method of detecting usage of the binary. This is especially useful for DLLs, which do not get executed directly, and scripts, which don’t necessarily generate a new process.
Why does the binary itself have to create the log? Can’t Windows create the log instead? The binary should create the log because, if the binary is renamed, the logging logic would still exist in the binary and the log would still be created. Relying on Windows to create the log instead would require Windows to successfully identify copied versions of the binary, which may be possible but not guaranteed to succeed.
Can’t attackers patch out the logging logic? They can, but that defeats the “living off the land” part of the attack.
Who determines what is a LOLBAS? These guys right here: https://lolbas-project.github.io/
Why log to Windows Security Auditing? Can’t we create a new category for these? We can, but honestly, Microsoft does not offer the same level of documentation for other categories as they do Windows Security Auditing.
Don’t some Binaries already have their own logging? Some do. For example, bitadmin usage is recorded in Bits-Client/Operational. This proposal is inspired by these types of logs:
How does this solve the parsing issue? The binary can log a parsed version of the parameters in its logs. In the end, it is the binary itself that is the canonical definition of how the parameters should be parsed.
It sounds like you’re trying to make Microsoft do your work. Sounds kinda lazy to me. You’re god damn right, I’m lazy. Last time I checked, that was a good thing. But if you’re having LOLBAS problems, I feel bad for you, son. I got 99 problems but rundll32.exe ain’t one!
P.S. If you’re interested in Threat Hunting or Detection Engineering, you may be interested in checking out our newsletter at the link here: https://threathuntersdigest.substack.com
