Wie wir den Axios-Lieferkettenangriff aufgedeckt haben

Präambel

Letzten Montagabend arbeitete ich bis spät in die Nacht, als eine Slack-Benachrichtigung von einem Überwachungstool einging, das ich drei Tage zuvor entwickelt hatte. Axios wurde kompromittiert; eines der beliebtesten npm-Pakete der Welt.

Mein Herz raste, ich wusste, jede Sekunde zählte, um zu reagieren und den Schaden zu begrenzen. Aber ehrlich gesagt war es so verrückt, dass ich dachte, es müsse ein falsch positives Ergebnis sein. Ich habe alles mehrmals überprüft, obwohl es ganz offensichtlich böswillig wirkte.

Es handelte sich nicht um ein falsch positives Ergebnis. Es handelte sich um einen der größten Lieferkettenkompromisse, die jemals auf npm vorkamen, wobei die Verantwortung mutmaßlich nordkoreanischen Staatsakteuren zuzuschreiben ist. Wir haben es mit einem Prototyp geschafft, den ich an einem Freitagnachmittag zusammengebastelt hatte und der auf meinem Laptop lief und von einer KI unterstützt wurde, die die Unterschiede auslas.

Ich möchte die ganze Geschichte erzählen. Wie wir hierher gekommen sind, was ich aufgebaut habe und warum ich glaube, dass es alle ein bisschen sicherer macht, wenn wir das offen teilen.

Ich mache mir schon seit einiger Zeit Sorgen um die Lieferkette.

Einige jüngste Vorfälle in der Lieferkette haben mir wirklich schlaflose Nächte bereitet. Kompromisse in der Lieferkette stellen ein schwieriges Problem dar. Bei Elastic arbeiten so viele Entwickler, und unsere Sicherheitskunden vertrauen darauf, dass wir sie schützen. Es ist deutlich geworden, dass der Status quo nicht mehr funktioniert und wir neue Technologien oder Verfahren benötigen, um Abhilfe zu schaffen. Ich hatte einige Ideen für ein vertrauenswürdigeres, KI-geprüftes Ökosystem, das auf App-Kontrollprinzipien aufbaut und gleichzeitig Kosten und Reibungsverluste minimiert.

Aber der Trivy-Kompromiss war der Punkt, an dem ich wirklich aufmerksam wurde. Am 19. März kompromittierte eine Gruppe namens TeamPCP die GitHub-Aktion aquasecurity/trivy-action (diejenige für den beliebten Sicherheitsscanner Trivy, ja, ein Sicherheitstool). Sie schleusten einen Credential-Stealer ein, der Geheimnisse aus CI/CD-Pipelines sammelte. Es wurde eine große Menge an Zugangsdaten gestohlen.

Das ging rasend schnell. Am 24. März wurde LiteLLM getroffen. TeamPCP hatte die PyPI-Veröffentlichungszugangsdaten von LiteLLM über die manipulierte Trivy-Pipeline gestohlen und sie benutzt, um bösartige Versionen zu verbreiten, die aggressive Zugangsdatendiebe waren. SSH-Schlüssel, Cloud-Zugangsdaten, API-Schlüssel, Wallet-Daten, einfach alles.

LiteLLM ist ein Paket, das ich selbst verwendet habe. Man könnte also sagen, dass ich zu diesem Zeitpunkt durchgehend „nachts wach“ war.

Mir war klar, dass nach all den durch den Trivy-Datendiebstahl durchgesickerten Zugangsdaten definitiv noch mehr folgen würden. Wir mussten etwas unternehmen, um dem zuvorzukommen. Sowohl im Interesse unserer Kunden als auch zum Schutz von Elastic.

Freitag, nach dem Nachtflug

Ich war gerade von der RSAC 2026 in San Francisco zurückgeflogen. Nachtflug Donnerstagabend. Wer schon mal nach vier Konferenztagen einen Nachtflug genommen hat, weiß, in welchem Zustand ich war. Ich war jedoch wie immer voller Vorfreude auf ein neues Projekt, also setzte ich mich hin und entwarf Version 0.0.1.

Die Idee: Änderungen überwachen, sobald sie in die Paket-Repositories übertragen werden. Führe einen Diff durch, um zu sehen, was sich geändert hat. Verwenden Sie KI/LLM, um festzustellen, ob die Änderungen böswillig sind. Das ist im Grunde alles.

Die Pipeline sieht folgendermaßen aus:

Überprüfe die Changelog-API von PyPI und den CouchDB _changes -Feed von npm auf neue Versionen.
Filtern Sie anhand einer Watchlist der 15.000 Pakete mit den meisten Downloads.
Laden Sie die alten und neuen Versionen direkt aus der Registry herunter (keine Installation über pip oder npm, keine Codeausführung).
Diff sie in einen Markdown-Bericht um.
Senden Sie den Diff an einen LLM: "Ist das böswillig?"
Falls ja, melde dies in Slack.

