This is a lame, cute, not-only-sysmon evasion that is not really an evasion, but more a social engineering trick – still, it may fool some junior analysts…

As I mentioned in my older post, there are tones of URL Schemes available in Win10. When you look at them, you will most likely think that anyone using them will always use the ‘start’ command, or the ‘ShellExecute*’ APIs.

And that’s the opportunity.

If you write a launcher that leverages these built-in, very well known schemes e.g. ‘ms-settings:defaultapps’ to create a dummy ‘host’ file (e.g. ‘ms-settings’) with the ADS attached to it called according to the second part of the URL Scheme (e.g. ‘defaultapps’), you will be able to launch ‘ms-settings:defaultapps’  that is actually not a protocol, but a real PE file.

Let’s have a look at an example:

copy notepad.exe ms-settings
type <yourexe> > ms-settings:defaultapps

This will create a copy of a legitimate (and signed) notepad.exe called ‘ms-settings’ and will append the ADS ‘ms-settings:defaultapps’ that is acting as an actual payload.

All you have to do is to launch it not via ShellExec, but directly via CreateProcess, and if you place the .exe in a ‘strategically named’ folder you may end up with a sysmon log like this:

Now… show me a junior analyst that won’t conclude it’s just one of the safe URL Schemes… because…  the first result for ‘ms-settings:defaultapps’ in Google is this.

They may even test it on their systems – launching ‘ms-settings:defaultapps’ from a command line will bring this innocent window:

A simple launcher that you can use for test can be downloaded from here. It simply launches ‘ms-settings:defaultapps’ ADS in its current directory.

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.