Introduction
Windows allows users on one system to access and manage other systems through a range of mechanisms. Many common tools and commands allow the user to specify the target as a remote system. Some of these commands run over Server Message Block (SMB), other commands use Remote Procedure Calls (RPC), while another option is Windows Remote Management (WinRM). These require different services running on the target and different firewall settings for proper communication.
Windows Management Instrumentation (WMI) provides an interface to many of the operating system’s core components. Although WMI has been included in Microsoft Windows for many years, only in the last few years have the security implications of WMI become commonly known. WMI can be used to query the state of the system or to start/stop processes or services. WMI has the concept of events, allowing an administrator to automatically run programs or scripts in response to activities that take place on the system.
Windows servers can be built and run without a graphical user interface (GUI) and managed remotely.
Managing Systems Remotely
Microsoft provides tools that can be used to manage Windows systems remotely; these tools are particularly useful in a domain. One set of tools uses Server Message Block (SMB) and provides access to the file system, including remote file access and manipulation, as well as control over local users and the registry. The second set of tools uses Remote Procedure Calls (RPC) to interact with the remote system. Administrators can use RPC to control services, logs, and scheduled tasks on the remote system; they can also be used to obtain a shell on the remote system. Windows Remote Management (WinRM) can also be used to obtain a shell on a remote system; WinRM also provides a direct interface to Windows Management Instrumentation (WMI).
Server Message Block (SMB)
Server Message Block (SMB) can be accessed across the network in more than one way. The simplest way is directly over TCP, in which case it uses TCP/445. SMB can also be accessed via NetBIOS over TCP/IP. In this latter case, name services are provided on TCP/137 and UDP/137, datagram services on UDP/138, and data on TCP/139.
SMB Firewall Rules
To use SMB, the host’s firewall must allow the connection. One approach is to allow access over TCP/445. This can be done one host at a time, but on a domain, it is better handled through group policy. To do so, create a new group policy object and edit it. Navigate Computer Configuration ➤ Policies ➤ Windows Settings ➤ Security Settings ➤ Windows Firewall with Advanced Security ➤ Windows Firewall with Advanced Security1 ➤ Inbound Rules. Right-click to create a new rule; this results in a dialog box like Figure 7-1. From the New Inbound Rule Wizard, choose the “Port” option, and specify TCP/445. For the action, select “Allow the Connection,” configure the profile, and provide a name for the Firewall rule. Apply the policy to one or more OUs containing computers in the domain. The resulting firewall rule will be visible on the firewall settings on the domain members.
The New Inbound Rule Wizard for Windows Firewall with Advanced Security, shown on Windows Server 2016
Remote File Access
These locations can be accessed with File Explorer through the address bar.
Drive Mapping
Managing Users and Groups
Using MMC as a domain administrator to manage services and the local users and groups on the remote domain member drake. Screenshot from Windows 10-1511.
Services
Provided SMB is accessible, a domain administrator can manage the services running on a remote system using MMC (Figure 7-2). For the snap-in, select Services, then provide the name of the remote system.
Services can also be managed remotely in both fashions if SMB is not accessible, provided RPC is accessible instead.
Registry
Using the registry editor to connect to the remote system Drake. Screenshot from Windows 10-1511.
Remote Procedure Calls (RPC)
Remote Procedure Calls (RPC) are a way a client can ask a remote target to execute a command. When a client makes a remote procedure call of a target, first the client contacts the target’s endpoint mapper; the target returns the services available and the ports that the services are using. On Windows systems, the default port for the endpoint mapper is TCP/135.
When the client is informed of the port on which the desired service is running, the client contacts that service on that port and makes the request. On older Windows systems like Windows 2000, Windows XP, and Windows Server 2003, the RPC services use ports between TCP/1025 and TCP/5000. On modern Windows systems, including all the ones described in this text, the RPC services use ports between TCP/49152 and TCP/65535. It is not the case that the same service always uses the same port.
RPC Firewall Rules
The use of a dynamic port range makes it more challenging to configure a traditional firewall to control access to RPC services. However, Windows Firewall with Advanced Security can be configured to control access to RPC services, and it can control the service(s) that may be contacted.
An administrator can create firewall rules that allow connections to any RPC service. To do so on a domain, create a new group policy and edit it; then navigate Computer Configuration ➤ Policies ➤ Windows Settings ➤ Security Settings ➤ Windows Firewall with Advanced Security ➤ Windows Firewall with Advanced Security2➤ Inbound Rules.
Two inbound rules need to be added. For the first, from the New Inbound Rule Wizard, select Custom, then select All Programs. On the Protocols and Ports step, for the Protocol Type choose TCP, but for the Local Port select RPC Endpoint Mapper. Adjust the scope as desired, allow the connection, and choose an appropriate domain. Give the rule a name, say “RPC Endpoint Mapper (Custom, via Group Policy).”
For the second rule, from the New Inbound Rule Wizard, select Custom, then select All Programs. On the Protocols and Ports step, for the Protocol Type choose TCP, but for the Local Port select RPC Dynamic Ports. Adjust the scope as desired, allow the connection, and choose an appropriate domain. Give the rule a name, say “RPC Dynamic Ports (Custom, via Group Policy).”
Scheduled Tasks
MMC with three remote connections to the system drake.pluto.test: one for local users and groups, one for Windows Event Viewer, and one for task scheduler. Shown on Windows 10-1607.
Event Logs
If a system allows RPC, it is possible to use MMC to view the Event Logs on a remote system. Launch MMC, and from the File menu select Add/Remove Snap-In. Choose Event Viewer and specify the remote computer (Figure 7-4).
Managing the Firewall Remotely
The Windows firewall itself can be managed remotely, provided the proper RPC rules are allowed. To do so on a domain, create or edit a group policy object and navigate Computer Configuration ➤ Policies ➤ Windows Settings ➤ Security Settings ➤ Windows Firewall with Advanced Security ➤ Windows Firewall with Advanced Security➤ Inbound Rules. Create a new rule and select the predefined option Windows Firewall Remote Management.
The firewall on the system can then be managed using MMC by selecting Add/Remove Snap-In and selecting Windows Firewall with Advanced Security.
Sysinternals Tools
Many of the SysInternals tools (cf. Chapter 3) can be run against remote systems. Some tools use SMB, others use RPC, and others can use either. Many require the remote registry service to be running on the target.
The corresponding program to kill a remote process is pskill.
General information about the remote system is available through psinfo.
Psexec
One of the most useful tools for a domain administrator is psexec. This tool allows the domain administrator to run arbitrary commands on remote hosts and return the results. To enable psexec, the remote system needs to allow access to SMB. If the system does not also allow access to RPC, the tool will run but with noticeable delays.
Here the error code 0 indicates that the command completed successfully.
Exit the remote shell with the command exit or by pressing CTRL+C.
Note that the Sysinternals suite does not need to be present on the remote system; it only needs to be present on the local system.
Windows Remote Management (WinRM)
Windows Remote Management (WinRM) is an implementation of the WS-Management protocol. It allows for the remote management of a system, including a tool that behaves similarly to psexec.
Enabling WinRM; Firewall Rules
Navigate Computer Configuration ➤ Policies ➤ Windows Settings ➤ Security Settings ➤ System Services. Select the Windows Remote Management Service (WS-Management) and configure it to start up automatically.
- Navigate Computer Configuration ➤ Preferences ➤ Control Panel Settings ➤ Services. Configure a new Service (Figure 7-5). Choose the WinRM service, set startup to Automatic, and the service action to Start Service. Under the recovery tab, configure the computer to restart the service if it fails.
Figure 7-5Configuring the WinRM service properties in the Group Policy Editor on Windows Server 2008 R2
Navigate Computer Configuration ➤ Policies ➤ Administrative Templates ➤ Windows Components ➤ Windows Remote Management ➤ WinRM Service. On Windows Server 2012 or later, select the option “Allow remote server management through WinRM.” On Windows Server 2008 R2, select the option “Allow automatic configuration of listeners.” Enable it and configure the IPv4 and IPv6 filters as appropriate. Note that if the filters are left blank, the service will not listen on any address.
Navigate Computer Configuration ➤ Policies ➤ Windows Settings ➤ Security Settings ➤ Windows Firewall with Advanced Security ➤ Windows Firewall with Advanced Security ➤ Inbound Rules. Create a new rule; from the list of predefined rules select Windows Remote Management. This allows traffic on TCP/5985.
Winrs
The remote shell is closed by the exit command.
PowerShell
Although WinRM uses HTTP as its transport protocol, the transferred data is encrypted. It is possible to configure WinRM to use HTTPS as its transport protocol; in this case, it runs by default over TCP/5986.
WinRM can do more than execute commands on a remote system. It has access to a great deal of information provided by WMI - Windows Management Instrumentation.
Windows Management Instrumentation (WMI)
Windows Management Instrumentation (WMI) is an implementation of Web-Based Enterprise Management (WBEM). The WMI service accesses data stored using the Common Information Model (CIM). Not only does this record data about the system’s hardware and software, it also tracks the current state of the system, including its running processes and services. Administrators can use WMI to query the state of the system and its processes. WMI can also be used to control the system; for example, it can be used to start and stop processes. WMI allows administrators to define events that are fired when a defined state occurs on the system; and consumers, which are programs or scripts that are run when an event is fired.
WMI Structure
Using MMC to view the available WMI namespaces. Shown on Windows 10-1607.
A much better tool to explore WMI is WMI Explorer. The current version (2.2.79) is available from SAPIEN Technologies at https://www.sapien.com/software/wmiexplorer and has a 45-day trial, while version 2.0.0, including its source code, is available from https://github.com/vinaypamnani/wmie2/releases .
The database for WMI is broken into namespaces. The most important namespace is \root\cimv2; however, the namespaces \root\SecurityCenter2 and \root\subscription are also significant. A namespace may possess sub-namespaces, like \root\cimv2\applications. Inside a namespace are classes; on a Windows 10-1511 system, for example, the namespace \root\cimv2 has 418 different classes. Inside a class are one or more instances. Instances can have properties, which store data about the instance; and methods, which allow actions to take place on that instance.
Running WMI Explorer 2.0 on Windows 10-1511, showing the class \root\cimv2\Win32_Account, and the instance corresponding to the domain user PLUTO\gmahler
The permanent objects in the WMI database are stored on the system by default in the file C:\Windows\System32\wbem\Repository\OBJECTS.DATA. Configuration information for WMI is stored in the registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM and in the WMI database itself at \root\Cimv2\Win32_WMISetting.
Using WinRM to Query WMI
There are several tools that can be used to query WMI; these include PowerShell and the program wmic. So long as the Windows Remote Management service is running on the target, another good choice is winrm.
Using WinRM to Enumerate WMI Data
The enumerate operation can be abbreviated simply to e, and the namespace wmi/root/cimv2 can be abbreviated to wmicimv2.
The result of this command are the accounts and groups on the system, including local and domain accounts.
WMI Explorer can also connect to a remote system by selecting the remote hostname in the computer box. Unlike WinRM, when WMI Explorer connects to a remote system, it uses RPC (TCP/135 and a higher numbered dynamic TCP port) instead of the fixed TCP/5985 used by WinRM.
Windows Query Language (WQL)
Careful examination of Figure 7-7 shows that the data shown seems to be from the SQL-like query SELECT * FROM Win32_UserAccount WHERE Domain="PLUTO" AND Name="gmahler". In fact, WMI uses WQL (WMI Query Language), which is a subset of ANSI SQL. There are three general types of queries in WQL: data queries, schema queries, and event queries. Data queries are the most common and are used to read or set data values. Schema queries provide information about the structure of WMI itself, while event queries are used to track activities that occur on the system.
The WQL query is passed as a filter to an enumerate query over all the namespaces in wmi/root/cimv2 rather than in a particular namespace.
Here the WQL operator LIKE is used to see if the string is present in the result. Wildcards in the name are denoted with ‘%’. Because the object of the LIKE operator is a string, it is enclosed in quotes, and because the WQL query is already in quotes, these inner quotes are escaped.
Using WinRM to Set WMI Values
To change the state of an instance, a set query is made for the class while the particular instance to be changed is determined by using the ? operator. The property that is to be changed is indicated with the @ symbol, and the braces enclose the name and new value of the property.
Using WinRM to Invoke WMI Methods
Another way to change the state of a WMI object is to use one of its available methods. Some, though not all, WMI instances have methods. The methods available to an instance of a WMI namespace can be found, for example, by examining the instance in WMI Explorer. Figure 7-7 shows that instances of the Win32_Account class have no associated methods.
To use the method, the administrator uses winrm with the invoke operation and the name of the method. As before, the particular instance of the class is specified using the ? operator.
The syntax here is like the syntax for the set operation. The invoke operation requires a command line; this is specified via the @ symbol and enclosed in braces.
Because the user jbach is on a remote system, there is no associated desktop for that user. Consequently, even though the program notepad++.exe starts and runs, it does not appear on the desktop for a user logged in locally on the remote system drake.
A list of interesting WMI classes is provided in the Notes and References.
Creating a WMI Namespace and Class
Example.mof
In Listing 7-1, the administrator is specifying the name of the remote host (drake) for the namespace, named ExampleNamespace.
The code continues with the definition of a class, named ExampleClass. This class has three variables; the first, named ID, is a 64-bit unsigned integer and is used as the key for the class. The class also contains the string named ExampleString and an array of strings, named ExampleArray.
Two instances of the class are generated; each provides the values for each of the class variables.
Because this information is stored using WMI, it does not appear directly in the file system on drake, save through its presence in the WMI database itself.
Delete.mof
WMI Events
An administrator can use WMI to define events and to define consumers, which are actions that take place when the event occurs.
WQL Schema Queries
This is a schema query because it is a query for the object Meta_Class. Schema queries can only be made for *, but they can be filtered with a WHERE clause. Here __CLASS is a system property that provides the name of the class.
System classes start with two underscores and are present in all namespaces. The events from system classes are called intrinsic events, while non-system ones are called extrinsic events.
WMI events fire when particular activities occur, for example the extrinsic event \root\cimv2\Win32_VolumeChangeEvent fires if a USB drive is added or removed from the system.
WMI Consumer Example: USB Connections
The script usb.mof that uses VBScript to record information in a file every time a USB device is inserted into the system.
The WQL query in the filter in Listing 7-3 is an example of an event query, which fires whenever a local device is added or removed from the system. The EventType is a characteristic of this event; its value is 1 for a configuration change, 2 for the arrival of a device, 3 for the removal of a device, and 4 for the docking of the system.3
The code in the ScriptText variable in Listing 7-3 is recognizable as VBScript; however, the script is enclosed in quotation marks with manually included newlines. Note the implied string concatenation and the need to escape quotes when used inside the script. The VBScript creates and opens a file in the file system (C:\LogUSB.txt), then it writes to that file. Because the script is called in response to an extrinsic event, it has access to the underlying event; this includes access to the DriveName variable, which can then be used in the script.
The script concludes with a __FilterToConsumer binding, which instructs the system to launch the consumer whenever the event occurs.
WMI Consumer Example: PowerShell Start or Stop
The script PSTrace.mof that tracks when PowerShell is started or stopped
Listing 7-4 is like Listing 7-3, but it contains two sets of filters, consumers, and bindings: one for when PowerShell starts, and one for when it stops. The event filter uses root\cimv2\Win32_ProcessStartTrace to detect when the process starts and root\cimv2\Win32_ProcessStopTrace to detect when it ends. Further, because PowerShell can be run as the stand-alone executable powershell.exe or through the integrated editor powershell_ise.exe, the event query looks only to see if the string “powershell” appears in the process name.
WMI Consumer Example: User Logon/Logoff
A script that records when users log on to a system
Like the previous scripts, this uses VBScript as the consumer; in this case, the script takes the data available in an instance of the class root\cimv2\LogonSession and writes it to the file C:\Logon.txt.
The major difference is in the event filter; it uses the system class __InstanceCreationEvent, which reports additions to the WMI database. Unlike the extrinsic events seen previously, this intrinsic event does not fire but instead is polled. The query in the script looks for changes in the WMI database every 15 seconds that are caused by changes in the Win32_LogonSession class. This change also results in a change to the consumer; instead of using TargetEvent, it must use TargetEvent.TargetInstance to access the data from the actual event. Finally, because this is polled, it is possible to miss an event because the change is made and then unmade within the polling time. If the polling time is shortened though, then the system consumes additional resources checking for these events.
It would be useful to correlate the LogonID with the details of the corresponding user. This can be done with an additional WQL query, using associators. The WQL statement ASSOCIATORS OF returns the instances associated with a source. In the case at hand, the administrator would like the instances of Win32_Account that are associated with the given LogonID.
Addition to Listing 7-5
This provides much more useful information.
Using wmic to Interact with WMI
A user can use winrm to interact with WMI, but only if the WinRM service is running. It is possible to interact with WMI without using WinRM. One option is to the command-line tool wmic. Help for wmic is provided by the command wmic /? or the command wmic /?:full.
Using wmic to Enumerate WMI Data
When wmic is used to connect to WMI on a remote system, it uses RPC, beginning with TCP/135 then a high numbered port. This is how tools like WMI Explorer and mofcomp.exe connect to a remote system, but this is different than WinRM, which uses TCP/5985.
Using wmic to Invoke WMI Methods
Using PowerShell to Interact with WMI
There are important differences between these two commands beyond the differences in the output format. The cmdlet Get-WmiObject is the older version and part of the original PowerShell 1.0. When run against a remote computer, Get-WmiObject uses RPC. This was superseded by Get-CimInstance in PowerShell 3.0. which was released with Windows 8 and Windows Server 2012. When run against a remote target, Get-CimInstance uses WinRM running on TCP/5985. The Get-CimInstance cmdlets also fail if the remote target is running PowerShell 2.0, like Windows 7.
Using Other Languages to Interact with WMI
WMIGen 10.0, seen on Windows 10-1607
Using Linux to Interact with WMI
The tool includes several scripts as examples. On recent systems like Ubuntu 16.04 and Kali, there are two particularly useful scripts located in the documentation directory, usually /usr/share/doc/python-impacket/examples.
The script wmiexec.py uses both SMB and RPC, while wmiquery.py uses RPC.
Windows Server Without a GUI
Windows Servers can be installed and run without a graphical user interface (GUI).
Installation Without a GUI
Installing Windows Server. On the left is Windows Server 2012, which includes the option for a Server Core Installation. On the right is Windows Server 2016, which includes the option for the Desktop Experience.
The administrator uses the up and down arrow buttons to move between the new password and the confirmed password.5
Adding or Removing the GUI
Windows Server 2012 introduced the ability to convert a server to/from a server core installation. This feature remains in Windows Server 2012 R2 but was removed in Windows Server 2016. Windows Server 2012 and 2012 R2 include a minimal graphical interface in the feature Graphical Management Tools and Infrastructure, and the full graphical interface in the feature Server Graphical Shell.
Windows Server 2012, before removing Graphical Management Tools and the Server Graphical Shell
Configuring a Server Without a GUI
Running sconfig on Windows Server 2012 without a GUI. Note the black background and the absence of features like the taskbar or start menu.
The sconfig tool varies slightly between versions of Windows Server.
Managing the Firewall
Configuring the Firewall to Allow SMB
This now allows the use of RPC-based tools, including drive mapping, services, and local users and groups (Figure 7-2). If the remote registry service is running, the administrator can also manage the registry remotely.
Configuring the Firewall to Allow RPC
The command line can also be used to allow RPC traffic through the firewall; this allows an administrator to remotely manage the event logs, scheduled tasks, processes, or services on the remote system using graphical tools.
With these firewall rules in place, the administrator can use graphical tools remotely like Event Viewer and Task Scheduler (Figure 7-4).
If both SMB and RPC traffic are permitted, the administrator can use Sysinternals tools like psservice, pslist, and psexec.
Allowing Windows Remote Management via the Command Line
If it is not started, the service can be started with the command sc start winrm and configured to start on subsequent boots with sc config winrm start=auto. The state of the Windows Remote Management system can also be configured from sconfig (Figure 7-11).
Together these allow a remote user to make remote connections to the system using either winrs or the PowerShell command Enter-PSSession.
On Windows Server 2008 R2, some additional work needs to be done. From the sconfig tool (Figure 7-11), select Configure Remote Management, then enable Windows PowerShell; this may require a system reboot. When this is complete, return to sconfig, again select Configure Remote Management, and select Allow Server Remote Management.
Server Manager
Server Manager can be used to manage systems remotely. Server Manager is included in the Remote Server Administration tools, so an Administrator can manage servers from a workstation without needing to log in to a server from the console.
Windows Server 2012 and Later
Windows Server 2012 and later use version 3.0 of the Windows Remote Management System. These can be managed remotely by Server Manager on Windows Server 2012 or later as well as by Windows 8 or later.
Launch Server Manager, then from the Dashboard select Add other servers to Manage (Figure 6-1). The administrator can select the additional server by specifying its name from Active Directory or from DNS. Once the server is managed, the administrator can add roles and features to the remote system from Server Manager by navigating Manage ➤ Add Roles and Features, then selecting the remote server from the server pool.
To configure a remote server as a domain controller, proceed as in Chapter 6 to select Active Directory Domain Services as the role, and choose the remote server as the destination server. Once the role is added, the user will be informed that configuration for Active Directory Domain Services is required. From the notification, select the option to promote the server to a domain controller. This launches the Active Directory Domain Services Configuration Wizard (Figure 6-2) which can be used to complete the process.
The tools provided by Server Manager can be used on the remote systems.
Windows Server 2008 R2
Windows Server 2008 R2 uses version 2.0 of the Windows Remote Management System and cannot be managed by any system using version 3.0. It can be managed remotely by Server Manager from Windows Server 2008 R2 as well as by Windows 7.
Server Manager running on Windows 7 SP1 connected to the remote server themisto, which has been promoted to a domain controller and had the DNS role installed
To configure Windows Server 2008 R2 Core as a domain controller, the administrator does not need to add the Active Directory role. Instead, the administrator runs dcpromo from the command line, specifying the domain configuration. This can be done with an answer file, or directly from the command line.
For more information about this process, see https://support.microsoft.com/en-us/help/947034/how-to-use-unattended-mode-to-install-and-remove-active-directory-doma.
Notes and References
For the benefit of the reader, some of the more interesting WMI classes, events, and subscription classes are summarized.
Useful WMI Classes
- WMI Class: root\cimv2\Win32_Account
WinRM alias: wmi/root/cimv2/Win32_Account
wmic alias: useraccount
Instances: One for each account or group on the local system or on the domain.
Properties: Information about the account, including name, domain, SID, status, and lockout status.
Methods: None
- WMI Class: root\cimv2\Win32_BIOS
WinRM alias: wmi/root/cimv2/Win32_BIOS
wmic alias: bios
Instances: One
Properties: Information about the BIOS of the system, including its name and version. The BIOS may indicate that the system is a virtual machine by considering the manufacturer or the SMBIOSBIOSVersion property.
Methods: None
- WMI Class: root\cimv2\Win32_BootConfiguration
WinRM alias: wmi/root/cimv2/Win32_BootConfiguration
wmic alias: bootconfig
Instances: One
Properties: Information about the boot configuration, including the location of the Windows directory and the last drive on the system.
Methods: None
- WMI Class: root\cimv2\Win32_ComputerSystem
WinRM alias: wmi/root/cimv2/Win32_ComputerSystem
wmic alias: computersystem
Instances: One
Properties: Information about the system, including hostname, whether it is part of a domain (including the name of that domain), as well as the primary owner of the system. The property model may be used to determine if the system is a virtual machine.
Methods: There are methods to rename the system, as well as to join or unjoin a domain or workgroup.
- WMI Class: root\cimv2\Win32_Desktop
WinRM alias: wmi/root/cimv2/Win32_Desktop
wmic alias: desktop
Instances: One for each desktop, including the default; one for system; and one for any logged-in user.
Properties: General information about the desktop, including the wallpaper.
Methods: None
- WMI Class: root\cimv2\Win32_Directory
WinRM alias: wmi/root/cimv2/Win32_Directory
wmic alias: None
Instances: One for each directory on the system, including network shared drives.
Properties: Data about the directory, including its name, creation data, drive, file type, status, and whether it is writeable and/or encrypted.
Methods: None
- WMI Class: root\cimv2\Win32_Environment
WinRM alias: wmi/root/cimv2/Win32_Environment
wmic alias: environment
Instances: One for each environment variable
Properties: Properties of the environment variable, including its name, status, value. and whether it is a system variable.
Methods: None
- WMI Class: \root\cimv2\Win32_Group
WinRM alias: wmi/root/cimv2/Win32_Group
wmic alias: group
Instances: One for each group on the local system or the domain.
Properties: Name, caption, and SID for each group.
Methods: Rename the group.
- WMI Class: \root\cimv2\Win32_GroupInDomain
WinRM alias: wmi/root/cimv2/Win32_Group
wmic alias: None
Instances: One for each case where a user is a member of a group.
Properties: The user and the group that has the user as a member.
Methods: None
- WMI Class: \root\cimv2\Win32_IP4RouteTable
WinRM alias: wmi/root/cimv2/Win32_IP4RouteTable
wmic alias: None
Instances: One for each IPv4 route destination
Properties: Properties of the network route, including the destination, netmask, and next hop.
Methods: None
- WMI Class: \root\cimv2\Win32_LoggedOnUser
WinRM alias: wmi/root/cimv2/Win32_LoggedOnUser
wmic alias: None
Instances: One for each logged-on user. Administrative privileges are needed to see all the instances.
Properties: The logon name, domain, and logon ID.
Methods: None
- WMI Class: \root\cimv2\Win32_LogOnSession
WinRM alias: wmi/root/cimv2/Win32_LogOnSession
wmic alias: logon
Instances: One for each logon event. Administrative privileges are needed to see all the instances.
Properties: The logon ID, the logon time, and the authentication method. It does not include the user.
Methods: None
- WMI Class: \root\cimv2\Win32_NetworkAdapter
WinRM alias: wmi/root/cimv2/Win32_NetworkAdapter
wmic alias: None
Instances: One for each network adapter.
Properties: Adapter name, type of connection, MAC address, speed, and the time it was last reset.
Methods: An adapter can be enabled, disabled, or reset; the power state can also be set.
- WMI Class: \root\cimv2\Win32_NetworkLoginProfile
WinRM alias: wmi/root/cimv2/Win32_NetworkLoginProfile
wmic alias: None
Instances: One for each user that has logged on to the system.
Properties: Account name, the last time the user logged on, the number of times the user logged on, the password age, the password’s expiration, and the user ID. Administrative privileges are needed to see all the instances.
Methods: None
- WMI Class: \root\cimv2\Win32_NTEventLogFile
WinRM alias: wmi/root/cimv2/Win32_NTEventLogFile
wmic alias: None
Instances: One for each of the Windows system logs. Without administrative privileges, no information is provided about the security log.
Properties: The log name, the number of records it has, the file containing the data, its maximum size, the overwrite policy, the time of the last access, the time of its last modification, and whether is readable or writeable.
Methods: Back up, copy, clear, delete, compress, uncompress or rename the log.
- WMI Class: \root\cimv2\Win32_NTLogEvent
WinRM alias: wmi/root/cimv2/Win32_NTLogEvent
wmic alias: None
Instances: One for each entry in any of the Windows system logs. Without administrative privileges, no information is provided from the security log.
Properties: The log file, computer name, the time the log entry was generated, the time the log entry was written, the type, and the message.
Methods: None
- WMI Class: \root\cimv2\Win32_OperatingSystem
WinRM alias: wmi/root/cimv2/Win32_OperatingSystem
wmic alias: os
Instances: One
Properties: Operating system name, version, build number, install date, serial number, last boot time, system directory, and Windows directory.
Methods: Set the date/time of the system, shut down the system, and reboot the system.
- WMI Class: \root\cimv2\Win32_Process
WinRM alias: wmi/root/cimv2/Win32_Process
wmic alias: process
Instances: One for each process running on the system.
Properties: Name, PID, when the process was started, and the command line used to start the process.
Methods: Create a new process, terminate an existing process, query the properties of the process, set its priority, or attach a debugger.
- WMI Class: \root\cimv2\Win32_QuickFixEngineering
WinRM alias: wmi/root/cimv2/Win32_QuickFixEngineering
wmic alias: qfe
Instances: Each hotfix that it installed on the system generates an instance.
Properties: The hotfix ID, caption, a description, the user that installed the hotfix, and the date that the hotfix was installed are recorded.
Methods: None
- WMI Class: \root\cimv2\Win32_Service
WinRM alias: wmi/root/cimv2/Win32_Service
wmic alias: service
Instances: One for each service on the system.
Properties: Service name; its caption; the binary for the service; the account name used to run the service; its state; whether it is started, and if it is started, its PID.
Methods: Create, delete, start, pause, or stop a service.
- WMI Class: \root\cimv2\Win32_Share
WinRM alias: wmi/root/cimv2/Win32_Share
wmic alias: share
Instances: One for each share on the system.
Properties: Name, caption, description, path, and status of the share.
Methods: Create, delete shares.
- WMI Class: \root\cimv2\Win32_StartupCommand
WinRM alias: wmi/root/cimv2/Win32_StartupCommand
wmic alias: startup
Instances: One for each startup command, including those in the registry located in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices.
Properties: The command, its name, its caption and description, the user that runs the startup command, and the location where the startup command lies in the file system.
Methods: None
- WMI Class: \root\cimv2\Win32_Volume
WinRM alias: wmi/root/cimv2/Win32_Volume
Wmic alias: volume
Instance: One for each drive connected to the system, including network shares.
Properties: Many, including the device ID, its file system, and its caption (drive letter).
Methods: Many, including methods to mount or dismount the disk, to run utilities like defrag or chkdisk, to set the power state, and the ability to reset the disk.
- WMI Class: \root\default\StdRegProv
WinRM alias: wmi/root/default/StdRegProv
Instances: None
Properties: None
Methods: Creating, enumerating, or deleting registry keys; getting or setting registry values.
- WMI Class: \root\SecurityCenter2
WinRM alias: wmi/root/SecurityCenter2/AntiVirusProduct
wmic alias: None
Instances: One for each antivirus product installed on the system.
Properties: These include the name, and the path to the executable of the antivirus product.
Methods: None
Note that for WinRM aliases, the combination wmi/root/cimv2 can be abbreviated to wmicimv2.
Useful WMI Events
- \root\cimv2\Win32_DeviceChangeEvent
Occurs when a device is added, removed, or modified; this includes changes in hardware or newly mapped devices or drives, including network drives.
Includes the time and event type.
- \root\cimv2\Win32_VolumeChangeEvent
Occurs when a local drive is added, removed, or modified; this does not include network drives.
Includes the time, drive name, and event type.
- \root\cimv2\Win32_ProcessStartTrace
Occurs when a new process is started.
Includes the process ID, process name, parent process ID, SID, session ID, and the time.
- \root\cimv2\Win32_ProcessStopTrace
Occurs when a process is stopped.
Includes the process ID, process name, parent process ID, SID, session ID, exit status, and time.
- \root\cimv2\RegistryKeyChangeEvent
Occurs when a registry key is changed.
Includes the hive and the key path.
Does not track changes to HKEY_CLASSES_ROOT or HKEY_CURRENT_USER.
- \root\cimv2\RegistryTreeChangeEvent
Occurs when a registry key and subkeys are changed.
Includes the hive and the registry key that contains the subkeys.
Does not track changes to HKEY_CLASSES_ROOT or HKEY_CURRENT_USER.
- \root\cimv2\RegistryValueChangeEvent
Occurs when a single value of a key is changed.
Includes the hive, key path, and the value.
Does not track changes to HKEY_CLASSES_ROOT or HKEY_CURRENT_USER.
- \root\cimv2\Win32_ComputerShutdownEvent
Occurs when the computer begins to shut down, restart, or a user logs off.
Includes the time, and the type - logoff or shutdown/reboot.
- __InstanceCreationEvent
Occurs whenever a new instance is added to the namespace.
Includes the time and the object being added.
- __InstanceDeletionEvent
Occurs whenever a new instance is deleted from the namespace.
Includes the time and the object being added.
Useful WMI Subscription Classes
\root\subscription\ActiveScriptEventConsumer
\root\subscription\CommandLineEventConsumer
\root\subscription\LogFileEventConsumer
\root\subscription\NTEventLogEventConsumer
\root\subscription\SMTPEventConsumer
References
The firewall rule proposed in the text to allow remote RPC calls can be tightened by choosing the program or service to which they apply. There are several predefined rules for RPC available in the New Inbound Rule Wizard that can be used for particular services. The advantage of the approach in the text is that only the one rule is needed for all the various examples, rather than separate rules for each service. At the same time, separate rules would allow for tighter control over what passes through the firewall.
For more information about WinRM and winrs, the reader is best served by Microsoft’s documentation. For WinRM, try https://docs.microsoft.com/en-us/windows/desktop/WinRM/portal while for winrs, try https://technet.microsoft.com/en-us/library/hh875630(v=ws.11).aspx . To configure WinRM to listen over HTTPS, try https://blogs.technet.microsoft.com/meamcs/2012/02/24/how-to-force-winrm-to-listen-interfaces-over-https/.
Windows Management Instrumentation: https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/wmi-start-page
WQL (SQL for WMI) - https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/wql-sql-for-wmi
Querying with WQL - https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/querying-with-wql
Receiving a WMI Event - https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/receiving-a-wmi-event
Managed Object Format - https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/managed-object-format--mof -
MOF Data Types - https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/mof-data-types
WMI Scripting Primer - https://msdn.microsoft.com/en-us/library/ms974579.aspx
Creating a WMI Script – https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/creating-a-wmi-script
How WMI Event Notification Works – https://technet.microsoft.com/en-us/library/ee156572.aspx
The book Windows Command Line Administration Instant Reference by John Paul Mueller (Sybex, 2010) has nice material that covers the wmic command-line tool.
Another nice introduction to WMI and MOF is https://www.codeproject.com/Articles/27914/WMI-MOF-Basics .
There are many WMI scripts available for download at https://gallery.technet.microsoft.com/scriptcenter/site/search?f%5B0%5D.Type=Tag&f%5B0%5D.Value=WMI.
For more about the difference between the WMI PowerShell cmdlets and the CIM cmdlets, see https://blogs.msdn.microsoft.com/powershell/2012/08/24/introduction-to-cim-cmdlets/ .
For more information about how to add or remove the GUI on Windows Server 2012 or 2012 R2, try https://blogs.technet.microsoft.com/gbanin/2012/12/11/converting-a-server-with-a-gui-to-or-from-server-core/ or https://blogs.technet.microsoft.com/heyscriptingguy/2013/01/25/use-powershell-to-remove-the-gui-on-windows-server-2012/ .
The announcement that Windows Server 2016 does not support adding or removing the GUI was made at, for example, https://cloudblogs.microsoft.com/windowsserver/2017/04/05/switching-between-windows-server-2016-server-core-and-desktop-experience/ .