Exchange Server und AMSI: Ein paar Infos

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:

AMSI-Architektur

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:

AMSI Provider

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:

Windows Defender Feature

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:

AMSI Test Script

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:

HttpRequestFiltering Logs

Innerhalb der HttpRequestFiltering Logs finden sich aber nützliche Informationen zu der blockierten Aktion:

HttpRequestFiltering Logs

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.

15 Gedanken zu „Exchange Server und AMSI: Ein paar Infos“

  1. Hi Frank,

    die Aktivierung funktioniert mit deinem Befehl nicht. So wie ich das sehe, sollte das „Remove-SettingOverride -Identity „DisablingAMSIScan“ sein. Kannst du das mal prüfen?

    Antworten
  2. Danke für den Artikel. Der Befehl ist nicht ganz richtig:
    New-SettingOverride -Identity DisablingAMSIScan -Component Cafe -Section HttpRequestFiltering -Parameters („Enabled=False“) -Reason „Testing“

    -Identity muss durch -Name ersetzt werden. Und ja, der Befehl deaktiviert dann das AMSI innerhalb des gesamten DAG. Nur wenn man den Parameter -Server mit angibt, wird es nur auf diesem angegebenen Server deaktiviert:

    „Note: If you set the override without using the -Server parameter, the override applies to all Exchange 2016/2019 servers in the forest.“

    Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/more-about-amsi-integration-with-exchange-server/ba-p/2572371

    Antworten
  3. Hallo,

    ich wollte mal den Test mit dem Scrip Test-AMSI.ps1 machen, erhalte aber diese Meldung:

    Test-AMSI : Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine
    Vertrauensstellung hergestellt werden..

    Mein Blick in Richtung Zertifikate war aber umsonst, alle gültig.
    Hat jemand eine Idee ?

    Vielen Dank im Voraus,
    Gruß
    Volker

    Antworten
  4. Hi Frank,

    in der Registry ist TLS 1.2 enabled

    HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client‘ -name ‚Enabled‘ -value ‚1‘ -PropertyType ‚DWord‘

    Muss ich das für die PS explizit noch machen ?

    Gruß
    Volker

    Antworten
  5. Hallo!

    ich erhalte folgenden Fehler wenn ich versuche via Test-AMSI oder manuell die Provider herauszufinden:

    PS C:\Windows\system32> $AMSI = Get-ChildItem ‚HKLM:\SOFTWARE\Microsoft\AMSI\Providers‘ -Recurse
    PS C:\Windows\system32> $AMSI -match ‚[0-9A-Fa-f\-]{36}‘

    Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers

    Name Property
    —- ——–
    {2781761E-28E0-4109-99FE-B9D12
    7C57AFE}
    {ECC7E393-B680-4109-86BD-77791
    05DF1BF}

    PS C:\Windows\system32> $Matches.Values | ForEach-Object {Get-ChildItem „HKLM:\SOFTWARE\Classes\CLSID\{$_}“ | Format-Table -AutoSize}
    Get-ChildItem : Der Pfad „HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{}“ kann nicht gefunden werden, da er nicht
    vorhanden ist.
    In Zeile:1 Zeichen:35
    + … ach-Object {Get-ChildItem „HKLM:\SOFTWARE\Classes\CLSID\{$_}“ | Forma …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (HKEY_LOCAL_MACH…lasses\CLSID\{}:String) [Get-ChildItem], ItemNotFound
    Exception
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

    Ich weiß dass der erst Defender ist und der zweite ESET. Aber warum kann es den letzten Befehl nicht korrekt ausführen (mit deiner auf github veröffentlichen Test-AMSI German.

    Danke für jede Hilfe!
    Gruß
    Christian Grams

    Antworten
    • Scheinbar unterstützt das Skript es nicht, wenn es mehr als einen AMSI Provider gibt.
      Ich habe ESET als AMSI Provider deaktiviert und siehe da es wird korrekt ausgeführt und zeigt Windows Defender an.

      Antworten

Schreibe einen Kommentar