Two days ago Mark released a new version of sysmon – version 8.0. It adds new features and addresses the issue I highlighted in my previous post.
This post is not about new version of sysmon though.
It’s more about its inner workings that I looked at a while ago.
Sysmon has two primary components – sysmon driver and sysmon service process (we will skip the architectural differences between sysmon’s x86 vs. x64 versions). The first one (driver) intercepts the events, the second (service process) writes them to the Event Log in a loop, using the DeviceIoControl to talk to the driver.
If you ever patched binary in memory or on disk, you know where it is going…
The core functionality that actually logs the stuff to the Windows Event Logs is called from the inside of the sysmon.exe service process. It’s nothing unusual, but obviously it’s also a potential weakness.
Since it’s a process – it can be patched. I tried it on a file level, and the results of a single byte patch are shown below – not a single event is being logged:
Assuming the attacker detects sysmon, and can acquire the required rights to modify it – patching in memory or on disk is pretty trivial and can basically disable the functionality of the tool…
Obviously, this applies to _any_ tool and any process or component using ReportEvent or EventWrite APIs, so want to reiterate how the availability of tools bias security researchers… Sysmon is used here more as a scapegoat to demonstrate the old-school rootkit technique than a targeted crusade against this fantastic tool.
How to fix it?
Perhaps sysmon could do some sanity checks of its integrity on a driver level? – It’s much harder to modify the driver and load its patched version than an .exe (especially on 64-bit Windows). Perhaps driver could also do occasional checks if the number of Events written to Event Logs is as expected/increasing? And if the sysmon is a dependency, any admin or EDR tool using it should probably verify the integrity of the file prior to launching it? Including automation? I believe there is no generic solution here at the moment, but basic self-checks could simply rely on verifying the signatures of the file (for file patch). For in-memory patches, this is much harder as you need a dedicated code that compares images on disk vs. images in-memory. You may be surprised, but some EDR solutions actually attempt to do that – it’s often much better than then ‘see-it-all’ approach that generates lots of noise.
Going back to rootkits – I used this term on purpose. Applying a single-byte patch will give you zero logging. It’s silly and easily detectable. A more complex patch could simply rootkit the bad guys activities out of the event log (just need to hook either the sysmon itself, or Event reporting APIs). As usual… whoever gets there first… wins.
