Unlike attacks carried out by traditional malware, fileless malware doesn’t require the attackers to install a single piece of software on a target’s machine. Instead, fileless malware attacks take tools built into Windows like Windows Management Infrastructure (WMI) and using them for malicious activity. These attacks are particularly challenging to detect since these tools and the actions they carry out are trusted.
The features of WMI are a blessing because they allows admins to perform tasks very quickly, but can very quickly turns into a curse when used for malicious operations. The same way an administrator uses WMI to query metrics and execute code, a hacker can use it to silently and instantly run malicious code across an entire network of machines. WMI also allows for persistence by auto-running programs stealthily on startup or based on specific events. WMI can’t be uninstalled, but it can be disabled. However, doing so impairs and limits what an administrator can do, such as update software across multiple machines.
A Brief Background on WMI
Windows Management Infrastructure (WMI) is the implementation of the WBEM and CIM standards on the Windows OS, and allows users, administrators and developers (as well as attackers) to enumerate, manipulate and interact with various managed components in the OS. In practice, WMI provides an abstracted, unified object-oriented model, which contains classes representing many discrete elements of a machine, without needing to directly interact (and study the documentation of) many unrelated APIs.
You can enumerate the instances of components represented by a class by issuing WMI queries, which are written in WQL, an SQL like language, or through abstractions such as the PowerShell CIM/WMI cmdlets. It is also possible to invoke methods on classes and instances, and thus to manipulate the underlying managed components using the WMI interface.
An important feature of WMI is the ability to interact with the WMI model of a remote machine, using either the DCOM or the WinRM protocol. This allows attackers to remotely manipulate WMI classes on a remote machine without needing to run any arbitrary code on it beforehand.
The Main Components of WMI
WMI consists of three major components:
- The WMI service (winmgmt) acts as a mediator between clients and the WMI model itself, and is responsible for handling all requests (method calls, queries, etc.) coming from client processes. While it cannot process most of these requests by itself, it is able to forward them to other components, and forward their responses back to the client.
- WMI providers are where the actual code implementing classes, instances and methods is implemented. Providers are mostly implemented as in-process COM objects.
- The WMI Repository is the central storage area for the model, containing things like class definitions and instances of objects which require persistence (as opposed to instances that are dynamically generated by providers.
