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

Timestamp EventID EventData
2017-09-19 21:10:00.401 19 EventNamespace: \root\\\\CimV2\
EventType: WmiFilterEvent
Name: \MaliciousSubscription\
Operation: Created
Query: \SELECT * FROM  __InstanceModificationEvent WITHIN 60 WHERE Targ etInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.System UpTime >= 240 AND TargetInstance.SystemUpTime < 325\
User: GenEric-PC\\Gen Eric
UtcTime: 2017-09-19 21:10:00.401
2017-09-19 21:10:00.431 20 Destination: \C:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1.0\\ \\powershell.exe -NonI -W hidden -enc JABHAHIAbwBVAFAAUABvAGwAaQBjAHkAUwBlAFQAVA [...] AkAEsAKQApAHwASQBFAFgA\
EventType: WmiConsumerEvent
Name: \MaliciousSubscription\
Operation: Created
Type: Command Line
User: GenEric-PC\\Gen Eric
UtcTime: 2017-09-19 21:10:00.431
2017-09-19 21:10:11.878 21 Consumer: \CommandLineEventConsumer.Name=\\\MaliciousSubscription\\\\
EventType: WmiBindingEvent
Filter: \__EventFilter.Name=\\\MaliciousSubscription\\\\
Operation: Created
User: GenEric-PC\\Gen Eric
UtcTime: 2017-09-19 21:10:11.878

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.

Timestamp EventID EventData
2017-09-19 21:17:09.171 1 CommandLine: C:\\Windows\\system32\\wbem\\wmiprvse.exe -Embedding
CurrentDirectory: C:\\Windows\\system32\\
Hashes: SHA1=9F5A4796B58D8B104A1C0F5A63DAF0032B947966,MD5=619A67C9F617B 7E69315BB28ECD5E1DF,SHA256=F34F231D117CCDFEBB9CB35C8D6FDFA7051DA27FDC1204FCCFF36 1FC0B13A0FF,IMPHASH=C1E65C7FF153F2C2E6A7E93706AE226A
Image: C:\\Windows\\System32\\wbem\\WmiPrvSE.exe
IntegrityLevel: System
LogonGuid: 49F1AF32-8951-59C1-0000-0020E7030000
LogonId: 0x000003e7
ParentCommandLine: C:\\Windows\\system32\\svchost.exe -k DcomLaunch
ParentImage: C:\\Windows\\System32\\svchost.exe
ParentProcessGuid: 49F1AF32-8951-59C1-0000-0010DA830000
ParentProcessId: 604
ProcessGuid: 49F1AF32-8955-59C1-0000-00105DF90100
ProcessId: 1956
TerminalSessionId: 0
User: NT AUTHORITY\\SYSTEM
UtcTime: 2017-09-19 21:17:09.171
2017-09-19 21:21:17.132 1 CommandLine: C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -NonI -W hidden -enc JABHAHIAb[...]wASQBFAFgA
CurrentDirectory: C:\\Windows\\system32\\
Hashes: SHA1=5330FEDAD485E0E4C23B2ABE1075A1F984FDE9FC,MD5=852D67A27E454 BD389FA7F02A8CBE23F,SHA256=A8FDBA9DF15E41B6F5C69C79F66A26A9D48E174F9E7018A371600 B866867DAB8,IMPHASH=F2C0E8A5BD10DBC167455484050CD683
Image: C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
IntegrityLevel: System
LogonGuid: 49F1AF32-8951-59C1-0000-0020E7030000
LogonId: 0x000003e7
ParentCommandLine: C:\\Windows\\system32\\wbem\\wmiprvse.exe -Embedding
ParentImage: C:\\Windows\\System32\\wbem\\WmiPrvSE.exe
ParentProcessGuid: 49F1AF32-8955-59C1-0000-00105DF90100
ParentProcessId: 1956
ProcessGuid: 49F1AF32-8A4D-59C1-0000-001042F00A00
ProcessId: 3888
TerminalSessionId: 0
User: NT AUTHORITY\\SYSTEM
UtcTime: 2017-09-19 21:21:17.132
2017-09-19 21:22:14.207 1 CommandLine: C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -NonI -W hidden -enc JABHAHIAbwBVAFAA[...]wASQBFAFgA
CurrentDirectory: C:\\Windows\\system32\\
Hashes: SHA1=5330FEDAD485E0E4C23B2ABE1075A1F984FDE9FC,MD5=852D67A27E454 BD389FA7F02A8CBE23F,SHA256=A8FDBA9DF15E41B6F5C69C79F66A26A9D48E174F9E7018A371600 B866867DAB8,IMPHASH=F2C0E8A5BD10DBC167455484050CD683
Image: C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
IntegrityLevel: System
LogonGuid: 49F1AF32-8951-59C1-0000-0020E7030000
LogonId: 0x000003e7
ParentCommandLine: C:\\Windows\\system32\\wbem\\wmiprvse.exe -Embedding
ParentImage: C:\\Windows\\System32\\wbem\\WmiPrvSE.exe
ParentProcessGuid: 49F1AF32-8955-59C1-0000-00105DF90100
ParentProcessId: 1956
ProcessGuid: 49F1AF32-8A86-59C1-0000-0010EB930B00
ProcessId: 1656
TerminalSessionId: 0
User: NT AUTHORITY\\SYSTEM
UtcTime: 2017-09-19 21:22:14.207

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.