Her0in · 2015/10/27 at 10:30

FireEye’s Advanced Reverse Engineering team (FLARE) has released a 90-page PDF titled “WMI Attack, Defense, and Forensic Analysis Techniques.” The WMI technology is described in detail from three perspectives of defense and forensic analysis. There is much to learn and think about. Therefore, I use my spare time to translate and arrange this document, take it out and share with you :), if there is a mistake, I hope you don’t hesitate to give advice.

In order to fully translate and interpret the content of the original document, I translated the original document in sections according to the analysis of the article. This article is the first one in the section, and the titles of the other two translations are as follows:

  • Defense of WMI Attack, Defense, and Forensic Analysis Techniques
  • Forensic Analysis of WMI Attack, Defense, and Forensic Analysis Techniques

A brief introduction 0 x00 WMI

WMI full name is Windows Management Instrumentation, that is, Windows Management specifications, in the Windows operating system, with the introduction of WMI technology and after the passage of time and obsolete, it as a powerful technology, Starting with Windows NT 4.0 and Windows 95, keep it consistent. It appears in all Windows operating systems and consists of a powerful set of tools for managing Windows systems locally or remotely.

Although widely known and widely used by system administrators since its inception, WMI technology became very popular in the security community when it was discovered in stuxnet. Since then, WMI has become increasingly popular in attacks such as performing system reconnaissance, anti-virus and virtual machine detection, code execution, lateral movement, permission persistence, and data theft.

As more and more attackers exploit WMI, it will be an important skill for security maintainers, incident responders, and forensic analysts to master and understand how to use it to their advantage. This whitepaper introduces WMI technology, demonstrates how to use WMI to construct a POC in an actual attack, how to use WMI as a basic IDS, and how to do forensic analysis in the WMI repository file format.

0x01 Revision History

Prior to Win2K, WMI was already supported, but a development kit was required to be downloaded and installed. Since Win2K, the system has WMI, and WMI has become an important component of the system. With the release of XP, 2003, Vista, Windows 7, etc., the functionality that WMI can provide is constantly being enhanced and improved.

The following is the corresponding WMI version in the operating system version:

  • Nt 4.0 1.01
  • Sms 2.0 1.1
  • Win2000 1.5
  • WinXP / 2.0 2003

0x02 WMI Architecture

WMI is a Web based Enterprise Management (WBEM) and Common Information Model (CIM) standard implemented by Microsoft and published by distributed Management Task Force (DMTF). The purpose of these two standards is to provide an industrial agnostic means of gathering and disseminating information about any managed component in the enterprise.

At a high level, Microsoft’s implementation of these standards can be summarized as follows:

Managed component

Managed components are represented as WMI objects — class instances that represent highly structured operating system data. Microsoft provides a wealth of WMI objects for communicating with operating system-specific information. For example: Win32_Process, Win32_Service AntiVirusProduct, Win32_StartupCommand and so on.

Use WMI data

Microsoft provides several ways to use WMI data and perform WMI methods. PowerShell, for example, provides a very simple way to interact with WMI.

Example Query WMI data

All WMI objects use a language similar to an SQL query called WMI Query Language (WQL). WQL has fine and subtle control over the WMI objects returned to the user.

Populate WMI data

When a user requests a specific WMI object, the WMI service (Winmgmt) needs to know how to populate the requested WMI object. This process is implemented by the WMI provider. The WMI provider is a COM-based DLL that contains an associated GUID that has been registered in the registry. Functionality of the WMI provider — such as querying all running processes, enumerating registry entries, and so on.

When WMI services populate WMI objects, there are two types of class instances: dynamic objects and persistent objects. Dynamic objects are generated during runtime when a particular query executes. For example, the Win32_Process object is dynamically generated during runtime. Persistent objects are stored in the CIM database located at %SystemRoot%\System32\wbem\Repository\, which stores instances of WMI classes, class definitions, and namespace definitions.