Ich wollte mich hauptsächlich auf die Top-Pakete konzentrieren, da Angreifer höchstwahrscheinlich ohnehin dorthin gehen würden und dies in Bezug auf Token und Rechenleistung viel weniger kostspielig wäre. Es ließ sich problemlos auf meinem Laptop ausführen.

Warum Cursor

Es gibt eine Menge Agentengurte auf dem Markt. Ich habe meine eigenen für Projekte wie das Reverse Engineering von KI-Malware geschrieben. Da ich aber sehr wenig Zeit hatte, entschied ich mich für Cursor , da es eines meiner wichtigsten Entwicklungswerkzeuge ist. Über die Agent-CLI können Sie sie programmatisch aufrufen: Sie übergeben einen Arbeitsbereich, eine Anweisung und ein Modell. Ich führe es im ask -Modus (schreibgeschützt) aus, sodass es nur die Unterschiede lesen, aber niemals etwas verändern kann. Der gesamte Analyseschritt ist ein einziger Unterprozessaufruf.

Die Aufgabenstellung ist einfach. Ich sage ihm, wonach es suchen soll (verschleierter Code, Base64, exec/eval, unerwartete Netzwerkaufrufe, Steganographie, Persistenzmechanismen, Missbrauch von Lebenszyklusskripten) und bitte es, mit Verdict: malicious oder Verdict: benign zu antworten. Analysiere das Urteil und handle entsprechend.

Zur Modellauswahl

Für die meisten Dinge verwende ich normalerweise Opus 4.6 oder GPT 5.4. Opus speziell für Aufgaben mit Schwerpunkt Cybersicherheit. Ich wollte aber die Kosten niedrig halten für etwas, das Dutzende von Veröffentlichungen pro Stunde analysieren muss.

In letzter Zeit gab es einige wirklich gute Blogbeiträge vom Cursor-Team, einen über die schnelle Regex-Suche für Agenten-Tools und einen weiteren über ihren Echtzeit-RL-Ansatz, bei dem sie tatsächliche Produktions-Inferenz-Token als Trainingssignale verwenden und etwa alle fünf Stunden verbesserte Checkpoints bereitstellen. Wirklich beeindruckende Ingenieurskunst.

Ich wollte Composer 2 also mal ausprobieren. Ich habe den Schnellmodus benutzt, der wirklich schnell ist. Perfekt für Echtzeit-Anwendungen. Kostengünstig, schnell und effektiv (in meinen Tests).

Test auf Telnyx

Man muss diese Dinge testen, um zu wissen, ob sie tatsächlich funktionieren. Das bedeutet in der Regel, dass man die Eingabeaufforderungen ordentlich anpassen muss.

Ich hatte Glück (oder Pech) mit dem Timing. Am selben Freitag, an dem ich das hier baute, wurde das telnyx PyPI-Paket von TeamPCP kompromittiert . Sie injizierten 74 Zeilen bösartigen Codes in _client.py: in WAV-Audiodateien versteckte Nutzdaten (Steganografie), Base64-Verschleierung, ein als msbuild.exe getarntes Windows-Persistenzimplantat und Exfiltration zu einem fest codierten C2.

Ich habe die Unterschiede zwischen dem legitimen und dem bösartigen telnyx -Paket verwendet, um die anfängliche Eingabeaufforderung zu erstellen. Das Modell war sehr gut darin, solche bösartigen Änderungen zu erkennen. Ich wollte außerdem sofort benachrichtigt werden, wenn eine Kompromittierung festgestellt wird, deshalb habe ich Slack-Benachrichtigungen hinzugefügt.

Montagabend

Ich habe es übers Wochenende laufen lassen. Es gab zahlreiche Veröffentlichungen, die sich alle als harmlos erwiesen.

Ich habe keinen einzigen Fehlalarm erhalten, was ehrlich gesagt seltsam ist, wenn man jemals im Bereich der Cybersicherheitserkennung gearbeitet hat. Wir ertrinken normalerweise in FPs. Ich habe das LLM absichtlich so eingestellt, dass es nur bei „hochvertraulichen“ Kompromittierungen der Lieferkette Alarm schlägt, da es standardmäßig in der Regel sehr schnell reagiert. Der Telnyx-Testfall läuft immer noch problemlos, ohne dass Fehlalarme auftreten. Bei einer so geringen Stichprobengröße könnte es sich um Überanpassung handeln, aber es bleibt keine Zeit, etwas Robusteres zu entwickeln.

Dann, am Montagabend, als ich spät dran war, kam die Slack-Benachrichtigung.

🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4

Wurde damit tatsächlich einer der größten Kompromisse in der Lieferkette der jüngeren Geschichte aufgedeckt?

