Detect Antivirus through WMI

Question

I have come up with a situation in which an installed antivirus is not detected by wmic or it's equivalent cmdlet. The system where I am having this issue is a windows server 2016 and the antivirus is SEP (Symantec Endpoint Protection)

While doing some research I have found two possible explanations for this, but as far as I understood, these answers are pretty different, actually could even be complementary. Since I am a newcomer to WMI I would like some clarification about them.

The command I am using for retrieving the information is:

wmic /NAMESPACE:\\root\SecurityCenter2 path antivirusproduct GET ...

The first explanation¹ I found is that the antivirusproduct class is not defined in server versions of windows which fits my problem since my machine is a windows server and I have tried the same command on a Win10 machine and it works.

The second explanation² talks about the fact that in order to detect the antivirus through WMI it has to be registered on the Windows Security Center.

Having said that the main questions are:

Is the antivirusprocut class defined by the Windows Security Center provider, actually, does WSC have a WMI provider. If not which WMI provider is defining this class. I have been looking at the list of providers in the reference documentation³ and there doesn't seem to be a provider defining this so I assume this must be set by a provider coming from a third party software, hence the guess about WSC.

Regardless of the provider why would a class be defined on windows desktop versions and not on a server ones.

Any clarification is appreciated.

---

¹ Detecting anti-virus on Windows with WMI - which namespace?

² https://support.moonpoint.com/os/windows/commands/wmic/determine-antivirus.php

³ https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-providers

Answer 1

Your questions

Is the antivirusprocut class defined by the Windows Security Center provider, actually, does WSC have a WMI provider. If not which WMI provider is defining this class. I have been looking at the list of providers in the reference documentation and there doesn't seem to be a provider defining this so I assume this must be set by a provider coming from a third party software, hence the guess about WSC.

A tool like WMI Explorer or EtwExplorer may be the better fit than the documentation.

Anyway, there is a service called "Windows Security Center" (C:\windows\system32\SecurityHealthService.exe on Windows 10) which, when disabled, silences the WSC notifications. It stands to reason that this is the other end of the RPC endpoint described in the technical part below. The following also look suspiciously related:

• SecurityHealthHost.exe (<-- sounds like it could be the WMI provider)
• SecurityHealthService.exe (service, mentioned above)
• SecurityHealthSystray.exe (arguably the GUI program running inside a log on session in what we have repeatedly been told by Microsoft is the Tray Notification Area -- aka TNA -- and not the System Tray 😜)
• SecurityCenterBroker.dll
• SecurityCenterBrokerPS.dll
• SecurityHealthAgent.dll
• SecurityHealthProxyStub.dll
• SecurityHealthSSO.dll

Anyone acquainted with COM will immediately spot the PS and ProxyStub parts in the names (they're synonymous). And we can find wscenter.mof which would also seem to be related and, if opened, gives us:

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

class AntiVirusProduct
{
  [key,Not_Null] string instanceGuid;
  [Not_Null] string displayName;
  [Not_Null] string pathToSignedProductExe;
  [Not_Null] string pathToSignedReportingExe;
  [Not_Null] uint32 productState;
  string timestamp;
};

But scouring the binaries for wscenter.mof or instances of IWbemProvider and similar turns up nothing. But, we already knew the name of the WMI object \\.\root\SecurityCenter2, so back to WMI Explorer:

So there you have your answer: Windows Defender hosts the WMI provider for SecurityCenter2 on Windows 10. Why -- or if indeed -- it doesn't do that on Windows Server was your other question.

But why in Windows Defender? My guess would be because it's a PPL.

Regardless of the provider why would a class be defined on windows desktop versions and not on a server ones.

Well, technically this is a question for the Microsoft folks, don't you think? And given they are secretive and protective about the larger part of the WSC API, I don't think we can expect any enlightening comments by the likes of Raymond Chen or so. Maybe in twenty years, though.

That said, isn't that the whole idea of WMI that you have dynamically provided information that is getting fed into a database and dynamically updated? So something being absent or present -- just like with COM -- is totally dynamic and based on the availability of a certain "component" (or provider in WMI terms).

And then there's the point that the WSC is inherently a GUI-heavy component. As such it's not a good fit for a server edition. Also mind the fact that Server Core used to be a thing when those interfaces were defined. So it's not far-fetched to assume that the server editions would lack this functionality even if the AV endpoint solution may be equipped to the WSC COM API. After all the instantiation of the COM classes will tell the software whether or not WSC is at all available.

Btw: this boils down to the same thing as, for example the task bar button progress interface. The proper way is not to inquire about the version of Windows and then decide to enable/disable this functionality. The proper way is to attempt to instantiate the class via COM and failing that disabling the functionality.

---

This isn't supported. The public functions from the WSC API seem to be unsupported for Server editions of Windows -- as you have already pointed out yourself. Check out the documentation for, say, WscGetSecurityProviderHealth:

Minimum supported server None supported

The thing is this, the Windows Security Center (WSC), now part of the Action Center in newer Windows versions was introduced with Vista, itself a consumer edition of Windows. Initially it was WMI-based. Meaning the AV vendors would also report their AV's state this way. This was switched to COM at some point (I don't remember 100%, but I think with Windows 7 SP1).

