Sie haben die falschen vierzig Minuten geprüft

Am 14. August veröffentlichte Ionut Arghire von SecurityWeek die Neuzuordnung durch SOCRadar für eine der größten Kompromittierungen von Entwicklerinfrastruktur in diesem Jahr. SOCRadar besaß den Datensatz auf Datensatzebene, mit Erfassungsprotokollen pro Organisation für 2.188 Entitäten, und stellte eine Frage, die niemand gestellt hatte: Wann verließen die Daten jede einzelne Organisation?

Bei 2.085 von ihnen war die Erfassung beendet, bevor die schadhaften Pakete, vor denen alle gewarnt wurden, überhaupt veröffentlicht waren. Das sind 95 %. Die Schlussfolgerung von SOCRadar passt in einen Satz:

„Dieses Timing passt zur vorgelagerten Trivy-Kompromittierung, nicht zum LiteLLM-Installationsfenster. Die 40 Minuten, über die alle berichtet haben, waren der Schlussakt, nicht das ganze Stück.“

Forscher hatten den Payload bereits im März auseinandergenommen. SOCRadar veränderte die Zeitachse. Fünf Monate lang fuhr die Branche ihre Incident Response gegen das falsche Fenster — mit Kontrollen, die nichts tun konnten, solange niemand das Schadhafte benannt hatte.

Der Schlussakt

Die berühmten vierzig Minuten gehören LiteLLM. Am 24. März gingen die Versionen 1.82.7 und 1.82.8 um 10:39 UTC auf PyPI online und hielten sich etwa vierzig Minuten, bevor PyPI sie in Quarantäne stellte. Die Empfehlung lautete damals, jede Installation bis 16:00 UTC an jenem Tag als verdächtig zu behandeln.

Der Payload verdient einen Moment für das, was er aushebelt. Es ist eine .pth-Datei, litellm_init.pth, abgelegt in site-packages. Python führt .pth-Dateien beim Start des Interpreters aus, ganz gleich, ob irgendetwas das Paket importiert, das sie installiert hat. Es gibt keine setup.py zum Prüfen und kein Installationsskript zum Entfernen, also ziehen --ignore-scripts und jede Kontrolle, die auf dem Ausführungsmodell von Installationsskripten aufbaut, daran vorbei. The Hacker News beschrieb den Mechanismus am 12. August und nannte die ökosystemweite Kennung CVE-2026-33634. Die Beute ging an models.litellm[.]cloud.

Die Angreifer schoben diese Wheels mit einem gestohlenen PyPI-Publishing-Token hoch, vorbei an LiteLLMs eigener Release-Pipeline. Woher also kam dieses Token?

Das ganze Stück

Trivy. Der Open-Source-Schwachstellenscanner von Aqua Security, den Zehntausende Pipelines ausführen, um genau solche Probleme zu finden.

Aquas Advisory, GHSA-69fq-xp46-6x23, beschönigt die Ursache nicht. Ein als TeamPCP geführter Akteur (bei Google UNC6780) zog Ende Februar über einen pull_request_target-Workflow ein Personal Access Token aus der GitHub-Actions-Umgebung von Trivy. Aqua legte das am 1. März offen und rotierte die Credentials. Das Advisory sagt dann, die Rotation sei „nicht atomar (nicht alle Credentials wurden gleichzeitig widerrufen)“ gewesen. Der Angreifer saß mitten in der Rotation und sammelte die neuen Secrets ein, während Aqua sie ausstellte.

Neunzehn Tage später gab er sie aus. Am 19. März force-pushte er 76 der 77 Versions-Tags in aquasecurity/trivy-action und alle sieben Tags in aquasecurity/setup-trivy auf schadhafte Commits, sodass ein auf @v0.28.0 gepinnter Workflow neuen Code holte, ohne dass sich im Repository etwas zu ändern schien. Über das kompromittierte Dienstkonto aqua-bot veröffentlichte er Trivy v0.69.4 auf GHCR, ECR Public, Docker Hub, deb und rpm. Die Docker-Hub-Images v0.69.5 und v0.69.6 folgten am 22.–23. März auf einem separat kompromittierten Credential.

StepSecuritys Analyse beschreibt, was der eingeschleuste Stealer tat, sobald eine Pipeline ihn ausführte:

