Her0in · 2015/11/09 joyfully

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 second one in the section, and the titles of the other two translations are as follows:

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

0 x00 WMI defense

For each WMI attack, there are an equal number of potential defenses.

Existing detection tools

The following tools can be used to detect and remove persistent WMI malware:

  • Sysinternals Autoruns
  • Kansa – a PowerShell module for event response

The disadvantage of these tools is that they can only detect WMI persistence code in a snapshot at a specific time. Once the attackers have done their work, they clean up the persistence code. However, WMI permanent subscriptions can be used to capture an attacker’s WMI persistence operations in real time.

Detection of WMI persistence through EventConsumers is minimal. The PowerShell code in Figure 11 queries all WMI persistence projects on the remote system.

Figure 11: PowerShell code that detects WMI persistence on a remote system

Use WMI to detect WMI attacks

There is an extremely powerful event handling subsystem in WMI right now, so WMI can be thought of as Microsoft’s free hosting IDS that you never knew existed. Considering that almost all system operations can trigger WMI events, WMI can capture many attacks in real time. Consider the following attacks and their respective impact in WMI:

1. Attackers use WMI as a persistence mechanism

  • Impact:__EventFilter 、__EventConsumer 和 __FilterToConsumerBindingIs created.__InstanceCreationEventThe event is triggered. Procedure

2. The WMI Shell toolset is used for C2 channels

  • Impact:__NamespaceThe instance of the object is created and modified. As a result,__NamespaceCreationEvent 和 __NamespaceModificationEventThe event was triggered.

3. Create a WMI class to store attacker data

  • Impact:__ClassCreationEventThe event is triggered. Procedure

4. The attacker installs a malicious WMI provider

  • Impact:__ProviderClass instance is created,__InstanceCreationEventThe event is triggered. Procedure

5. The attacker continues the attack through the Start menu and Registry

  • Impact:Win32_StartupCommandClass instance is created,__InstanceCreationEventThe event is triggered. Procedure

6. The attacker continues the attack with additional registry values

  • Impact:RegistryKeyChangeEvent 和 RegistryValueChangeEventThe event is triggered. Procedure

7. The attacker installs services

  • Impact:Win32_ServiceClass instance is created,__InstanceCreationEventThe event is triggered. Procedure

All attacks and the effects described above can be represented by WMI event queries. When used in conjunction with event consumers, defenders can be extremely creative in choosing how to detect and respond to an attacker’s actions. For example, the defender could choose to receive an E-mail message after creating any instance of Win32_StartupCommand.

When WMI events are created to alert attackers to their behavior, it is important to recognize that attackers may also be familiar with WMI, and that existing WMI defense event subscriptions can be checked and deleted. So a game of cat and mouse began. As a final defense mechanism adopted to prevent an attacker from deleting your defense event subscription, you can register an event subscription to detect __EventFilter for __InstanceDeletionEvent events, __EventConsumer and __FilterToConsumerBinding objects. Then, if the attacker successfully deletes the WMI permanent defense event subscription, the defender will have one last chance to get an attack alert at the time of deletion.

Mitigation measures

In addition to deploying a WMI permanent defense event subscription, there are several mitigation measures that might prevent some or all of the ongoing WMI attacks.

  1. The system administrator can disable the WMI service. This is very important for an organization to consider its needs for WMI. Be sure to consider any contingencies that may arise from discontinuing the WMI service. Windows has become increasingly dependent on WMI and WinRM for administrative tasks.
  2. Consider blocking WMI protocol ports. If there is no valid reason to use WMI remotely, consider configuring DCOM to use a single port and then block that port. This is a sensible mitigation measure because it blocks remote WMI but allows the service to run locally.
  3. WMI, DCOM, and WinRM events are recorded in the following event logs: a. Microsoft-windowswinrm /Operational I. Display failed WinRM connection attempts with source IP address b.microsoft-windows-wmi-activity /Operational I. C. microsoft-Windows distributedcom I. method calls that contain failed WMI queries and may contain evidence of attacker activity Displays failed DCOM connection attempts with source IP addresses

0x01 Common Information Model (CIM)

