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?
Das Windows AntiMalware Scan Inteface (AMSI) ist eine Schnittstelle mit der sich Dienste und Anwendungen in Antimalware Lösungen integrieren lassen. Mittels der AMSI Schnittstelle lassen sich beispielsweise PowerShell Scripte, Makros und JavaScripts auf schadhafte Funktionen prüfen, auch wenn diese nur im Arbeitsspeicher agieren, ohne dass auf das Dateisystem zugegriffen wird. Exchange Server nutzt nun die AMSI Schnittstelle um Daten aus den HTTP Protokollen an eine Antimalware Lösung weiterzuleiten und untersuchen zu lassen, bevor die Daten durch Exchange verarbeitet werden. So ist es beispielsweise möglich einen Angriff abzuwehren, bevor dieser die Exchange Prozesse „erreicht“. Exchange nutzt also AMSI um schon auf der Protokollebene Angriffe erkennen zu können, beispielsweise bevor eine Webshell (ähnlich wie bei der HAFNIUM Lücke) in das Dateisystem geschrieben wird.
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:
Source: 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:
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:
Das Script kann mit dem Parameter -ExchangeServerFQDN ausgeführt werden um die Funktion zu testen. Das Test-AMSI Script versucht dann einen HTTP-Post Request auf folgenden Pfad auszuführen „https://$ExchangeServerFQDN/ecp/x.js„. Wer sich ein wenig mit HAFNIUM beschäftigt hat, erkennt hier schnell den Bezug :-)
Im Idealfall wird dieser Request also blockiert und mit dem HTTP-Status „400 – Bad Request“ (bzw. 400 – Ungültige Anforderung auf deutschem OS) beantwortet:
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:
Note: After installing a CU, the entries in the web.config files are added again and therefore the interface is also reactivated.