ENS / AMSI support triggers 3rd party app to fail

[pbnlnai]

Hello,

is anybody affected by AMSI feature as it is included in ENS Threat Protection?

We are running a deployment solution that got interfered by the way McAfee handles AMSI.

If enabled AMSI (even in observe mode) in OAS policies our deployment agent fails, if disabled everything is fine, better was fine..... since we started deploying ENS 10.7 disabling AMSI does not the trick, means our deployment agent does not work anymore....

Following had been installed on the PC's:

McAfee Endpoint Security Platform 10.7.0.1285

McAfee Threat Protection 10.7.0.1415

McAfee Adaptive Threat Protection 10.7.0.1285

McAfee Threat Protection 10.7.0.1415

McAfee Web Control 10.7.0.1086

Actually there is no way to get the deployment agent running other than removing 10.7 or rolling back to 10.6. Strange thing (valid for all ENS version) no event or log is written by ENS even if debug log is enabled. It simply blocks it.

Support tickets had been opened month ago at McAfee and the deployment solution vendors support. The play kind of ping pong on customers back, blaming each other and that's it. No solution, no progress.

Just for the record, our setup was also tested using 4 other AV vendors and none of them had an issue. Neither with the used deployment solution nor with Windows 10 AMSI. In my opinion it is ENS who is causing the trouble due to this.

Anyone else having issues with applications if the AMSI is enabled in the OAS policies? How did you fix it? Any help appreciated....

KR

[Former Member]

Hi @pbnlnai 

Thanks for posting here. May I have your Service Request number? (You can send me a direct message with it). I was working on a similar issue the other day and would very much like to verify if you are seeing the same or not.

I appreciate it can sometimes be frustrating when multiple parties are involved. From our perspective, we always require the third party which is failing to identify why/ what exactly is failing so we can pinpoint the point of failure and continue our investigation. This is documented in KB73182.

It's great if you already have the other third party involved! We are always more than happy to collaborate with them to get this issue resolved for you.

[pbnlnai]

SR # <4-20423413021>

[Former Member]

Thanks! This is exactly the same. I will leave a note for the owner of your case so he can take further action with you.

[PaulG]

This is occurring in our environment as well on systems with Windows 10 (1903), ENS 10.7, and AMSI enabled.

When we looked at the task manager, we noticed (in our case) that svchost.exe (WinMgmt) CPU usage was spiked.  If we disabled AMSI through policy or unregistered the provider, CPU usage returned to normal and our WMI reliant products began working again.  We noticed a number of errors in the EndpointSecurityPlatform_Errors log and errors specifying the AMSI provider dll in the Event Logs (Applications and Services -> Microsoft -> Windows -> CodeIntegrity)

We also opened an incident with support as well as with Microsoft.

-Paul

[pbnlnai]

Hi,

Using ENS 10.6.1x we have been able to workaround the problem by disabling AMSI in the On-Access-Policy. In the meantime we got 2 new ENS 10.6.1 modules (common and the threat prevention) by McAfee support to be tested. But they did not solve the problem.

If we install the ENS 10.7.x on our clients disabling AMSI in the OAS policy will not workaround the problem anymore. Most strange thing in our case is, that nothing is logged anywhere, even if debug logging is enabled on agent and threat prevention level in terms of the deployment agent we are using.

Excluding the affected software in the OAS policy as part of low risk profile from scanning does not work either.

In terms of the code integrity events, I can say, we see them too. But in my opinion they are not caused by ENS they are related to Windows Defender and you find articles and notes inside the Win 10 change logs about it.  Following just an example

Changelog win 10 1903 / KB4512941

Addresses an issue in which Windows Defender Application Control will not allow third-party binaries to be loaded from a Universal Windows Platform application. CodeIntegrity event error 3033 appears as, “Code Integrity determined that a process (<process name>) attempted to load <binary name> that did not meet the Store signing level requirements.”

M.

[PaulG]

Running Sysinternals Procmon showed repeated references to the HKLM\SOFTWARE\Microsoft\AMSI\Providers, which is normal and expected as indicator that an AMSI event was triggered.  Then errors once it begins processing requests using the provider (mfeamsiprovider.dll).  These same errors do not occur on Systems below 1903.  We have not rolled back to 10.6.1 to test machines since disabling AMSI handling in the OAS policy fixes the issue.  We did have to completely disable AMSI because enabling it with the "enable observe mode" checked caused the same issue.

Our software deployment application is heavily reliant on WMI calls so we saw the most amount of pain stemming from that.  I don't know if your app has integrations with WMI or if its just script runs that is causing this issue.


As for the code integrity events, they are definitely caused by McAfee on our systems and not that Microsoft support bulletin for a few reasons.

• We have disabled Windows Defender so it would not be responding to AMSI event.
• We have the August patch installed in which they've resolved the Windows Defender Issue
• The offending process is not a UWP application, its a standard Win32 app and because of this "Store Signing" is not in the loop.  Only standard "Microsoft Signing".

In our scenario we saw a spike in CPU usage by the process svchost.exe (hosting WinMgmt) and in the CodeIntegrity log that process was referenced.

Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume3\Program Files\McAfee\Endpoint Security\Threat Prevention\MfeAmsiProvider.dll that did not meet the Microsoft signing level requirements.

This seems to align with changes to signing requirements on 1903 documented by Microsoft Docs on AMSI.  Although its worth noting that the FeatureBits flag made no difference in our scenario.

Are you seeing issue only on 1903 machines with 10.7?

-Paul

[pbnlnai]

I can confirm having AMSI enabled plus the observe mode inside the OAS policy will cause trouble with the deployment agent. It is really necessary to completely switch off the AMSI support inside the OAS policy.

The deployment agent we actually use has no WMI integration and is based on running scripts.

I am still wondering that you do not have any issues with your deployment tool using the 10.7 with the AMSI support disabled. By switching from ENS 10.6 to 10.7 we got the problem back that we could workaround by disabling AMSI thus we had to roll back all 10.7 to 10.6 installations.

Actually we do not have an 1903 installation anymore. I just can offer to test something on 1809 or 1909.

THX for changing informations

M.

[denn]

Any fixes for this issue ? Have the same on 1909 with the ENS 10.7 May verion.

[pbnlnai]

Actually we use the ENS 10.7 that had been released in May  and installed  it on a bunch of Computers.

I have to say the problem we had been faced with seems to be gone.

There are some minor issues but compared to all the ENS releases since autumn last year the MAy version has been used to replace all our previous 10.6 installations.

KR

M.