Structured WMI data

The architecture of most WMI objects is described in managed Object Format (MOF) files. The MOF file uses a C++ -like syntax and provides the schema for a WMI object. Thus, although the WMI provider generates the raw data, the MOF file provides a formatted schema for the data it produces. From a security maintainer’s point of view, it is worth noting that WMI object definitions can be created without MOF files. Instead, they can plug directly into the CIM database using.NET code.

Remote transmission of WMI data

Microsoft provides two protocols for remote transfer of WMI data: Distributed Component Object Model (DCOM) and Windows Remote Management (WinRM).

The WMI operation is performed

Some WMI objects include executable methods. For example, a common method that an attacker performs when moving sideways is the static Create method in the Win32_Process class, which can quickly Create a new process. In addition, WMI provides an event system that allows users to create, modify, or delete any WMI object instance using registered event handlers.

Figure 1 provides a high-level overview of Microsoft’s implementation of WMI and the relationship between the components that Microsoft implements and the standards that it implements.

Figure 1: High-level overview of the WMI architecture

0x03 WMI class and namespace

WMI represents most of the data related to operating system information and manipulation in the form of objects. A WMI object is an instance of a class with a highly structured definition of how information is represented. On MSDN, there are many details of the commonly used WMI classes. For example, a common and documented WMI class is Win32_Process. There are also many undocumented WMI classes, but fortunately, all WMI classes can be queried using the WMI Query Language (WQL).

The hierarchy of namespaces for WMI classes is very similar to that of traditional, object-oriented programming languages. All namespaces are derived from the ROOT namespace, and Microsoft uses ROOT\CIMV2 as the default namespace when querying objects in scripting languages without explicitly specifying a namespace. The following registry key contains all WMI Settings, including the default namespace defined:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM

You can use the PowerShell code below to recursively query all WMI classes and their respective namespaces.

Figure 2: PowerShell sample code listing all the WMI classes and namespaces

In our tests on Windows 7, we found that there are already 7,950 WMI classes, which means a lot of operating system data can be retrieved.

Here is a partial result of the full WMI classpath returned by the above script:

0 x04 querying WMI

WMI provides a simple syntax for querying WMI object instances, classes, and namespaces — WMI Query Language (WQL).

There are three types of WQL queries:

2. Event query – used for a WMI event registration mechanism, such as the creation, deletion, or modification of WMI objects 3. Meta query – Used to query the WMI class schema

Examples of query

Instance queries are the most common WQL queries used to get instances of WMI objects. The basic instance query takes the following form:

SELECT [Class property name|*] FROM [CLASS NAME] <WHERE [CONSTRAINT]>

The following query returns results for all running processes whose executable names contain “Chrome”. Specifically, this query returns the string “Chrome” in the name field of all properties of each instance of the Win32_Process class.

SELECT * FROM Win32_Process WHERE Name LIKE "%chrome%"

Event query

Event query provides an alarm mechanism that triggers the event class. Used for common event query triggers when WMI class instances are created. Event queries will take the following form:

SELECT [Class property name|*] FROM [INTRINSIC CLASS NAME] WITHIN [POLLING INTERVAL] <WHERE [CONSTRAINT]>

SELECT [Class property name|*] FROM [EXTRINSIC CLASS NAME] <WHERE [CONSTRAINT]>

Internal and external events are explained in further detail in the Events section.

Below are the event query triggers for interactive user logins. According to the MSDN documentation, the LogonType value for interactive logins is 2.

SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2

Here is the event query trigger when removable media is inserted:

SELECT * FROM Win32_VolumeChangeEvent WHERE EventType = 2

Yuan query

Meta-queries provide a WMI class schema discovery and inspection mechanism. Meta query takes the following forms:

