AMSI - AntiMalware Scan Interface

Viren und Malware bekämpft man mit Virenscannern, was meist gut funktioniert, wenn die Malware nicht zu neu ist und die Virenscanner diese schon erkennen können. Aber es gibt auch "unkenntlich" gemachte Malware, die nicht als Datei auf einer Festplatte liegt und daher von dateibasierten Virenscannern nicht so einfach gefunden wird. Hier gibt es von Microsoft mittlerweile eine Lösung, die auch für Exchange interessant wird.

Im Anschluss an den Abschnitt über Exchange und AMSI beschreibe ich grundsätzlich die AMSI-Funktion, die aber nicht neu ist sondern schon im Jahr 2016 auf der BlackHat16 Konferenz analysiert wurde.

AMSI ist erst am Windows 10 und höher und Windows Server 2016 und höher verfügbar.

Exchange 2016 CU21 und Exchange 2019 CU10 wurde Ende Juni 2021 released und integriert AMSI in sein Schutzkonzept

Es geht um Geschwindigkeit!

Eigentlich komisch, dass Microsoft sine Schnittstelle wie AMSI erst mit Windows 2016 / Windows 10 bereitgestellt hat,. Der Ansatz ist ja so einfach und offen. Vielleicht vergleichen wir aber einmal die klassischen Ansätze bei der Malware-Erkennung und Abwehr. Ein Client (gut oder böse) spricht mit einem Service, der die Anfragen verarbeitet und dabei Dateien ausliefert oder abspeichert.

Services haben Fehler und so kann ein böser Client die Funktion stören oder sogar eigenen Code auf dem Service ausführen oder Daten verändern. Gegen solche Angriffe gibt es klassische mehrere Ansätze:

  • Am Client
    Der Virenscanner auf dem Client ist Pflicht aber hilft nicht, wenn der Angreifer seinen eigenen Client nutzt.
  • Auf dem Kabel
    Web Application Proxy-Systeme können Anfragen analysieren und ggfls. blockieren, so Sie schon per Pattern dies unterscheiden können und das Protokoll generell "analysierbar" ist. Das geht mit HTTP, FTP und einigen anderen Protokollen relativ gut aber wenn z.B. SQL-Statement, Eingaben über RDP-Verbindungen oder VPN-Verbindungen genutzt werden, ist das nicht mehr so einfach. Intrusion Detection Systeme versuchen solche Angriffe und Muster zu erkennen und den Client auszusperren.
  • Auf dem Service
    Wen der Hersteller über eine Lücke informiert wird, kann er ein Update verteilen, welches dann die Firmen natürlich zügig installieren sollten. Das kann aber manchmal länger dauern und es gibt immer Firmen, die viel zu lange warten. Der Hersteller kann hier aber wenig Einfluss.
  • AV-Produkte
    Malware "versucht" etwas und hier kommen die klassischen Virenscanner ins Spiel, die eine bekante Malware nach einem Patternupdate erkennen und verhindern können. Früher haben die Produkte den Zugriff auf Dateiserver überprüft, mittlerweile werden auch Prozesse überwacht. Das Problem hier ist, das ein aktiver Eingriff des AV-Produkts durch eine Blockade oder Veränderung bei dem eigentlichen Service einen Fehler produziert und das Ergebnis und die Reaktion schwer vorhersehbar ist. Wird der Prozess abgeschossen oder der Zugriff uterbunden, dann stört dies die Funktion.

AMSI bindet sich nun unterhalb des Service ein und erwartet eine Mitarbeit vom Service, welcher eingehende Informationen vor der Verarbeitung erst einmal über die AMSI-Schnittstelle prüfen lässt. Dahinter steckt dann wieder ein Virenscanner wie Microsoft Defender oder 3rd Party Produkte.

