LiteLLM auf PyPI von TeamPCP angegriffen: Ein genauer Blick auf die Malware-Kampagne zum Diebstahl von Zugangsdaten

Startseite » Python » LiteLLM auf PyPI von TeamPCP angegriffen: Ein genauer Blick auf die Malware-Kampagne zum Diebstahl von Zugangsdaten

Am 24. März 2026 verwandelte sich ein äußerst beliebtes Python-Paket für einige Stunden unbemerkt in einen mächtigen Anmeldeinformationsdieb. Zwei manipulierte Versionen von LiteLLM, einer weit verbreiteten Bibliothek, die als … verwendet wird, … einheitliche Schnittstelle zu großen Sprachmodellen (LLMs)wurden auf PyPI hochgeladen, wodurch kurzzeitig eine große Anzahl von Systemen einem ausgeklügelten Lieferkettenangriff ausgesetzt war.

Die bösartigen Versionen, 1.82.7 und 1.82.8 zur VerfügungDie Schadsoftware enthielt eine mehrstufige Payload, die in der Lage war, Geheimnisse von Entwicklerrechnern, CI/CD-Systemen, Cloud-Infrastrukturen und Kubernetes-Clustern abzugreifen und diese anschließend auf vom Angreifer kontrollierte Server zu exfiltrieren. Die Kampagne wurde durchgeführt. mit der Bedrohungsgruppe TeamPCP verbunden, das seit Monaten Trivy, Checkmarx-Tools und Docker-Images angreift, Angriffe auf die npm-Lieferkette und nun zum PyPI-Ökosystem.

Was ist LiteLLM und warum war es ein so wichtiges Ziel?

LiteLLM ist ein Open-Source-Python-Bibliothek und Proxy-Server Es fungiert als eine Art universeller Adapter für LLM-APIs. Es ermöglicht Anwendungen die Kommunikation mit über hundert verschiedenen Modellen – von Anbietern wie OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI und anderen – über eine einzige API im OpenAI-Stil.

Aufgrund dieser Rolle hat sich das Projekt tief im KI-Ökosystem verankert. Berichte mehrerer Sicherheitsanbieter deuten darauf hin, dass LiteLLM etwa 3–3.4 Millionen Downloads pro TagEinige Telemetriedaten deuten darauf hin, dass es in etwa 36 % der überwachten Cloud-UmgebungenFür Angreifer stellt die Kompromittierung eines Pakets mit dieser Signatur eine seltene Gelegenheit dar, mit einem einzigen Schritt auf eine riesige Menge sensibler Daten und Zugangsdaten zuzugreifen.

LiteLLM ist so konzipiert, dass es oft direkt zwischen Anwendungen und mehrere KI-DienstleisterDiese Position bedeutet, dass sie routinemäßig API-Schlüssel, Umgebungsvariablen, Konfigurationsdateien und andere für den Zugriff auf externe LLM-Endpunkte erforderliche Geheimnisse verarbeitet. Eine Hintertür in einer solchen Abhängigkeit kann diese Werte unbemerkt abfangen und exfiltrieren, ohne dass ein direkter Angriff auf die vorgelagerten Plattformen selbst notwendig ist.

Der Vorfall verdeutlicht auch, wie eng die moderne Softwareentwicklung verflochten ist: Lokale Workstations, CI/CD-Pipelines, Kubernetes-Cluster und Cloud-Konten sind alle über gemeinsame Geheimnisse und Automatisierung miteinander verbunden. Ein einziger beeinträchtigte Abhängigkeit in diesem Graphen Dies kann letztendlich dazu führen, dass Anmeldeinformationen über viele Ebenen der Systemarchitektur einer Organisation hinweg offengelegt werden, wodurch die Auswirkungen weit über einen einzelnen Host hinausgehen.

Wie die schädlichen LiteLLM-Versionen eingeführt wurden

Die vergifteten Freisetzungen LiteLLM 1.82.7 und 1.82.8 wurden am Morgen des 24. März 2026 auf PyPI hochgeladen. 08: 30 UTCSie blieben fast zwei Stunden lang verfügbar, bevor sie vom PyPI-Sicherheitsteam unter Quarantäne gestellt und durch Drittanbieter-Sicherheitsmechanismen blockiert wurden; die Entfernung wurde etwa 11: 25 UTC.

