Exchange Server and AMSI: Some information

With the July 2021 CUs for Exchange Server, Microsoft has introduced AMSI integration as a new feature for Exchange 2016 and 2019. Here is some information about the new feature.

What is AMSI?

The Windows AntiMalware Scan Interface (AMSI) is an interface with which services and applications can be integrated into anti-malware solutions. Using the AMSI interface, PowerShell scripts, macros and JavaScripts, for example, can be checked for malicious functions, even if they only operate in memory without accessing the file system. Exchange Server now uses the AMSI interface to forward data from the HTTP protocols to an anti-malware solution and have it examined before the data is processed by Exchange. This makes it possible, for example, to fend off an attack before it "reaches" the Exchange processes. Exchange therefore uses AMSI to detect attacks at the protocol level, for example before a webshell (similar to the HAFNIUM vulnerability) is written to the file system.

AMSI is an open interface that can also be integrated by manufacturers. From version 2016, Windows Server includes Windows Defender in the standard installation, which also supports AMSI. If no other AMSI-capable anti-malware software is installed, Windows Defender scans the http protocols of the Exchange Server. As soon as a third-party product is installed, Windows Defender is deactivated and the third-party provider can scan the data and, in the best case, block attacks. Here is a graphical overview of how it works:

Quelle: https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps

Exchange Server and AMSI

Only a few requirements must be met for Exchange to be able to use the AMSI interface:

• Windows Server 2016 (or higher) as operating system
• Exchange 2016 CU 21 or Exchange 2019 CU 10 (or higher)
• Windows Defender with AV Engine version 1.1.18300.4 (or higher) or another third-party anti-malware program with AMSI support (McAfee, TrendMicro, Sophos, etc)

Exchange and AMSI can therefore be used out-of-the-box with Windows Defender, but as soon as an AMSI-capable third-party product is installed, only the third-party product is used and no longer Windows Defender. For some third-party providers, such as McAfee, the new AMSI integration was problematic and caused problems. Extremely slow Outlook connections (Windows Defender was not affected).

Important: AMSI does not scan for SPAM or virus-infected mails that are processed by Exchange, but the http protocols that clients use to communicate with Exchange (OWA, EWS, ActiveSync, MapioverHTTP, Autodiscover). For AntiSpam or scanning mails for viruses, integration via Transport Agent is still required (or upstream filters).

AMSI Provider

Using AMSI providers (see graphic above), AntiMalware tools can use the AMSI interface and scan the content of HTTP connections. The AntiMalware tools that have registered an AMSI provider can be viewed with the following commands:

$AMSI = Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\AMSI\Providers' -Recurse
$AMSI -match '[0-9A-Fa-f\-]{36}'
$Matches.Values | ForEach-Object {Get-ChildItem "HKLM:\SOFTWARE\Classes\CLSID\{$_}" | Format-Table -AutoSize}

In this example, it is Windows Defender that accesses the interface via the AMSI provider:

In this example, only Windows Defender is installed as the AMSI provider. If the list is completely empty and at least Windows Server 2016 is used as the operating system, it could be that Windows Defender is not installed:

As already mentioned, third-party tools can cause very severe performance problems for clients, as AMSI can be used to examine every HTTP request to the Exchange server. If the tools take too much time for each HTTP request at this point, Exchange performance suffers and the clients become unusably slow. This becomes particularly clear if no cache mode is used, as is the case in VDI or RDS environments, for example.

Test of the AMSI integration

The Exchange AMSI integration can be detected with a PowerShell test script. Microsoft has published a special script for this purpose:

• https://microsoft.github.io/CSS-Exchange/Admin/Test-AMSI/

However, the test script only works on servers with an English-language operating system. I have therefore modified the script from Microsoft so that it can run on German-speaking servers. The adapted script can be found here:

• https://github.com/FrankysWeb/Test-AMSI-GermanOS

The script can be executed with the parameter -ExchangeServerFQDN to test the function. The test AMSI script then attempts to execute an HTTP post request to the following path "https://$ExchangeServerFQDN/ecp/x.js". Anyone who has studied HAFNIUM a little will quickly recognize the reference here :-)

Ideally, this request is blocked and answered with the HTTP status "400 - Bad Request" (or 400 - Invalid Request on German OS):

In this case, a potentially malicious HTTP post request was blocked by AMSI (specifically Windows Defender). Unfortunately, in this case no event log entry or warning is displayed in Windows Defender, but only an entry in a log file is generated:

However, the HttpRequestFiltering logs contain useful information about the blocked action:

You could now send these log files to a SIEM system or process them using PowerShell. I am currently creating a reporting module for the Exchange Reporter and in the next article there will also be corresponding PowerShell examples for processing the logs.

Deactivate AMSI

After installing the corresponding Exchange CUs, the AMSI interface is activated by default. If the AMSI integration causes problems, the interface can be deactivated with the following commands:

New-SettingOverride -Identity DisablingAMSIScan -Component Cafe -Section HttpRequestFiltering -Parameters ("Enabled=False") -Reason "Testing"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

Note: The last line restarts the IIS, therefore the client connections are interrupted.

The interface can be reactivated with the following commands:

Remove-SettingOverride -Identity DisablingAMSIScan -Component Cafe -Section HttpRequestFiltering -Parameters ("Enabled=False") -Reason "Testing"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

A restart of the IIS processes is also necessary when activating.

Alternatively, the interface can also be deactivated for certain protocols, such as MAPIoverHTTPs or RPCoverHTTPs. How this works is described in the course of this article:

• Exchange 2016/2019: AMSI integration causes problems with Outlook

Note: After installing a CU, the entries in the web.config files are added again and therefore the interface is also reactivated.