The state reported via the new COM-based API (and available to AV vendors under NDA through MVI) is probably also exposed via WMI. But the actual state changes have to be done via COM on modern Windows and the executable that performs that change needs to be EV-signed as far as I recall (it's been >5 years for me).

As far as I recall and given what I see on a recent Windows 10, the file wscisvif.dll should be the one to implement the ISV (i.e. third-party vendor) interface for WSC. I don't know if that is present or absent in the Server editions (have none handy right now). Anyway, wscisvif.dll stands for "Windows Security Center ISV API".

But equipped with that knowledge we can dig deeper. It's evidently an InProc-COM-server registered in the usual places:

• HKCR\CLSID\{F2102C37-90C3-450C-B3F6-92BE1693BDF2}
• HKCR\WOW6432Node\CLSID\{F2102C37-90C3-450C-B3F6-92BE1693BDF2}
• HKLM\SOFTWARE\Classes\CLSID\{F2102C37-90C3-450C-B3F6-92BE1693BDF2}
• HKLM\SOFTWARE\Classes\WOW6432Node\CLSID\{F2102C37-90C3-450C-B3F6-92BE1693BDF2}
• HKLM\SOFTWARE\WOW6432Node\Classes\CLSID\{F2102C37-90C3-450C-B3F6-92BE1693BDF2}

... so we can inspect the exported DllGetClassObject. I won't go into the GUIDs one can discover with that (given the prerequisite the reporting binary be EV-signed it's of limited value), but we can see the relevant implementation is in virtual long CWscIsv::UpdateStatusAV(enum _WSC_SECURITY_PRODUCT_STATE, int). With that enum name we could ask a search engine for more info and may end up here where we can find:

enum _WSC_SECURITY_PRODUCT_STATE  {
    WSC_SECURITY_PRODUCT_STATE_ON = 0,
    WSC_SECURITY_PRODUCT_STATE_OFF = 1,
    WSC_SECURITY_PRODUCT_STATE_SNOOZED = 2,
    WSC_SECURITY_PRODUCT_STATE_EXPIRED = 3
};

enum _WSC_SECURITY_SIGNATURE_STATUS {
    WSC_SECURITY_PRODUCT_OUT_OF_DATE = 0,
    WSC_SECURITY_PRODUCT_UP_TO_DATE = 1
};

I lack the continued access to the documentation provided via MVI, but this looks plausible. And any typelib viewer can tell you the same anyway from the TYPELIB embedded as resource in wscapi.dll:

From that typelib we can also glean the names of relevant COM interfaces: IWSCProductList, IWscProduct, IWSCDefaultProduct.

Mind you, the decision what constitutes "out of date" is up to the vendor reporting back to WSC.

The functionality implemented by the COM server seems to go back to the wscapi.dll which contains exported functions starting with wsc (all lowercase) and with Wsc, which I assume indicate that they are private and public interfaces respectively.

Anyway, that's where we can also find the function mentioned way at the top (WscGetSecurityProviderHealth). This DLL seems to make heavy use of RPC facilities to talk to the code that constitutes the "meat" of the WSC.

I didn't find any indicators of these two DLLs implementing a WMI provider, so it stands to reason that the RPC endpoint on the other end does that, if WMI state is available.