Mit dem passenden Windows Betriebssystem und Virenscanner ist die Schnittstelle vorhanden. In der Regel sind Pattern-Updates für einen AV-Scanner viel schneller verteilt als ein Hotfix oder Update. Es geht also nicht darum, dass defekte Produkt zu patchen sondern den Missbrauch sehr früh zu erkennen und nicht erst, wenn die Malware sich auf der Festplatte verewigt. Es muss das Ziel sein, dass möglichst viele "Vordertüren" einen empfangenen Datensatz frühzeitig AMSI vorlegen, ehe Sie selbst die Daten weiter interpretieren und damit vielleicht kompromittiert werden.

Das gilt nicht nur für per HTTP an einen Webserver übergebe Daten sondern auch für JavaScript im Browser, VBA-Makros, PowerShell und VBScript. Ein Virenscanner kann hier also direkt den Sourecode bewerten anstatt dessen Verhalten zu analysieren oder ihn erst bei der Ablage auf dem Dateisystem zu erkennen.

Eigentlich warte ich nur drauf, dass jemand einen AMSI-Proxy baut, der auch Linux-Dienste um die Scan-Funktion erweitert.

AMSI und Exchange

Exchange ist eigentlich ein grundsolides Messagingsystem, welches Mails überträgt und Informationen in seinen Datenbanken ablegt. Natürlich kann Malware auch per Mail in ein System kommen und so gibt es auf dem SMTP-Transport einen Malwarescanner von Microsoft und Dritthersteller haben eigene Erweiterungen geschrieben.

Mit Exchange 2013 hat Microsoft aber die VSAPI-Schnittstelle entfernt, über welche Virenscanner auch Realtime-Scans auf der Datenband ausführen konnten. Damit konnte man die Elemente in einer Exchange Datenbank nur noch "geplant" scannen. Das gibt aber auch jahrelang gut.

Der große Weckruf kam aber im Frühjahr 2021 mit dem Hafnium Exploit, bei dem die Malware nicht per Mail sondern über die Webschnittstelle aufgespielt wurde. Der IIS hat per HTTP-Requests sich dazu verleiten lassen, derart übermittelten Code im Speicher auszuführen. Hier hatte Exchange keinen Schutz.

Zwar wurden die Lücken zügig gefixt und als Update bereitgestellt, aber die Administratoren haben sich oft länger Zeit gelassen. Vermutlich hat auch dieses Großereignis zusammen mit den weiteren Lücken der Pwn2Own 2021 dazu geführt, dass Microsoft auch über dieses Einfallstor einen verbesserten Schutz einbaut.

Am 11. Juni 2021 wurde auf dem Exchange Blog verkündet, dass die üblicherweise für den dritten Dienstag des Quartals angekündigten Updates verzögert werden. Anstatt wie geplant am 15. Juni 2021 sollen die CUs erst am 29. Juni 2021 veröffentlicht werden. Microsoft begründet dies mit dem Wunsch, erst noch die AMSI-Integration fertig zu stellen.

AMSI integration in Exchange Server provides the ability for an AMSI-capable antivirus/antimalware solution to scan content in HTTP requests sent to Exchange Server and block a malicious request before it is handled by Exchange Server. The scan is performed in real-time by any AMSI-capable antivirus/antimalware solution that runs on the Exchange server as the server begins to process the request. This provides automatic mitigation and protection which compliments the existing antimalware protection in Exchange Server to make your Exchange servers more secure than ever.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/news-about-the-june-2021-cumulative-update-for-exchange-server/ba-p/2437578

Sie können nun natürlich spekulieren, warum diese Erweiterung nun sogar die Verzögerung der Updates verursacht. Ist diese Funktion so wichtig, weil weitere Angriffe kurz bevorstehen? Vielleicht geht es aber auch einfach nur darum, über Windows Defender für die Zukunft dynamischer auf Angriffe und Schadsoftware reagieren zu können.

Die Funktion AMSI kommt aber nur ab Exchange 2016 und Exchange 2019 im dem Updates Juni 2021 und funktioniert nur ab Windows Server 2016 oder höher, da frühere Server Versionen keinen AMSI-Support haben.

