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

Mitigating bad admin abuse of WMI over WinRM

Introduction

When I created this blog back in August, I had intended to open with a detailed posting on PowerShell Remoting that I still haven't finished yet. In an effort to breathe new life into this space, I've decided to write a post that piggy-backs off of content from others in the industry, hopefully adding some useful information in the process!

Last night I read Tony Lambert's post on RedCanary's blog about Lateral Movement Using WinRM and WMI. In it, Tony provides a great example of lateral movement by spawning a process using WMI's win32_process class via WinRM's WMI plugin, covers detecting this sort of activity, and then covers some suggestions for mitigating the threat. One of Tony's suggested mitigation tactics is designing your network architecture in such a way as to only allow WinRM access from secured, trusted systems. This will certainly help with mitigating lateral movement risks with WMI over WinRM (or other WinRM plugins like PowerShell Remoting), but what about the risk of a bad admin or stolen access to this privileged system?

Problem

Suppose that you have a central server for connecting to endpoints to perform remote operations and you use PowerShell Remoting over WinRM in conjunction with JEA to ensure that your admins can only run certain commands on endpoints or have to go through additional restrictions like multifactor authentication in order to perform their work. How would you stop a user with access to the central server from circumventing your security controls by just creating whatever processes they want via WMI over WinRM?

Here's an example:

Bad admin trying to use PSRemoting to launch an unauthorized executable that is blocked by the JEA configuration for PSRemoting.

Bad admin using WMI over WinRM to launch their unauthorized executable instead.

Context

Before we try to answer the question of how do we prevent this abuse, let's backup and look at how this whole thing works.

WMI is available as a plugin for WinRM by default, you can see all plugins that are available at any given point with the command winrm enumerate winrm/config/plugin -format:pretty

Let's look specifically at WMI with the command winrm get winrm/config/plugin?Name="WMI Provider" -format:pretty


Above, you can see the plugin configuration for the WMI plugin for WinRM. You may notice some familiar terms that were in Tony's post, such as the capability type Invoke which was used to call the create method on the win32_process class. You could also leverage other capability types like enumerate fairly easily with winrm enumerate wmicimv2/win32_process to enumerate processes on a machine.

So how do we prevent this plugin from being abused?

Solution

There are many ways to approach this problem, each with their own pros and cons. While reviewing the plugin configuration above, I noticed the Security tags in each resource section with a SDDL string. If I toss that string against PowerShell's ConvertFrom-SDDLString, you can see what access it is granting

As you can see administrators have free reign over this plugin. With that in mind, a few solutions come to mind

1. Change the SDDL, granting a more specific group access. I have not tried this personally, but I would speculate it ought to work. However, I don't think it solves our problem. What if your bad admin is in that specific group too?
2. Setup PowerShell Remoting to not require membership in the local administrators group. While this is supposed to be possible, I to this day have been unable to do this successfully. Additionally, this still leaves WMI open for abuse.

But what if we tried something a little more aggressive? What if we simply disable the WMI plugin from WinRM? If you aren't using it legitimately, why leave it around for someone to abuse?

Disabling the WMI plugin for WinRM

To disable the WMI plugin for WinRM, run the PowerShell command set-item -Path "WSMan:\localhost\Plugin\WMI Provider\Enabled" -Value $false and restart the WinRM service.

Let's see how our bad admin is doing with this plugin disabled

Awesome!

But wait just a minute, there's one more problem to solve. WinRM is completely configurable remotely, so what happens if the bad admin turns WMI back on remotely?

While I've not figured out the correct parameters to flip the switch back to on using the winrm command, I would speculate it is possible.

I would advise that you setup auditing on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin and all subkeys. This will cover someone enabling the WMI plugin, creating a new plugin that's the same as the WMI plugin but under a different name, and creating unapproved PSRemoting PSSessionConfigurations. You can audit with either Windows' built-in advanced security settings, or a tool like Sysmon. From there you could centrally forward and alert on Security event ID 4663 or Sysmon event IDs 12-14.

I hope this information was useful, with my limited free time I think it'll be easier for me to write posts like this that just add onto other posts in the industry. Feel free to reach out to me on twitter or leave a comment with any feedback!

Hello, World!

Hello and welcome to Tales from Infosec.

My name is Eric and I have created this blog as a place to share information security related content that I hope others will find useful.

Posts will pertain to information security/technology in some form or fashion and will be written by me or guest contributors.