SELECT [Class property name|*] FROM [Meta_Class<WHERE [CONSTRAINT]>

The following query will list all WMI classes starting with the string “Win32” :

SELECT * FROM Meta_Class WHERE __Class LIKE "Win32%"

When performing any WMI queries, the default namespace ROOT\CIMV2 is implicitly used unless it is explicitly provided.

0x05 Interacts with WMI

Microsoft and third-party vendors provide a wealth of client tools to enable you to interact with WMI. The following is a non-exhaustive list of such client utilities:

PowerShell

PowerShell is an extremely powerful scripting language with a wealth of capabilities for interacting with WMI. As of PowerShell V3, the following CMDlets (PowerShell command terms) are available to interact with WMI:

  • Get-WmiObject
  • Get-CimAssociatedInstance
  • Get-CimClass
  • Get-CimInstance
  • Get-CimSession
  • Set-WmiInstance
  • Set-CimInstance
  • Invoke-WmiMethod
  • Invoke-CimMethod
  • New-CimInstance
  • New-CimSession
  • New-CimSessionOption
  • Register-CimIndicationEvent
  • Register-WmiEvent
  • Remove-CimInstance
  • Remove-WmiObject
  • Remove-CimSession

The WMI and CIM CMDlets provide similar functionality. However, the CIM CMDlet introduces PowerShell V3 and provides some additional flexibility through WMI CMdlets. The biggest advantage of using CIM CMDLets is that they work on top of WinRM and DCOM protocols. The WMI CMDlet works only on top of the DCOM protocol. But not all systems will have PowerShell V3 + installed. PowerShell V2 is installed on Windows 7 by default. Therefore, it is considered the least public program by an attacker.

wmic.exe

Wmic.exe is a powerful command-line utility that interacts with WMI. It has a large number of easy-to-remember default aliases for WMI objects, but you can also perform more complex queries. Wmic.exe can also execute WMI methods, which attackers often use to move horizontally by calling the Create method of Win32_Process. One of the limitations of wmic.exe is that it cannot accept methods that call embedded WMI objects. When PowerShell is not available, wmic.exe is sufficient to perform system reconnaissance and basic method calls.

wbemtest.exe

Wbemtest.exe is a powerful WMI diagnostic tool with a graphical interface. It can enumerate object instances, execute queries, register events, modify WMI objects and classes, and invoke methods locally or remotely. Its interface isn’t particularly user-friendly for most users, but from an attacker’s point of view, it’s perfectly acceptable as an alternative when other tools aren’t available — for example, if the application whitelist mechanism blocks wmic.exe and Powershell.exe, Then wBemTest.exe will be a powerful utility with a less-than-ideal UI (as shown in Figure 3).

Figure 3. Graphical interface of WBEmTest

WMI Explorer

WMI Explorer is a good WMI class discovery tool. It provides an elegant GUI (shown in Figure 4) that allows you to explore the WMI repository in a hierarchical manner. It can also connect to a remote WMI repository and perform queries. WMI class discovery tools like this are invaluable to security researchers looking for WMI classes that can be used for attack or defense.

Figure 4 WMI Explorer

CIM Studio

CIM Studio is a Microsoft legacy free tool that allows you to easily browse the WMI repository. Like the WMI Explorer, this tool is also good for WMI class discovery.

Windows Script Hosting (WSH) language

Microsoft provides two WSH scripting languages, VBScript and JScript. Although they are old-fashioned and not exactly elegant programming languages, they are both powerful scripting languages when it comes to interacting with WMI. In fact, backdoors have emerged in VBScript and JScript that utilize WMI as the primary C&C mechanism. In addition, as explained later, they are the only support ActiveScriptEventConsumer event consumer component of language, the component for the attacker and defender is a very valuable WMI components. Finally, from an attack point of view, VBScript and JScript are the smallest common programs on older versions of Windows systems without PowerShell installed.

C/C++ calls the IWbem* COM API

If you need to interact with WMI in an unmanaged language such as C or C++, you will need to use the COM API of WMI. Reverse engineers will need to be very familiar with this interface and each COM Guid to fully understand the malware interacting with WMI.

The.net System. Management class

The.net class library provides several wmi-related classes in the system. Management namespace, making it relatively easy to write programs that interact with WMI using languages such as C#, VB.Net, and F#. In subsequent examples, these classes will be used to supplement the existing WMI/CIM CMDlets in PowerShell code.

winrm.exe

Winrm.exe can enumerate WMI object instances, invoke methods, and create and delete object instances on local and remote computers where the WinRM service is running. Winrm Settings can also be configured using winrm.exe. The following example shows how winrm.exe can be used to execute commands, enumerate multiple instances of objects, and retrieve a single object instance:

  • winrm invoke Create wmicimv2/Win32_Process @{CommandLine="notepad.exe"; CurrentDirectory="C:\"}
  • winrm enumerate http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
  • winrm get http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem

Linux versions of WMIC and WMIS-PTH

Wmic is a simple Linux command-line utility for performing WMI queries. Wmis is a remote call command line wrapper for the Create method of the Win32_Process class, and has been heavily used by penetration testers because it supports connecting to remote computers using NTLM hases.

0x06 Using WMI remotely

Although you can interact with the local WMI, the real power of the WMI can only be shown over the network. At present, thanks to the existence of DCOM and WinRM protocols, remote object query, event registration, WMI class method execution, and class creation can be supported.

These protocols appear to benefit attackers because most organizations and security providers generally do not review the content transmitted by these malicious activities. To effectively exploit remote WMI, an attacker needs the credentials of a privileged user. The WMIS-PTH utility, on the Linux platform, requires a hash of the victim’s user.

Distributed Component Object Model (DCOM)

It has been the default protocol used by WMI since the advent of DCOM, establishing the initial connection over TCP’s port 135. Subsequent data exchanges use randomly selected TCP ports. You can configure the scope of this port by using dcomCNfg.exe and eventually modifying the following registry key:

Rpc HKEY_LOCAL_MACHINE \ Software \ Microsoft \ \ Internet - Ports (REG_MULTI_SZ)

All the WMI cmDlets built into PowerShell communicate using DCOM.

Windows Remote Management (WinRM)

Recently, WinRM replaced DCOM as the recommended remote management protocol for Windows. WinRM is built based on the Web Services Management (WSMan) specification, a SOAP-based device management protocol. In addition, PowerShell’s remote transfer protocol is also based on the WinRM specification, and PowerShell provides extremely powerful Windows enterprise remote management. WinRM also supports WMI and performs CIM operations over the network.

By default, the WinRM service listens on TCP port 5985 (HTTP) and is encrypted by default. You can also configure the certificate to support HTTPS. In this case, the TCP port 5986 is monitored.

WinRM Settings are easy to configure using GPO, winrm.exe, or WSMan PSDrive in PowerShell, as shown below:

PowerShell provides a CMdlet to easily verify that the WinRM service is listening on — test-wsman. If test-wsman returns a result, the WinRM service on the system is listening.

To interact with the system’s WMI to run the WinRM service, the only built-in tools that support remote WMI interaction are Winrm.exe and PowerShell’s CIM CMDlet. In addition, for systems not running the WinRM service, the CIM CMDlet can also be configured to use DCOM.

0 x07 WMI events

From an attacker’s or defender’s point of view, one of the most powerful features of WMI is the ability to respond asynchronously to WMI events. With a few exceptions, WMI events can be used to respond to almost any event on the operating system. For example, a WMI event might be used to trigger a process creation event. This mechanism can then be used to perform command line audits on any Windows operating system.

There are two types of WMI events — both running in the context of a local single process and a WMI permanent event subscription. Local events can sustain the lifetime of the host process, and although the WMI permanent event subscription is stored in the WMI repository, running as SYSTEM permission can continue to run after a restart.

Event trigger condition

To install a permanent event subscription, the following three things must be done:

1. Event filter – filter out events of interest 2. Event consumer – action to be performed when an event is triggered 3. Consumer-bound filters – Bind filters to the consumer’s registration mechanism

Event filter

Event filters describe the events of interest and perform WQL event queries. Once system administrators have configured filters, they can use it to receive notifications when new events are created. As an example, event filters might be used to describe some of the following events:

  • Create a process with a specific name
  • Load the DLL into the process
  • Create an event log with a specific ID
  • Insert removable media
  • The user logged off
  • Create, modify, delete any files or directories

Event filters are stored as an instance of a ROOT\subscription:__EventFilter object. Event filter queries support the following types of events:

Internal events

Internal events represent events that create, modify, and delete any WMI class, object, or namespace. They can also be used for timers or alerts executed by WMI methods. The following internal events take the form of system classes (those starting with two underscores) and exist in each WMI namespace:

  • __NamespaceOperationEvent
  • __NamespaceModificationEvent
  • __NamespaceDeletionEvent
  • __NamespaceCreationEvent
  • __ClassOperationEvent
  • __ClassDeletionEvent
  • __ClassModificationEvent
  • __ClassCreationEvent
  • __InstanceOperationEvent
  • __InstanceCreationEvent
  • __MethodInvocationEvent
  • __InstanceModificationEvent
  • __InstanceDeletionEvent
  • __TimerEvent

These events are very powerful because they can be used as triggers for almost any conceivable event in an operating system. For example, if an interactive login-based event is triggered, the following internal event query can be formed:

This query is converted to create an instance of the Win32_LogonSession class of login type 2 (interactive).

Because internal events fire with a certain frequency, the event polling interval must be specified in the WITHIN clause of the WQL query statement. That is, it may sometimes miss events. For example, if the form of the event query is to create an instance of a WMI class, the event will be missed if the instance is created and destroyed (as is common with some processes — Win32_Process instances) within the polling interval. This possibility must be considered when creating internal WMI queries.

SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2

External events

External events solve potential round problems associated with internal events because they are triggered immediately when the event occurs. The fly in the ointment, however, is that there are not many external events in WMI; however, all external events that do exist are powerful and perform very well. The following external events may be useful to attackers and defenders:

  • ROOT\CIMV2:Win32_ComputerShutdownEvent
  • ROOT\CIMV2:Win32_IP4RouteTableEvent
  • ROOT\CIMV2:Win32_ProcessStartTrace
  • ROOT\CIMV2:Win32_ModuleLoadTrace
  • ROOT\CIMV2:Win32_ThreadStartTrace
  • ROOT\CIMV2:Win32_VolumeChangeEvent
  • ROOT\CIMV2: Msft_WmiProvider*
  • ROOT\DEFAULT:RegistryKeyChangeEvent
  • ROOT\DEFAULT:RegistryValueChangeEvent

The following external event query form can be used to capture all executable modules (user mode and kernel mode) that each process has loaded: SELECT * FROM Win32_ModuleLoadTrace

Event consumer

Event consumption is a class derived from the __EventConsumer system class that represents actions when an event is triggered. The system provides the following useful standard event consumables:

  • LogFileEventConsumer – Writes event data to the specified log file
  • ActiveScriptEventConsumer – perform inline or JScript VBScript script content
  • NTEventLogEventConsumer – Creates an event log entry that contains event data
  • SMTPEventConsumer – Sends an email containing event data
  • CommandLineEventConsumer – Executes a command line program

The attacker in response to their event, extensive use of ActiveScriptEventConsumer and CommandLineEventConsumer class. These two event consumers give attackers great flexibility to execute whatever payload they want without having to write a malicious executable or script to disk.

Example of malicious WMI persistence

The PowerShell code in Figure 5 is a modified example of WMI persistence code that exists in the SEADADDY malware family. The event filter, taken from PowerSploit’s persistence module, is intended to be triggered shortly after the system starts, and the event consumer only needs to execute an executable file with system permissions. The event filter in Figure 5 acts as a trigger between 200 and 320 seconds after the system starts. The event consumer executes the specified executable when the event is triggered. Register and bind the filter and consumer together by specifying the filter and an instance of __FilterToConsumerBinding.

Figure 5: WMI persistence PowerShell code for SEADADDY malware

0x08 WMI Attack Technology

WMI is an extremely powerful tool in all stages of an attacker’s attack life cycle. The system provides a wealth of WMI objects, methods, and events that are extremely powerful and can perform everything from system reconnaissance, anti-virus, virtual machine detection, code execution, lateral movement, covert storage of data, and persistence. It can even create a pure WMI backdoor without writing files to disk. Attackers using WMI have many advantages:

  • It is installed by default on all Windows operating systems and dates back to Windows 98 and NT4.0.
  • For executing code, it can implicitly run PSEXEC.
  • WMI permanent event subscriptions are run as system permissions.
  • Defenders are often unaware that WMI can serve as a versatile attack vector.
  • Almost every system operation can trigger a WMI event.
  • Nothing is done to the disk except to store it in the WMI repository.

The following list shows several examples of how WMI can be used to perform operations at various stages of an attack.

The reconnaissance system

The first thing many malware masters and penetration testers do is system reconnaissance, and WMI contains a number of classes that help attackers sense their target’s environment. The following WMI classes are a subset of the data that can be collected during the reconnaissance phase of an attack:

  • Host/operating system information :Win32_OperatingSystem, Win32_ComputerSystem
  • File/directory listing: CIM_DataFile
  • Examples of disk volumes are Win32_Volume
  • Registry operation: StdRegProv
  • Run process: Win32_Process
  • Examples of services: Win32_Service
  • Event log: Win32_NtLogEvent
  • Login account: Win32_LoggedOnUser
  • Sharing: Win32_Share
  • The patch Win32_QuickFixEngineering has been installed

Antivirus/VM detection

Antivirus engine detection

Installed AV products usually register themselves in the root\SecurityCenter or root\SecurityCenter2 namespace of the AntiVirusProductclass class in WMI. Which namespace depends on the version of the operating system.

A WMI client can obtain installed AV products by executing the following WQL query example:

SELECT * FROM AntiVirusProduct

As shown below:

Universal virtual machine/sandbox detection

Malware can use WMI to detect common virtual machine and sandbox environments. For example, if you have less than 2 GB of physical memory or a single-core CPU, it is likely that the operating system is running in a virtual machine.

The following is an example of WQL query:

SELECT * FROM Win32_ComputerSystem WHERE TotalPhysicalMemory < 2147483648

SELECT * FROM Win32_ComputerSystem WHERE NumberOfLogicalProcessors < 2

Figure 6 shows checking a generic virtual machine using WMI and PowerShell:

Figure 6: Checking the generic virtual machine PowerShell code

Check VMware VMS

The following query example tries to find if VMware strings appear in some WMI objects and checks if VMware Tools daemons are running:

SELECT * FROM Win32_NetworkAdapter WHERE Manufacturer LIKE "%VMware%"

SELECT * FROM Win32_BIOS WHERE SerialNumber LIKE "%VMware%"

SELECT * FROM Win32_Process WHERE Name="vmtoolsd.exe"

SELECT * FROM Win32_NetworkAdapter WHERE Name LIKE "VMware%"

Figure 7 illustrates the VMware virtual machine detection using WMI and PowerShell:

Figure 7: Checking the PowerShell code for the VMware virtual machine

Code execution and lateral movement

There are two common ways to implement remote code execution of WMI: the Create method of Win32_Process and the event consumer.

Win32_Process Create method

The Win32_Process class contains a static method called Create that can Create processes locally or remotely. In this case, WMI is just like running psexec.exe, but without unnecessary forensics operations such as creating a service. The following example demonstrates executing a process on a remote machine:

A more practical malicious use case is to call the Create method and use powershell.exe to call a malicious script that contains embedded scripts.

Event consumer

Another way to implement code execution is to create a WMI permanent event subscription. Typically, WMI permanent event subscriptions are designed to continuously respond to certain events. However, if an attacker wanted to implement a payload, they might simply configure the event consumer to remove its corresponding event filter, consumer, and filter bound to the consumer. The advantage of this technique is that payload runs as a system process and avoids displaying payload in plaintext in command line audits. For example, if using a VBScript ActiveScriptEventConsumer content, so the only creation process is the following WMI scripting host process:

%SystemRoot%\system32\wbem\scrcons.exe -Embedding

As an attacker, the challenge is to select an intelligent event filter in order to use this class as an attack vector. If they just want to trigger payload to run a few seconds later, they can use the __IntervalTimerInstruction class. An attacker may choose to execute the payload after the user’s screen is locked, in which case an external Win32_ProcessStartTrace event can be used as the trigger to create logonui.exe. Attackers can get creative in an appropriate event filter of their choice.

Covert storage data

Attackers cleverly exploit the WMI repository itself as a means of storing data. One way to do this is by creating a WMI class on the fly and storing arbitrary data as the value of a static property of the class. Figure 8 illustrates storing a string as the value of a static WMI class attribute:

Figure 8: Example PowerShell code for creating a WMI class

The previous example demonstrates creating a native WMI class. However, it is also possible to create remote WMI classes, which will be explained in the next section. The ability to create and modify classes remotely will enable an attacker to store and retrieve arbitrary data and turn WMI into an effective channel for C2.

It is up to the attacker to decide what they want to do with the data stored in the WMI repository. The following examples illustrate several practical examples of how an attacker can exploit this mechanism.

Use WMI as C2 channel

Using WMI as a mechanism for storing and retrieving data also enables WMI to function as a pure C2 channel. This clever idea of using WMI was first exposed by Andrei Dumitrescu in his WMI Shell tool — using the namespace that creates and modifies-wMI as a channel for C2.

There are actually many C2 staging mechanisms available, such as the WMI class creation discussed earlier. It is also possible to use the registry for data dumps as channels for WMI C2. The following example demonstrates some POC code that leverages WMI as a C2 channel.

A “Push” attack

Figure 9 illustrates how to create a WMI class remotely to store file data. This file data can then be written remotely to a remote file system using Powershell.exe.

Figure 9: PowerShell code that creates the WMI class remotely and writes to the remote file system

“Pull” attack

Figure 10 illustrates how to use the registry to receive the results of a PowerShell command. In addition, many malicious tools try to capture the output of PowerShell commands that simply convert the output to text. This example utilizes PowerShell object serialization and deserialization methods to preserve the rich type information currently present in PowerShell objects.

Figure 10: PowerShell code pulling back command data from WMI class attributes

0x09 WMI Provider

Providers are the backbone of WMI. Almost all WMI classes and their respective methods are implemented in the provider. The provider is either a user-mode COM DLL or a kernel driver. Each provider has its own CLSID to distinguish the associated COM in the registry. This CLSID is used to find the real DLL that implements the provider. In addition, all registered providers have their own instances of the __Win32Provider WMI class. For example, consider the following REGISTERED WMI provider to handle registry operations:

Locate the DLL corresponding to the RegistryEventProvider provider by referencing the following registry values:

HKEY_CLASSES_ROOT\CLSID\{fa77a74e-e109-11d0-ad6e-00c04fd8fdff}\InprocServer32 : (Default)

Malicious WMI provider

WMI providers are only used to provide legitimate WMI functionality to users, so malicious WMI providers can be used by attackers to extend THE functionality of WMI.

Casey Smith and Jared Atkinson published poCS for malicious WMI providers that remotely execute Shellcode and PowerShell scripts. Malicious WMI providers serve as an effective persistence mechanism that allows an attacker to execute code remotely as long as the attacker has valid user credentials.