Du vertraust einem Sicherheitsdienst, der dein Haus bewachen soll. Du gibst ihm die Schlüssel. Er soll nach Einbrechern Ausschau halten. Doch der Dienst entpuppt sich als Schläfer und öffnet den Einbrechern selbst die Tür. So funktioniert die Technik, die wir besprechen: Die Antimalware Scan Interface (AMSI) von Microsoft ist ein neutraler Vermittler zwischen Skript-ausführenden Anwendungen wie PowerShell und den installierten Antiviren- oder EDR-Lösungen. Sie soll bösartige Inhalte abfangen, bevor sie ausgeführt werden. Die Architektur hat eine unbeabsichtigte Schwachstelle: Drittanbieter können eigene AMSI-Provider registrieren. Hat ein Angreifer erst Administratorrechte auf einem System, manipuliert er diese Funktion und installiert einen fingierten Provider. Bei jedem Aufruf von PowerShell – oder jeder anderen AMSI-fähigen Anwendung – löst er eine eigene Aktion aus. Das ist keine theoretische Gefahr. Ein öffentlich verfügbarer Proof-of-Code zeigt, wie es funktioniert. Der Angreifer registriert eine DLL mit einer speziellen Scan()-Methode. Bei bestimmten Schlüsselwörtern (einem Trigger) führt sie beliebigen Code aus – etwa eine Verbindung zu einem Command-and-Control-Server. Das geschieht im Hintergrund, der Benutzer bekommt nichts mit. Warum ist das gefährlich? AMSI-Provider gelten als legitimer Mechanismus. Sicherheitsteams achten auf verdächtige Prozesse, Netzwerkverbindungen oder Dateien – weniger darauf, wer als AMSI-Provider registriert ist. Genau diese Lücke nutzen Angreifer. Sie verstecken sich im Vertrauensraum des Betriebssystems. Ihr Code wird bei jeder PowerShell-Sitzung erneut ausgeführt. Das ist Persistence auf einem kompromittierten System: Der Angreifer muss Administratorrechte nicht jedes Mal neu erlangen – sein Provider sorgt dafür, dass er bei jeder Interaktion mit PowerShell eine Hintertür offen hat.
Wie funktioniert die Antimalware Scan Interface? Microsoft hat AMSI mit Windows 10 eingeführt. Es schließt die Lücke zwischen Skript-Engines wie PowerShell, VBScript oder JScript und den Sicherheitsprodukten. Vorher musste jedes Sicherheitstool selbst in die Prozesse hineinreichen, um Skriptinhalte zu lesen – aufwändig und oft umgangen. AMSI bietet eine standardisierte Schnittstelle: Eine Anwendung wie PowerShell sendet den auszuführenden Code an AMSI, und AMSI leitet ihn an den registrierten Antimalware-Provider weiter. Der Provider untersucht den Inhalt und gibt eine Bewertung zurück: sauber, verdächtig oder bösartig. Erst dann entscheidet die Anwendung, ob sie den Code ausführt. Das Design ist herstellerneutral – jeder Sicherheitsanbieter kann einen eigenen Provider registrieren. Microsoft selbst veröffentlichte ein Codebeispiel, um Entwicklern die Implementierung zu erleichtern. Diese Offenheit ist der Hebel für Angreifer. Sie schreiben einen Provider, der nicht auf Malware scannt, sondern auf einen Trigger lauscht. Der Provider wird wie jede andere COM-Komponente registriert, über die Registry unter HKLM\SOFTWARE\Microsoft\AMSI\Providers. Ist er erst eingetragen, wird er bei jeder AMSI-Instanziierung geladen – typischerweise, wenn eine PowerShell-Konsole geöffnet wird. Der Code des fingierten Providers ist simpel: Die Scan()-Methode prüft, ob der übergebene Inhalt einen festgelegten String enthält. Trifft das zu, startet sie einen neuen Thread, der die eigentliche Schadaktion ausführt – etwa einen Reverse Shell startet. Die Ausführung erfolgt mit den Privilegien des PowerShell-Prozesses, also im Kontext des aktuellen Benutzers. Wenn der Benutzer Administrator ist, hat auch der Schadcode volle Kontrolle.
Die konkrete Umsetzung dieser Technik ist einfach. Der Proof-of-Code von Pentestlab zeigt eine DLL, die als COM-Komponente die IAmsiProvider-Schnittstelle implementiert. Der Kern liegt in der Scan()-Methode: Sie vergleicht den übergebenen Inhalt mit einem oder mehreren Trigger-Strings (im Beispiel ipurple.team). Stimmt der String überein, ruft sie CreateThread auf und startet eine Funktion, die die Windows-Rechner-App (calc.exe) oder eine andere ausführbare Datei startet. Die Registrierung erfolgt mit regsvr32.exe, dem Standardwerkzeug für COM-Komponenten. Der Befehl regsvr32 AmsiProvider.dll trägt die notwendigen Schlüssel in die Registry ein – sowohl den Provider unter dem AMSI-Pfad als auch die CLSID unter HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. Nach der Registrierung reicht es, in PowerShell "ipurple.team" einzugeben, um die Payload auszulösen. Die Ausführung erfolgt im selben PowerShell-Prozess. Das bedeutet auch, dass die DLL in diesen Prozess geladen wird – ein Hinweis, den Sicherheitsteams erfassen können. Der Code zeigt auch eine Deinstallationsroutine (DllUnregisterServer), die die Registry-Einträge wieder entfernt. Der Angreifer kann so Spuren verwischen. Für die Registrierung ist Administratorenzugriff erforderlich, denn der Registry-Pfad liegt unter HKEY_LOCAL_MACHINE. Hat der Angreifer diese Rechte bereits, ist die Technik sehr effektiv, weil sie sich als legitime Systemkomponente tarnt.
Wie erkennt man einen gefälschten AMSI-Provider? Der naheliegendste Ansatz: Überwachung des Registry-Schlüssels HKLM\SOFTWARE\Microsoft\AMSI\Providers. Jeder neu hinzugefügte Unterschlüssel – eine GUID – sollte verdächtig sein, sofern er nicht von einem autorisierten Sicherheitsanbieter stammt. Unternehmen sollten dort per Gruppenrichtlinie ein Überwachungs-Audit einrichten, insbesondere für Set Value, Create Subkey und Query Value. Die Registrierung löst Windows-Ereignis 4663 aus (Versuch, auf ein Registry-Objekt zuzugreifen). Da auch die Installation legitimer Provider solche Ereignisse erzeugt, muss man die Ereignisse mit einer Liste vertrauenswürdiger Quellen abgleichen. Eine zweite Erkennungsmöglichkeit: Überwachung von DLL-Ladungen in PowerShell-Prozesse. Der gefälschte Provider wird als DLL (z. B. AmsiProvider.dll) in den PowerShell-Prozess geladen. Mit Sysmon können Sie Ereignis-ID 7 (Image geladen) nutzen, um unsignierte DLLs in PowerShell zu erkennen. Das produziert viele False Positives, weil auch nicht signierte .NET Native Images geladen werden. Sie können diese Quelle ausschließen, aber ein schlauer Angreifer könnte seine Schad-DLL genau in diesen Pfad legen. Deshalb prüfen Sie zusätzlich den Prozessbaum: Ein PowerShell-Prozess, der einen ungewöhnlichen Kindprozess startet (etwa cmd.exe oder einen unbekannten Executable), ist ein starkes Alarmsignal. Es gibt ein minimales Tool namens AmsiProviderMonitor.exe, das alle drei Minuten den AMSI-Provider-Registry-Zweig auf neue Einträge prüft und bei unsignierten DLLs in verdächtigen Pfaden Alarm schlägt. Das ist ein guter Ausgangspunkt für die Eigenentwicklung.
Die Hürde für den Angreifer ist nicht niedrig – er braucht lokale Administratorrechte, um den Provider zu registrieren. Hat er diese, ist die Technik äußerst effektiv. Sie missbraucht das Vertrauen in AMSI und verursacht kaum verdächtige Netzwerkaktivitäten. Microsoft hat mit Windows 10 Version 1903 eine Signaturprüfung für AMSI-Provider eingeführt: Ab diesem Update kann das Betriebssystem verlangen, dass Provider-DLLs signiert sein müssen. Standardmäßig ist diese Prüfung nicht aktiviert. Sie müssen sie über eine Gruppenrichtlinie (Turn on AMSI Provider signing check) einschalten. Das ist die effektivste Maßnahme: Aktivieren Sie die Signaturprüfung, dann werden nur noch DLLs mit einer gültigen digitalen Signatur als Provider zugelassen. Der Angreifer müsste dann entweder eine gültige Signatur besorgen (teuer und aufwändig) oder auf andere Persistence-Techniken ausweichen. In Kombination mit Registry-Überwachung und DLL-Ladungsprüfung schaffen Sie eine mehrschichtige Verteidigung.
Für den Alltag bedeutet das: AMSI ist keine Blackbox, der wir blind vertrauen. Die Schnittstelle ist ein mächtiges Werkzeug – aber auch gegen uns einsetzbar. Die Technik ist nicht weit verbreitet, aber der öffentliche Code senkt die Eintrittsschwelle. Unternehmen, die PowerShell intensiv nutzen (und das tun heute die meisten), sollten die Registry und Prozessabläufe überwachen. Wenn Sie die Signaturprüfung aktivieren, eliminieren Sie die Gefahr fast vollständig – solange der Angreifer keine signierte DLL beschaffen kann. Die Registry-Überwachung bleibt als zweite Ebene. Viele Organisationen haben die Signaturprüfung nicht aktiviert, oft aus Unwissenheit oder Sorge vor Kompatibilitätsproblemen. In einer Umgebung, in der Sie die installierten Sicherheitsprodukte kennen, sollte die Aktivierung kein Problem sein. Fangen Sie klein an: Überwachen Sie mit SIEM oder Sysmon die Registry-Änderungen unter HKLM\SOFTWARE\Microsoft\AMSI\Providers. Prüfen Sie bei jedem Vorfall, ob der registrierte Provider bekannt und signiert ist. Das ist ein praktischer Schritt, den Sie noch heute umsetzen können.
Quelle: ipurple.team
