Using SCOM to detect WMI Persistence Attempts

I have to tip my hat to a colleague (Ian Smith) for pointing me to this paper that Matt Graber did for Blackhat in 2015. It was an interesting read on how attackers can use WMI to do a number of things. I haven’t done much work within the Security Monitoring MP in regards to WMI, so this seems like some low hanging fruit to attack. Step one was to figure out what I could detect. I borrowed Matt’s code to do some simple tests. So for those that want to play along at home, here you go:

$filterName = ‘BotFilter82’
$consumerName = ‘BotConsumer23’
$exePath = ‘C:\Windows\System32\evil.exe’
$Query = “SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA ‘Win32_PerfFormattedData_PerfOS_System’ AND TargetInstance.SystemUpTime >= 200 AND TargetInstance.SystemUpTime < 320”
$WMIEventFilter = Set-WmiInstance -Class __EventFilter -NameSpace “root\subscription” -Arguments @{Name=$filterName;EventNameSpace=”root\cimv2″;QueryLanguage=”WQL”;Query=$Query} -ErrorAction Stop
$WMIEventConsumer = Set-WmiInstance -Class CommandLineEventConsumer -Namespace “root\subscription” -Arguments @{Name=$consumerName;ExecutablePath=$exePath;CommandLineTemplate =$exePath}
Set-WmiInstance -Class __FilterToConsumerBinding -Namespace “root\subscription” -Arguments @{Filter=$WMIEventFilter;Consumer=$WMIEventConsumer}

This PowerShell basically creates what is known as a WMI subscription. Subscriptions, in and of themselves, are not bad things. Applications use them all the time for creating processes under certain conditions, but unfortunately, an attacker can do this too. In this case, Matt was demonstrating how an attacker can create a subscription to execute a command line based executable (evil.exe) once the system was up between 200 and 320 seconds. I’m not too terribly concerned with query needed to execute it. The big take away here is monitoring for the use of the command line event consumer, as we can train SCOM to potentially look for something useful.

That useful information was found in the WMI-Activity log with this event:

The 5861 that was generated appears to be fairly rare. I don’t see it anywhere else on my lab, and the event description clearly lays out the code that I ran. As such, I have an easy set of items to search for:

Event Log = Microsoft-Windows-WMI-Activity/Operational

Event ID = 5861

Event Description contains “//./root/subscription” AND “CommandLineEventConsumer”

I’ll let this bake in my lab, and hopefully we will see this added to the next edition of Security Monitoring. Happy SCOMing.

Update 3/19 – This rule fires not only when the schedule is created, but also any time the conditions are met for it to be rerun.. If you have something legitimate creating WMI schedules, you’ll probably want to disable this rule for that particular machine. I did add a suppression event by the logging computer, so you should only see a repeat count here. Simply investigate the cause, and if it’s legit, you’ll want to override it. Beyond that, it has been very quiet.