Introduction

Let's say an 'Administrator' lands on a target network host and wants to look around and 'administer' the system without uploading any new tools… How can I do that without burning any of my Script Kiddie tools?

WMI or Windows Management Instrumentation or Windows Managed Infrastructure is an interface for managed components that provides data and operations to consumers or users. In particular, WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards. This jargon basically means that there is a way for you to manipulate and observe system data. This could be data about the system itself, applications, networks, devices, processes, etc., all of which could be extremely useful to the average Script Kiddie trying to gain information about a target. Thankfully, WMI has been a part of the operating system since Windows 2000 (although it has gone through some upgrades since then).

WMI can be a powerful tool for administrators (and Script Kiddies) because it has the added benefit of being able to gather and/or manipulate information on a remote computer. That's right, you can use WMI to perform advanced reconnaissance or even manipulate those systems using remote WMI connections. These connections are made through DCOM or Windows Remote Management (WinRM), which uses the WS-Management SOAP-based protocol. It's unlikely you'll be able to do this from outside a network, but once inside, you may be able to collect all kinds of information or even facilitate lateral movement.

But wait, there's more! WMI can be used programmatically through scripts or applications. These programs can be used to automate administrative tasks (or nefarious Script Kiddie operations) on the local or remote systems. And Microsoft was extremely helpful by making WMI available to programmers of all backgrounds, including C/C++, Visual Basic, .NET languages, and various Windows Script Host (WSH) languages like VBScript and JScript. In fact, almost all of the common programming languages, including Python, have libraries that support COM. Finally, Microsoft also made a fairly easy-to-use command-line interface for WMI called the WMI Command-Line Utility (Wmic.exe). Even better, WMI has been easily accessible via PowerShell since Windows 7.

WMI Architecture

Wow. WMI sounds like the perfect 'administrator' tool. How does it work? Where is it getting all that data?

As mentioned, WMI is Microsoft’s implementation of WBEM, and it uses the CIM standards published by the DMTF. WMI uses a uniform model and interface which means that client programs and system administrators don't have to learn different operating system APIs or numerous data formats. This design has the added benefit of making the functionality of some of these underlying operating system APIs available to scripting languages or remote operators that would not otherwise have the ability to call these APIs.

The WMI architecture is designed using a consumer-provider pattern. In this pattern, the consumer is the client script or administrator that wants the data, and the provider is a server or managed object providing the data about the system or resource. WMI is the infrastructure that connects the two, and the diagram below shows how everything works together. Developers can use WMI to view and make changes to CIM objects and in-turn the provider will retrieve or modify data on the underlying resource.

In this diagram, the lowest level represents the WMI providers. A provider is a COM object that manages a system resource for WMI. These managed objects can be a physical or logical component like a processor or a process. These providers are like device drivers in that they act as an interface between the user and underlying objects. The providers typically consist of a DLL file loaded by the WMI service (WMIPSrv.exe), but they can also be contained within stand-alone service executables. A provider represents an underlying component using a class which is defined in a Managed Object Format (MOF) file. The operating system comes with numerous built-in providers including a Registry provider that is used to access the Windows Registry via the StdRegProv class. In addition to providing access to some of an underlying component's properties, a provider may also provide methods for manipulating the system components, such as StdRegProv.CreateKey().

The middle layer of the diagram is the WMI infrastructure itself. This infrastructure is the operating system component and is implemented as the WMI service (WinMgmt). The infrastructure is comprised of two parts: the core and the repository. The repository is organized into namespaces and contains definitions of all the WMI providers' classes. The WMI service acts as an intermediary between the providers and the consumers. When a consumer requests data from a provider, the service loads the provider (if not already loaded) and retrieves data about the component dynamically. The consumer can also receive notifications from a provider by subscribing to certain events.

Lastly, the top layer of the WMI architecture is the consumer level. This is the application or script that a user utilizes to interact with the WMI infrastructure. A consumer can enumerate data, query, run methods, or subscribe to events. Consumers typically use the COM API or Scripting API for WMI. This is the space where most users and developers play. All of the computer's information is available if you just know how to access it!

Using WMI

