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:
- Create a listener
- Generate a launcher connecting to the Listener
- Execute the launcher on your target
- Once we can access the reverse shell
- Elevate privileges in needed
- 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.