“The Common Information Model (CIM) is an open standard that defines how managed elements are represented in an IT environment as a common set of objects and their relationships. The distributed management task force maintains the CIM, allowing consistent management of these managed elements independent of their manufacturer or supplier. WMI uses the CIM standard to represent the objects it manages. For example, systems queried by a system administrator through WMI must obtain an instance of a processing object through the standardized CIM namespace.

WMI maintains a register of all manageable objects in the CIM repository. The CIM repository is a persistent database stored on the local machine running the WMI service. When CIM is used, it maintains definitions of all manageable objects, including their relationships and who provides instances of them. For example, when software developers expose performance statistics for custom applications through WMI, they must first register descriptions of performance metrics. This allows WMI to interpret queries correctly and respond with well-formatted data.

CIM is object-oriented and supports features such as (single) inheritance, abstract and static properties, default values, and the ability to attach any key-value pairs to items called “qualifiers”.

Related classes are grouped under a hierarchical namespace. The properties and methods declared by a class are exposed through a managed object. A property is a name field for a particular type of data contained in a class instance. Class definitions describe metadata about attributes, and instances of classes contain concrete values populated by WMI providers. A method is a named routine that executes in an instance of a class and is implemented by the WMI provider. The class definition describes its prototype (return value type, name, parameter type), but does not implement it. A qualifier is a key-value pair of metadata that can be attached to namespaces, classes, properties, and methods. Common qualifiers provide the value of a string-type hint to indicate how the client interprets enumeration items and language code pages.

For example, Figure 12 lists some of the namespaces installed on the clean version of Windows 10. Note that they can easily be represented as trees. When the client does not declare its own namespace, WMI selects the ROOT\CIMV2 namespace as the default.

Figure 12. Example namespace

On this installation of Windows, the ROOT\CIMV2 namespace contains 1,151 class definitions. Figure 13 lists some of the classes found in this namespace. Note that each class has a name and a path that uniquely identifies the class. By convention, some classes have a qualifier called Description, which contains a human-readable string describing how the class should be hosted. The WMI Explorer tool provides a user-friendly interface to get the Description qualifier and display its value in a grid view.

Figure 13 example class

Figure 14 lists some exposed properties in instances of the Win32_LogicalDisk class. This definition declares 40 attributes, and the Win32_LogicalDisk class instance contains the specific value for each attribute. For example, the DeviceID attribute is A string used to uniquely identify disks, so A WMI client can enumerate class instances and expect values like A:, C:, D:.

Figure 14 Example properties

Figure 15 lists exposed methods in an instance of the Win32_LogicalDisk class. This definition declares five methods and the associated WMI provider allows clients to call these methods on Win32_LogicalDisk instances. The two Windows at the bottom of the panel describe the parameters and data that the calling method must provide. In this example, the Chkdsk method takes five Boolean arguments and returns a 32-bit integer describing the status of the operation. Note that the parameters of the Description qualifier attached to these methods will serve as API documentation for the WMI client developer.

Figure 15 method example

On this installation of Windows, there are three instances of the Win32_LogicalDisk class. Figure 16 lists class instances that use their unique instance paths. This path is formed by combining the names and values of special attributes that have qualifiers in the class name. In this case, there is one property: DeviceID. Each class instance is populated with concrete data from the same logical project.

Figure 16 Example of a class instance

Figure 17 lists the specific values for C: disk volumes in an instance of the Win32_LogicalDisk class. Note that not all 40 attributes are listed here; Properties that have no explicit value in a class definition also have no default value.

Figure 17 C: disk volume property values in an instance of the Win32_LogicalDisk class

0x02 Managed Object Format (MOF)

WMI uses the managed Object Format (MOF) to describe the language of the CIM classes. An MOF file is a text file that contains statements for specific things that can be queried, such as the name of the thing, the field type of the complex class, and permissions related to object groups. The structure of the language is java-like, equivalent to a restricted Java interface declaration. System administrators can extend CIM support with MOF files through WMI and the mofcomp.exe tool can insert formatted data into MOF files from the CIM database. A WMI provider is typically defined by a supplied MOF file, which defines the data and event classes and the COM DLL file that provides the data.

