high CPU usage by WMI process

[Seahawker]

Hi, 

we are currently evaluating the upgrade from VSE to ENS in our environment and experience some issues with ScriptScanning/AMSI-Option.

As soon as we activate AMSI in the policy, the CPU usage of svchost/wmi raises to 20-30%. If we deactivate AMSI, the process falls back to 0-1% as expected. The behavior can instant be replicated.

As there are no additional options to configure AMSI but turning it on and off... we are not sure how to approach this problem. We don't see anything unsual in the McAfee Debugging logs (as far as we understand them). 

In our environment the Micrsoft Baseline Security Policies have been applied and we are using BeyondTrust Privilege Management. (deactivating/uninstalling BeyondTrust does not have any effect on the behavior)

The Testenvironment:

Windows 10 1903/1909 (patches applied, hardware and virutal platform)
McAfee Agent 5.6.5.165
ENS Platform 10.7.0.1675
ENS TP 10.7.0.1705 (not ATP, as mentioned in KB92399)
ENS Policies have been upgraded from VSE to ENS by McAfee Assistant in ePO. OnAccess Policy has already been rebuilt from scratch for testing reasons.

Behavior was also seen with the previous versions of ENS and before April Patchday.

Is this issue known? 

[Daveb3d]

Also using BeyondTrust, but don't see that at all.  I do have ATP installed.  For kicks, maybe try installing it and see if the issue persists.  IMO, you should deploy it anyway, but that is just my 2 cents. 

You probably will want to get a procmon capture, ETL trace from Windows Performance Recorder and AMTrace, along with debug logs (MER) and open a ticket.  

[mmoore3]

Have you tried to apply the default McAfee policy rather than the migrated policy?4

The data collection mentioned in other post is what will be needed for opening a service request.

[neiltaph]

Did you get a fix for this?

I am looking at re-enabling AMSI but getting the same thing in our tests, high CPU of WMI svchost.exe (25% 1 core). 

[Seahawker]

hi @neiltaph 

from our observation, the behavior started with Windows 10 1903/1909.

we were in contact with McAfee support, had an open case for this issue and delivered procmon traces, McAfee traces, logs, etc. but did not get a fix.

McAfee told us that MfeAmsiProvider.dll could not be loaded by svchost but could not find a reason why this is happening,.

So we asked Microsoft who refered to this:
Starting in Windows 10, version 1903, if your AMSI provider DLL is not Authenticode-signed, then it may not be loaded (depending on how the host machine is configured). For full details, see IAntimalwareProvider interfac: https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider

Our latest tests with Windows 10 2004 did not show this behavior anymore. Machines running with 1909 and ENS were upgraded to 2004 and the behavior disappered. But this are just the first test results, no final statement.

[neiltaph]

Thanks for the information, very helpful.

I was going to test but haven't had a chance yet, to install McAFee ATP on the client machine. We currently don't have it installed, was thinking it might affect it as well as there were some articles saying bad performance unless there was a update to a signature which only exists on ATP component.

I shall re-look at the newer version of windows 10 and see if that fixes it without ATP.

When it was using the high cpu it was "working". I could run obfuscated power shell code  with the EICAR file. When enabled (with bad cpu performance) it did find the eicar, when AMSI was turned off ("good CPU performance") it did not find the EICAR file.