OK. I see the value in WMI. It offers a treasure trove of data to 'administrators'. How do I actually use it? I think you mentioned something about scripting.

As mentioned, WMI is really a way of viewing and/or modifying system data, and it can be accessed programmatically using COM or via a scripting API. This means that you can use WMI from a compiled client application or a simple script. WMI is just the infrastructure that makes interacting with the underlying providers of data easy to do. In this way, the user is acting as the consumer of data, and system services are acting as the provider. Most users will operate at this level; however, it is possible to implement your own provider of data, but that is outside the scope of this introduction to WMI for Script Kiddies, so stay tuned for a future blog on this next level usage.

Because WMI is just a set of APIs, it's easy to integrate into your compiled C/C++ programs using the IWbem COM objects or in your .NET assemblies using System. Management classes. WMI can be automated through WSH languages scripts such as VBScript and JScript. In addition, there are numerous pre-built applications available for system administration via WMI, including Microsoft tools like the WMI command-line, WBEM tester tool, CIM Studio, WinRM tool, and PowerShell. Using these tools may take some getting used to and some time to understand the WMI Query Language (WQL).

WMI Command-Line

The WMI command-line (Wmic.exe) is provided by Microsoft and built into Windows. It provides a fairly simple and easy-to-use interface for WMI. It is compatible with existing shells and utility commands. It also has an interactive mode and a non-interactive mode, and it includes a large number of aliases, commands, and global switches. Although extremely simple and readily available, it does not allow you to call methods that accept WMI objects. However, it is powerful enough for most Administrators and Script Kiddies.

WBEM Tester Tool

The WBEM tester tool (wbemtest.exe) is included with WMI installations as a diagnostic tool, but it also allows administrators and developers to perform many queries and operations from a GUI. The GUI allows users to enumerate, open, create, and delete classes and instances. You can also perform data and event queries and execute methods. All of these operations can be done locally or remotely. The downsides are that the user-interface is complicated, and it is a GUI that may not be optimal for Script Kiddies.

CIM Studio

CIM Studio is part of the WMI Software Development Kit. It's a legacy tool, so it may not be available. If it is available, it can be used to explore the WMI classes including properties, methods, and associations. Again, it is not widely available, so probably not that useful for Script Kiddies, but another tool to be aware of.

WinRM Tool

WinRM is the Microsoft implementation of WS-Management Protocol, a SOAP-based protocol. It provides a common way for systems to access and exchange information and management data. This data is supplied by WMI. WinRM is available via scripting objects, the Windows Remote Shell (WinRS), or in the WinRM command-line tool. WinRM is part of Windows, but to obtain data from a remote computer, the WinRM service must be configured and enabled. By default, the WinRM services listens on TCP port 5985 but can be configured to use SSL over TCP port 5986. These ports must be allowed through the firewall, which is typically for internal network administration. The command-line tool is capable of performing most tasks but may be more unfamiliar than PowerShell, which can also access WMI remotely using WinRM.

PowerShell

PowerShell is a cross-platform command line with its own scripting language. It's a more modern and feature-rich shell compared to Windows's default command prompt. The shell and scripting language supports objects that facilitate WMI enumeration, queries, and method calls. The scripting language is commonly used for automated system administration because it can easily use the .NET Common Language Runtime (CLR) and objects. It is easily extensible through modules, classes, and cmdlets. In fact, Windows comes with many cmdlets specifically for interacting with WMI, including those in the screenshot below:

Windows PowerShell is probably the easiest method to connect to WMI on a remote computer and the local system. The remote WMI connections are affected by the firewall, but as mentioned, remote administration is typically allowed internally. PowerShell can work over DCOM using WinRM (which supersedes DCOM and is the recommended remote management protocol). When connecting to a remote computer using PowerShell, a user specifies the remote computer, credentials to access the remote computer, and the authentication/impersonation level for the connection. This can facilitate remote 'administration', aka network enumeration and lateral movement in Script Kiddie speak.

WQL

