What’s happening?
Given the intricate landscape of cybersecurity, the misuse of Windows Management Instrumentation (WMI) stands out as a pervasive threat. WMI facilitates centralized management of Windows devices by providing a consistent and well-documented interface that can be utilized by various management applications developed by Microsoft and third-party vendors.
This article delves into methodologies utilized by cybersecurity professionals to mitigate the abuse of WMI, which threat actors exploit for various malicious intents.
High-profile and low-profile malicious entities employ WMI, utilizing manual and automated techniques to execute commands stealthily, move laterally compromised systems, and even achieve persistence goals. Understanding these methodologies is crucial in fortifying defenses against different cyber threats.
Technique T1047 Windows Management Instrumentation (WMI)
Windows Management Instrumentation (WMI) is a powerful management framework in the Windows operating system, allowing administrators to automate system tasks, monitor performance, and gather information about the system. However, malicious actors often exploit WMI for nefarious purposes, leveraging its capabilities to execute commands remotely, evade detection, and persist on compromised systems. By abusing WMI, attackers can stealthily execute commands, establish persistence mechanisms, and carry out various malicious activities without raising suspicion.
Hunting the threat: from hypothesis to event analysis
The most common way of hunting for WMI abuse is quite simple – we assume that the threat actor is going to move laterally or execute some commands with the help of the wmic.exe command line tool so that the following hypothesis can be generated:
“wmic.exe utility is utilized to execute something via WMI.”
EDR query, in this case, might look like this:event_type: “Process creation” AND Payload.ImageFileName: “*\\wmic.exe” AND Payload.CommandLine: “*process call create*”
Example of such execution via wmic.exe looks like the following from an EDR perspective:
Picture 1: Examples of wmic being used for the execution of commands
More criteria can be added to the query, e.g., AND Payload.CommandLine: “*/node:*” to get suspicious events indicating remote execution (/node parameter followed by a hostname or an IP address of the host or allows the execution on the designated host).
Like any expert threat hunter, we should always question the easiest methods. Hence, It’s essential to recognize that the described hunting approach relies on the premise that EDR coverage in our environment is very close to 100%, which is not usually the case. On top of that, commands and files may be executed via WMI without using wmic.exe. These reasons mean this hunting approach is slightly limited (yet rewarding in certain cases since it enables quick identification of the attacker’s controlled hosts).
But don’t fret; there is another way of hunting for WMI usage, which is noisy but allows you to cover a wide breadth of cases. First of all, let’s pay attention to commonalities between different examples of execution via WMI seen in EDR telemetry for corresponding process creation events:
Picture 2: Commonalities between different processes executed via WMI
Picture 3: Commonalities between different processes executed via WMI
We can see through the images that there is a common parent process – WmiPrvSe.exe, occasionally referred to as “wmi host process” or “wmi engine process.” To aid our objective, it is crucial to understand that if something is executed via WMI, its corresponding process is spawned as a WmiPrvSe.exe child. This presents an effective option for hunting, as demonstrated by the following query:event_type: “Process creation” AND Payload.ParentImageFileName: “*\\wmiprvse.exe”
Our test scope showcases what we’ve already viewed:
Picture 4: Example of WMI host process-oriented query being executed
However, when expanding our search to a real environment, we might encounter some challenges.
Picture 5: Real-life example of the above query execution
Given that it is a noisy query, it requires copious work to yield interpretable results, including statistics-based exclusions or inclusions based on the user. One good example of this is to include events produced by NETWORK SERVICE users, which may be indicative of remote WMI execution:
Picture 6: Example of a limiting criteria usage
A concrete way is to look for the stats in your particular environment and try to search for outliers with malicious/suspicious intentions:
Picture 7: Statistic regarding the frequency of execution of different processes via WMI
In conclusion, the methodologies outlined for WMI execution abuse offer valuable insights. The suggested noisy hypothesis isn’t solely beneficial for lateral movement hunting; it’s also effective for identifying WMI persistence. In both scenarios, WmiPrvSe.exe serves as the parent process.
Roman Rezvukhin – Head of Malware Analysis and Threat Hunting Team
https://www.group-ib.com/blog/hunting-rituals-4/