Das Besondere an diesem Fall ist, dass Die Hintertür tauchte im entsprechenden GitHub-Quellcode nicht auf.Endor Labs und andere Forscher stellten fest, dass die bösartige Logik in das erstellte und auf PyPI verteilte Wheel eingeschleust wurde, nicht in das öffentliche Repository. Dies deutet darauf hin, dass die Kompromittierung während oder nach dem Build-/Veröffentlichungsprozess erfolgte und nicht durch einen sichtbaren Code-Commit.

Konkret stellten Analysten fest, dass die Datei litellm/proxy/proxy_server.py enthielt eine eingebettete Base64-kodierte Nutzlast, die fehlt in derselben Datei im GitHub-CommitEtwa ein Dutzend Zeilen wurden zwischen ansonsten gültigen Codeblöcken eingefügt (zum Beispiel in der Nähe der Definition von REALTIME_REQUEST_SCOPE_TEMPLATE und der showwarning Diese zusätzlichen Zeilen dekodierten und führten im Hintergrund ein verstecktes Skript aus, sobald das Modul importiert wurde.

In Version 1.82.8Die Angreifer gingen noch einen Schritt weiter, indem sie eine .pth Datei benannt litellm_init.pth in die Python-Umgebung. Denn Python verarbeitet alle .pth Dateien beim Start des Interpreters, dadurch wurde sichergestellt, dass die Nutzlast ausgeführt werden konnte. bei jedem Python-Aufrufselbst wenn LiteLLM selbst nie von der Anwendung importiert wurde.

Diese Eskalation führte 1.82.8 deutlich gefährlicherJedes Python-Skript, jeder Test-Runner, jedes Build-Tool oder jede Automatisierung, die in einer Umgebung mit installiertem kompromittiertem Paket gestartet wird, würde im Hintergrund stillschweigend die Logik zum Diebstahl von Anmeldeinformationen auslösen.

Verbindung zur umfassenderen TeamPCP-Kampagne

Der LiteLLM-Kompromittierungsfall ereignete sich nicht isoliert. Untersuchungen von Sonatype, Wiz, Endor Labs und anderen bringen ihn mit einem anderen Problem in Verbindung. laufende Lieferkettenkampagne von TeamPCP, eine Gruppe, die Ende 2025 Aufmerksamkeit erregte und seither eine Reihe von Open-Source-Projekten und Entwickler-Ökosystemen ins Visier genommen hat.

Anfang März wurden dieselben Schauspieler mit dem Hintertür-Einbruch in Verbindung gebracht. Trivy von Aqua Security Schwachstellenscanner und zugehörige GitHub Actions sowie bösartige Varianten von Checkmarx-Tools, einschließlich KICSDie Kampagne umfasste GitHub Actions und OpenVSX-Erweiterungen. Darüber hinaus wurden npm-Pakete, Docker Hub-Images und Kubernetes-Umgebungen einbezogen, wobei häufig Infrastruktur, Verschlüsselungsmethoden und Persistenzartefakte wiederverwendet wurden.

Bei der Aufklärung des LiteLLM-Vorfalls gaben die Betreiber bekannt, dass ein PyPI-Veröffentlichungstoken Ein im GitHub-Repository von LiteLLM als Umgebungsvariable gespeicherter Token wurde über den kompromittierten Trivy-Workflow exfiltriert. Dieser Token wurde anschließend missbraucht, um Die manipulierten PyPI-Releases veröffentlichenDadurch können die Angreifer die Zwei-Faktor-Sicherheitsmaßnahmen für Benutzerkonten umgehen und bösartige Wheels einschleusen, ohne den öffentlichen Quellcode zu verändern.

Die Forscher weisen zudem auf verdächtige Commits und Workflows hin, die um den 23. März in LiteLLM-bezogenen Repositories erstellt wurden. Dazu gehören ein kurzlebiger Branch und ein GitHub-Actions-Workflow mit einem bekannten RSA-Public-Key, der auch in anderen TeamPCP-Payloads verwendet wurde. Telemetriedaten von Workflow-Ausführungen legen nahe, dass auf die den CI-Runnern zur Verfügung stehenden Geheimnisse zugegriffen und diese exfiltriert wurden.

Im Verlauf aller Vorfälle zeigte die Gruppe ein einheitliches Muster: Zugangsdaten in einer Umgebung stehlen und dann in das nächste Ökosystem wechselnIn diesem Fall ermöglichte eine Fehlkonfiguration in Trivys GitHub Actions den Diebstahl eines privilegierten Tokens; dieses Token führte zu bösartigen Trivy-Releases und Docker-Images; diese wiederum ermöglichten die Kompromittierung der Checkmarx-Tools und letztendlich des LiteLLM PyPI-Pakets.

Funktionsweise der LiteLLM-Malware

Analysen mehrerer Anbieter beschreiben die LiteLLM-Hintertür als eine mehrstufige, Base64-verschlüsselte Python-Nutzlast Es ist auf Unauffälligkeit, Flexibilität und Widerstandsfähigkeit ausgelegt. Die Logik ist in etwa drei Schichten unterteilt, von denen jede eine andere Phase des Angriffs abdeckt.

In der ersten Schicht wird der eingefügte Code in proxy_server.py oder unter der litellm_init.pth Datei entschlüsselt und startet einen versteckten OrchestratorAnstatt leicht erkennbare Funktionen wie exec()Das Skript nutzt Unterprozessaufrufe und Standardbibliotheksfunktionen, um die dekodierte Nutzlast auszuführen und deren Ausgabe zu erfassen, wodurch es sich nahtlos in das normale Anwendungsverhalten einfügt.

Sobald dieser Orchestrator läuft, sammelt er die Ausgabe der nachfolgenden Stufe. verschlüsselt die gesammelten Daten mit AES‐256‐CBC Anschließend wird der AES-Sitzungsschlüssel selbst mit einem fest im Code verankerten RSA-Schlüssel verschlüsselt. Der verschlüsselte Datenblock und der Schlüssel werden in einem Archiv mit dem Namen „“ zusammengefasst. tpcp.tar.gz, analog zu anderen TeamPCP-Operationen, und bereiteten sich auf die Datenexfiltration vor.

Die zweite Schicht ist verantwortlich für aggressive Systemerkundung und Beschaffung von ZugangsdatenEs listet Hostnamen, Benutzer- und Netzwerkinformationen sowie Umgebungsvariablen auf und durchsucht anschließend eine lange Liste von Pfaden und Konfigurationsdateien nach sensiblen Daten. Zu den Zielen gehören:

• SSH-Schlüssel und Konfigurationsdateien (Client und Server)
• Cloud-Zugangsdaten für AWS, GCP und Azure, einschließlich aus Metadaten abgeleiteter Token
• Kubernetes kubeconfig-Dateien, Dienstkonto-Tokens und Cluster-Geheimnisse
• Umgebungsdateien wie .env Varianten, die häufig zum Speichern von API-Schlüsseln verwendet werden
• CI/CD-KonfigurationGeheimnisse und Zugriffstoken
• Terraform, Helm und andere IaC- oder Bereitstellungsartefakte
• Datenbankverbindungszeichenfolgen und Konfigurationsdateien
• TLS/SSL-Privatschlüssel und Authentifizierungsmaterial
• Cryptocurrency Brieftaschen und zugehörige Daten

In manchen Umgebungen begnügt sich der Dieb nicht mit dem Einsammeln. Er versucht, Die gefundenen Anmeldeinformationen aktiv nutzenzum Beispiel durch Abfragen von APIs von Cloud-Anbietern, Abrufen von Kubernetes-Geheimnissen oder Erkunden erreichbarer Ressourcen, wodurch die Wahrscheinlichkeit einer lateralen Ausbreitung und nachfolgender Kompromittierung erhöht wird.

Die dritte Schicht bietet Persistenz und FernsteuerungEs schreibt ein Python-Skript auf die Festplatte (häufig beobachtet als sysmon.py) und registriert es als einen dauerhaft laufenden Dienst, oft getarnt als etwas Harmloses wie beispielsweise ein „Systemtelemetriedienst“. Dieser Dienst kontaktiert die Infrastruktur des Angreifers regelmäßig, typischerweise alle 50 Minuten, um zusätzliche Befehle oder Nutzdaten abzurufen.

Forscher bemerken hier ein merkwürdiges Verhalten: Als bestimmte Sicherheitsanbieter versuchten, die Nutzdaten vom Command-and-Control-Endpunkt abzurufen, antwortete der Server mit einem Link zu einer remasterten Version des Songs „Bad Apple!!“, offenbar als … Ablenkungstaktik gegen automatisierte AnalyseAuf infizierten Systemen kann derselbe Mechanismus jedoch im Laufe der Zeit unbemerkt neue Funktionen bereitstellen.

Exfiltrationskanäle und Angreiferinfrastruktur

Im Rahmen der LiteLLM-Vorfälle beobachteten Analysten die Kommunikation mit mindestens zwei Hauptdomänen, die von Angreifern kontrolliert wurden: modelslitellmcloud , checkmarxzoneDiese entsprechen der Infrastruktur, die in früheren TeamPCP-Aktivitäten verwendet wurde, und erfüllen unterschiedliche Funktionen.

Das verschlüsselte Archiv tpcp.tar.gz ist typisch hochgeladen auf models.litellmcloudDadurch können die Betreiber gestohlene Zugangsdaten aus Tausenden von nachgelagerten Systemen abrufen. In einigen Varianten werden verschiedene Unterpfade von checkmarxzone (zum Beispiel, checkmarxzone/raw or .../vsx) werden verwendet, um Persistenzskripte oder zusätzliche Stufen bereitzustellen.

Auf kompromittierten Systemen haben Verteidiger eine Reihe wiederkehrender Probleme gemeldet. Indikatoren für eine Kompromittierung (IoCs) im Zusammenhang mit der LiteLLM-Malware:

• Vorhandensein des Archivs tpcp.tar.gz in temporären oder Arbeitsverzeichnissen
• Temporäre Dateien wie z. B. /tmp/pglog , /tmp/.pg_state
• Python-Skript- und Konfigurationspfade im Zusammenhang mit sysmon.py und eine passende Service-Datei (oft in Benutzer- oder Systemd-Konfigurationsverzeichnissen)
• Unerwartet litellm_init.pth Dateien in Python site-packages für Version 1.82.8
• Ausgehender Datenverkehr oder DNS-Abfragen, die auf Folgendes verweisen modelslitellmcloud or checkmarxzone

Bösartige Logik wurde in Dateien zurückverfolgt, die Folgendes umfassten proxy_server.py (LiteLLM 1.82.7 und 1.82.8) und litellm_init.pth (1.82.8). Sicherheitsanbieter haben Hashes und weitere Indikatoren für Kompromittierung (IoCs) katalogisiert und aktualisieren ihre Empfehlungen fortlaufend, sobald weitere forensische Details bekannt werden.

Auswirkungen auf KI-, Cloud- und CI/CD-Umgebungen

Weil LiteLLM häufig verwendet wird in KI-gesteuerte Anwendungen und DiensteDie praktischen Auswirkungen dieses Kompromisses reichen weit über einfache Paketnutzer hinaus. In Cloud-Umgebungen, in denen LiteLLM als Gateway zu LLM-Anbietern diente, befinden sich wahrscheinlich Geheimnisse im selben Laufzeit- oder Konfigurationsbereich.

Wiz und andere Beobachter schätzen, dass LiteLLM in etwa ein Drittel der beobachteten WolkenumgebungenDies unterstreicht das potenzielle Ausmaß. Einige von BleepingComputer zitierte Quellen deuten darauf hin, dass die Zahl der Datenexfiltrationsereignisse in die Hunderttausende gehen könnte, obwohl eine unabhängige Bestätigung der genauen Zahlen noch aussteht.

Insbesondere betont die Malware Folgendes: Kubernetes-fähiges VerhaltenIn vielen Analysen versucht die Schadsoftware, privilegierte Pods auf allen Knoten eines Clusters zu verteilen und diese anschließend für den Zugriff auf Geheimnisse und Konfigurationsobjekte zu nutzen. In separaten, aber damit zusammenhängenden TeamPCP-Operationen beobachteten Forscher, wie Kubernetes-Cluster mit Skripten angegriffen wurden, die Knoten löschten, sobald sich die Umgebung im Iran zu befinden schien, während gleichzeitig an anderen Orten Hintertüren (wie der sogenannte CanisterWorm) installiert wurden.

Der Fokus auf CI/CD-Tools ist ebenso deutlich. Durch die Kompromittierung von Trivy GitHub Actions, Checkmarx VS Code-Erweiterungen und GitHub Actions sowie nun auch LiteLLM erhalten Angreifer Einfallstore, wo Die Automatisierung verfügt bereits über weitreichende Berechtigungen. über Repositories, Build-Artefakte und Bereitstellungsberechtigungen. Dieser Ansatz verwandelt ansonsten sicherheitsorientierte Tools in Sprungbretter für umfassendere Kompromittierungen.

FBI-Beamte und Branchenforscher haben gewarnt, dass mit große Mengen gestohlener Zugangsdaten in der HandDaher ist zu erwarten, dass es in den Wochen und Monaten nach der ersten Veröffentlichung von LiteLLM zu weiteren Meldungen über Datenschutzverletzungen, sekundären Eindringversuchen und Erpressungsversuchen kommen wird.

Erkennungs-, Eindämmungs- und Sanierungsmaßnahmen

Für Organisationen, die möglicherweise LiteLLM-Versionen heruntergeladen oder ausgeführt haben 1.82.7 oder 1.82.8 Die Empfehlungen von Sicherheitsanbietern und PyPI-Betreuern sind unmissverständlich: Betroffene Systeme als kompromittiert behandelnDie einfache Deinstallation des Pakets entfernt weder Persistenzmechanismen noch macht sie einen möglicherweise bereits erfolgten Diebstahl von Zugangsdaten rückgängig.

Zu den empfohlenen Sofortmaßnahmen gehören:

• Identifizieren Sie alle Installationen von LiteLLM 1.82.7 oder 1.82.8 auf Entwicklerrechnern, CI/CD-Runnern, Containern und Produktionsumgebungen.
• Entfernen Sie die schädlichen Versionen. und LiteLLM auf eine bekannte, funktionierende Version festzulegen (wobei 1.82.6 zum Zeitpunkt der Berichterstattung weithin als die letzte fehlerfreie Version galt).
• Alle Zugangsdaten rotieren Zugriff aus betroffenen Umgebungen: SSH-Schlüssel, Cloud-Provider-Schlüssel und -Token, Kubernetes-Secrets, CI/CD-Secrets, Datenbank-Zugangsdaten, TLS-Schlüssel sowie alle Wallets oder zahlungsbezogenen Secrets.
• Suche nach Persistenzartefakten, sowie sysmon.pyverdächtige systemd-Dienstdefinitionen und ungewöhnliche Dateien unter ~/.config oder temporäre Verzeichnisse wie /tmp/pglog , /tmp/.pg_state.
• Kubernetes-Cluster untersuchen für unerwartet privilegierte Pods, insbesondere in Namensräumen wie kube-systemund für ungewöhnliche Servicekonten oder Rollenbindungen.
• Ausgehende Verbindungen überwachen und DNS-Abfragen für bekannte Angreiferdomänen wie models.litellmcloud , checkmarxzone.

In Umgebungen, in denen die Hintertür möglicherweise über einen längeren Zeitraum aktiv war, empfehlen viele Experten, dass ein vollständiger Neuaufbau von einer vertrauenswürdigen Basis aus Dies dürfte der sicherste Weg sein, insbesondere für kritische Infrastrukturen. Angesichts der Art der Malware können subtile Manipulationen oder zusätzliche Schadsoftware nicht allein durch das Entfernen des LiteLLM-Pakets ausgeschlossen werden.

Organisationen werden außerdem dazu angehalten, robustere Methoden anzuwenden. Abhängigkeitsmanagement und Lieferkettenabwehr: Festlegung auf bestimmte, verifizierte Versionen, Aktivierung von Tools, die bekannte schädliche Pakete beim Einbinden blockieren oder kennzeichnen, und Einbeziehung einer automatisierten Verhaltensanalyse, die unerwartete Netzwerk- oder Dateisystemaktivitäten während Builds und Tests erkennen kann.

Was der LiteLLM-Fall über Lieferketten für KI-Software aussagt

Der LiteLLM-Vorfall verdeutlicht einen breiteren Trend, der sich in den letzten Jahren abgezeichnet hat: Hochleistungskomponenten in KI- und Cloud-Stacks werden zu Hauptzielen Für Angreifer in der Lieferkette. Anstatt Endbenutzeranwendungen direkt anzugreifen, suchen Bedrohungsakteure zunehmend nach Schwachstellen in der Toolchain, bei denen die Kompromittierung einer einzelnen Bibliothek oder eines Plugins Zugriff auf viele nachgelagerte Organisationen ermöglicht.

Pakete wie LiteLLM befinden sich effektiv auf einem Engpass für GeheimnisseSie vermitteln Anrufe an KI-Anbieter, greifen in CI/CD- und Infrastrukturautomatisierungssysteme ein und laufen oft mit erweiterten Berechtigungen. Da immer mehr Unternehmen LLM-Funktionen mithilfe von Open-Source-Tools integrieren, steigt der Wert solcher Komponenten – und damit auch der Anreiz, Hintertüren einzubauen.

Gleichzeitig verdeutlicht der Angriff die Herausforderungen beim Schutz von Build- und Veröffentlichungs-Pipelines. In diesem Fall nutzten Angreifer mutmaßlich eine Fehlkonfiguration des Trivy-Workflows aus, um ein Token zu stehlen und dieses anschließend zu verwenden, um manipulierte Pakete auf PyPI zu veröffentlichen, während der öffentliche Quellcodebaum scheinbar sauber blieb. Versionskennzeichnungen und Build-Schritte wurden Teil der Angriffsflächeund nutzt dabei die Tatsache aus, dass viele Pipelines auf Tags anstatt auf fixierte Commits setzen und möglicherweise implizit Artefakten vertrauen, die von bekannten Maintainern stammen.

Anbieter wie Sonatype, Wiz und Endor Labs betonen die Wichtigkeit von automatisierte Echtzeit-Sicherheitsvorkehrungen Das System kann anomales Verhalten – wie bisher unbekannte Netzwerkziele oder verschlüsselte Datenexfiltration – erkennen, selbst wenn Paketmetadaten und Repository-Historie legitim erscheinen. Repository-Firewalls, auf Bedrohungsanalysen basierende Scanner und die Kontextanalyse von Abhängigkeiten werden zunehmend als notwendige Sicherheitsebenen und nicht mehr als optionale Zusatzfunktionen betrachtet.

Für Wartungsfirmen und Organisationen gleichermaßen ist der LiteLLM-Kompromiss eine Erinnerung daran, dass Geheimnisverwaltung, CI/CD-Härtung und Anmeldeinformationsrotation Sie sind grundlegend für die Sicherheit der Lieferkette. Unvollständige oder nicht-atomare Rotation von Anmeldeinformationen in früheren Vorfällen hinterließ Sicherheitslücken, die TeamPCP Wochen später wiederverwenden konnte. Dies zeigt, wie ein einziger Fehler bei der Reaktion auf einen Vorfall sich kaskadenartig auf ganze Ökosysteme auswirken kann.

Die Kampagne, die LiteLLM erfasste, begann mit einem scheinbar begrenzten Workflow-Problem und erstreckt sich seither auf GitHub Actions, Docker Hub, der Shai-Hulud-npm-VorfallOpenVSX und PyPI. Da sich Hintertüren in weithin vertrauten Tools und KI-Konnektoren verstecken und gestohlene Zugangsdaten in die Infrastruktur von Angreifern fließen, verdeutlicht dieser Vorfall, wie schnell die Software-Lieferkette zu einer attraktiven und hochwirksamen Angriffsfläche werden kann.