Type to search
Analyze a file Free Tools

Windows Security Center: Fooling WMI Consumers

‹ Blog

Windows Security Center: Fooling WMI Consumers

Windows Security Center is a reporting tool that is built into the operating system, since the release of service pack 2 for Windows XP, that monitors the health state of the endpoint in different areas, such as Windows updates, firewall settings and antivirus/antispyware settings. In order for third party security applications to be Windows compliant, they must report their state to Security Center through the use of a private API that can be obtained by signing an NDA.

It is no surprise that antivirus software is a necessity in today's digital world to detect a growing list threats. But what about detecting the antivirus software protecting the endpoint in a growing list of antivirus software? Surely we can use Windows Security Center to determine the antivirus software protecting the endpoint, right? Yes and no.

Recently, Microsoft have exposed some new interfaces for determining the product's name and state that are reporting the Windows Security Center that are available on Windows 8 operating system. Microsoft has even provided a sample project illustrating how to work with the new Windows Security Center interfaces. So problem solved yes? Well for Windows 8 users, Microsoft has provided a secure way of obtaining this information, but how relevant is this today? If you consider the market share for Windows 8 desktops, not very relevant at all. So how can earlier operating systems query this information? WMI.

Windows Security Center is built upon Windows Management Instrumentation (WMI) which is an infrastructure for managing all kinds of data and operations on Windows operating systems. I am not going to go into the details of the WMI architecture, but I must briefly discuss a few aspects of it here: WMI consumers, WMI providers, and WMI repository.

A WMI consumer is a management application or script that can query information, run provider methods, or subscribe to events. A WMI provider supplies data for managed objects and handles messages (or invocations) sent from WMI to the managed objects. The WMI repository is a centralized storage area for managed objects organized by WMI namespaces. The following simplified diagram illustrates how each of these components of the WMI infrastructure interact with each other.

WMI diagram

In our example, the antivirus software reporting to Windows Security Center is the WMI provider, and our scripts for retrieving the antivirus software information is the WMI consumer. There are 2 different versions of the Security Center WMI namespace.

// WMI namespace for Security Center 1, pre-Vista
root\SecurityCenter

// WMI namespace for Security Center 2, post-Vista
root\SecurityCenter2

Our focus will be on the AntiVirusProduct WMI class, which the antivirus software will provide an instance of to the given namespace. The following Managed Object Format (MOF) represents the AntiVirusProduct WMI class for Security Center 1:

class AntiVirusProduct
{
    string  companyName;              // Vendor name
    string  displayName;              // Application name
    string  instanceGuid;             // Unique identifier
    boolean onAccessScanningEnabled;  // Real-time protection
    boolean productUptoDate;          // Definition state
    string  versionNumber;            // Application version
}

There are additional properties, such as pathToEnableOnAccessUI, to the AntiVirusProduct class not listed above as they are rarely used by WMI providers. The following MOF represents the AntiVirusProduct WMI class for Security Center 2:

class AntiVirusProduct
{
    string  displayName;              // Application name
    string  instanceGuid;             // Unique identifier
    string  pathToSignedProductExe;   // Path to application
    string  pathToSignedReportingExe; // Path to provider
    uint32  productState;             // Real-time protection & defintion state
}


Now that we have an understanding of where Security Center stores information in the WMI repository and what information the antivirus software provides to Security Center, we can write a WMI consumer to access this data. There are countless examples online for how to achieve this, such as here, here, and here. For simplicity of this post, I will use a simple Visual Basic script as my WMI consumer. The following script will detect instances of AntiVirusProduct in Security Center 1 and display them in a message box.

' Open handle to to Windows Security Center '
Set oWMI = GetObject( _
  "winmgmts:{impersonationLevel=impersonate}!\\.\root\SecurityCenter")
  
' Run Query for all AntiVirusProduct instances '
Set colItems = oWMI.ExecQuery("Select * from AntiVirusProduct")

' Check if we found any instances '
If colItems.count = 0 Then
    Msgbox "No antivirus products", vbOKOnly, "Alert"
    WScript.Quit
End If

' Iterate over each of the instances found and dump useful display data '
For Each objItem in colItems
  With objItem
    Msgbox "Company name = " & .companyName & vbLf _
       & "Product name = " & .displayName & vbLf _
       & "Product version = " & .versionNumber & vbLf _
       & "RTP status = " & .onAccessScanningEnabled & vbLf _
       & "Up-to-date = " & .productUptoDate & vbLf _
       , vbOKOnly, "Antivirus product"
  End With
Next


We can slightly alter the script above to work with Windows Security Center 2.

' Open handle to to Windows Security Center '
Set oWMI = GetObject( _
  "winmgmts:{impersonationLevel=impersonate}!\\.\root\SecurityCenter2")
  
