WMI

The folks over at CyberTriage recently shared a complete guide to WMI; it’s billed as a “complete guide to WMI malware”, and it covers a great deal more than just malware. They cover examples of discovery and enumeration, as well as execution, but what caught my attention was persistence. This is due in large part to an investigation we’d done in 2016 that led to a blog post about a novel persistence mechanism. The persistence mechanism illustrated in the blog post bore remnants similar to what was seen in this Mandiant BlackHat 2014 presentation (see slide 44).

What’s interesting is that we continue to see this WMI persistence mechanism used again and again, where event consumers are added to the WMI repository. In addition to the 2016 blog post mentioned previously, MS’s own Human-operated ransomware blog post from 2020 includes the statement, “…evidence suggests that attackers set up WMI persistence mechanisms…”.

In addition to some of the commands offered up by the CyberTriage guide and other resources, MS’s own AutoRuns tool includes a check for WMI persistence mechanism on live systems.

There are also a number of tools for parsing the WMI repository/OBJECTS.DATA file for event consumers added for persistence during disk or “dead box” forensics, such as wmi-parser and flare-wmi. 

Chad Tilbury shared some really great info in his blog post, Finding Evil WMI Event Consumers with Disk Forensics.

Disk forensics isn’t just about parsing the WMI repository; there’s also the Windows Event Log. From this NXLog blog post regarding WMI auditing, look for event ID 5861 records in the WMI/Operational Even

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.