Ich habe die Analyse überprüft. Ich habe es nochmal überprüft. Ich habe es noch einmal überprüft. Die Angreifer hatten sich Zugang zum npm-Konto eines Maintainers verschafft, die E-Mail-Adresse in ein von ihnen kontrolliertes ProtonMail-Konto geändert und zwei bösartige Versionen (1.14.1 und 0.30.4) veröffentlicht. Sie haben keinen Code direkt in Axios eingeschleust. Stattdessen fügten sie eine Phantomabhängigkeit namens plain-crypto-js hinzu, die einen Postinstall-Hook ausführte, der plattformübergreifende Malware bereitstellte. Es war ganz offensichtlich böswillig.

Die Antwort

Ich habe mich umgehend an unser Informationssicherheitsteam und unser Forschungsteam bei Elastic gewandt, um sie in Betrieb zu nehmen. Ich wusste, dass jede Sekunde zählte. Es stellte sich heraus, dass sie, als ich sie kontaktierte, bereits Elastic Defend-Warnungen auf einem Host erhalten hatten, auf dem das schädliche Paket installiert war, und aktiv darauf reagierten. Zu diesem Zeitpunkt hatte aber noch niemand das Ausmaß des Problems erkannt oder eine grundlegende Erklärung dafür gefunden, wie die Maschine infiziert wurde. Das Überwachungstool lieferte den fehlenden Kontext.

Ich habe versucht, eine E-Mail an security@npmjs zu senden, und habe eine Unzustellbarkeitsbenachrichtigung erhalten. Ich habe versucht, meine Daten an deren Sicherheitsportal zu übermitteln, und erhielt eine Fehlermeldung. In meiner Verzweiflung twitterte ich, um einen Menschen zu erreichen. Ich habe außerdem umgehend ein Sicherheitsproblem im Axios-Repository selbst gemeldet.

Später sah ich einen Tweet von einem anderen Forscher, der die Kompromittierung beobachtet hatte, und mir wurde klar, dass ich dies eher als eine Schwachstelle denn als einen Vorfall in der Lieferkette behandelte. Mit einer Verwundbarkeit koordiniert man sich im Stillen. Angesichts einer aktiven Sicherheitslücke, die derzeit Malware auf den Rechnern der Nutzer installiert, ist ein umfassender und offener Ansatz die richtige Entscheidung. Deshalb habe ich X umgehend alle von mir zusammengetragenen Details mitgeteilt.

Wir erhielten sogar Warnmeldungen von unseren Telemetriedaten, die betroffene Organisationen in freier Wildbahn aufzeigten. Das Gerät lief aktiv.

Zum Glück hat das Axios-Team sofort reagiert und die Pakete ziemlich schnell entfernt. Außerdem erhielt der C2-Server des Angreifers so viele Anfragen, dass er zusammenbrach. Es hätte viel schlimmer kommen können.

Unser Team bei Elastic Security Labs hat ausführliche technische Berichte über den Sicherheitsvorfall veröffentlicht. Der erste Teil behandelt die gesamte Angriffskette, die plattformübergreifende Malware und das C2-Protokoll: Einblick in die Axios-Lieferkettenkompromittierung – ein RAT, sie alle zu beherrschen. Der zweite Abschnitt behandelt Jagd- und Erkennungsregeln für Linux, Windows und macOS: Elastic veröffentlicht Erkennungsmaßnahmen für die Axios-Lieferkettenkompromittierung.

Wie geht es von hier aus weiter?

Die aktuelle Lage ist nicht gut, und wir müssen uns als gesamtes Software-Ökosystem verbessern, ganz zu schweigen von der Sicherheitsbranche.

In zwei Wochen im März:

Trivy (ein Sicherheitsscanner) wurde kompromittiert, um CI/CD-Geheimnisse zu stehlen.
LiteLLM wurde mithilfe dieser gestohlenen Geheimnisse kompromittiert.
Telnyx wurde in derselben Kampagne kompromittiert.
Axios, eines der meistgenutzten Pakete in npm, wurde von einem mutmaßlichen nordkoreanischen Akteur kompromittiert.
und mehr

Paketregister sind kritische Infrastruktur. Die Teams, die PyPI und npm betreiben, leisten großartige Arbeit, aber die Bedrohung hat sich so weit entwickelt, dass die aktuellen Vertrauensmodelle damit nicht mehr umgehen können. Wir benötigen eine bessere automatisierte Überwachung von Paketänderungen. Nicht nur das Scannen von Signaturen, sondern das tatsächliche Verstehen der Funktion des Codes. LLM-Absolventen sind darin wirklich gut, wie dieses Projekt zeigt. Und wir brauchen eine schnellere Rotation der Zugangsdaten nach Sicherheitsvorfällen. Die Kettenreaktion von Trivy über Litellm zu Telnyx entstand, weil gestohlene Credits nicht schnell genug rotiert wurden.

