Die IT-Sicherheitswelt erlebt gerade eine Lehrstunde in Sachen Abhängigkeiten. Was wie ein isolierter Vorfall bei LiteLLM (einer populären Bibliothek für LLM-Schnittstellen) aussieht, entpuppt sich bei genauerem Hinsehen als hochgradig professionelle Angriffskette. Die Gruppe „TeamPCP“ hat nicht einfach nur ein Paket gehackt – sie hat das Vertrauen in die Toolchain militarisiert.
Die Anatomie des Angriffs: Perfide Einfachheit
Am 24. März 2026 wurden zwei kompromittierte Versionen von LiteLLM (1.82.7 und 1.82.8) auf PyPI hochgeladen. Während die Version 1.82.7 noch auf die klassische Code-Injektion in bestehende Dateien setzte, nutzte 1.82.8 eine weitaus gefährlichere Methode: Ein sogenanntes .pth-File.
Diese Dateien werden von Python bei jedem Interpreter-Start automatisch ausgeführt – völlig egal, ob die Bibliothek litellm im Code überhaupt importiert wird. Es reicht, wenn das Paket in der Umgebung installiert ist. Der Effekt? Ein automatisierter „Credential-Stealer“, der im Hintergrund SSH-Keys, Cloud-Zugangsdaten (AWS, GCP, Azure) und Kubernetes-Token absaugt.
Das Security-Paradoxon
Das eigentlich Ironische (oder Tragische) an diesem Fall: Der Einstiegspunkt war kein schwaches Passwort bei LiteLLM selbst. Die Angreifer nutzten gestohlene Identitäten aus einem vorherigen Hack auf Trivy – ausgerechnet ein Tool, das Unternehmen einsetzen, um ihre Sicherheit zu erhöhen.
Hier zeigt sich das „Security-Tool-Paradoxon“: Werkzeuge für Security, Observability und Infrastruktur benötigen naturgemäß hohe Privilegien. Wer den Wächter kontrolliert, kontrolliert das gesamte Haus. TeamPCP hat sich über Wochen hinweg von einem Tool zum nächsten gehangelt (Trivy -> Checkmarx KICS -> LiteLLM) und dabei jedes Mal wertvollere Publishing-Tokens erbeutet.
Der Payload: Mehr als nur Datendiebstahl
Der Angriff folgt einem klaren Drei-Stufen-Plan:
Exfiltration: Systemdaten und Secrets werden verschlüsselt an einen täuschend echt aussehenden C2-Server (models.litellm.cloud) gesendet.
Persistenz: Ein lokaler Backdoor-Dienst wird als „System Telemetry Service“ getarnt, um dauerhaften Zugriff zu behalten.
Laterale Ausbreitung: Findet das Skript Kubernetes-Credentials, versucht es, privilegierte Pods auf jedem Node des Clusters zu starten.
Für IT-Entscheider ist das ein Weckruf. Die schiere Masse von 3,4 Millionen täglichen Downloads bei LiteLLM bedeutet, dass potenziell hunderttausende Systeme infiziert wurden, bevor PyPI die Pakete nach wenigen Stunden löschte.
Strategische Checkliste: Was jetzt zu tun ist
Wer in der kritischen Zeitspanne am 24. März Pakete aktualisiert oder Container-Builds durchgeführt hat, sollte nicht auf Glück hoffen.
Identifikation: Prüfen Sie Ihre site-packages auf die Datei litellm_init.pth. Wenn sie da ist, brennt die Hütte.
Totaler Key-Reset: Betrachten Sie alle Secrets auf betroffenen Maschinen als kompromittiert. Ein einfacher Patch reicht nicht; Passwörter, API-Keys und Zertifikate müssen rotiert werden.
Version-Pinning: Nutzen Sie vorerst nur die verifizierte Version 1.82.6 oder warten Sie auf offizielle Signale des Teams, bevor Sie neuere Versionen einsetzen.
Dieser Vorfall markiert eine neue Qualität von Supply-Chain-Angriffen, bei denen KI-gestützte Bots (wie der von TeamPCP eingesetzte „Hackerbot-Claw“) die Suche nach Schwachstellen in der CI/CD-Pipeline automatisieren. In einer Welt, in der wir hunderte von Abhängigkeiten blind vertrauen, ist die Integrität unserer Build-Prozesse das neue Primärziel.
3 Key Takeaways
Vertrauen ist gut, Pinning ist besser: Automatisierte Updates von Bibliotheken ohne festgeschriebene Versionen (Hash-Verification) sind in Produktionsumgebungen ein unkalkulierbares Risiko.
Security-Tools sind Primärziele: Werkzeuge mit hohen Privilegien müssen isoliert und ihre ausgehenden Netzwerkverbindungen streng überwacht werden.
Post-Infection-Audit ist Pflicht: Das Löschen eines schadhaften Pakets entfernt nicht die installierte Backdoor oder den bereits erfolgten Abfluss von Cloud-Credentials.