CloudSEK und HudsonRock hatten in diesem Monat berichtet, dass wahrscheinlich mehr als 2.500 Organisationen von dem LiteLLM-Angriff betroffen waren. SOCRadar widerspricht dieser Einordnung teilweise: Der Großteil dieser Fälle gehe nicht auf LiteLLM selbst zurück, sondern auf die vorgelagerte Kompromittierung von Trivy.

Nach Angaben von SOCRadar lagen für 2.188 Organisationen Datensätze auf Einzelebene vor, darunter Zeitstempel, Arten der erfassten Zugangsdaten, eingesetzte CI/CD-Plattformen und Domains. Jeder Datensatz enthalte einen ersten und letzten Beobachtungszeitpunkt. Der früheste Eintrag stamme vom 19. März um 18:05 UTC, der späteste vom 24. März um 20:09 UTC. Damit erstrecke sich die beobachtete Aktivität über etwas mehr als fünf Tage.

Für 2.085 Organisationen und damit 95 Prozent der 2.188 identifizierten Fälle endete die Datensammlung laut SOCRadar bereits vor dem 24. März, also bevor die manipulierten LiteLLM-Pakete in die Registry eingestellt wurden. Das passe zeitlich zur vorgelagerten Trivy-Kompromittierung und nicht zum Installationsfenster von LiteLLM. Die rund 40 Minuten, auf die sich viele Berichte konzentrierten, seien laut SOCRadar nur der Schlusspunkt gewesen, nicht das gesamte Geschehen.

Die früheste Datensammlung begann demnach 18 Minuten nach der Veröffentlichung des bösartigen Trivy-Builds am 19. März. Einen deutlichen Anstieg habe es am 22. und 23. März gegeben, als manipulierte Trivy-Images auf Docker Hub verfügbar waren. Das Geschehen endete am 24. März, nachdem PyPI die Pakete unter Quarantäne gestellt hatte. SOCRadar wertet das als Hinweis auf Persistenz auf bereits infizierten Systemen: Die .pth-Nutzlast sei weiter ausgeführt worden, obwohl die ursprüngliche Infektionsquelle bereits entfernt war.

Bei LiteLLM selbst wurden laut Quelle zwei vergiftete Paketversionen am 24. März veröffentlicht und blieben ungefähr 40 Minuten online. Sie enthielten eine .pth-Datei, die Python beim Start des Interpreters automatisch ausführt, selbst wenn LiteLLM nie importiert wird. Dadurch wurden Schutzmechanismen umgangen, die Skripte normalerweise ignorieren.

Betroffen waren sechs CI/CD-Plattformen: GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI und Buildkite. Die Auswirkungen waren weltweit sichtbar, wobei Deutschland, Brasilien und Frankreich laut SOCRadar am stärksten betroffen waren.

Die Schadsoftware zielte breit auf Geheimnisse. Bei mehr als 1.000 Organisationen wurden JWTs und Authentifizierungs-Token offengelegt. In Hunderten Fällen betraf dies private Schlüssel, AWS-Zugangsschlüssel, GitLab-Token, OpenAI-API-Schlüssel, Slack-Webhooks, GitHub-Actions-Token und Google-API-Schlüssel. Der höchste in den Daten erfasste Geheimnis-Bestand lag laut SOCRadar bei rund 3.477, gefolgt von rund 3.459. In einem Fall verteilten sich 3.459 Geheimnisse auf lediglich sechs Dateien.

SOCRadar weist außerdem darauf hin, dass bei mehr als 1.100 Organisationen E-Mail-Adressen von Committern kompromittiert wurden. In diesen Fällen verfügten die Angreifer demnach sowohl über Entwickler-Identitäten als auch über Maschinen-Token.

Bei der Zuordnung der Datensätze stuft SOCRadar 56 Prozent der 2.188 Organisationen als hohe Sicherheit ein, 39 Prozent als mittlere und 6 Prozent als niedrige, jeweils gerundet. Die oft genannte Zahl von mehr als 2.500 Organisationen erkläre sich laut Unternehmen daraus, welche Datensätze tatsächlich eindeutig zuordenbare Identifikatoren enthielten. Zugleich betont SOCRadar, es handele sich um Expositionszahlen und nicht um bestätigte Kompromittierungen; die Angaben basierten auf einer rekonstruierten Stichprobe, nicht auf einer vollständigen Erhebung.

Die gestohlenen Informationen werden laut SOCRadar bereits gehandelt. Ein Bedrohungsakteur biete auf Telegramm eine Sammlung von Daten aus LiteLLM, Trivy und CanisterWorm an, die wahrscheinlich in verschiedenen Phasen der Kampagne zusammengestellt wurde.