Cyberbedrohungen
KI-Gateway war eine Hintertür
TeamPCP orchestrierte eine der raffiniertesten, öffentlich dokumentierten Supply Chain-Kampagnen gegen mehrere Ökosysteme. Die Kompromittierung von LiteLLM ist eine Fallstudie dazu, warum KI-Infrastrukturen zum nächsten bevorzugten Ziel in der Lieferkette werden können.
Save to Folio
Wichtige Erkenntnisse
- LiteLLM wurde auf PyPI kompromittiert, wobei zwei seiner Versionen bösartigen Code enthielten. Diese Versionen setzten eine dreistufige Payload ein.
- Sensible Daten von Cloud-Plattformen, SSH-Schlüssel und Kubernetes-Cluster wurden ins Visier genommen und vor der Exfiltration verschlüsselt.
- Der LiteLLM-Vorfall war Teil einer umfassenderen Kampagne der kriminellen Gruppe TeamPCP. Die Gang hatte zuvor bereits Sicherheitswerkzeuge wie Trivy und Checkmarx KICS kompromittiert, um Anmeldedaten zu stehlen und bösartige Payloads zu verbreiten.
Am 24. März begannen Produktionssysteme, auf denen LiteLLM lief, auszufallen, und die Verantwortlichen beobachteten außer Kontrolle geratene Prozesse, eine CPU-Auslastung von 100 % sowie Container, die durch Out-of-Memory-Fehler (OOM) beendet wurden. Die Stack-Traces deuteten darauf hin, dass das LiteLLM-Paket – ein beliebtes Python-Paket, das täglich 3,4 Millionen Mal heruntergeladen wird und als einheitliches Gateway zu mehreren LLM-Anbietern dient – auf PyPI kompromittiert worden war. Bei der Analyse stellte sich heraus, dass die Versionen 1.82.7 und 1.82.8 bösartigen Code enthielten, der Cloud-Anmeldedaten, SSH-Schlüssel und Kubernetes-Geheimnisse stahl.
Die bösartigen Versionen setzten eine dreistufige Payload ein: einen Credential Harvester, der auf über 50 Kategorien von Geheimnissen abzielte, ein Kubernetes-Toolkit für die laterale Bewegung, das ganze Cluster kompromittieren konnte, und eine persistente Backdoor, die eine fortlaufende Remote-Code-Ausführung ermöglichte.
Der Angriff war kein Einzelfall. Er war das jüngste Glied in einer Kette kaskadierender Supply Chain-Kampagnen der Gruppe TeamPCP. Die Kampagne umfasste PyPI, npm, Docker Hub, GitHub Actions und OpenVSX in einer einzigen koordinierten Operation. Obwohl sie nicht speziell auf KI-Infrastrukturen abzielte, geriet LiteLLM über Entwickler-Tools in deren Wirkungsbereich und zeigt, wie KI-Proxy-Dienste, die API-Schlüssel und Cloud-Anmeldedaten auf sich konzentrieren, zu Kollateralschaden geraten, wenn Supply Chain-Angriffe vorgelagerte Abhängigkeiten kompromittieren.
Sicherheitsscanner wird zum Angriffsvektor
Trivy, ein von Aqua Security entwickelter Open-Source-Schwachstellenscanner, durchforstet Container-Images, Dateisysteme und Infrastructure-as-Code auf Sicherheitslücken und ist über die GitHub-Action „trivy-action“ in die CI/CD-Pipelines von Tausenden von Softwareprojekten integriert.
Sicherheitsscanner sind besonders gefährliche Ziele in der Lieferkette. Aufgrund ihres Designs benötigen sie umfassenden Lesezugriff auf die von ihnen gescannten Umgebungen, einschließlich Umgebungsvariablen, Konfigurationsdateien und Runner-Speicher. Wenn ein Scanner kompromittiert wird, wird er zu einer Plattform zum Sammeln von Anmeldedaten mit legitimem Zugriff auf Geheimnisse.
Ende Februar 2026 nutzte ein Akteur einen falsch konfigurierten Workflow in Trivys CI aus, um das persönliche Zugriffs-Token (Personal Access Token) von „aqua-bot“ zu exfiltrieren. Aqua Security gab den Vorfall am 1. März bekannt und leitete eine Rotation der Anmeldedaten ein. Laut Aquas eigener Analyse nach dem Vorfall „könnten Angreifer Kenntnis von den aktualisierten Tokens erlangt haben“.
Diese Lücke erwies sich als entscheidend. TeamPCP nutzte noch gültige Anmeldedaten, um 76 von 77 Release-Tags im trivy-action-Repository und alle sieben Tags in setup-trivy zwangsweise in bösartige Commits zu übertragen, die einen mehrstufigen Credential-Stealer enthielten. Der Schadcode sammelte Cloud-Anmeldedaten und SSH-Schlüssel aus dem Dateisystem, verschlüsselte das Bundle und exfiltrierte es. Laut einer Analyse von CrowdStrike lief der legitime Trivy-Scan danach weiterhin und erzeugte normale Ausgaben – ohne sichtbare Anzeichen für eine Kompromittierung.
Ein Sicherheitsscanner wurde zum Einstiegspunkt für eine Kompromittierung der Lieferkette. Die Kompromittierung von Trivy in GitHub Actions verschaffte dem Angreifer die Schlüssel, um beliebige Versionen von LiteLLM auf PyPI zu veröffentlichen. Alles, was folgte, war die Ausnutzung dieses anfänglichen Stützpunkts.
Die Erkenntnis ist entscheidend: Ihre CI/CD-Sicherheitstools haben denselben Zugriff wie Ihre Deployment-Tools. Weeswn sie kompromittiert, ist alles nachgelagerte System gefährdet.
Der Angriff begann mit einem primitiveren Ansatz, und die rasche Iteration zeugt von der operativen Raffinesse des Angreifers. Zwei Versionen mit zwei Vektoren: Version 1.82.7 (10:39 UTC), Version 1.82.8 (10:52 UTC, 13 Minuten später). Diese 13-minütige Iteration, von einer Injection auf Funktionsebene bis hin zur Persistenz auf Interpreter-Ebene, zeigt einen Angreifer, der das Ausführungsmodell von Python tiefgreifend verstanden und seinen Auslieferungsmechanismus unter operativem Druck angepasst hat. Die Einzelheiten dazu liefert der Originalbeitrag.
Payload
LiteLLM fungiert als Vermittler zwischen Anwendungscode und Modellanbietern wie OpenAI, Anthropic, Azure AI und Dutzenden anderen, wobei es LLM-API-Aufrufe weiterleitet, den Datenverkehr ausbalanciert und protokolliert. Version 1.82.8 enthielt eine Überraschung: eine große Datei namens LiteLLM_init.pth, die im Hintergrund alle gefundenen Geheimnisse an einen vom Angreifer kontrollierten Server exfiltrierte.
Ein Fehler in der Payload, eine Fork-Bombe, die außer Kontrolle geratene Prozesse erzeugte, war der Auslöser für die Analyse. Ohne diesen Fehler hätte der Credential-Stealer tagelang oder wochenlang unbemerkt laufen können, bevor er entdeckt worden wäre.
Laut der Sicherheitsanalyse von FutureSearch hatte ein Angreifer die Konten der Betreuer des litellm-Projekts gekapert. Er umging die standardmäßigen GitHub-Release-Protokolle und pushte kompromittierte Versionen direkt auf PyPI. Da litellm zwischen Entwicklern und fast jedem wichtigen LLM-Endpunkt angesiedelt ist, wird es von allem – von einfachen Skripten bis hin zu fortgeschrittenen Codierungsagenten – als Abhängigkeit einbezogen.
Die Open-Source-Community organisierte sich rasch, und die schnellen Abwehrmaßnahmen begrenzten wahrscheinlich die tatsächlichen Auswirkungen der Exfiltration von Anmeldedaten.
Beide kompromittierten Versionen nutzen zwei vom Angreifer kontrollierte Domains, die unterschiedlichen Zwecken dienen: der Verschlüsselung der gestohlenen Anmeldedaten und der Exfiltrierung an eine Domain, die nur einen Tag vor dem Angriff registriert wurde. PyPI stellte beide Versionen etwa drei Stunden nach der Veröffentlichung unter Quarantäne.
Architektur und Funktionsweise des LiteLLM-Angriffs
Die Malware ist als dreischichtiges, Base64-kodiertes Python-Skript aufgebaut. Jede Schicht wird zur Laufzeit dekodiert und ausgeführt, wodurch eine Kette von Payloads im Arbeitsspeicher entsteht, die als eigenständige Dateien niemals die Festplatte berühren.
Der PyPI-Kanal war der Vektor mit der größten Auswirkung: Paketinstallation, automatische Aktivierung, Umgebungsprüfung, Erfassung von Anmeldedaten, Verschlüsselte Exfiltration sowie Erzeugung von Persistenz. Alle technischen Einzelheiten zum Ablauf siehe Originalbeitrag.
Wer ist TeamPCP?
Die Zuordnung zu Tätergruppen bei Supply-Chain-Kampagnen ist von Natur aus schwierig, denn gemeinsam genutzte Tools, gemeinsame Infrastruktur und absichtliche False Flags sind weit verbreitet. Diese Gruppe von Angreifern agiert unter verschiedenen Pseudonymen, darunter TeamPCP, Shellforce, PersyPCP und @pcpcats auf X, und unterhält eine breite und koordinierte Online-Präsenz. Sie nutzt mehrere Telegram-Kanäle und eine Onion-Website, um ihre Exploits zu veröffentlichen und für ihre Opfer zu werben. Über diese Plattformen stellen sie Details zu kompromittierten Unternehmen bereit und bieten Kontaktinformationen für Verhandlungszwecke an.
Wir haben ein formales ACH-Framework (Analysis of Competing Hypotheses) auf drei Attributionskandidaten angewendet. Verschiedene Hinweise deuten insgesamt auf einen Betreiber oder ein kleines Team hin, das sich in der westlichen Kultur und der Internetkultur auskennt, und nicht auf einen Stellvertreter eines Nationalstaates. Der Entwicklungsverlauf der Tools lässt ein kleines, motiviertes Entwicklerteam mit Hintergrund in der Sicherheitsforschung vermuten, nicht eine groß angelegte kriminelle Operation.
Die Konzentration auf den an Zugangsdaten reichen kommerziellen Sektor, auf Jobplattformen mit PII-Datenbanken, auf Fintech mit integrierten Zahlungsabwicklern sowie auf POD-Anbieter mit Zugriff auf Händlerkonten passt zu einem kriminellen Monetarisierungsmodell, das sich auf den Weiterverkauf von Zugangsdaten und die Vermittlung von Zugriffsrechten konzentriert. Die Opferauswahl ist opportunistisch, nicht strategisch. Der Akteur hat das kompromittiert, was verwundbar war, nicht das, was für einen staatlichen Geheimdienst von Wert war. Unser systematischer Vergleich der öffentlichen Berichterstattung mit unseren Analyseergebnissen deckte auch erhebliche Lücken auf. (siehe Originalbeitrag).
Fazit
Die Kompromittierung von LiteLLM ist eine Fallstudie dazu, warum KI-Infrastrukturen zum nächsten bevorzugten Ziel in der Lieferkette werden können. Alle reden über fortgeschrittene KI-Schwachstellen, doch Angreifer nutzen genau dieselben Infrastrukturschwachstellen aus, gegen die wir seit einem Jahrzehnt kämpfen.
Der KI-Technologie-Stack basiert auf standardmäßigen, anfälligen Open-Source-Grundlagen. Angreifer zielen immer auf das zentrale, schwächste Glied ab. Dieser Vorfall deckt die Risiken von unkontrollierten Updates aus öffentlichen Quellen auf sowie die Schwachstelle, die durch mangelnde Vorsicht und Überwachung bei übereilten Patches entstehen kann. Eine CI/CD-Pipeline, die automatisch die neueste Version ohne Quarantänezeit abruft, schafft eine Schwachstelle für sich selbst.
LiteLLM nimmt eine privilegierte Position im AI/ML-Stack ein; es verwaltet API-Schlüssel für jeden Modellanbieter, für den es als Proxy fungiert. Im Proxy-Bereitstellungsmodell führt eine Kompromittierung nicht nur zum Verlust von Standard-Cloud-Anmeldedaten, sondern gleichzeitig auch von LLM-API-Schlüsseln für OpenAI, Anthropic, Azure AI und anderen.
Das Risikoprofil bei der Nutzung von SDKs/Bibliotheken, wo LiteLLM mit Anmeldedaten pro Anfrage aufgerufen wird und die Speicherung der Schlüssel nicht zentralisiert, unterscheidet sich von dem Proxy-Bereitstellungsmodell, das den primären Anwendungsfall von LiteLLM in der Produktion darstellt. Letzteres birgt das größere Schadenspotenzial.
Gestohlene LLM-API-Schlüssel verschaffen Angreifern:
- Kostenlose Rechenleistung für ihre eigenen Operationen (API-Schlüssel großer Anbieter können monatliche Rechenkosten in Höhe von Tausenden von Dollar verursachen)
- Zugriff auf Konversationsverläufe bei einigen Anbietern
- Die Möglichkeit, Antworten in kundenorientierte KI-Produkte einzuschleusen
Warum KI-Infrastrukturen besonders gefährdet sind
Transitive Abhängigkeitstiefe. KI-/ML-Projekte weisen außergewöhnlich tiefe Abhängigkeitsbäume auf.
Das rasante Wachstum des Ökosystems überholt die Sicherheitsreife. Der Druck, KI-Funktionen auf den Markt zu bringen, treibt die schnelle Einführung von schlecht geprüften Paketen voran. Die LLM Top 10 von OWASP listet LLM03 (Schwachstellen in der Lieferkette) als eines der größten Risiken auf.
Sicherheitstools als Angriffsfläche. Die Tools, die Verteidiger zur Sicherung der KI-Infrastruktur einsetzen, können zum Einstiegspunkt werden.
Es ist wichtig, zwischen den Fähigkeiten der Payload und den bestätigten Auswirkungen zu unterscheiden: Der Originalbeitrag umfasst eine Übersichtstabelle zum Thema.
Die Tools, die Entwickler zur Interaktion mit KI-Systemen, Proxy-Gateways, Modell-Routern, Experiment-Trackern und Inferenzservern installieren, verarbeiten von Natur aus hochsensible Geheimnisse. Supply-Chain-Angriffe auf diese Tools nutzen das Vertrauen und die Zugriffsrechte der KI-Infrastruktur selbst aus.
Sicherheitsempfehlungen
Wenn Sie LiteLLM irgendwo in Ihrem Stack einsetzen, und versuchen Sie, den Angreifern einen Schritt voraus zu sein. Sofortmaßnahmen
- Ist in einem Python-Site-Packages-Verzeichnis LiteLLM_init.pth vorhanden, gehen Sie von einer vollständigen Kompromittierung der Anmeldedaten aus.
- Ändern Sie ALLE Anmeldedaten, die als Umgebungsvariablen oder in Konfigurationsdateien auf Systemen vorhanden waren, auf denen LiteLLM 1.82.7 oder 1.82.8 installiert war, einschließlich CI/CD-Runner.
- Blockieren Sie Folgendes auf DNS- und Firewall-Ebene: checkmarx[.]zone, LiteLLM[.]cloud, models.LiteLLM.cloud, 83.142.209.11, 46.151.182.203.
- Überprüfen Sie npm-Pakete auf Verweise auf checkmarx-util oder Postinstall-Hooks, die GITHUB_ACTIONS auslesen.
- Integrieren Sie Trivy und alle Sicherheitsscanner in Ihre CI/CD-Pipeline.
Strukturelle Abwehrmaßnahmen
- Setzen Sie „npm install --ignore-scripts“ in CI/CD-Pipelines durch, es sei denn, Postinstall-Skripte werden explizit überprüft.
- Achten Sie auf die unerwartete Erstellung von „.pth“-Dateien in Python-Site-Paketen; jedes Schreiben in eine .pth-Datei außerhalb einer als sicher bekannten Baseline sollte einen kritischen Alarm auslösen.
- Fixieren Sie Paketversionen und überprüfen Sie SHA256-Hashes. Erstellen und setzen Sie Software-Stücklisten (SBOMs) für alle Produktionsbereitstellungen durch.
- Setzen Sie eine stabile und bewährte Version durch, anstatt auf die neueste Version umzusteigen, die möglicherweise noch nicht getestet wurde.
- Setzen Sie Verhaltenserkennung für das massenhafte Auslesen von Anmeldedaten ein, anstatt sich auf signaturbasierte Antivirenprogramme zu verlassen.
- Implementieren Sie JARM-Fingerabdruck-Überwachung für TLS-Verbindungen, um Hosting-ASNs abzusichern.
- Prüfen Sie transitive Abhängigkeiten. Möglicherweise verwenden Sie LiteLLM nicht direkt, sondern beziehen es über DSPy, CrewAI oder andere Frameworks.
- Implementieren Sie Egress-Filterung.
- Achten Sie auf Fork-Bombs/Ressourcenerschöpfung als potenziellen Indikator für eine Kompromittierung der Lieferkette – so wurde der LiteLLM-Angriff erstmals bemerkt.
Im Originalbeitrag finden Sie auch eine Tabelle der MITRE ATT&CK-Zuordnung.
Diese Analyse wurde vom ZDI Threat Hunting-Team durchgeführt. Den vollständigen technischen Bericht mit allen IOC-Tabellen, Infrastrukturdiagrammen, MITRE ATT&CK-Zuordnungen und Snort/Suricata-Regeln erhalten Sie direkt beim Team.