Introduction

Sysmon v6.10 has been released on the 11th of September and introduces new features such as WMI events reporting. At the first sight, these new capabilites seem very interesting for SOC and Incident Response purposes. Therefore in this article, we are going to explore the new events generated by this latest version of Sysmon. We will also discuss in which extent we can use these events to detect real life WMI abuses.

Modus Operandi

The idea behind this experiment being to detect WMI abuses, we are going to use the well-known Powershell Empire which will enable us to achieve WMI persistence without too much effort. We do not go into details in how to achieve WMI persistency with Empire but the process is rather simple:

1. Create a listener
2. Generate a launcher connecting to the Listener
3. Execute the launcher on your target
4. Once we can access the reverse shell
5. Elevate privileges in needed
6. We make use of powershell/persistence/elevated/wmi module in order to start the launcher at every boot of the system

Once we have setup the WMI persistency, we can reboot the system and wait for the reverse shell to connect back to empire. This latter should pop as SYSTEM user as shown below for agent Y5RBWZPS. After all these steps are completed, we know that all the interested steps had the opportunity to be monitored by Sysmon so we can collect the events and analyse those.

  Name            Lang  Internal IP     Machine Name    Username            Process             Delay    Last Seen
  ---------       ----  -----------     ------------    ---------           -------             -----    --------------------
  EU4P7A2Y        ps    192.168.56.101  GENERIC-PC      *GenEric-PC\Gen Ericpowershell/3452     5/0.0    2017-09-19 23:16:31
  Y5RBWZPS        ps    192.168.56.101  GENERIC-PC      *WORKGROUP\SYSTEM   powershell/3888     5/0.0    2017-09-19 23:22:23

Sysmon Events Generated

Before reboot

The new Sysmon events being EventIDs 19,20 and 21 we can first search for those in order to grab the persistency

After reboot

In order to find the interesting events related to WMI persistence, we decided to follow the wmiprvse.exe process since it is the one used to spawn processes to be spawned by WMI. Once we have found the interesting one (spawning powershell), we decided to track the ProcessGuid back. We see that wmiprvse.exe is spawned by svchost.exe and then spawns our malicious Empire launcher and that is basically it. There are many other events related to the start of wmiprvse.exe like ImageLoad, ProcessAccess, RegistryEvent, etc, but those do not look to be of interest for hunting.

How to detect in the wild

We don't have much possibilities to detect such persistency, out of the fact that the launcher is beaconning every 5 seconds to an external IP address, but this is launcher specific and cannot be considered as reliable. We have only two possibilities, either catch the event generated at the moment of the installation or the events generated when WmiPrvSE.exe spawns the implant. This latter is more reliable since it is supposed to be generated each time the system reboots, as long as the implant is there.

It is easy to say that we should monitor any WMI events and any process spawned by the WmiPrvSE.exe but we first have to confirm that it would not generate too much noise not to flood the analysts. According to previous tests we have done (c.f.: Sysmon Events Table), the WMI related events (19, 20, 21) are not frequent on regular workstations and thus you should expect a very low false positive rate (likely close to 0). We have also ran a test over a 5h long Sysmon capture and tried to evaluate the number of CreateProcess events with a ParentImage ending with WmiPrvSE.exe (case insensitive search). The result of this search revealed that there is no other process spawned by WmiPrvSE.exe.

Both the two signatures seem quite relevant and should be considered as extremely suspicious and should be investigated further by the analysts.

Gene Rules

Gene is a tool we have developed in order to match events against rules and report the matching events. The rules mentionned here after can be used to detect the WMI persisence method discussed above. Those rules have been pushed to our rule repository (gene-rules) so that you just need to refresh your rule set if you want to use those.

{
"Name": "WMIEvents",
"Tags": ["WMI"],
"Meta": {
  "EventIDs": [19, 20, 21],
  "Channels": ["Microsoft-Windows-Sysmon/Operational"],
  "Computers": [],
  "Criticality": 7,
  "Author": "@0xrawsec",
  "Comment": "This rule catches any WMI events"
  },
"Matches": [],
"Condition": ""
}

{
"Name": "WMICreatedProcess",
"Tags": ["WMI"],
"Meta": {
  "EventIDs": [1],
  "Channels": ["Microsoft-Windows-Sysmon/Operational"],
  "Computers": [],
  "Criticality": 7,
  "Author": "@0xrawsec",
  "Comment": "This rule catches the processes spawned by WMI"
  },
"Matches": [
  "$wmi1: ParentImage ~= '(?i:\\\\wmic.exe$)'",
  "$wmi2: ParentImage ~= '(?i:\\\\wmiprvse.exe$)'"
  ],
"Condition": "$wmi1 or $wmi2"
}

Conclusion

WMI persistency has been seen several times over the last years and it is still a great way to hide since it is not easy to spot with common tools. It is even more challenging to detect in big infrastructures where running custom tools is often prohibited or very difficult to achieve.

We have shown that Sysmon is a tool of choice to enhance the detections of WMI abuses with only few false positives through two simple detection rules. The first one consists of monitoring any WMI related Sysmon events (19, 20, 21) and can detect a fresh persistence setup. The second detection rule consists of watching an any process with a ParentImage ending with WmiPrvSE.exe. This latter can be used to spot already installed implant(s) using WMI persistency.

We hope this article will help you to sharpen the detection rules of your SIEM and we wish a happy hunting to everyone.