WMI as an attack vector is not new. It has been used to aid attacks within Microsoft networks since its invention. However, it has been increasingly weaponized in recent years, largely due to its small forensic footprint. In a world of greater enterprise visibility and advanced endpoint protection, blending in using native tools is the logical next step.
First, what is WMI? Windows Management Instrumentation is Microsoft's implementation of the WBEM standard. It has existed all the way back to Windows NT. Out of the box, WMI provides almost 4000 different configurable items. If your motherboard has a WMI driver, you can manage the CPU fan (ref. Win32_Fan class)! It was designed to aid in administrating large, distributed environments.
As we will see, WMI can be used for a lot more than just data collection (and reconnaissance). While it does an excellent job of providing configuration data, it can also be used for a wide range of attacker activity. WMI is one of the easiest and most stealthy components of many modern attacks. WMI attacks generally require administrator rights, but once admin is attained, the door is wide open for post-exploitation. In fact, every aspect of the post-exploit kill chain can be accomplished with built-in WMI capabilities, and unfortunately, minimal logging. Attackers have gravitated to it because It is an excellent way to evade application whitelisting and host-based security tools. WMI employs all trusted, signed binaries, and any scripts required can be easily obfuscated to prevent detection. It is largely "memory only" and on the network side, it employs standard DCOM / PSRemoting traffic, possibly encrypted, blending into a very noisy pipe.
The best attackers have gravitated towards WMI because it is fairly difficult to detect and mitigate in the modern enterprise. However, there are multiple techniques you can use to discover evil WMI activity.
Command Line Auditing and WMI Logs
If you want to reliably detect malicious WMI, your first priority is to get command line auditing. Luckily, that isn't hard these days. Microsoft has backported the ability to record command lines in Process Tracking events all the way back to Windows 7. An even better option is the free Sysmon tool from Microsoft Sysinternals. Sysmon is highly targeted towards malicious activity and can be easily filtered to ensure the resulting logs do not overwhelm your collection capabilities. The on by default WMI-Activity Operational event log has been improved in modern versions of Windows and should be collected from endpoints. Finally, many of the latest generation of endpoint detection and response tools include the native capability to record all command lines (and the historical data can be particularly useful for scoping an environment once activity and tradecraft is discovered).
Auditing the WMI Repository
One of the more insidious WMI attacks is the use of WMI Events to employ backdoors and persistence mechanisms. These events and corresponding consumers are stored in the local WMI repository within the file system and are broadly invisible to both users and system administrators. While WMI and PowerShell can be used for attacks, they equally can be used for defense. Native support for WMI and easy scalability makes PowerShell an obvious choice for detecting attacks like WMI event consumers. This is great news, because you do not need fancy tools for detection of one of the stealthier WMI threats. The following commands collect WMI event filters, consumers, and bindings on a system.
Get-WMIObject -Namespace root\Subscription -Class __EventFilter
Get-WMIObject -Namespace root\Subscription -Class __EventConsumer
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding
PowerShell remoting facilitates collection at scale, and getting the results into something like an elastic search database can allow easy hunting for anomalies, even across thousands of systems. Simply stated, the only reason evil WMI Event Consumers are stealthy is because most organizations are not looking for them.
File System Residue
Contrary to their categorization as "fileless malware", WMI attacks can leave behind file system artifacts. The files representing the WMI repository can be analyzed for modifications, including offline analysis to easily detect malicious WMI Event Consumers. MOF files are a common way to introduce malicious classes into the WMI repository. What exactly is a MOF file? Think of it as a text file representing WMI class definitions and instances. Definitions in the WMI repository are initially defined in MOF files. They can also be used to extend WMI (which is how attackers use them). Sadly, a MOF file can be named anything, be located anywhere, and even deleted after it is introduced into the WMI repository. But every attack is different, and evil MOF files are still found on compromised systems. If you aren't so lucky, copies may be left behind in the C:\Windows\System32\wbem\AutoRecover folder, or referenced in the HKLM\SOFTWARE\Microsoft\Wbem\CIMOM registry key. Of course, PowerShell can be used in lieu of MOF files, but that opens up an entirely separate set of possible detections like the PowerShell Operational event log or transcript logging. What we are aiming for is layered detection.
Memory Analysis
As WMI and PowerShell become ubiquitous in the enterprise, we should expect to see them in our memory process trees. A process tells us a lot about the type of activity occurring on the system. WMI CommandLine Event Consumers kick off a new WmiPrvSE process to run an executable or PowerShell script. Scrcons.exe (literally named script consumers .exe) is the parent of any ActiveScript consumers such as VBScript or Jscript (it is also a rare process, making it a great candidate for detections). WMI was designed to be queried and controlled remotely, and the WmiPrvSE.exe process (WMI Provider Host) is responsible for running WMI commands on a remote (target) system. WmiPrvSE facilitates the interface between WMI and operating system. WMI is incredibly flexible and attackers have identified many ways to run malicious code using it ("wmic.exe process call create" is the classic example, but it can get much more involved). You may even see attackers move to WMI when PowerShell remoting is available because it is less obvious to have things running via WMI. The children of a WmiPrvSE process can often be the clue that helps identify suspicious behavior.
If a wsmprovhost.exe process is identified on a system, it indicates PowerShell remoting activity. This process is executed on the remote, or target system. This pattern includes PowerShell capabilities like Enter-PSSession, Invoke-Command, New-PSSession, or any number of PowerShell cmdlets that natively have the "-ComputerName" parameter such as Set-Service, Clear-EventLog, and Get-WmiObject. Finding malicious WMI and PowerShell in memory can be challenging due to the amount of legitimate activity happening in the modern enterprise. As with all things hunting, context is important, and we can often get more context by looking at the parent and children of processes.
Webcast and the SANS FOR508 Course
If this sparks your interest, I'll dive deeper into these topics on an upcoming webcast (see below). If you want real world experience finding and responding to these types of attacks, take a look at the latest version of SANS FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics. We have six days of new exercises investigating a large-scale enterprise intrusion emulating an APT29/Cozy Bear adversary (who commonly abuse WMI and PowerShell to accomplish their objectives). It's Time to Go Hunting!!!
________________________________________________________________________________
JOIN THIS WEBCAST TO FIND OUT MORE:
Investigating WMI Attacks
- When: Thursday, March 7th, 2019 at 3:30 PM EST (20:30:00 UTC)
- Conducted by Chad Tilbury
- Register now
Overview
Advanced adversaries are increasingly adding WMI-based attacks to their repertoires, and most security teams are woefully unprepared to face this new threat. Join SANS Senior Instructor Chad Tilbury for an overview of the state of WMI hacking, including real world examples of nation state and criminal actor tradecraft. Detection tools and analysis techniques for addressing the threat will be discussed along with actionable steps to better increase your organizations security posture.
(Note: A recording and slides will be available afterwards at the same link)