Microsoft Threat Intelligence legt eine umfassende Analyse von Angriffen vor, die drei mit dem Betrieb von KI verbundene Umgebungen zum Ziel hatten: das LiteLLM-Gateway, die RAGFlow-Plattform zur Dokumentenverarbeitung und Retrieval-Augmented Generation sowie die Kestra-Umgebung zur Orchestrierung von Workflows. Trotz unterschiedlicher Angriffswege wiederholten sich die Ziele nahezu: der Diebstahl von Zugangsschlüsseln, die Einrichtung dauerhafter Zugriffsmöglichkeiten und der Zugriff auf Rechenressourcen zur Nutzung für das Schürfen von Kryptowährungen.
Die Bedeutung der drei Fälle liegt darin, dass die Angreifer diese Werkzeuge nicht lediglich als separate Anwendungen behandelten, sondern sie als Kontrollpunkte angriffen, an denen sich Zugangsdaten, Verbindungen zu Modellanbietern, Möglichkeiten zur Befehlsausführung und der Zugriff auf Datenbanken oder Container bündeln. Laut Microsoft macht dieser Fokus KI-Gateways sowie Management- und Orchestrierungsplattformen zu hochwertigen Zielen innerhalb von Unternehmensumgebungen.
Drei Angriffswege und ein einheitliches Ergebnismuster
Im Fall von LiteLLM geht Microsoft mit hoher Zuversicht davon aus, dass der initiale Zugriff durch die Ausnutzung einer exponierten Gateway-Schnittstelle erfolgte. Der Beitrag verweist auf öffentliche Schwachstellenpfade, darunter CVE-2026-42271, die mit authentifizierter Befehlsausführung an LiteLLM-MCP-stdio-Testendpunkten verbunden ist, sowie auf einen Forschungsweg, der sie mit CVE-2026-48710 verknüpft, einer Schwachstelle zur Umgehung der Host-Header-Validierung in Starlette. Diese Verbindung kann in betroffenen Konfigurationen dazu führen, dass die Remote-Befehlsausführung ohne gültige Zugangsdaten möglich wird.
Nach dem Einbruch las die Schadsoftware die Umgebung des Hauptprozesses innerhalb des Containers, darunter /proc/1/environ, auf der Suche nach Schlüsseln von Modellanbietern, dem LiteLLM-Hauptschlüssel, Datenbankverbindungszeichenfolgen, Passwörtern und Tokens. Anschließend wurden ausführbare Dateien heruntergeladen, die als Linux-Dienste getarnt waren; außerdem wurden Host, Ports und Prozesse untersucht sowie das Schürfen mithilfe von XMRig oder RandomX vorbereitet. Die PostgreSQL-Verbindungszeichenfolge wurde ebenfalls verwendet, um auf LiteLLM-Tabellen zuzugreifen, die Modelleinstellungen, Anbieter-Schlüssel und vom Proxy ausgegebene virtuelle Schlüssel enthalten können. Zu den Persistenzmechanismen gehörten die Änderung der Datei authorized_keys für ein Dienstkonto, die Änderung von Cron-Aufgaben sowie die Verwendung versteckter Dateien und getarnter Dienstnamen.
Bei RAGFlow konzentrierte sich die beobachtete Aktivität auf das Abfangen von Zugangsdaten für Sprachmodelle, die Mandanten hinzufügen oder ändern. Microsoft beobachtete zunächst ein SSRF-ähnliches Verhalten, anschließend die Ausführung von Befehlen im Kontext eines Flask-Dienstes und eine Änderung des Anwendungsstartpfads zum Laden eines versteckten Hooks. Der Hook erfasste den Anbietertyp, den Modellnamen, den API-Schlüsselinhalt und Endpunktdaten und übermittelte sie nach außen. Der Beitrag betont, dass Microsoft die Schwachstelle, die die Ausführung verursachte, nicht mit hoher Zuversicht bestimmen kann; CVE-2026-45312, CVE-2026-28797, CVE-2026-24770 und CVE-2025-68700 werden als möglicher technischer Kontext genannt, nicht als bestätigte Ursache dieses Falls.
Bei Kestra geht Microsoft mit hoher Zuversicht davon aus, dass die Ausnutzung mit der kritischen Schwachstelle CVE-2026-49869 verbunden war, die eine Umgehung der Authentifizierung, die Definition eines schädlichen Workflows unter Verwendung des Process Runners und anschließend die Ausführung von Shell-Befehlen auf dem Worker ermöglichen kann. Dieser Weg wurde genutzt, um auf einen Docker-Socket zuzugreifen, die Containerumgebung zu untersuchen, einen Mining-Worker bereitzustellen und Prozesse zur Verschleierung von Dateien auszuführen. Später wurden Workflows außerdem verwendet, um entfernte Skripte abzurufen und direkt auszuführen und anschließend die verschlüsselte Ausgabe über die Key-Value-Schnittstelle von Kestra zu speichern.
Was ändert sich praktisch für Verteidigungsteams?
Die wichtigste Schlussfolgerung lautet, dass die Risikobewertung von der Funktion der KI-Umgebung innerhalb des Unternehmens ausgehen muss. Ein Gateway kann ein Speicher für Schlüssel von Modellanbietern und eine Datenbank für virtuelle Schlüssel sein, während eine RAG-Plattform Mandanteneinstellungen enthalten kann und eine Workflow-Engine möglicherweise über Berechtigungen zur Befehlsausführung und zur Interaktion mit externen Diensten verfügt. Daher reicht es nicht aus, Erkennungsindikatoren für jedes Produkt isoliert anzuwenden.
Microsoft empfiehlt, KI-Gateways als Secrets-Speicher der höchsten Schutzklasse zu behandeln, LiteLLM und ähnliche Werkzeuge zu aktualisieren, die Authentifizierung für API- und Administrationsschnittstellen zu erzwingen, Administrationsports zu beschränken und sie nicht direkt dem Internet auszusetzen. Außerdem empfiehlt Microsoft, separate virtuelle Schlüssel für jedes Team mit Ausgabenlimits zu verwenden, die Schlüssel der Anbieter in einem verwalteten Secrets-Speicher statt in Prozessumgebungsvariablen abzulegen und möglicherweise offengelegte Schlüssel zu rotieren.
Zu den weiteren Kontrollen gehören die Anwendung des Prinzips der geringsten Privilegien auf Gateway und Datenbank, die Platzierung der Datenbank hinter einem privaten Endpunkt und einer restriktiven Firewall sowie die Durchsetzung von Netzwerk-Egress-Regeln, die Verbindungen standardmäßig ablehnen und nur erforderliche Endpunkte zulassen. Der Zugriff auf /proc/1/environ, das Starten von Shells, Python oder Download-Tools aus einem Gateway-Prozess, Änderungen an Cron- oder SSH-Dateien, die Verwendung eines Docker-Sockets sowie die Ausführung aus temporären, beschreibbaren Pfaden sollten überwacht werden.
Grenzen der Schlussfolgerungen und Prüfungsfragen
Die drei Fälle belegen nicht, dass jede Bereitstellung von LiteLLM, RAGFlow oder Kestra auf dieselbe Weise gefährdet ist; außerdem unterscheidet Microsoft klar zwischen bestätigten Schwachstellen in einigen Pfaden und möglichen Schwachstellen im Fall von RAGFlow. Ebenso stellt das Vorhandensein von Merkmalen in einigen Schadsoftwarekomponenten, die auf die Verwendung von Hilfs- oder generativen Werkzeugen hindeuten, keinen Beleg für deren Quelle oder die Identität ihrer Entwickler dar. Daher sollten diese Ergebnisse zum Aufbau von Erkennungshypothesen und zur Überprüfung von Konfigurationen genutzt werden, nicht zur Zuordnung eines Angriffs zu einer bestimmten Gruppe.
Microsoft stellt Advanced-Hunting-Abfragen bereit, um Verhaltensketten zu erkennen, etwa wenn das Gateway Interpreter oder Download-Tools startet, Umgebungsvariablen des Hauptprozesses liest, auf LiteLLM-Tabellen zugreift, versucht, ein MSR-Modul mit aktivierter Schreibfunktion zu laden, oder SSH-Schlüssel beziehungsweise Cron ändert. Der praktische Wert dieser Abfragen zeigt sich, wenn sie in einer einzigen Zeitleiste miteinander verknüpft werden: Ein einzelner Shell-Prozess kann administrativ bedingt sein, doch seine Kombination mit dem Lesen von Geheimnissen, einer externen Verbindung und der Ausführung einer Datei aus einem temporären Pfad erhöht den Verdachtsgrad erheblich.