MOF is an object-oriented language that consists of the following parts:

  • The namespace
  • class
  • attribute
  • methods
  • qualifiers
  • The instance
  • reference
  • annotation

All entities described in the “Common Information Model (CIM)” section can be described using the MOF language. The following sections describe how to use the MOF language to describe CIM entities.

Namespaces in MOF

To declare a CIM namespace in the MOF, use the #pragma namespace (\\ computerName \path) directive. Typically, this statement is found at the very beginning of the file and applies to the rest of the statements in the same file.

The MOF language allows new namespaces to be created by declaring a parent namespace and defining a new instance of __namespaceclass. For example, we could create the \\.\ROOT\default\NewNS namespace using the MOF file listed in Figure 18.

Figure 18 creating a namespace in MOF

Class definition in MOF

To declare a class in an MOF, you first need to define the current namespace and then use the class keyword. Provides the new class name and the inherited class. Most classes have a parent class, and developers of new WMI classes should find the appropriate class to inherit from. Next, describe the properties and methods supported by the new class. When qualifiers are attached to classes, properties, and methods, there is additional metadata associated with an entity, such as an explanation using purposes or enumerations. Use dynamic modifiers to instruct providers to dynamically create instances of classes. The abstract class qualifier is used to indicate that no instances of the class can be created. The read property qualifier is used to indicate that the value is read-only.

MOF supports common data types used by programmers, including strings, numeric types (Uint8, Sint8, Uint16, sint16, etc.), dates (datetime), and arrays of other data types.

Figure 19 shows the structure of the statement that defines a class in MOF, while Figure 20 shows a sample MOF file that defines two new classes: ExistingClass and NewClass. Both classes can be found in the \\.\ROOT\default namespace. The ExistingClass class has two attributes: Name and Description. The Key qualifier of the Name attribute indicates that it is used to uniquely identify an instance of this class. The NewClass class has four explicit attributes: Name, Buffer, Modified, and NewRef. NewClass also inherits the Description attribute of its base class ExistingClass. NewClass is marked with dynamic qualifiers, which means that the associated WMI provider will dynamically create instances of this class as needed. NewClass has a method called FirstMethod that takes an argument of a 32-bit unsigned integer and returns an 8-bit unsigned integer value.

Figure 19. MOF class definition structure

Figure 20 creating a class definition in MOF

Instances in MOF

To define an instance of a class in an MOF, use the instance keyword after the class name. The name-value key-value pair list is used to populate the specific attribute value. Figure 21 lists an MOF file that creates an instance of the \\.\ROOT\ Default \ExistingClass class with specific values SomeName and SomeDescription for the Name and Description attributes, respectively. The rest of the fields will be filled in nil by default.

Figure 21 creates an instance of a class in MOF

References in MOF

CIM class attributes can reference existing instances of other classes through the instance object path. This is called a reference. To define a reference to a class instance in an MOF, you need to use the REF keyword as part of the attribute’s data type. For example, the MOF statement listed in Figure 22 declares a class reference named NewRef that points to an instance of the ExistingClass class.

Figure 22 defines an instance reference of a class in MOF

To set the value of a reference property, set the value of the property to the instance object path used to identify an existing class instance. For example, the MOF statement listed in Figure 23 can set the property of NewRef to an instance of the ExistingClass class with the Name attribute, which is equivalent to assigning the Name attribute of an ExistingClass instance directly using SomeName.

Figure 23 sets a reference to a class instance in MOF

Comments in MOF

The MOF format supports single – and multi-line C-style comments. Figure 24 lists annotations for the various styles of MOF statement definitions.

Annotations in Figure 24 MOF

MOF automatically recovers

WMI’s CIM repository implements transactional cache insertion of MOF files to ensure that the database is not corrupted. If the system crashes or stops during insertion, the MOF file can be registered for subsequent automatic recovery. To enable this feature, use the #pragma AutoRecover statement at the top of the MOF file. At this point, the WMI service will add the full path to the MOF file to the MOF File Automatic recovery list, which is stored in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Autorecover MOFs