StifleR WMI Provider

Windows Management Instrumentation (WMI) is a Command and Control (C&C) infrastructure that is integrated within Windows. It provides three primary capabilities:

Exposing state information regarding a configurable entity
Invoking control methods on a configurable entity
Publishing events from a configurable entity

These facilities are a complete instrumentation solution for any Windows application, and multiple system components expose information through the use of WMI providers. This information can be consumed from a multitude of languages and technologies by WMI consumers, using a standard query language (WQL).

The StifleR server interface for automation is a WMI Provider In practical terms this means the administrator uses a WMI interface to communicate and control the StifleR server component.

The primary advantage to using WMI in favour of other communication technologies that abound is that WMI is a standardized C&C mechanism which can be consumed by numerous existing C&C frameworks. Most Windows components expose C&C information using WMI, and it is preferable that a single C&C framework is used instead of reinventing a C&C framework for each individual component. This makes a single C&C tool suitable for a variety of configurable and controllable entities.

Most automation of StifleR is done through the StifleR WMI Provider. This is present under the \\ROOT \StifleR WMI namespace on the StifleR server itself.

Updating Values

StifleR is a multithreaded asynchronous service, which means that the changes done through WMI cannot be guaranteed. A change might return the original value and not the changed value, so keep this in mind when scripting against StifleR. If the returned value does not match the value that you are attempting to write it has not been successful and will have to be retried.

After creating or making configuration changes, you should check to ensure that the value you to set has been changed to what is actually running. Some values are checked as part of the function to ensure that the change was successful and will return a failure if not. But some simple value changes have to be verified, as the underlying code runs asynchronously and on multiple threads in order to maximize performance.

The reason StifleR has been designed to work this way is because the internal workings are running on multiple threads asynchronously which may or may not have write access to the internal data structures at any given time. Rather than waiting for a lock to be lifted, using precious resources, the data is flushed to free resources. This allows StifleR to support an extreme large number of simultaneous connections.

For example, if you are trying to set the TargetBandwidth for a Location, make sure that there is a check for the running value after the Set command and make sure that the value has in fact been updated.

Listing Method and Instance Parameters

Using WMI with the CALL and GET /? parameters will give the following outputs:
C:\>wmic /namespace:\\root\stifler path StifleREngine CALL /?
Method execution operations.
USAGE:
CALL <method name> [<actual paramlist>]
NOTE: <actual paramlist> ::= <actual param> | <actual param>,  <actual paramlist> 
The following verb(s)/method(s) are available:

C:\Windows\system32>wmic /namespace:\root\stifler path StifleREngine GET /?
 Property get operations. 
USAGE: 
GET [<property list>] [<get switches>]
NOTE: <property list> ::= <property name> | <property name>,  <property list> 
The following properties are available:

Some properties will be listed as Operation “Write” which means you can use the SET verb to write to them. To find all items that allows Write, replace GET /? with SET /?.

An example how to use the SET operator

wmic /namespace:\\root\stifler path Subnets.SubnetID="192.168.90.44" SET Description=Test

StifleR WMI Provider

Updating Values

Listing Method and Instance Parameters

Further Reading

Updating Values

Listing Method and Instance Parameters

Further Reading