Eine Organisation, die im TeamPCP-Anmeldedatenarchiv genannt wurde, teilte Kevin Beaumont mit, dass die Sicherheitslücke behoben worden sei und alle Zugangsdaten geändert worden seien. Er überprüfte die Richtlinien der Organisation zur verantwortungsvollen Offenlegung, stellte fest, dass diese das Testen von Anmeldedaten erlaubten, und probierte es aus.
Das ist ein einziger Beitrag, eine einzige Organisation, und Beaumont hat den Namen nicht genannt. Betrachten Sie es als einen einzelnen Datenpunkt. Aber es ist ein Datenpunkt, der den Zusammenhang zwischen einem abgeschlossenen Behebungsticket und einer widerrufenen Berechtigung verdeutlicht, und es gibt noch einen zweiten, der vom ersten Opfer in der Kette stammt.
Was die Enthüllungen vom August noch ergaben
Im Juli habe ich über das TeamPCP-Anmeldeinformationsarchiv geschrieben und dargelegt, dass es letztlich davon abhängt, ob Ihre „ cloud “-Token darin enthalten sind, inwieweit Sie von der VECT- ransomware -Kooperation betroffen sind. Im August wuchs das Archiv an Umfang und erhielt eine Liste der Betroffenen.
- CloudSEK, 11. August: mehr als 2.500 Unternehmen und rund 434.000 CI/CD-Pipelines.
- Hudson Rock, 12. August: ein 153-GB-Archiv mit 433.909 Dateien, das erfasst und analysiert wurde und 118.829 CI-Runner-Dumps enthält, die 2.488 Unternehmensdomänen zugeordnet werden können.
Lesen Sie den Vorbehalt von CloudSEK vor der Überschrift. Die dort genannten Zahlen „beschreiben rekonstruierte Sicherheitslücken“ und „sollten nicht als Beweis dafür verstanden werden, dass jede aufgeführte Organisation erfolgreich kompromittiert wurde oder dass alle Anmeldedaten gestohlen wurden“. Das Erscheinen in dem Datensatz ist ein Grund für weitere Untersuchungen, aber kein bestätigter Sicherheitsvorfall. Der Beitrag von Hudson Rock enthält keinen vergleichbaren Vorbehalt, was man beim Vergleich der beiden Listen beachten sollte.
Beide Firmen nennen die Organisationen, bei denen sie Übereinstimmungen festgestellt haben. Ich werde diese Namen hier nicht wiederholen. Eine rekonstruierte Sicherheitslücke ist kein bestätigter Angriff, und diese Unterscheidung geht verloren, sobald daraus eine Liste mit Firmennamen wird.
Keines der beiden Unternehmen hat das Archiv veröffentlicht. Hudson Rock hat es in seine Cavalier-Plattform integriert und wendet ein Verfahren zur Offenlegung auf Einzelfallbasis an; CloudSEK betreibt eine öffentliche Suchfunktion. Ob das Korpus in größerem Umfang im Umlauf ist, ist unklar, und die Personen, die am nächsten daran sind, sind sich uneinig:
- Alon Gal von Hudson Rock erklärte gegenüber Help Net Security, dass „es derzeit nirgendwo durchgesickert ist und nicht in großem Umfang im Umlauf ist“.
- Beaumont erklärte in derselben Woche: „Derzeit sind Terabytes an Zugangsdaten im Internet im Umlauf.“
- SOCRadar hat festgestellt, dass ein Händler auf Telegram ein Datenpaket aus LiteLLM, Trivy und CanisterWorm mit einer komprimierten Größe von über 150 GB anbietet, was darauf hindeutet, dass es sich um einen einzigen Verkäufer handelt, der über diese Sammlung verfügt, und nicht um eine breite Verbreitung.
Diese Unterscheidung legt fest, wie schnell die Anmeldedaten voraussichtlich verwendet werden. Sie ändert nichts daran, dass sie im März kopiert wurden.
Das Zeitfenster ist größer als das, von dem alle berichtet haben.
Dies stellt meinen Beitrag vom Juli ebenso richtig wie die Berichterstattung aller anderen.
Über die Kampagne wurde als „LiteLLM-Sicherheitsvorfall“ berichtet, wobei der Schwerpunkt auf den rund 40 Minuten am 24. März lag, in denen die manipulierten Pakete auf PyPI verfügbar waren. SOCRadar analysierte die Zeitstempel der 2.188 Organisationsdatensätze und stellte fest, dass die Gefährdung bereits früher bestand:
- Frühester Erfassungszeitpunkt: 19. März, 18:05 Uhr UTC
- Stand: 24. März, 20:09 UTC
- Datensätze, die Inkassotätigkeiten vor dem 24. März belegen, also vor der Einführung der LiteLLM-Pakete: 2.085 von 2.188, das sind 95 Prozent
SOCRadar interpretiert diesen Zeitablauf so, dass er eher auf die vorhergegangene Kompromittierung von Trivy als auf das Installationsfenster von LiteLLM hindeutet, und SecurityWeek hat dies am 14. August ebenfalls so dargestellt. Die Formulierung von SOCRadar ist hier maßgeblich: Die 40 Minuten waren der Schlussakt, nicht das gesamte Stück.
Eine Protokollsuche, die sich auf den 24. März beschränkte, war also zu eng gefasst. Dieses Datum ist zwar immer noch relevant, wenn Sie die manipulierten Versionen installiert haben, doch der Großteil der Sicherheitslücke geht auf einen früheren Zeitpunkt zurück.
Trivys eigene Sanierungsmaßnahme dient als Fallstudie
Ein Grund, warum die Rotation fehlschlägt, lässt sich am ersten Opfer erkennen.
Aqua sperrte am 1. März die Zugangsdaten, darunter auch die Automatisierungsidentitäten, von denen die Ermittler wussten, dass sie kompromittiert waren. Die Zeitleiste von CloudSEK beschreibt in Verbindung mit der Chronologie von Aqua und dem NVD-Eintrag zu CVE-2026-33634, was anschließend geschah. Die Aktivitäten wurden über einen anderen Benutzer und ein anderes Token fortgesetzt. Das am 1. März beobachtete Token tauchte am 19. März erneut im Rahmen böswilliger Aktivitäten auf. Am 22. März griff ein Dienstkonto, das niemand als kompromittiert angesehen hatte, auf 43 Repositorys in einer anderen Organisation zu. CloudSEK rekonstruiert einen Zeitraum von etwa 20 Tagen, in dem ein Automatisierungstoken nach der Rotation weiterhin nutzbar blieb, und weist darauf hin, dass es sich bei dieser Zahl um eine eigene Rekonstruktion und nicht um einen verifizierten forensischen Zeitraum handelt.
Flare drückt es noch deutlicher aus: „Aqua hat die Zugangsdaten rotiert, aber einige übersehen. Die verbleibenden Zugangsdaten blieben gültig.“
Die Anmeldedaten wurden nicht gleichzeitig ungültig gemacht, sodass mindestens eine Identität weiterhin nutzbar blieb, während Ersatz-Geheimnisse ausgestellt wurden. Die daraus von CloudSEK gezogene Schlussfolgerung lautet: Wenn eine noch bestehende Identität auf die neu rotierten Geheimnisse zugreifen könnte, würde die Rotation einzelner Token den Eindringling nicht zwangsläufig entfernen. Wird die Rotation als Abfolge von Token-Ersetzungen und nicht als ein einziger Eindämmungsvorgang für alle Identitäten im Freigabepfad durchgeführt, besteht die Gefahr, dass dem Angreifer seine eigenen Ergebnisse ausgehändigt werden.
„Wir haben alles rotiert“ und „die Zugangsdaten funktionieren nicht mehr“ sind unterschiedliche Behauptungen. Nur die zweite ist überprüfbar, und Beaumonts Test ist der einzige öffentliche Test dazu, den ich gesehen habe.
Die Hälfte, die niemand erreichen kann
Die zweite Fehlerart ist eher dem Offenlegungsmodell zuzuschreiben als einem bestimmten Opfer.
Hudson Rock konnte 118.829 Runner-Dumps zu namentlich genannten Domains zuordnen und macht deutlich, was nicht zugeordnet werden konnte: Eine große Anzahl von Dateien „enthält hochsensible Geheimnisse, lässt sich jedoch organisatorisch überhaupt nicht eindeutig zuordnen“. Diese Organisationen haben aktive Geheimnisse im Korpus, haben aber keine Möglichkeit, davon zu erfahren. GitGuardian brachte die Konsequenz am 14. August auf den Punkt: Keines der beiden Unternehmen kann ein Unternehmen benachrichtigen, das es nicht namentlich benennen kann; eine verantwortungsvolle Offenlegung erfordert eine Adresse, und ein generisch konfigurierter CI-Runner hinterlässt keine.
Das Fehlen in einem Suchwerkzeug ist also nur ein schwacher Hinweis. Wenn Sie die betroffenen Trivy-Aktionen oder LiteLLM 1.82.7 bzw. 1.82.8 in diesem Fenster ausgeführt haben, geben Ihre eigenen Pipeline-Aufzeichnungen Aufschluss über die Frage der Offenlegung – nicht darüber, ob ein Forscher Ihren Runner einer Domain zuordnen könnte.
Warum es sich hierbei um Lücke 2 handelt
Ein gestohlener AWS-Schlüssel, ein Repository-Token, ein Kubernetes-Dienstkonto oder ein Modellanbieter-Schlüssel authentifiziert sich über dieselbe Schnittstelle, die auch die Pipeline nutzt – und zwar von einer Infrastruktur aus, die wie eine Automatisierung aussieht –, und führt dabei Vorgänge aus, zu deren Ausführung die Identität berechtigt ist. Der „ cloud “-Anbieter protokolliert einen erfolgreichen API-Aufruf von einem anerkannten Prinzipal. Die Authentifizierung gelingt. Bei den nachfolgenden Aktivitäten kommt an keiner Stelle ein Exploit zum Einsatz.
Solange die Anmeldeinformationen noch gültig sind, gibt das Ergebnis der Authentifizierung keinen Aufschluss, da es sich um einen Erfolg handelt. Bei der Anmeldung bleiben jedoch Signale bestehen – darunter ein unbekanntes Netzwerk oder ein ungewöhnlicher Client –, die eine Warnung rechtfertigen. Die dauerhaften Signale sind verhaltensbedingt: ein Dienstkonto, das auf eine Ressource zugreift, auf die es zuvor noch nie zugegriffen hat, oder ein abgelaufenes Token, das weiterhin vorgelegt und akzeptiert wird. Jedes einzelne lässt sich erklären, in ihrer Abfolge jedoch nicht.
Was diese Woche zu tun ist
Überprüfen Sie die Rotation statt des Tickets. Vergewissern Sie sich für jede Berechtigungsklasse, auf die der betroffene Prozess zugreifen könnte, dass der alte Wert nun abgelehnt wird:
- Cloud Schlüssel und alle Daten, die aus dem Instanz-Metadatendienst ausgelesen werden können
- Repository-, Registry- und Paketveröffentlichungstoken
- SSH-Schlüssel und Kubernetes-Dienstkonten
.envInhalte, Datenbank-URLs und Schlüssel von KI-Anbietern
Der Ansatz von Flare sollte bei einer Nachverfolgungsprüfung berücksichtigt werden: Betrachten Sie die Rotation als Bestandsaufnahme und nicht als Maßnahme zur Behebung eines Vorfalls. Dies funktioniert nur, wenn Sie den vollständigen Umfang kennen, und wie CloudSEK anmerkt, sind leere Protokolle kein Beweis dafür, dass eine Anmeldeinformation nie kopiert wurde.
Erweitern Sie dann die Suche auf den Zeitraum vom 27. Februar bis Ende März:
- Pipeline-Service-Konten, die sich bei der Produktionsumgebung authentifizieren
- Repositories mit dem Namen
docs-tpcpodertpcp-docsinnerhalb Ihrer eigenen Organisation - Jeder vor April 2026 ausgegebene Token, der noch im Umlauf ist
Das Kapitel „Gap 2“ in „Mind Your Attack Gaps“ behandelt denselben Fehlerfall anhand der „ Scattered Spider “-Helpdesk-Kette, bei der die Anmeldedaten gültig waren und die Anmeldung einwandfrei verlief. Unter Vectra AI veranschaulichen wir, wie sich eine Identität nach der Authentifizierung verhält – über cloud, Identität und Netzwerk hinweg –, wo ein gültiges gestohlenes Token sichtbar wird.
Das Archiv stammt aus dem März. Ob dies im September noch von Bedeutung ist, kann Ihr Berechtigungsspeicher beantworten.
---
Offenlegung: Vectra AI erscheint im Datensatz von CloudSEK. Eine kompromittierte Trivy-GitHub-Action wurde am 19. und 20. März in einer begrenzten Anzahl unserer CI/CD-Workflows ausgeführt, wodurch Build-Metadaten und kurzlebige, auf einzelne Jobs bezogene Anmeldedaten offengelegt wurden. Wir haben das Problem intern erkannt, die Tools innerhalb weniger Stunden ausgetauscht und die entsprechenden Anmeldedaten aktualisiert sowie unsere Aufzeichnungen im August erneut mit den Erkenntnissen von CloudSEK abgeglichen. Unsere vollständige Stellungnahme finden Sie hier.