Wer noch Exchange 2013 oder älter betreibt, profitiert davon genauso wenig wie Exchange 2016 Server auf Windows 2012 oder 2012R2.

Natürlich muss neben der AMSI-Schnittstelle auf dem Server auch Windows Defender oder anderer AMSI-kompatibles AV-Produkt installiert sein, sich zügig aktualisieren und der Lieferant der Patterns die neue Schadsoftware auch erkennen.

Dennoch ist es ein wichtiger und richtiger Schritt, per HTTP-Request eingelieferte Daten auch auf Schadcode zu prüfen. Mit dem Sysinternals Process Monitor können Sie beim W3PSRV z.B. bei Sophos sogar sehen, wenn AMSI eingebunden ist

Die AMSI-Integration finde nicht im STORE.EXE-Prozess statt, sondern direkt im IIS. Hier gibt es die beiden für die Client-Kommunikation bekannten Verzeichnisse "/MAPI" und "RPC", die als virtuelle Verzeichnisse auf folgende Pfade verweisen:

%exchangeinstallpath%\FrontEnd\HttpProxy\mapi
%exchangeinstallpath%\FrontEnd\HttpProxy\rpc

In den beiden Verzeichnissen gibt es eine WEB.CONFIG, über die der IIS parametrisiert wird. Hier ist ein HTTP-Filter konfiguriert, der die Anfragen AMSI vorwirft. (Zur Lesbarkeit umgebrochen)

<add name="HttpRequestFilteringModule" 
     type="Microsoft.Exchange.HttpRequestFiltering.HttpRequestFilteringModule, 
           Microsoft.Exchange.HttpRequestFiltering, 
           Version=15.0.0.0, Culture=neutral, 
           PublicKeyToken=31bf3856ad364e35"
/>

Wenn eine Malware über AMSI gefunden wird, dann meldet AMSI das an Exchange und Exchange protokolliert dies in einer "HttüRequestFiltering_*.log-Datei auf dem Exchange Server im Verzeichnis

C:\Program Files\Microsoft\Exchange Server \V15\Logging\HttpRequestFiltering

Oder wo auch immer sie ihren Exchange installiert haben.

In der Rege ist der Ordner leer, aber wenn das Http RequestFiltering etwas zu tun hatte, dann finden Sie hier den Eintrag. Interessant sind dabei dann die Werte aus dem Zeitpunkt (Timestamp), der angesprochenen URL und natürlich die Client-IP. Die Zeile enthält auch noch die Felder im Request und Namen der Cookies aber keine Inhalte und schon gar keinen Dump des kompletten Request für eine weitere Untersuchung. Das ist zum einen Schade um eine weitere Analyse zu unterstützen aber kann auch gut sein, denn in dem Request könne ja auch Anmeldeinformationen, Bearer-Tokens etc. enthalten sein. Vielleicht kann aber der AMSI-Service, welcher hoffentlich auch Alarm schlägt, hier weitere Informationen liefern.

AMSI Exchange Probleme

Auf der einen Seite ist der gute Gedanke, die schon länger vorhandene AMSI-Schnittstelle in Exchange einfach zu nutzen. Auf der anderen Seite stehen natürlich AV-Hersteller, die natürlich mit ihrer besseren Scanfunktion in Verbindung mit AMSI werben. Nun ist aber Exchange dann eines der ersten Produkte, die jetzt plötzlich AMSI sehr intensiv nutzen. Damit zeigt sich aber auch, welcher 3rd Party-Hersteller hier noch Verbesserungspotential hat. Anscheinend gibt es durchaus wieder die üblichen Anlaufprobleme mit neuen Schnittstellen und ich fühle mich in die Welt von SVAPI zurückversetzt, als die ersten "Store-Scanner" jede Mail bei einer Änderung in der Datenbank prüfen wollten. Diese Schnittstelle hat Microsoft hat ja dann mit Exchange 2013 eingestampft.

