WMI: Still A Challenge and Opportunity on Windows
CyberSecurity Adventures
WMI: Still A Challenge and Opportunity on Windows
Windows Management Instrumentation (WMI). The bane of defenders, used by malicious actors since time immemorial (or at least Windows 2000) and still around. Today’s blog is going to outline some of the Risks, Rewards, and Opportunities WMI subscriptions offer Cyber Defenders.
WMI Subscriptions
WMI Subscriptions describe a way to use WMI Event Filters, Event Consumers and Event Binders to watch or subscribe to WMI Events. In this blog post, I’m going to provide a series of examples, comments and resources that anyone looking to get into WMI Subscriptions from a Defensive Cyberspace perspective can use to learn and excel in this area.
Extrinsic and Intrinsic Events
For this blog, it’s important to understand that there are two types of WMI events — these are called ‘Extrinsic’ and ‘Intrinsic’.
Extrinsic Events refer to events that fire in response to some operating system event. Specifically, they are predefined occurrences which which are not linked directly to the WMI data model (Microsoft Documentation). There are 7 classes of WMI Events, and you can find a full list of them here.
Intrinsic Events refer to events that occur in response to a change in the WMI data model. The can be observed through polling of a specified WMI class.
For a practical example, consider the difference between the Win32_ProcessStartTrace extrinsic event and the Win32_Process intrinsic class. The Win32_ProcessStartTrace class fires every time a process is started. Without fail. In contrast the Win32_Process class, when queried, provides a list of all the currently running processes. Put another way — if you subscribe to the ProcessStartTrace, you will capture every single process that starts. If you poll the Process class every 5 seconds and a process starts and exits within that 5 seconds (such as a malicious executable injecting into memory) this will not be observed.
Naturally, things are not quite this simple. For instance, the Win32_Process class provides significantly more information about a process than the Win32_ProcessStartTrace, however, it does change the risk / reward / opportunity profile for defenders…
Subscribing to WMI Events
WMI Event subscribers, extrinsic or intrinsic, are constructed in three parts; creating a WMI Filter, WMI Consumer, then binding them together with a WMI Binder.
WMI Filters define a filter constructed in the WMI Query Language (WQL). Similar in nature to Structured Query Language (SQL) queries, a WQL Query defines what is being searched for from the class required and then provides further detail as required. If an intrinsic event is being used, the timeframe for polling of the class also needs to be specified.
Here is an example of a WQL Query which will fire every time notepad.exe is started:SELECT * FROM WIN32_ProcessStartTrace WHERE ProcessName=’notepad.exe’
In contrast, here is an example of a WQL Query which will fire every time notepad.exe is running at the time of the query:SELECT * FROM Win32_Process WITHIN 5 WHERE ProcessName=’notepad.exe’
WMI Consumers define the action to be taken when called. WMI provides five consumer classes to use, these being:
- ActiveScriptEventConsumer — Executes a predefined script in an arbitrary scripting language.
- CommandLineEventConsumer — Launches an arbitrary process in the local system context.
- LogFileEventConsumer — Writes customized strings to a text log file located in a directory of users choosing.
- NTEventLogEventConsumer — Logs a specific message to the Windows NT event log.
- SMTPEventConsumer — Sends an email message using SMTP.
What is interesting about options 1 & 2 is that they start with local system level privileges. This means they run with a higher level of privileges than an admin on that local system. It’s one of the reasons this technique is so prevalent and widely used. For instance, this code below would open calc.exe (the Windows Calculator) at system if linked to an ActiveScriptEventConsumer.powershell.exe calc.exe
WMI Binders define the Filter and Consumer to be linked together. Of interest is that while a Filter can have multiple Consumers bound to it, a Consumer can only consume a single Filter.
Some code to create these subscriptions:
For this blog post, I created a small lab which walks through a demonstration of the discussion so far. Specifically, it recreates the MITRE ATT&CK Technique T1084, then outlines how to detect it and eradicate it. All of the steps can be performed on a local or remote Windows machine, provided you have the Windows Management Framework (Powershell) 5, Powershell remoting and administrator credentials.
Risks
With that introduction completed, now comes the fun part!
To be clear, WMI subscriptions are risky. There are some fundamental challenges with WMI which cannot be overcome.
WMI is a feature of Windows. As things are now, WMI is part of Windows operating system. You cannot disable or prevent it from occurring. Microsoft is making steps forward with the use the Common Interface Model (WMI upgrade) and restricting access to WMI, however, it is by no means difficult to access. Everything from the .NET framework through to Visual Basic script, Powershell and WMIC can access it. There’s a reason why despite this being a challenge for many years, it is still used successfully by adversaries.
WMI executes with system level privileges. WMI is inherently ‘dumb’ in nature, performing very few checks and balances in its operation. One of these is that a consumer always runs at system. This is very handy if speed of execution and not having random interrupt routines mess up your actions is your goal, but is also pretty awesome if you want to bypass many (most)of the security controls on a Windows machine.
WMI is fileless. Because of the nature of WMI, it is considered fileless. When dropping a script inside an ActiveScriptEventConsumer, many of the typical forensic artifacts left by a file (i.e. an entry on the Master File Table, Timestamps etc) do not exist. Instead, one has to query the WMI classes directly, or set up a polling method. Again, this speeds up the execution of WMI consumers, but also makes it difficult to track and control.
However, if you accept and understand all of these factors, then set about building a team of people who can understand, quantify, then respond to this risk, you could come up with some pretty interesting opportunities…
Opportunities
Consider this. What if you put together a Hunt team. A team who understood how the Windows operating system worked. Who knew how to program (not just script, but full OOP), who could understand these concepts, then deliver active risk management back to your organisation. For instance…
WMI is a feature of Windows. In this instance, the defenders have the advantage! They have the admin privileges required to create their own WMI subscriptions, which could mean some pretty interesting outcomes:
- They could replace an adversaries WMI Filter with their own. This would neuter the adversaries intent, reduce the risk, but also allow them to monitor the adversary further.
- They could attach a second WMI Consumer to the original filter. This could be interesting — for instance, if the adversary is opening up a process and firing a packet to a remote C2 channel, we could fire Netstat.exe to capture this communication.
There’s actually quite a lot more which could be done, but hopefully this paints a picture :)
WMI executes with system level privileges. Turns out, on Windows, you can get a lot more information about the OS when querying with system. Including the ability to hide yourself from a standard netstat.exe or Get-Process query. Knowing this, your team could be empowered to see significantly more about the OS than normal. Hmmmmm.
WMI is fileless. So we have a situation. We have an active adversary on an endpoint (or endpoints) and we need to hunt them back to understand the scope of their intrusion. Problem is, we suspect that if they find us hunting them, they might retreat, or hide deeper. So, we need to hide our actions, while hunting them. Turns out that successful, high end hunt teams need to use the same living off the land techniques as adversaries, for almost the same reason. Only difference is, hunt teams have the advantage that they have all the access they need.
Rewards
With my blog post wrapping up, I want to take a second to outline some of the rewards WMI could offer Cyber Defenders.
Firstly, in understanding how WMI works, we have a way to asymmetrically track and monitor adversarial actions.
Secondly, we now have a way to run our remote processes with system level techniques.
Thirdly, we can now perform a whole range of scripted actions using a fileless technique.
Finally
As I conclude this blog post, I hope that I’ve provided some really interesting and stimulating material. This is something I’m deeply passionate about, and I’d love any feedback you have on the article and concepts expressed here. Thanks a ton for reading it so far!
Resources/References
- (Resource) — HostHunter Framework
- (Reference) — Windows Management Instrumentation (WMI) Offense, Defense and Forensics
- (Reference) — PowerShell and Events: Permanent WMI Event Subscriptions
- (Resource) — Mattifestation WMI Persistence Template
Note: All opinions and thoughts in this article are my own and do not represent the perspective of my employer.
**Update. I originally reposted this blog from my personal account. I changed the title. In the new title I used the word vulnerability however upon reflection I feel this is misleading. WMI is a challenging problem for defenders. However it is functionality working as designed 😆 Doesn’t make defenders lives any easier, but there you go.
Say Hi!
I love hearing from my readers, so feel free to reach out. It means a ton to me when you clap for my articles or drop a friendly comment — it helps me know that my content is helping.
❤