Now that you know some of the tools available to utilize WMI, we need to discuss how to use WMI. Almost all of these tools rely on WQL to interact with WMI and the underlying classes and objects. WQL is a subset of the Structured Query Language (SQL) with some slight changes to support WMI. For an in-depth look at the language, refer to Microsoft's website (https://docs.microsoft.com/en-us/windows/win32/wmisdk/wql-sql-for-wmi), but to get started, we need to understand just a few things. As the language implies, WQL is all about queries that can be broken down into data queries, event queries, and schema queries. Data queries are used to retrieve information about classes and instances and are the most common type of queries. Event queries can be used to register to receive event notifications from specific providers, and schema queries are used to retrieve information about WMI class definitions themselves instead of actual instances.

As mentioned, most WMI queries pertain to classes and instances. When making a query, you use the SELECT verb. Queries can use the WHERE clause for extension and customization. WHERE clauses can make use of the common comparison operators including =, <, >, <=, >=, and !=. There are a few additional WQL-specific operators for use with instances of classes and strings including IS, IS NOT, ISA, and LIKE. WQL can also take advantage of Boolean operators and constants like AND, OR, NOT, TRUE, and FALSE.

While most tools allow you to make WMI queries using WQL, some tools have additional functionality or application specific commands. For instance, most tools offer ways to execute class functions including creating, listing, or destroying instances, as well as running methods on specific instances. These capabilities do not necessarily make use of WQL and may rely on other languages or verbs. For further details, refer to each tool's documentation. WMIC uses:

• List - list information
• Get - retrieve values
• Call - execute a method
• Set - set a value of a property
• Create - create a new instance
• Delete - delete an existing instance
• Assoc - display associations

Interesting WMI

So, WMI has a lot of data AND is easy to use thanks to an abundance of tools, including some that Microsoft was so generous to include with the operating system. But, what are some useful WMI queries or commands that your run-of-the-mill Script Kiddie Administrator might want to use?

As we've seen, WMI and corresponding tools provide an easy way to query, enumerate, and modify system resources and data. WMI gives us an API that is readily available through scripts and utilities. We even have a query language to help us. So, with all of this access and all of these tools, what can we really do? The options are endless. You can certainly find lists of commands for system administrators and penetration testers alike available online. Here are a few interesting WMI commands and uses to keep in mind as an enterprising Script Kiddie just trying to explore and control your new world. In the following examples, we will switch between WMIC and PowerShell commands. They each have their own program specific syntax, but a similar command can be crafted for either tool.

List Logged-On Users

When operating on a target system, you may be interested in the other currently logged-on users. In the following PowerShell example, we use the 'Get-WmiObject' cmdlet to query for all instances of the Win32_LoggedOnUser and pipe the results out to a secondary evaluation that filters out any Service, Network, or System logons.