' Run Query for all AntiVirusProduct instances '
Set colItems = oWMI.ExecQuery("Select * from AntiVirusProduct")

' Check if we found any instances '
If colItems.count = 0 Then
    Msgbox "No antivirus products", vbOKOnly, "Alert"
    WScript.Quit
End If

' Iterate over each of the instances found and dump useful display data '
For Each objItem in colItems
  With objItem
     Msgbox "Product name = " & .displayName & vbLf _
        & "Path to product = " & .pathToSignedProductExe & vbLf _
        & "Product state = " & .productState & vbLf _
        , vbOKOnly, "Antivirus product"
  End With
Next


What are these scripts doing?

  1. Connecting to the Security Center WMI namespace
  2. Running a WQL query to find all instances of AntiVirusProduct in the namespace
  3. Checks if we didn't find any instances, if so, will alert and exit
  4. Iterate over each instance found and display the values

To summarize, our WMI consumer scripts have the ability to detect which antivirus application is reporting to Security Center and determine the state of the product. So, how can we trick our consumer to detect an antivirus application that is not installed on the system?

The information that we just accessed is stored in the WMI repository, which is a storage area. Any WMI consumer can make a query on this information. We can insert data into this WMI namespace for the AntiVirusProduct WMI class through a WMI provider. There are numerous ways to provide data to WMI. We are going to use the MOF Compiler, which is part of the .NET Framework, to insert data into the WMI repository. Remember, that in order for a security product to actually report it's status notifications to Security Center, it must use the private API's, however, I am talking about WMI consumers.

The following MOF file (fake-av.mof) represents an instance of the AntiVirusProduct WMI class for Security Center 1:

#pragma autorecover

#pragma namespace("\\\\.\\root")

instance of __Namespace
{
  Name = "SecurityCenter";
};

#pragma namespace("\\\\.\\root\\SecurityCenter")

instance of AntiVirusProduct
{
    companyName = "ESET, spol. s.r.o.";
    displayName = "ESET NOD32 Antivirus 4";
    instanceGuid = "{CD3EA3C2-91CB-4359-90DC-1E909147B6B0}";
    onAccessScanningEnabled = TRUE;
    productUptoDate = TRUE;
    versionNumber = "6.2.71.2";
};


To compile and insert the managed object into the WMI repository, run the following command with administrative privileges. The following assumes that mofcomp.exe is in your %PATH% and you are running this from the same directory as your "fake-av.mof" file.

 C:\Documents and Settings\test\Desktop>mofcomp.exe fave-av.mof

If successful, you will see the following output:

 Microsoft (R) MOF Compiler Version 6.1.7600.16385
 Copyright (c) Microsoft Corp. 1997-2006. All rights reserved.
 Parsing MOF file: fake-av.mof
 MOF file has been successfully parsed
 Storing data in the repository...
 Done!


Now if we run the same Visual Basic script above, we will falsely detect ESET NOD32 Antivirus 4 on the endpoint with its real time protection status on and the virus definitions up-to-date. The same process can used with Security Center 2 with the following MOF file.

#pragma autorecover

#pragma namespace("\\\\.\\root")

instance of __Namespace
{
  Name = "SecurityCenter2";
};

#pragma namespace("\\\\.\\root\\SecurityCenter2")

instance of AntiVirusProduct
{
	displayName = "ESET NOD32 Antivirus 4";
	instanceGuid = "{CD3EA3C2-91CB-4359-90DC-1E909147B6B0}";
	pathToSignedProductExe = 
	"C:\\Program Files\\ESET\\ESET NOD32 Antivirus\\ecmd.exe";
	pathToSignedReportingExe =
	"C:\\Program Files\\ESET\\ESET NOD32 Antivirus\\x86\\ekrn.exe";
	productState = 266240;
};


The values to provide to productState are undocumented. In fact, all of the WMI namespaces and classes are undocumented, however, the following blog post shines some undocumented light on the matter, which has held true in all of my testing.

The moral of the story, do not rely solely on a WMI consumer for detecting security products reporting to Security Center. They can easily be fooled.

WMI antivirus detection

Disclaimer

This post is, by no means, meant to discredit the security that Microsoft provides with Windows Security Center. There have been posts in the past that have brought up spoofing Security Center in the context of malware attacks. The content of this post should be applied to software manageability.

There are ways in which one could authenticate the content returned to the WMI consumer. The purpose of this article is merely to expose the effect of having a "lazy" WMI consumer for security product inventory through Security Center.

If you liked this post and want to read more, sign up for our mailing list to have updates delivered to you!

Windows WMI OESIS IT Infrastructure