Eine praktische Sache, die Sie jetzt sofort tun können: Installieren Sie Paketaktualisierungen nicht sofort. Füge eine Einweichzeit hinzu. Neue Versionen sollten eine gewisse Zeit lang verfügbar sein, bevor sie in Ihre Builds integriert werden. Wir tun dies mit unseren CI/CD-Systemen bei Elastic als Reaktion auf shai-hulud. Das wird zwar nicht alles verhindern, aber es gibt der Community Zeit, Sicherheitslücken zu erkennen, bevor sie Ihre CI/CD-Pipelines und Entwicklerrechner erreichen. Die gute Nachricht ist, dass viele Paketmanager native Unterstützung dafür hinzugefügt haben. Um beispielsweise eine 7-tägige Verzögerung durchzusetzen:

npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"

Wir veröffentlichen dies als Open Source.

Wir veröffentlichen das Tool: Supply-Chain-Monitor

Ich möchte von Anfang an ehrlich sein. Es handelt sich um einen Machbarkeitsnachweis. Ich habe es an einem Nachmittag ohne Schlaf gebaut. Ich erwarte nicht, dass es irgendjemand im Produktionsmaßstab einsetzen wird. Für die LLM-Analyse ist ein Cursor-Abonnement erforderlich, die Veröffentlichungen werden sequenziell verarbeitet und die Watchlists sind statisch.

Aber der Ansatz funktioniert. Durch den Vergleich von Paketversionen in Echtzeit und den Einsatz von KI zur Klassifizierung der Änderungen konnte ein Lieferkettenangriff auf eines der beliebtesten Pakete in npm aufgedeckt werden.

Ich teile dies, weil es für die Gemeinschaft am besten ist, aus unseren Erfahrungen zu lernen. Wenn jemand diese Idee aufgreift und etwas Besseres daraus macht, umso besser. Wenn ein Paketregistrierungsteam dies in seine Pipeline integriert, umso besser. Wenn es bedeutet, dass jemand anderes beim nächsten Mal einen großen Spielzug macht, hat es sich gelohnt.

So funktioniert es (für Neugierige)

Monitoring: Zwei Threads fragen PyPI (über changelog_since_serial() XML-RPC) und npm (über CouchDB _changes Feed) ab. Neuerscheinungen, die den Top-N-Listen entsprechen, werden in die Warteschlange gestellt. Der Zustand bleibt bis last_serial.yaml erhalten, sodass er dort fortgesetzt wird, wo er unterbrochen wurde.

Vergleich: Alte und neue Versionen wurden direkt von Registry-APIs heruntergeladen. Keine Installation per pip/npm, keine Codeausführung. Archive extrahiert, Dateien gehasht, Unified-Diff-Bericht in Markdown generiert.

Analyse: Der Diff-Bericht wird im Nur-Lese-Modus an die Cursor Agent CLI gesendet. Prompt fordert es auf, nach Indikatoren für die Lieferkette zu suchen. Die Ausgabe wurde zur Ermittlung des Ergebnisses ausgewertet.

Warnung: Bei einem bösartigen Urteil wird eine Slack-Nachricht mit dem Paketnamen, dem Rang, dem Registry-Link und einer Zusammenfassung der Analyse ausgelöst.

KI im Bereich Sicherheit, über dieses Projekt hinaus

Die Sicherheit der Lieferkette ist ein großes Problem, aber wir sind nicht machtlos. Künstliche Intelligenz gibt uns neue Werkzeuge an die Hand, um uns in großem Umfang und mit Maschinengeschwindigkeit zu verteidigen. Dieses Projekt ist ein Beispiel dafür, wie KI zur Lösung eines Sicherheitsproblems eingesetzt wird, aber wir haben im Bereich Elastic Security insgesamt schon viele interessante Arbeiten mit KI durchgeführt. Eine Sache möchte ich hervorheben: Unser Team hat kürzlich einen Beitrag über die Verwendung von Attack Discovery, Workflows und Agent Builder zur automatischen Erkennung und Bestätigung von APT-Angriffen veröffentlicht. Dies zeigt die Leistungsfähigkeit der Elastic Platform, die agentenbasierte Sicherheit bietet, um die Effizienz und Effektivität Ihres SOC in einer Zeit, in der wir alle von Angriffen überflutet werden, deutlich zu verbessern.

Das Supply-Chain-Monitor-Projekt ist unter github.com/elastic/supply-chain-monitor verfügbar.

Vielen Dank an das Elastic Infosec-Team für die schnelle Reaktion auf den Vorfall, an die axios-Maintainer für die schnelle Abschaltung und an die Sicherheits-Community für die gemeinsame Anstrengung, die den Schaden begrenzt hat.