Adversaries use this persistence mechanism to execute arbitrary code in response to activity on the endpoint such as a user logging in or out or a file being written to a specified path.
When the above command is run, it will download and execute the contents of the XSL file.Īdversaries also use WMI for persistence via the trio of WMI event consumers, filters, and filter-to-consumer bindings. Here’s an example of what this can look like: wmic os get /FORMAT:"" We’ve also run into adversaries leveraging XSL Script Processing, which can be used to bypass application control and-courtesy of WMIC’s /format option-download code from a remote location. enumerate group membership (including local and in many configurations, domain administrator accounts).determine what antivirus product may be installed.
In addition to enumerating and manipulating volume shadows, adversaries use WMIC to enumerate and modify dozens of aspects of a Windows system or environment. The pattern above will cause wmiprvse.exe to spawn the vssadmin.exe process. Ironically, we sometimes see a less than stealthy version of this attack using WMIC: wmic process call create vssadmin.exe delete shadows /all /quiet However, wmic.exe may also be used to manage volume shadows without calling vssadmin.exe via a command like the following: wmic shadowcopy delete /noninteractive Because ransomware operators frequently use the Volume Shadow Administration utility, vssadmin.exe, for this purpose, many organizations send alerts to the SOC when it executes. During ransomware attacks, adversaries often list and delete volume shadows, which are used to recover files. Variations of the above command line may include passed credentials.Īnother common way adversaries use WMI, and WMIC specifically, is to gather information and modify systems. If your security audit policies are logging logon events, you should see a corresponding network (type 3) logon event associated with this activity. On the destination host, the given process will appear as a child of wmiprvse.exe. Here is a WMI lateral movement technique that we see often: wmic.exe /node: process call create This is important to remember because if you’re looking at suspicious activity that ties back to a parent process of wmiprvse.exe, you may be dealing with an adversary who is using wmic.exe on a remote system to execute payloads on the system you’re investigating-a form of lateral movement. There are a number of Windows binaries that make WMI calls under the hood that are handled by wmiprvse.exe- tasklist.exe is one example. On the server side, wmiprvse.exe-or the WMI Provider Host-services many, but not all, requests made by clients. Because we observe wmic.exe far more often than Get-WMIObject, the examples provided below will focus on the former. Administrators and adversaries alike use both for the purposes mentioned above. The most recognized clients are the command-line utility wmic.exe (aka WMIC), and the PowerShell cmdlet Get-WMIObject. How do adversaries use WMI?īefore delving deeper into how adversaries use WMI, understand that there are client and server components that make up WMI. Furthermore, because WMI is routinely used for benign purposes, malicious activity often blends in with legitimate activity. Note that because WMI can carry out these tasks on both local and remote systems, adversaries can use it for lateral movement. What makes WMI useful to administrators also makes it attractive to adversaries. Like many of the threats highlighted in this report, WMI is a native Windows feature that can be used on local or remote systems.