Sophos AMSI Protection Logging - Turn Off

I think it's less about AMSI logging, more about the Sophos AMSI Provider DLL being pulled into processes that load amsi.dll. E.g. PowerShell, cscript.exe, Etc:

If I look on my computer, AMSI protection is being loaded in the following processes:

If you look in:

Microsoft-Windows-CodeIntegrity/Operational

I.e.

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-CodeIntegrity%4Operational.evtx

Do you see from the EventData section of the event, which process is getting referenced?  Is it a svchost.exe process? If so, which one?  Is it a protected process?

Thanks.

Do you have SvchostProcessMitigation configured?
https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-servicecontrolmanager
This might explain some of the repeat events?

Hi. Thank you for your response.

But when you look into my computer, here's what I am getting.

Sophos User930 said:

Microsoft-Windows-CodeIntegrity/Operational

Sophos User930 said:

Do you have SvchostProcessMitigation configured?

Provided the details above, can you see now why there is repeating events? That's why if it safe to turn off the AMSI logging?

You'd have to disable AMSI totally in policy to prevent the Sophos AMSI provider being registered under:

For 64-bit processes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers\{19016286-87D5-4D51-A042-2A9C5CBB8D5F}

For 32-bit processes:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\AMSI\Providers\{19016286-87D5-4D51-A042-2A9C5CBB8D5F}

When you disable AMSI in policy the above keys would be removed, so when a new process such as Outlook.exe loads the Microsoft AMSI.dll, that DLL doesn't enumerate the installed AMSI providers and load those COM registered DLLs, i.e. SophosAmsiProvider.dll.

I can't tell from the event log which process it was that attempted to load the SophosAmsiProvider.dll without seeing the event log details. E.g.

In this case we have a svchost.exe process, which must be 64-bit given the path to the exe and provider dll, PID 5020, that is causing the DLL load which is being rejected.

The RequestedSigningLevel is detailed here:

Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers) – Alex Ionescu’s Blog (alex-ionescu.com)

I believe that the SophosAmsIProvider.dll would probably need to be signed by Microsoft for it to load into some processes probably based on the requirements of the process.At the moment it is signed by Sophos as you might expect.

It seems that the amsi.dll must try and load it for each request and doesn't record/cache that it failed to load it previously. Depending on the behaviour of the process in respect to AMSI work I assume it gets into a state of constantly trying and failing.

The only thing I think you can do is to determine the process that is attempting to load it in the first instance and then consider the options.

You might need to turn on process creation auditing with cmd line logging, so you can reboot the computer.  See the error in the CI event log, check the PID in the event details, then check the Security Event log to find out which PID that was.  Chances are it's a Svchost process but I suspect they aren't shown in your screenshot is that you ran Process Explorer as you, un-elevated so it didn't list svchost processes for example.

You'd have to disable AMSI totally in policy to prevent the Sophos AMSI provider being registered under:

For 64-bit processes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers\{19016286-87D5-4D51-A042-2A9C5CBB8D5F}

For 32-bit processes:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\AMSI\Providers\{19016286-87D5-4D51-A042-2A9C5CBB8D5F}

When you disable AMSI in policy the above keys would be removed, so when a new process such as Outlook.exe loads the Microsoft AMSI.dll, that DLL doesn't enumerate the installed AMSI providers and load those COM registered DLLs, i.e. SophosAmsiProvider.dll.

I can't tell from the event log which process it was that attempted to load the SophosAmsiProvider.dll without seeing the event log details. E.g.

In this case we have a svchost.exe process, which must be 64-bit given the path to the exe and provider dll, PID 5020, that is causing the DLL load which is being rejected.

The RequestedSigningLevel is detailed here:

Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers) – Alex Ionescu’s Blog (alex-ionescu.com)

I believe that the SophosAmsIProvider.dll would probably need to be signed by Microsoft for it to load into some processes probably based on the requirements of the process.At the moment it is signed by Sophos as you might expect.

It seems that the amsi.dll must try and load it for each request and doesn't record/cache that it failed to load it previously. Depending on the behaviour of the process in respect to AMSI work I assume it gets into a state of constantly trying and failing.

The only thing I think you can do is to determine the process that is attempting to load it in the first instance and then consider the options.

You might need to turn on process creation auditing with cmd line logging, so you can reboot the computer.  See the error in the CI event log, check the PID in the event details, then check the Security Event log to find out which PID that was.  Chances are it's a Svchost process but I suspect they aren't shown in your screenshot is that you ran Process Explorer as you, un-elevated so it didn't list svchost processes for example.

Hi,

Sorry for the late reply.

See below image for the event log details to which process it was attempted to load.

So, I ran the Process Exporer with admin right and here's what I am getting.

What are my options? Disable AMSI thru registry?

Thank you.

So Process Explorer, running as admin now shows all processes that the Sophos AMSI provider is being loaded into OK.

The event log shows process 5566 (a svchost.exe process) was unable to load it due to the signing requirements and hence the event log entry.

It would nice to know what svchost process that is.

Lookin on my Windows 11 computer at the svchost.exe processes that have a protection level:

From the Top they are 
- Application Identity
- Delivery Optimization
- Security Center
- Client Licence Service (ClipSVC)
- AppX Deployment Service (AppXSVC)

So I assume it's one of those services on your computer but it would be good to know for certain.

If you reboot the computer, open the event log, find the new event from the boot.  Get the PID from the event details as you have show above, then in Task Manager, go the Services page and look for the PID found, what services are hosted in it.  I assume it's one of the above, maybe the "Delivery Optimization" service? I will assume as it's a svchost.exe process it's not a transient process.

The services page allows you to map the PID to the service:




I understand Sophos are going to get the SophosAmsiProvider.dll signed by Microsoft but in the meantime, it would be nice to know which svchost.exe on your computer the SophosAmsiProvider.dll provider is failing to load into.

You could disable AMSI in policy the event would stop but AMSI is a useful protection feature and it seems a shame to disable it to stop Event log entries. Especially if it's just from one process.

Hi,

Again, thank you for your detailed response. It really helps me a lot to understand the process.

Sophos User930 said:

If you reboot the computer, open the event log, find the new event from the boot.  Get the PID from the event details as you have show above, then in Task Manager, go the Services page and look for the PID found, what services are hosted in it.  I assume it's one of the above, maybe the "Delivery Optimization" service? I will assume as it's a svchost.exe process it's not a transient process.

So, I look into my Task Manager and you're right. The PID 5566 is being map to Delivery Optimization service.

Sophos User930 said:

I understand Sophos are going to get the SophosAmsiProvider.dll signed by Microsoft but in the meantime, it would be nice to know which svchost.exe on your computer the SophosAmsiProvider.dll provider is failing to load into.

You could disable AMSI in policy the event would stop but AMSI is a useful protection feature and it seems a shame to disable it to stop Event log entries. Especially if it's just from one process.

I also read some articles regarding Sophos AMSI not being signed by Microsoft. Based on our observation, we found which svchost.exe is falling to load into. Regarding with disabling the AMSI policy, it would not be an option to us since as you said it is a powerful and useful protection. So, it leaves us no choice but to wait for Sophos.