Understanding and auditing WMI

One of the key use cases for WMI as an attack vector is fileless malware. How can malware be fileless, you may ask?

The technologies and techniques used may vary, but if you think about it, malware is software (malicious of course), and software is simply a set of instructions for a machine to execute. In conclusion, we can deduct that "fileless malware" is software that has been embedded with instructions intended to spy on or harm the system, without having to store them on a file on disk.

The following two use cases explore how WMI can be used as an instrument for fileless malware.

The first publicly known occurrence of malicious WMI use was Stuxnet more than ten years ago, and as you may recall, this was a rather sophisticated attack from a well-funded hacking team.

One group that has perfected the use of WMI as a stealthy and efficient backdooring mechanism is APT29 (aka "Cozy Bear"). APT29 is one of the top global hacking groups, targeting governments, think tanks, and international organizations. This shows just how powerful of a tool WMI can be when used knowledgeably.

In the case of APT29, they found in PowerShell and WMI a perfect backdoor recipe using a "living off the land" strategy. It means that native OS tools and 100% legitimate configurations are used to deliver the malicious logic. This is as stealthy as it gets.

The POSHPY backdoor was designed to use WMI for storage and persistence while leveraging PowerShell to write and execute the backdoor logic:

Using WMI as a means to enable malware activities is called WMI hijacking since the malicious actor is taking a valid software asset and weaponizing it for their purposes. The previous example regarding the POSHPY backdoor is also a form of WMI hijacking, but a very special one because of the overall strategy employed.

WMI hijackers are common these days, so common that they’re a sort of digital plague; it’s like fileless WMI malware, commoditized. The following is a list of some well-known malware using WMI hijacking:

Examples abound, so if you’re interested in investigating more scenarios, launch a search for "WMI" on the MITRE website and have hours of fun!

Windows security auditing is a Local Security Policy setting that enables events to be triggered when any attempt is made to access or modify a SACL-protected system resource, regardless of success or failure. SACL stands for System Access Control List. For further information see Microsoft’s documentation on Access Control Lists.

Windows security auditing events will increase the number of events generated by the system, and they can be very verbose, which is likely one of the reasons it’s not enabled by default. Enabling object auditing, however, will dramatically increase our chances to detect malicious WMI activity.

To test the effects of enabling the audit policy for object access, we will use a simple WMIC command that lists active processes on a system:

With such a powerful command like this, that can retrieve information from memory for each active process, you would think it would light up with Windows events like a Christmas tree. Well, guess what? All you get is a single event in the Microsoft-Windows-WMI-Activity/Operational log that’s no different than what is produced by other sources. The only thing it provides is a notification of when WMI activity was recorded.

We can improve this by turning on a couple of knobs in the Local Security Policy (secpol.msc). From there, expand Local Policies > Audit Policy.

Double-click on Audit object access and enable both Success and Failure. Click Apply followed by OK to save settings.

Now, if we execute our test WMIC command from above, the results will be very different from what we initially saw. This time around, the Security log shows three events, each one having a different Event ID: 4656, 4663, and 4658. Of these three, the one providing the most information is identified by Event ID 4656: A handle to an object was requested.

If you examine this event carefully, it contains user information as well as the nature of the query. It tells you which object was accessed and the executable that processed the query: C:\Windows\System32\wbem\WmiPrvSE.exe. From this information, you can identify what a person is trying to do using WMI.

It gets even better, because we can enable WMI-specific auditing in order to generate events containing even more detail. To do this, you need to open the Windows MMC (mmc.exe) and add the WMI Control snap-in.

This brings up the WMI-specific Access Control module, which includes the auditing capability.

At this point, choose the security principals that will need to have auditing enabled. The screenshot below shows the Administrator user, but consider adding all relevant accounts to be monitored.

The enumerated parts of the Auditing Entry for Root window can be explained as follows:

Once the configuration is applied, we can execute the wmic process list brief command again. Event ID 4662 ("An operation was performed on an object.") will now be logged in the Security log; if you pair this with Event ID 4656 you get a very clear picture of what occurred. See how Event ID 4662 below shows the exact query that was made on the system (in "Parameter 2", under "Additional Information"):

Another source of meaningful information to help us track WMI activity is PowerShell. Since a PowerShell script is typically executed as part of these attacks, it makes sense to enable PowerShell auditing. Fortunately, this one is pretty straightforward to enable.

You enable this from the Group Policy Editor (gpedit.msc) by expanding Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell.

For our use case, we will enable the first two policies:

To demonstrate PowerShell auditing, we will use a sample script that disables registry values related to TLSv.1. Once the script is executed, several events will be logged in the Powershell/Operational log. We’re especially interested in Event ID 4103, which provides details about scripts executed on the system. The following event sample shows the script’s full path and filename, and the actual commands it executed.

If you’ve spent some time administering Windows servers, chances are good that you’ve come in contact with Sysmon. If not, Sysmon is a tool that can capture more information than the default Windows logs. It’s a very useful tool, especially for "obscure" activities that are not addressed very well by the default logs.

In the case of WMI, Sysmon focuses on logging subscription-related activities, since they’re so sensitive and widely used to launch attacks. You will typically see these events appear consecutively:

This is a set of event IDs you will absolutely want to monitor on your system. They are included in the default configuration provided by the Sysmon developers available on GitHub.

The WMI/Operational event log source provides several Event IDs by default. The ones you’ll encounter more commonly are:

It’s important not to overlook the WMI/Operational event log even if it feels like the above two events don’t provide much useful information. Remember that a key strategy behind launching malware using WMI is persistence, and persistence is achieved by generating a subscription. Here’s where the WMI/Operational event log proves more useful:

The following is a sample of event ID 5861, providing information about a permanent subscription. With this kind of information at hand, an incident response team can quickly verify and disable the offending subscription, since it includes the location and name of the source.

A WMI trace log is available in Event Viewer, but it’s not active by default. To activate it, follow the instructions provided by the Microsoft documentation on Obtaining WMI Events Through Event Viewer.

The screenshot above shows the enabled Trace log under the WMI-Activity channel in Event Viewer.

One thing to bear in mind is that tracing often provides events that aren’t meaningful, so baselining and applying filters would be a good idea. For example, you can find better context in events 11 and 17 from the trace log, and can safely discard event 50.

With NXLog Enterprise Edition’s filtering capabilities, discarding unwanted events is easy and consumes only minimal resources. Filtering out noise events also means that you avoid sending them to your SIEM. Have a look at Filtering logs in the NXLog User Guide for more information on how to apply filtering from the source.

It’s paramount to collect events from different sources and perspectives to gain a complete picture of WMI activity on your system. Mandiant threat researchers came up with a way to turn the enemy’s weapon against themselves. Their process is nicely documented in their blog post WMI vs. WMI: Monitoring for Malicious Activity.

Their script detects WMI-based process executions, as well as new WMI subscription activities, and logs them in the Application log. The script is available in the referenced article that you can download and test out yourself.

In order to test the WMI-based process execution, use the test provided in the script readme file, or simply start any common process with WMIC:

After executing this command, Event ID 8 with source WSH will be logged in the Applications log:

Testing the creation of new consumers and subscriptions requires a bit more effort. See the https://learn-powershell.net blog[ Learn Powershell | Achieve More] post PowerShell and Events: Permanent WMI Event Subscriptions for a detailed explanation. The following is an example of an event logged after creating a new consumer:

Now it’s time to put it all together! Although WMI requires this multilayered logging approach we’ve been following, NXLog Enterprise Edition makes it easy to capture all these valuable events with a single configuration file. We will start by providing individual snippets for each log source followed by a complete configuration.