Get-WmiObject -Query "select * from Win32_LoggedOnUser" |  ?{$_.LogonType -notmatch '(Service|Network|System)’}

List Domain Users

WMI can be used to query information about the domain, using LDAP. In the following WMIC example, the command uses the LDAP namespace to query for domain users and gets the SAM account name.

wmic /NAMESPACE:\\root\directory\ldap PATH ds_user GET ds_samaccountname

In this PowerShell example, the command gets all Win32_UserAccount objects but filters on the DOMAIN being equal to the domain name that you are interested in. Notice how the PowerShell command performs a query for all instances of a class in a slightly different method than before without including a specific WQL query statement.

Get-WMIObject –Class Win32_UserAccount -Filter "DOMAIN = '<DOMAIN>'"

Listing Domain Administrators

Besides simply listing all users, you may be interested in just the users that are part of a specific group. In the following WMIC example, the command returns any instance of win32_groupuser where the group name is 'domain admins' and the domain matches the domain you are interested in. Notice the use of the WHERE clause.

wmic path win32_groupuser where (groupcomponent="win32_group.name='domain admins',domain='DOMAIN'")

List Running Processes

When on a target system, one of the top pieces of information for situational awareness is a list of running processes, or you could be interested in one process in particular. In the following WMIC example, the command returns a brief listing of any instance of process where the name is svchost.exe. Notice the listing specifier brief which only returns a subset of data for each instance.

wmic process where name='svchost.exe' list brief

The following PowerShell example also lists all instances of svchost.exe.

Get-WmiObject -Class Win32_Process -Filter 'name="svchost.exe"'

And here is the PowerShell equivalent for listing all instances of svchost.exe using a WQL query:

Get-WmiObject -Query "Select ProcessID,ExecutablePath from Win32_Process where name='svchost.exe'" -Namespace root\cimv2

Create a Process

In addition to just listing processes or other WMI instances, you can also call methods of WMI classes. The following is a WMIC command for creating a new process using the 'Create' method:

wmic process call create 'calc.exe'

And now we have the PowerShell equivalent for creating a new process using the Invoke-WmiMethod cmdlet to call the 'Create' method of Win32_Process.

Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList @(calc.exe)

Remote Operations

Previously, we mentioned that in addition to running these WMI queries and methods against the local system, we can also connect to remote systems and access their WMI providers. The following WMIC example demonstrates connecting to 'servername' using the specified username and password then using the process WMI provider on the remote system to create a new process.

wmic /NODE:"servername" /USER:"yourdomain\administrator" /PASSWORD:password process call create 'calc.exe'

The 'Invoke-WmiMethod' cmdlet in PowerShell can also run against a remote system by specifying the ComputerName and passing in an authorized credential. Credentials can also be passed into the command by first creating a credential object using the Get-Credential cmdlet in PowerShell.

Invoke-WmiMethod -Class Win32_Process -Name Create - ArgumentList 'calc.exe' 
-ComputerName 'servername'  -Credential 'targetdomain\targetuser'

List AV Products

Besides processes and users, you may also be interested in installed applications or maybe antivirus products in particular. Well, WMI conveniently has a provider for such information. In this WMIC example, the command queries for all instances of antivirusproducts and gets the displayName, productState, and pathToSignedProductExe properties from each instance. Notice that this provider is in the \\root\securitycenter2 namespace.

wmic /namespace:\\root\securitycenter2 path antivirusproduct GET displayName,  productState, pathToSignedProductExe

And here is the PowerShell equivalent for querying for these AntiVirusProduct instances:

Get-WmiObject -Namespace root\SecurityCenter2 -Class AntiVirusProduct

Detect Virtualization

In addition to detecting antivirus products, most Script Kiddies may be interested in whether or not they are operating in a virtualized environment. One way to detect this is by examining the BIOS serial number. In this PowerShell example, we query all Win32_BIOS instances to see if any contain the string 'VMware'. Notice the use of wildcard string matching in the filter.

Get-WmiObject Win32_BIOS -Filter 'SerialNumber LIKE "%VMware%"'

Find Interesting Files

Finally, let's try to find some interesting files using WMI. Perhaps you would be interested in any file containing 'password' in the filename. This WMIC example queries all data files on the 'C:' that have a name containing 'password' and gets the name, size, and whether or not it is readable. Again, notice the use of wildcard string matching in the Name filter.

wmic DATAFILE where "drive='C:' AND Name like '%password%'" GET Name,readable,size /VALUE

Conclusion

This is amazing. I will definitely use WMI the next time I need to 'administer' a new victim network host (that I totally own). Sometimes Microsoft is just so helpful in providing tools for us Script Kiddie Administrators.

WMI certainly makes the task of administrating workstations and the network easy. In addition to all the information and a simple interface, there are many tools available to take advantage of WMI, and several are provided by Microsoft and available by default on Windows systems. Script Kiddies and administrators can use these tools to query WMI classes and instances as well as call methods of these classes and instances. The amount of data available is immense, and the ability to access and manipulate this data is powerful; but, as we know, with great power comes great responsibility. So, make sure you know what you're doing, read the documentation, try out some of these helpful commands, and, as always, check your return values.

References

https://en.wikipedia.org/wiki/Windows_Management_Instrumentation

https://docs.microsoft.com/en-us/windows/win32/wmisdk/

https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf

https://www.ethicalhacker.net/features/root/wmi-101-for-pentesters/

https://kwcsec.gitbook.io/the-red-team-handbook/techniques/enumeration/recon-commands/wmic-commands