Killing Sysmon Silently

Today I've got a mini-blog with commentary on what I view as a pretty nasty bug in Sysinternals' Sysmon.

After reading Sysinternals Sysmon suspicious activity guide I started playing with GPO/registry based rule changes for my own deployment of sysmon configs internally.

While testing, I noticed that Sysmon's EventID 16, the event logged when Sysmon detects a configuration change, does not occur when HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters\Rules is modified directly.

To me, this is huge for an attacker. They have the ability to silently kill Sysmon on a machine without raising the alarm.

Consider the following example: I've applied a config using the -c argument on sysmon.exe, verified that a config state change event was generated, destroyed the config using Powershell without another event ID 16 being generated, and verified that Sysmon is now broken and may not be logging as defenders had intended. As an attacker I could have also brought in my own valid config that disables all logging as well 😁

So how could a defender detect this? As it turns out, with Sysmon!

If you add a RegistryEvent option to your config looking for modifications to SysmonDrv, you can spot someone messing with Sysmon in your environment.

Here's what my demo config looks like:

And here it is in action