Mit den Juli 2021 CUs für Exchange Server hat Microsoft für Exchange 2016 und 2019 die AMSI Integration als neues Feature eingeführt. Hier gibt es ein paar Infos zu dem neuen Feature.
Was ist 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.
Bei AMSI handelt es sich um eine offene Schnittstelle, welche auch von Herstellern integriert werden kann. Windows Server enthält ab Version 2016 in der Standardinstallation den Windows Defender, welcher ebenfalls AMSI unterstützt. Ist also keine andere AMSI fähige Antimalware Software installiert, scannt Windows Defender die http-Protokolle des Exchange Servers. Sobald ein Drittanbieter Produkt installiert ist, wird der Windows Defender deaktiviert und der Drittanbieter kann die Daten scannen und im besten Fall Angriffe blockieren. Hier mal eine grafische Übersicht der Funktionsweise:
Quelle: https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps
Exchange Server und AMSI
Damit Exchange die AMSI Schnittstelle verwenden kann, müssen nur wenige Voraussetzungen erfüllt sein:
- Windows Server 2016 (oder höher) als Betriebssystem
- Exchange 2016 CU 21 oder Exchange 2019 CU 10 (oder höher)
- Windows Defender mit der AV Engine Version 1.1.18300.4 (oder höher) oder ein anderes Drittanbieter Antimalware Programm mit AMSI Unterstützung (McAfee, TrendMicro, Sophos, etc)
Exchange und AMSI kann also Out-of-the-Box mit dem Windows Defender genutzt werden, sobald aber ein AMSI-fähiges Drittanbieter Produkt installiert ist, wird ausschließlich das Drittanbieter Produkt genutzt, nicht mehr Windows Defender. Bei einigen Drittanbietern wie beispielsweise McAfee war die neue AMSI Integration problematisch und sorgte für extrem langsame Outlook Verbindungen (Windows Defender war davon nicht betroffen).
Wichtig: Mittels AMSI wird nicht auf SPAM oder virenverseuchte Mails gescannt welche durch Exchange verarbeitet werden, sondern die http-Protokolle die Clients verwenden um mit Exchange zu kommunizieren (OWA, EWS, ActiveSync, MapioverHTTP, Autodiscover). Für AntiSpam oder das Scannen von Mails auf Viren ist weiterhin eine Integration via Transport Agent erforderlich (oder vorgelagerte Filter).
AMSI Provider
Mittels AMSI Provider (siehe Grafik oben), können AntiMalware Tools die AMSI Schnittstelle nutzen und den Inhalt der HTTP-Verbindungen scannen. Die AntiMalware Tools welche einen AMSI Provider registriert haben, kann man sich mit den folgenden Befehlen anschauen:
$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 diesem Beispiel ist es der Windows Defender, welcher per AMSI Provider auf die Schnittstelle zugreift:
In diesem Beispiel ist nur der Windows Defender als AMSI Provider installiert. Falls die Liste komplett leer ist und mindestens Windows Server 2016 als Betriebssystem eingesetzt wird, könnte es sein, dass Windows Defender nicht installiert ist:
Wie bereits erwähnt können Drittanbieter Tools für sehr starke Performance Probleme der Clients sorgen, denn mittels AMSI kann jeder HTTP-Request zum Exchange Server untersucht werden. Wenn sich an dieser Stelle die Tools zu viel Zeit für jeden HTTP-Request genehmigen, leidet darunter die Exchange Performance und die Clients werden unbenutzbar langsam. Besonders deutlich wird dies, wenn kein Cache Mode benutzt wird, wie es beispielsweise in VDI oder RDS Umgebungen der Fall ist.
Test der AMSI Integration
Die Exchange AMSI Integration lässt sich mit einem PowerShell Test Script püren. Microsoft hat dazu extra ein ein Script veröffentlicht:
Das Test Script funktioniert allerdings nur auf Servern mit englischsprachigem Betriebssystem. Ich habe daher das Script von Microsoft abgeändert damit es mit deutschsprachigen Servern lauffähig ist. Das angepasste Script findet sich hier:
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 diesem Fall wurde also eine potenziell schadhafter HTTP-Post Request durch AMSI (konkret Windows Defender) blockiert. Leider wird in diesem Fall aber kein Eventlog Eintrag oder eine Warnung im Windows Defender angezeigt, sondern lediglich ein Eintrag in einem Logfile erzeugt:
Innerhalb der HttpRequestFiltering Logs finden sich aber nützliche Informationen zu der blockierten Aktion:
Man könnte nun diese Logfiles an ein SIEM System schicken, oder auch per PowerShell weiterverarbeiten. Ein Reporting Modul für den Exchange Reporter erstelle ich gerade und im nächsten Artikel wird es auch entsprechende PowerShell Beispiele für die Verarbeitung der Logs geben.
AMSI deaktivieren
Nach der Installation der entsprechenden Exchange CUs ist die AMSI Schnittstelle in der Standardeinstellung aktiviert. Wenn die AMSI Integration zu Problemen führt, lässt sich die Schnittstelle mit den folgenden Befehlen deaktivieren:
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
Hinweis: Die letzte Zeile startet den IIS neu, daher werden die Client Verbindungen unterbrochen.
Mit den folgenden Befehlen lässt sich die Schnittstelle wieder aktivieren:
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
Auch beim Aktivieren ist wieder ein Neustart der IIS Prozesse nötig.
Alternativ lässt sich die Schnittstelle auch für bestimmte Protokolle, wie etwa MAPIoverHTTPs oder RPCoverHTTPs deaktivieren. Wie dies funktioniert ist im Verlauf dieses Artikels beschrieben:
Hinweis: Nach der Installation eines CUs werden die Einträge in den web.config Dateien wieder hinzugefügt und daher auch die Schnittstelle wieder aktiviert.