WMI 101 for Pentesters

PowerShell has gained popularity with SysAdmins and for good reason. It’s on every Windows machine (and now some Linux machines as well), has capabilities to interact with almost every service on every machine on the network, and it’s a command-line utility. For the same exact reasons, PowerShell has also become a favourite method of attackers interacting with a victim machine. Because of this, organizations have gotten wise to this attack vector and have put measures in place to mitigate its use. But there’s another way! Many don’t know of another built-in Windows utility that actually pre-dates PowerShell and can also help them in their hacking pentesting engagements. That tool is Windows Management Instrumentation (WMI). This tutorial will be a small introduction to not only understand the usage of WMI to enumerate information from local and remote machines, but we’ll also show you how to start and kill processes! So let’s jump into WMI 101 for pentesters.

Background on WMI

I will keep this article at an introductory level to understand how to enumerate information at a high level. But as with most tutorials, let’s define some terms and provide some historical background. This may get dry but stick with me.

Windows Management Instrumentation (WMI) is Microsoft’s implementation of Web-based Business Management Standards (WBEM), the common information model (CIM) and the Distributed Management Task Force (DMTF). Microsoft has officially stated:

“Windows Management Instrumentation (WMI) is the infrastructure for management data and operations on Windows-based operating systems.”

So what does that mean? Simply, WMI stores a bunch of information about the local machine and allows you to access that data as well as manage Windows computers locally and remotely.

WMI came pre-installed in Windows 2000. It was made available as a download for Windows NT and Windows 95/98. For historical purposes, Monad, was born in 2002 with its first public appearance in 2003. In the spring of 2006, Monad was renamed Windows PowerShell and didn’t make a final release until November of 2006.

By default, WMI can be accessed by the Windows Script Host (WSH) languages such as VBScript and JScript. From Windows 7 PowerShell can be also used to access WMI. Furthermore, the IWbem COM API can be used with C/C++ and the ‘System.Management’ namespace with .Net languages such as C#, VB.Net and F#. Almost every popular programming languages such as Python, Ruby, PHP, Delphi, et al have third-party libraries or built-in libraries which support WMI.

The command-line interface to access WMI is called the Windows Management Instrumentation Command-line (WMIC). However, WMI can also be accessed directly with PowerShell. From PowerShell v3 onwards, CIM (Common Information Model) cmdlets can be found. The CIM cmdlets can be used to interact with WMI over WS-MAN (WinRM). These CIM cmdlets will aid us when WMI is blocked but WinRM is allowed on the target machine.

Exploring Namespaces

WMI namespaces can be explored in several different ways from using WMIC directly or by using PowerShell.

Using WMIC

Using PowerShell

Another method is by using WQL, the WMI Query Language. Microsoft’s documentation defines WQL as, “a subset of standard American National Standards Institute Structured Query Language (ANSI SQL) with minor semantic changes to support WMI.” So, we can use commonly understood SQL statement in quotes such as:

Exploring Classes

To get a list of WMI classes of a specific Namespace using PowerShell, we can use the ‘List’ parameter. In this example we are listing the classes of default namespace, ‘root\cimv2’.

Another method is by using “Get-CimClass” cmdlet:

If we want only the classes that start with “win32” inside the “root\cimv2” namespace, we can use a wildcard like this:

Furthermore, the tool WMI Explorer can be used to have a better view of the namespaces, classes and methods with descriptions and examples.

In summary, each Namespace contains Classes. Classes contain:

• Properties – Information that can be retrieved.
• Methods – Functions that be performed.
• Instances – Instances of the class objects. Each instance with Methods and Properties.
• Events – Produces notifications about changes in WMI data and services.

WMI Query Language – WQL

We briefly mentioned WQL in an example above, but let’s dive a little deeper. WQL queries can be directly accessed by the ‘wbemtest.exe’ binary and using PowerShell. WQL is used in scripting languages and programming languages when accessing WMI. For this article I will not go in depth regarding each type, however WQL Queries can be categorized as follows:

• Instance Queries
• Event Queries
• Meta Queries

Once you open the wbemtest binary, click on Connect and create a new connection to the required namespaces as shown above. If you are creating a connection to a remote machine, you can provide the credentials in this dialog box. In this example, I will connect to the default namespace ‘root\cimv2’.

After creating the connection, click on ‘Query’ to test a WQL query. In this example I will use the following query to enumerate files on the disk from the path “C:\temp”

It will enumerate the files on the ‘temp´ folder and display the file name.

This is the PowerShell syntax for the same request:

WMI Verbs

The following is for usage with WMIC:

• List – List Information
• Get – Retrieve values
• Call – Execute a method
• Set – Set value of a property
• Create – Creates a new instance
• Delete – Deletes an instance
• Assoc – Displays the Associators

Putting WMI All Together

Using WMIC

The following command can be used to list the aliases used in WMIC for the corresponding WQL Query.

The list is much longer than what you see in the screenshot above. I highly recommend you try this on your own machine to see what I mean. Much lower in the list, you will find the ‘process’ alias, and it uses the “Select * from Win32_Process” WQL query. By using the alias, we can shorten the command in the following way:

In this next example, I am using the ‘get’ verb to retrieve specific properties from the class.

This is an example of using the method ‘GetOwner’ to retrieve the owner of the target process.

To create a process we can use the ‘Create’ method. This is widely used by pentesters and in malware to create a remote process.

To kill a process the ‘Terminate’ method can be used.

Using PowerShell

Now let’s try some similar activities using PowerShell. This time, let’s look for Word.

Next, we’ll filter our data even more to get the information we want.

Using WQL

And how would this look using PowerShell and some WQL? Here, I am selecting the Caption, Process ID and the Executable Path properties from the ‘winword.exe’ process.

Using the CIM cmdlets you can retrieve all information or retrieve a specific property like this:

Listing all the methods of the ‘Win32_Process’ Class can be done like this:

For executing a method, the ‘Invoke-WmiMethod’ is used:

Using CIM we can call a method like this:

Remote WMIC

We also mentioned above that the same tools can be used over the network. This is the syntax you can use to accomplish the above example in remote computers:

WMIC

Powershell

And, as we did before, here’s how it can be done using PowerShell:

Furthermore, in Linux the tool ‘pth-wmic’ can be used to pass-the-hash instead of the password:

Conclusion

As you can see, WMI has loads of functionality, most of which have yet to be explored in this article. But even in the little we explored, you can clearly see that WMI can be used as an alternative when PowerShell is monitored or blocking certain scenarios. In a future article, we can play with WMI’s power in other ways good for pentesters such as using it as a C2C in engagements.

I hope this article covered the fundamentals of WMI usage and encouraged you to continue researching on your own. With that in mind, here’s a little homework. As with all useful technologies, there will eventually be a new version to expand on the capabilities proven by the previous version. Windows Management Instrumentation (WMI) is no different as it also has been updated to the Windows Management Infrastructure (MI). Microsoft says that MI is fully backwards compatible while reducing dev time and has tighter integration with Powershell. Go check it out and share what you discover.