Das scheint sich nun mit AMSI zu wiederholen und zeigt sich nach Installation von CU21/CU10 durch Performance-Problemen bei Outlook und OWA und einer hohen CPU-Last auf dem Exchange Server. Weniger mit Windows Defender sondern eher mit nicht vorbereiteten 3rd Party Produkten. Daher kann es notwendig sein, bis zu einem Update durch den AV-Hersteller die AMSI-Integration in Exchange oder dem AV-Hersteller temporär zu deaktivieren.

Bei Problemen können sie temporär die Filterfunktion ausschalten. Prüfen Sie aber auch ihren Virenscanner, ob Sie vielleicht dort auch die AMSI-Konfiguration anpassen können oder das Problem durch ein Update gelöst werden könnte. Ansonsten beschreibt Microsoft dies selbst:

# AMSI Integration in Exchange deaktivieren

New-SettingOverride -Name "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

Zum Reaktivieren wird der "SettingOverride"-Eintrag einfach wieder gelöscht.

# AMSI reaktivieren

Remove-SettingOverride -Name "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

AMSI und Defender

Natürlich bindet auch Windows Defender die AMSI-Schnittstelle ein. Hier ein Beispiel, wo Defender meldet, dass ein Zugriff auf Exchange per HTTPS eine Payload enthalten hat, die über AMSI an Defender zur Prüfung gegeben und blockiert wurde. Auf dem Server selbst ist dies im Security Center zu sehen

Mit dem zentralisierten Plattform kann ich im Backend noch deutlich mehr sehen.

Die böse Payload wurde also schon bis zum IIS durch etwaige davor geschaltete Web Application Protection-Lösungen geroutet und dort nicht blockiert.

Basisschutz

Auf der Seite https://docs.microsoft.com/de-de/windows/win32/amsi/how-amsi-helps hat Microsoft ein schönes Schaubild veröffentlicht:

die AMSI-Architektur
Quelle: https://docs.microsoft.com/de-de/windows/win32/amsi/how-amsi-helps

Die AMSI-Schnittstelle steht auf folgenden Systemen bereit:

  • Microsoft Windows 10 Pro x64/x86
  • Microsoft Windows 10 Enterprise x64/x86
  • Microsoft Windows Server 2016

Ich hoffe natürlich, dass die Funktion auch die Home-Version von Windows 10 bekommt.

Allein mit der API ist es natürlich nicht getan. Die Anwendungsentwickler müssen ihre Software entsprechend erweitern, damit Sie Daten an AMSI zur Prüfung übermitteln. So könnten Office Applikationen decodierte Makros vor der eigentlichen Ausführung der AMSI-Schnittstelle vorlegen. Als Web-Entwickler könnte ich aber auch von Anwender hochgeladene Dateien oder Skripte in Echtzeit scannen. AMSI funktioniert also nicht ohne Mithilfe der Entwickler der Applikation, welche andere Programme oder Skripte ausführt.

PowerShell 2.0 nutzt meines Wissens noch nicht. Erst ab PowerShell 5 werden Skripte auch einem vorhandenen AMSI-Scanner zugeführt. WScript/CSript, JavaScript und Office VBA-Makro Interpreter legen Skripte auch AMSI vor.

Die große Änderung hierbei ist aber, dass der Code nicht erst auf eine Festplatte geschrieben werden muss, damit dieser dann von einem "Realtime-Scanner" überprüft und ggfls. der Zugriff verhindert wird, womit dann die Applikation vielleicht nicht umgehen kann. Die Applikation kann AMSi den unbekannten Datenstrom im Speicher vorlegen und bekommt eine aussagekräftige Meldung.

Auch die Unterseite von AMSI ist offen für Erweiterungen. AMSI funktioniert natürlich mit dem in Windows sowieso eingebauten "Windows Defender". Aber auch Drittprodukte können ihre Scan-Engine in AMSI so einbinden, dass AMSI diese Dienste nutzt.

Insofern ist es nur verständlich, dass die Hersteller hier zügig eine Verbindung geschaffen haben:

Weitere Links