• Die Umgebung jedes Runner-Prozesses über /proc/*/environ lesen.
• Den Speicher des GitHub-Actions-Runner-Workers über /proc/<pid>/mem dumpen, mit base64-kodiertem Python. Das holt die Secrets zurück, die ein Runner in seinen Logs maskiert, denn die Maskierung ist ein Log-Filter, während der Prozessspeicher die unmaskierten Werte hält.
• Das Dateisystem nach privaten SSH-Schlüsseln, Git-Credentials, AWS-, GCP- und Azure-Tokens, Kubernetes-Secrets, Docker-Konfigurationen, Datenbank-Credentials, Terraform-State und Kryptowährungs-Wallets absuchen.
• All das unter einem fest einkompilierten RSA-4096-Public-Key hybrid verschlüsseln und an scan.aquasecurtiy.org schicken.

Lesen Sie diesen Hostnamen noch einmal. Es ist die eigene Domain des Herstellers mit zwei vertauschten Buchstaben. Für einen Domain-Reputations-Feed oder für eine Analystin, die um 2 Uhr nachts den ausgehenden Verkehr überfliegt, ist ein Scanner, der mit etwas spricht, das wie aquasecurity.org aussieht, die unauffälligste Zeile der Seite.

Schlug der Upload fehl, legte der Stealer im GitHub-Konto des Opfers ein öffentliches Repository namens tpcp-docs an und hängte die Beute als Release-Assets daran.

SOCRadar datierte die erste Erfassung auf achtzehn Minuten nach dem Onlinegang des schadhaften Builds.

Was die Pipelines verlassen hat

Hudson Rock beschaffte sich das Archiv, und Help Net Security berichtete am 13. August über seine Größe: 153 GB, 433.909 Dateien, 118.829 CI-Runner-Dumps, zugeordnet zu 2.488 Unternehmensdomains. CloudSEKs unabhängige Zählung von rund 434.000 Dateien setzte die Exposition auf knapp 2.500 Organisationen und mehr als 430.000 Pipelines an. Hudson-Rock-CTO Alon Gal nannte es eine „globale ethische Offenlegungsanstrengung“ und sagte, das Ausmaß „schiebt uns in eine völlig neue Welt, was die erforderliche Art der Reaktion angeht“. Kevin Beaumonts Lesart: „Das ist ein massiver Lieferkettenbruch aufgrund schlechter KI-Sicherheit.“

SOCRadars Aufschlüsselung pro Organisation geht weiter. Mehr als tausend Organisationen verloren JWTs und Authentifizierungstokens. Hunderte verloren private Schlüssel, AWS-Access-Keys, GitLab-Tokens, OpenAI-API-Keys, Slack-Webhooks, GitHub-Actions-Tokens und Google-API-Keys. Eine Organisation verlor rund 3.477 einzelne Secrets. Elfhundert legten die E-Mail-Adressen ihrer Committer offen. Die Runner waren GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI und Buildkite. Deutschland, Brasilien und Frankreich traf es am härtesten, und die Sammlungen werden inzwischen über Telegram gehandelt.

Jede Kontrolle in dieser Kette brauchte einen Namen

Stellen Sie die Abwehrmaßnahmen auf, die es im März gab, und notieren Sie, was jede von ihnen brauchte, bevor sie handeln konnte.

Das Advisory brauchte, dass Aqua die Kompromittierung erkennt. Der Rückzug brauchte, dass PyPI das Paket erkennt. Die IoC-Liste brauchte jemanden, der scan.aquasecurtiy.org als feindlich liest statt als Tippfehler eines Herstellers, dem alle vertrauen. Die Checkliste „Haben Sie zwischen 10:39 und 16:00 UTC installiert?“ brauchte die richtigen fünf Stunden. Domain-Reputation brauchte, dass die Domain eine Reputation hat. Die Neuzuordnung, die 2.085 Organisationen mitteilte, dass sie die falsche Woche angeschaut hatten, brauchte ein geleaktes Archiv, das auftaucht, und ein Forschungsteam, das sich fünf Monate später damit hinsetzt.

Jede davon ist eine Identitätskontrolle: Sie wirkt auf eine Sache, nachdem jemand die Sache benannt hat. Benennen ist die Art, wie das Ökosystem Wissen teilt, und es funktioniert — das hier ist also keine Klage über die Leute, die Advisories schreiben. Es ist ein Punkt über die Reihenfolge der Operationen. Eine Identitätskontrolle kommt nach der Benennung, und in dieser Kampagne war jedes Artefakt drei bis zwölf Stunden live. Die achtzehn Minuten zwischen Veröffentlichung und erster Erfassung beantworten die Frage, ob diese Reihenfolge gut genug war.

Die Kontrollen, die das Ergebnis hier verändern, sind die, die den Namen nicht brauchen.

Eine Uhr, kein Orakel

Bromure Agentic Coding schickt jeden Paketabruf durch den hostseitigen MITM-Proxy, bevor ein Byte die VM erreicht, und die Altersschwelle ist die einzige Lieferkettenschicht, die standardmäßig aktiv ist. Sie verweigert jede Paketversion, die jünger ist als ein Stichwert. Zwei Tage, ab Werk.

Sie führt keinerlei Lookup durch. Sie hat keine Meinung über den Maintainer, den Publisher, die Signatur oder den Namen. Sie liest den Veröffentlichungszeitpunkt und wendet eine Untergrenze an — in der Annahme, dass ein frisches Release am ehesten dasjenige ist, das vor einer Stunde gekapert wurde, und dass es einen arbeitenden Entwickler fast nichts kostet, dieses Fenster abzuwarten.

Gegen diese Kampagne ist das der gesamte Kampf. LiteLLM 1.82.7 und 1.82.8 existierten vierzig Minuten. Eine Zweitagesschwelle bedeutet, dass sie aus Sicht der VM nie existiert haben. Der Proxy entfernt zu frische Versionen aus den Registry-Metadaten und richtet latest und die übrigen Dist-Tags auf die neueste überlebende Version aus, sodass pip install litellm und jeder Semver-Bereich ohne Fehler auf 1.82.6 auflösen — und es nichts gibt, worum ein Agent herumrouten könnte. Fordern Sie eine vergiftete Version per exaktem Pin an, gibt der Artefakt-Abruf-Backstop ein 451 zurück, dessen Body das tatsächliche Alter des Pakets gegen das geforderte Minimum stellt. Pip gibt es wörtlich aus:

Bromure Supply-Chain Security blocked this request: pypi package
[email protected] published 34 minutes ago — policy requires 2 days minimum

Die Schwelle deckt npm, PyPI, Cargo, RubyGems und Packagist mit vollständigen Veröffentlichungszeiten ab. Für pip führt sie einen Lookup auf Abruf gegen die JSON-API von PyPI aus, da der Standard-PEP-503-Index keine Zeitstempel trägt. Jede Entscheidung landet, während sie fällt, im Sicherheitsprotokoll (Fenster → Lieferketten-Protokoll…).

Was ein Speicherabbild einbringt

Der beste Zug des Stealers war, den Speicher des CI-Runner-Workers zu lesen, um Secrets zurückzuholen, die die Log-Maskierung verborgen hatte. Das funktioniert, weil die Maskierung kosmetisch ist und der Prozess die Werte hält.

Lassen Sie ihn gegen einen Bromure-Workspace laufen, und er holt Platzhalter zurück, weil der Prozess Platzhalter hält. Die Leitungsgrenze ist der zentrale Mechanismus des Produkts: Jedes Credential, das Sie konfigurieren, erscheint innerhalb der VM als strukturerhaltende Fälschung, während der echte Wert verschlüsselt auf Ihrem Mac bleibt. Der Host-Proxy setzt ihn erst auf die Leitung, nachdem die Anfrage die VM verlassen hat — und nur, wenn die Anfrage an den Host geht, für den dieses Credential geprägt wurde.

Gehen Sie die eigene Liste des Stealers gegen eine Bromure-VM durch:

Bromure leitet jede Fälschung aus dem echten Wert plus einem installationsspezifischen 32-Byte-Salt über HKDF-SHA256 ab, sodass ein Werkzeug, das seinen eigenen Schlüssel fingerprintet (Claude Code cacht einen Schlüssel-Hash), das Credential nie zwischen Sitzungen rotieren sieht. Es gibt auch keinen Schalter, den man vergessen könnte. Der Proxy ist der einzige Weg der VM ins Netz, also trägt eine Anfrage, die ihn umgeht, einen Platzhalter und scheitert an der Authentifizierung der Gegenstelle. Die Grenze fällt konstruktionsbedingt geschlossen aus.

Der Typosquat, den nie jemand gesehen hatte

Nun zur Exfiltration. Am 19. März hatte scan.aquasecurtiy.org keine Reputation, keine Historie und keinen Grund, auf irgendjemandes Blocklist zu stehen. Genau deshalb wählte TeamPCP ihn.

Bromures Kompromittierungsdetektor liest davon nichts. Er beobachtet Ihre Credentials statt der Reputation des Ziels. Ein Aho-Corasick-Automat, gebaut aus den für den Workspace geprägten Fälschungen, durchsucht jede ausgehende Anfrage, Header und Body. Taucht eine dieser Fälschungen in einer Anfrage an einen Host außerhalb des Bereichs auf, für den sie geprägt wurde, behandelt der Proxy die Anfrage als Exfiltrationsversuch:

1. Der Proxy weist die Anfrage mit HTTP 451 ab und leitet kein einziges Byte an das Ziel weiter.
2. Bromure pausiert die VM auf der Stelle.
3. Eine Meldung benennt, was passiert ist: ein ausgehender Versuch, ein Session-Credential an einen Host zu leaken, für den es nicht geprägt wurde.

Bromure markiert den Workspace anschließend als kompromittiert, und der nächste Start verlangt, das VM-Disk-Image und das persistente Home zu löschen, bevor er bootet. Ihre Tokens, SSH-Schlüssel und Workspace-Einstellungen überstehen das. Der Trace-Inspector (⇧⌘I) und bromure-cli trace leaks zeigen den auffälligen Host und die exakte Anfrage, sodass Sie binnen einer Minute sagen können, ob eine Abhängigkeit oder eine per Prompt injizierte Anweisung verantwortlich war.

Eine AKIA-förmige Prägung mit Geltungsbereich amazonaws.com, die in einem POST an scan.aquasecurtiy.org auftaucht, löst diesen Automaten beim ersten Versuch aus. Der Detektor hat von der Domain nie gehört und muss es auch nicht. Er weiß, dass dieses Credential genau eine legitime Zielfamilie hat und dass dies eine andere ist. Es gibt nichts zu aktivieren; er läuft bei jeder Anfrage.

Die Zeitachse, die Sie schon besitzen

Das Protokollierungsproblem überdauert hier den Vorfall.

Forscher rekonstruierten die Zeitachse von außen, aus einem geleakten 153-GB- Archiv, das erst auftauchen, beschafft und durchgesiebt werden musste, bevor irgendwer sagen konnte, welches Fenster zählte. Die Opfer konnten es aus ihren eigenen Aufzeichnungen nicht beantworten, weil diese Aufzeichnungen die beiden entscheidenden Fakten ausließen: welche Artefakte ihre Pipelines wann abriefen und wohin die daraus entstandenen Prozesse Verkehr schickten.

Ein Bromure-Workspace erzeugt diese Aufzeichnung als Nebeneffekt seiner Arbeitsweise. Jeder Abruf quert den Host-Proxy, also hält das Sicherheitsprotokoll jede Entscheidung von Altersschwelle, OSV, socket.dev und 451 als laufenden Mitschnitt. Jede Anfrage quert denselben Proxy, also liefert bromure-cli trace ls Host, Methode, Status, Latenz und die Marker swap×N / LEAK×N pro Workspace, trace hostnames listet jeden einzelnen Host, den eine Sitzung kontaktiert hat, und trace summary aggregiert das Ganze. Alles bleibt im Ruhezustand auf Ihrem Mac unter dem Master-Key des Vaults verschlüsselt.

So wird die Frage, die SOCRadar im August beantwortete — wurde ich abgeschöpft, und wann? —, zu einer Zwei-Minuten-Abfrage, die Sie schon im März selbst ausführen, gegen Ihre eigenen Daten, ohne darauf zu warten, dass jemand den richtigen Namen veröffentlicht.

Das ist das Argument. Niemand kann das Ökosystem schneller darin machen, Dinge zu benennen: Der März zeigte die Incident Response des Herstellers selbst, die einen neunzehntägigen Nachlauf und eine falsche Attribution hinterließ. Was Sie ändern können, ist, ob Ihr Ergebnis vom Namen abhängt. Setzen Sie eine Uhr vor die Registry, setzen Sie Platzhalter in die Maschine, die den Code ausführt, und führen Sie Ihr eigenes Protokoll darüber, was sie geholt hat und wohin sie gesprochen hat.

---

Quellen: SecurityWeek, „Trivy, Not LiteLLM Behind the 2,500 Org Compromise“ (14. August 2026) · Aqua-Security-Advisory GHSA-69fq-xp46-6x23 · StepSecurity, „Trivy Compromised a Second Time“ · The Hacker News (12. August 2026) · Help Net Security (13. August 2026) · CrowdStrike, „From Scanner to Stealer“