Eine Analyse des Vorfalls in der Lieferkette von Axios

Aktualisiert: 3. April 2026 – Es wurden Details dazu hinzugefügt, wie das Konto ursprünglich kompromittiert wurde.

--

Wenn ein weit verbreitetes Paket kompromittiert wird, gehen die meisten Teams nach einem bewährten Schema vor: Sie überprüfen den Diff, identifizieren die schädliche Version und prüfen, ob diese in ihre Umgebung übernommen wurde. Diese Vorgehensweise ist zwar notwendig, löst das Problem jedoch nur teilweise.  

Axios ist ein ein weit verbreiteter HTTP-Client im npm-Ökosystem. Es ist tief in modernen Anwendungsstacks verankert und in Entwicklertools, Backend-Diensten, Frontend-Frameworks und CI-Pipelines eingebettet. Installationen finden nicht an einem einzigen Ort statt, sondern laufen kontinuierlich auf Arbeitsstationen, Build-Systemen und in Produktionsumgebungen ab. In vielen Fällen werden neue Abhängigkeiten während der Bereitstellung oder bei Skalierungsvorgängen automatisch aufgelöst, was bedeutet, dass eine kompromittierte Version weit über die Entwicklerrechner hinausgelangen kann.

‍

Während des Sicherheitslückenzeitraums führte jede Umgebung, in der die betroffenen Versionen ausgeführt wurden, vom Angreifer kontrollierten Code aus. Genau dieser Umstand sollte die Reaktion bestimmen. Das Problem ist nicht die Versionsnummer oder der Unterschied in den Abhängigkeiten, sondern die Tatsache, dass nicht vertrauenswürdiger Code innerhalb von Systemen ausgeführt wurde, die bereits über privilegierten Zugriff verfügten.  

Was ist eigentlich passiert?

Ein Betreuerkonto für Axios wurde gehackt, wodurch bösartige Versionen veröffentlicht und mit Tags versehen werden konnten, sodass Standardinstallationen auf diese zurückgriffen.

Weitere Angaben des Betreibers deuten darauf hin, dass es sich eher um eine gezielte Social-Engineering-Aktion als um einen einfachen Verlust von Zugangsdaten handelte. Der Angreifer gab sich als legitimes Unternehmen aus, richtete einen überzeugenden Slack-Workspace mit kopiertem Branding und Profilen bekannter Ingenieure ein und vereinbarte ein Live-Meeting über Microsoft Teams. Im Rahmen dieses Gesprächs wurde der Betreiber aufgefordert, ein scheinbar routinemäßiges Update zu installieren, das in Wirklichkeit die malware installierte, malware der Angreifer Zugang zu seiner Umgebung verschaffte.

‍

Von dort aus nutzte der Angreifer diesen Zugriff, um mit einer Hintertür versehene Versionen von axios direkt auf npm zu veröffentlichen und so den üblichen Release-Prozess des Projekts zu umgehen.

Die Änderung selbst war minimal. Eine einzige Abhängigkeit, plain-crypto-js, wurde dem Paket hinzugefügt, aber nirgendwo im Code darauf verwiesen, da dies nicht erforderlich war. Ihr Zweck war die Ausführung, nicht die Funktionalität.  

Diese Abhängigkeit führte zu einer nach der Installation Hook, der während des normalen Betriebs automatisch ausgeführt wurde npm install Prozess. Es gab keine Aufforderung, keine Warnung und keinen Hinweis darauf, dass etwas schiefgelaufen war. Anstatt die endgültige Nutzlast zu enthalten, hat das Skript diente als Tropfer.  

Sobald das Programm ausgeführt wurde, stellte es eine Verbindung zu einer vom Angreifer kontrollierten Infrastruktur her und sendete eine Anfrage, die wie normaler npm-bezogener Datenverkehr aussah. Der Inhalt der Anfrage ahmte legitime Kommunikation mit dem Registry-Server nach, doch das Ziel lag außerhalb des Systems. Die Antwort lieferte eine plattformspezifische Nutzlast, die auf macOS, Windows oder Linux zugeschnitten war; diese wurde anschließend auf die Festplatte geschrieben und im Hintergrund ausgeführt.  

Zu diesem Zeitpunkt war das Ziel bereits erreicht. Auf dem System lief bereits ein Fernzugriffstool, das unabhängig vom Installationsprozess war.  

Der Dropper beseitigte anschließend seine eigenen Spuren. Das Installationsskript wurde gelöscht, und die Paketmetadaten wurden so umgeschrieben, dass sie sauber wirkten. Wer die Abhängigkeiten danach überprüfte, würde nichts offensichtlich Bösartiges entdecken. Die Installation würde legitim erscheinen, obwohl die Schadlast bereits ausgeführt worden war.  

Was diesen Vorfall besonders relevant macht, ist die Tatsache, dass er nicht auf einer offensichtlich schwachen Konfiguration beruhte. Der Betreuer hatte eine Multi-Faktor-Authentifizierung eingerichtet und war dabei, auf vertrauenswürdige Veröffentlichungen mittels OIDC umzustellen. Die älteren Veröffentlichungswege stützten sich jedoch weiterhin auf langlebige npm-Token, die die MFA von ihrer Konzeption her umgehen.  

Diese Koexistenz führte zu der Sicherheitslücke. Die strengere Kontrolle war zwar vorhanden, wurde aber nicht durchgängig durchgesetzt. Der Angreifer musste den vorgesehenen Veröffentlichungsworkflow nicht unterbrechen. Er musste lediglich den Pfad nutzen, der noch verfügbar war.  

Die ersten Diskussionen zwischen dem Betreuer und der Community führten schnell zu einem einheitlichen Ergebnis: Es gab zwar strenge Sicherheitsvorkehrungen, doch veraltete Authentifizierungswege stellten weiterhin ein Sicherheitsrisiko dar.    

‍

‍

‍

Dies ist das Muster, das sich bei Vorfällen in der Lieferkette immer wieder zeigt. Der Angriff erfolgt über die Identitätsdaten, die Schadsoftware wird über vertrauenswürdige Vertriebskanäle verbreitet, und die Ausführung verschmilzt mit dem normalen Verhalten. Wenn die Veränderung bemerkt wird, ist der Code bereits ausgeführt worden.  

‍

Warum sich dies nahtlos in normale Arbeitsabläufe einfügt  

Mit Schadcode versehene Pakete sind nichts Neues, doch dieser Fall sticht hervor, weil er sich nahtlos in normale Entwicklungsabläufe einfügt und gezieltem Zugriff mit einer breiten Verbreitung verbindet.

Wie bereits erwähnt, entscheidet der Exploit selbst selten über den Ausgang. Entscheidend ist vielmehr, was nach der Codeausführung innerhalb der Umgebung geschieht.  

Mehrere Faktoren lassen diesen Vorfall schwerwiegender erscheinen als typische Angriffe auf die Lieferkette.  

Axios ist weit verbreitet, wodurch sich der potenzielle Schadensradius weit über eine einzelne Anwendung oder ein einzelnes Team hinaus erstreckt. Die Gefährdung beschränkte sich nicht auf Organisationen, die explizit darauf angewiesen waren. Jedes Paket, jeder Build-Workflow oder jeder CI-Job, der es während des Zeitfensters transitiv aufgelöst hat, könnte die schädliche Version abgerufen haben, was es schwierig macht, das gesamte Ausmaß der Auswirkungen schnell zu ermitteln.

Die Ausführung erfolgte sofort. Die Schadsoftware wurde innerhalb von Sekunden nach der Installation ausgeführt, häufig über automatisierte Pipelines. Huntress registrierte die erste bekannte endpoint bereits 89 Sekunden nach der Veröffentlichung der schädlichen Version, was verdeutlicht, wie schnell moderne Entwicklungsumgebungen neue Abhängigkeiten auflösen und ausführen.

Gleichzeitig unternahm der Angreifer Schritte, um die Spuren zu verwischen. Das Installationsprogramm löschte sich selbst, die Paket-Metadaten wurden überschrieben, und bei Nachprüfungen nach dem Vorfall gab es keine Anzeichen dafür, dass etwas nicht stimmte. Die Änderung selbst war präzise: Es wurde eine Abhängigkeit hinzugefügt, es gab keine funktionalen Änderungen und keine offensichtlichen Anzeichen, es sei denn, man untersuchte die betreffende Datei genau.

Was diesen Fall zudem besonders macht, ist die Art und Weise, wie er begann. Der Angriff ging nicht vom Paket-Ökosystem selbst aus, sondern von einer gezielten Social-Engineering-Kampagne gegen den Betreuer. Indem der Angreifer auf Vertrauen setzte, anstatt eine technische Schwachstelle auszunutzen, umging er Sicherheitsmaßnahmen wie die Zwei-Faktor-Authentifizierung und verschaffte sich direkten Zugriff auf den Release-Prozess.

Gerade diese Kombination aus gezielter Identitätsmanipulation und Verbreitung über die Software-Lieferkette macht diese Art von Angriffen schwer vorhersehbar und noch schwieriger einzudämmen.

Von der Paketinstallation bis zur Offenlegung von Zugangsdaten

Die Installation ist nur der Einstiegspunkt. Sobald der Dropper ausgeführt wird, übernimmt er die Berechtigungen und Zugriffsrechte des Systems, auf dem er läuft.  

In der Praxis gehören dazu häufig GitHub-Token, npm-Token, cloud , CI/CD-Geheimnisse, API-Schlüssel und SSH-Daten. Keines dieser Elemente muss ausgenutzt werden, da sie bereits in vertrauenswürdigen Umgebungen wie Entwickler-Workstations und Build-Pipelines verfügbar sind.  

Zu diesem Zeitpunkt ist der Angreifer nicht mehr auf das Paket selbst angewiesen. Der Fokus verlagert sich darauf, auf welche Systeme diese zugreifen können und wie dieser Zugriff ausgenutzt werden kann.  

Wir haben bereits gesehen, wie sich dieses Muster entwickelt. Im Fall von Shai-Hulud verlagerte sich der Angriff rasch von der Ausführung hin zum Sammeln und Wiederverwenden von Anmeldedaten und breitete sich unter Ausnutzung bestehender Vertrauensbeziehungen über Repositorys und Pipelines aus.  

Das Paket dient als Übertragungsmedium. Das Risiko ergibt sich daraus, was diese Übertragung ermöglicht.  

Dieses Muster beschränkt sich nicht nur auf npm-Pakete. Beim jüngsten Vorfall bei Trivy nutzten die Angreifer kompromittierte CI/CD-Tools, um Code direkt innerhalb der Build-Pipelines auszuführen und so in großem Umfang cloud , Kubernetes-Geheimnisse und API-Token abzugreifen. Ein anderer Einstiegspunkt, dasselbe Ergebnis: Ausführung innerhalb einer vertrauenswürdigen Umgebung, gefolgt von sofortigem Zugriff auf alles, was diese Umgebung erreichen kann.

Die Sichtbarkeitslücke nach der Installation

Genau hier verlieren die meisten Organisationen den Überblick.  

Es ist relativ einfach festzustellen, ob eine schädliche Version in einer Lockdatei enthalten ist, doch lässt sich daraus nicht ableiten, wo der Code tatsächlich ausgeführt wurde. Build-Protokolle erfassen das Verhalten von losgelösten Hintergrundprozessen nur selten, und Entwicklerrechner unterliegen oft nicht denselben Überwachungsmaßnahmen wie Produktionssysteme.  

Bis die schädliche Abhängigkeit identifiziert und entfernt wurde, hat die ursprüngliche Ausführung bereits stattgefunden, sodass den Teams nur wenige Anhaltspunkte und eine Reihe unbeantworteter Fragen bleiben.  

Hat die Nutzlast auf die Anmeldedaten zugegriffen?

Wurden diese Zugangsdaten wiederverwendet?

Erstreckten sich die Aktivitäten auch auf cloud SaaS-Umgebungen?  

In vielen Fällen lassen sich diese Fragen mit herkömmlichen Werkzeugen allein nicht eindeutig beantworten.  

Eine praktische Methode zur Überprüfung der Exposition

Für Teams, die versuchen, von der Annahme „wir könnten betroffen sein“ zu konkreten Maßnahmen überzugehen, ist die ausgehende Kommunikation einer der schnellsten Indikatoren, den es zu überprüfen gilt.

Wir haben auf der Vectra AI eine spezielle 5-minütige Suche veröffentlicht, um Systeme zu identifizieren, die möglicherweise die bösartige Axios-Payload ausgeführt haben, indem wir nach Kommunikation mit der Infrastruktur des Angreifers gesucht haben.

Im Mittelpunkt dieser Suche steht eine kleine Auswahl besonders zuverlässiger Indikatoren, die mit der Kampagne in Verbindung stehen, darunter der Bereich „Command and Control“ sfrclak.com und die zugehörige IP-Adresse 142.11.206.73. Jedes System, das während oder nach dem Zeitfenster der Gefährdung mit dieser Infrastruktur kommuniziert, sollte als verdächtig eingestuft werden.

Die Abfrage listet Netzwerksitzungen auf, an denen diese Domain oder IP-Adresse beteiligt ist, einschließlich der Quell- und Zielhosts, des Protokolls und der Verbindungshäufigkeit. In der Praxis sollten Analysten besonders auf Systeme achten, die wiederholte oder automatisierte Verbindungen aufweisen, sowie auf Hosts, bei denen bisher keine Kommunikation mit ähnlichen externen Infrastrukturen festgestellt wurde.

Von dort aus kann die Untersuchung zügig voranschreiten. Wechseln Sie zu DNS-, HTTP- und SSL-Telemetriedaten, um den Umfang der Kommunikation zu erfassen, und korrelieren Sie diese anschließend mit endpoint , um den verantwortlichen Prozess zu identifizieren. Wenn sich die Aktivität bestätigt, sperren Sie die Infrastruktur und isolieren Sie das betroffene System zur Behebung des Problems.

Diese Art der gezielten Suche ersetzt zwar keine umfassenden Untersuchungen, bietet den Teams jedoch eine schnelle Möglichkeit, potenziell kompromittierte Systeme zu identifizieren und Prioritäten bei der Reaktion zu setzen. Bei einem Vorfall, bei dem die Ausführung unbemerkt erfolgt und nur wenige Hinweise vorliegen, kann dieses erste Signal die Zeit, die benötigt wird, um zu verstehen, was tatsächlich in Ihrer Umgebung ausgeführt wurde, erheblich verkürzen.

Angriffe auf die Lieferkette konzentrieren sich zunehmend auf Identitäten

Sobald der Zugriff erlangt ist, ist der Angriff nicht mehr auf malware angewiesen. Gültige Anmeldedaten bieten einen zuverlässigeren und schwerer aufdeckbaren Weg, um weiter voranzukommen.  

Angreifer können sich authentifizieren, APIs aufrufen und mit Systemen interagieren, indem sie dieselben Schnittstellen und Arbeitsabläufe nutzen, auf die Entwickler und Automatisierungssysteme täglich zurückgreifen. Dadurch können sie sich in den normalen Betrieb einfügen und gleichzeitig ihren Einflussbereich auf verschiedene Umgebungen ausweiten.  

Das Das Shai-Hulud-Beispiel veranschaulichte, wie dies funktioniert: Gestohlene Token wurden verwendet, um Repositorys zu erstellen, Pipelines zu ändern und über bestehende Vertrauensbeziehungen zu expandieren, ohne dass auf der Ebene einzelner Ereignisse offensichtliche Anomalien auftraten.  

Der Axios-Vorfall bietet dieselbe Gelegenheit. Ein Dienstkonto, das auf Ressourcen zugreift, die es zuvor noch nie genutzt hat, ein Token, das in einem neuen Kontext auftaucht, oder eine Pipeline, die sich anders verhält als erwartet – all dies sind für sich genommen erklärbare Ereignisse. Betrachtet man sie jedoch im Zusammenhang, ergeben sie ein Muster, das eher auf einen Missbrauch von Zugriffsrechten als auf einen normalen Betriebsablauf hindeutet.  

Erkennen, was nach dem Einbruch geschieht

Sobald der Code ausgeführt wurde, verlagert sich der Schwerpunkt von der Prävention hin zum Verständnis, wie der Zugriff genutzt wird.  

Eines der ersten Anzeichen in dieser Angriffskette ist die ausgehende Kommunikation mit der Command-and-Control-Infrastruktur. Selbst wenn der Dropper seine eigenen Artefakte entfernt, bleibt diese Netzwerkaktivität bestehen. Ungewöhnliche externe Verbindungen von Entwicklerrechnern, CI-Runner oder Anwendungsumgebungen können ein deutliches Anzeichen dafür sein, dass etwas nicht stimmt, insbesondere wenn das Ziel nicht mit dem erwarteten Abhängigkeits- oder Build-Verhalten übereinstimmt.  

Die Vectra AI konzentriert sich darauf, diese Muster über Identitätssysteme, cloud SaaS-Umgebungen sowie Netzwerkaktivitäten hinweg zu identifizieren. Sie deckt Authentifizierungsverhalten auf, das nicht dem etablierten Nutzungsverhalten entspricht, hebt Zugriffsmuster hervor, die vom erwarteten Workload-Verhalten abweichen, und erkennt Aktivitäten, die auf Vorbereitung, Persistenz oder laterale Bewegung hindeuten.  

Für sich genommen fallen diese Signale vielleicht nicht besonders auf. In ihrer Gesamtheit zeigen sie jedoch, ob ein Vorfall bereits in der Ausführungsphase gestoppt wurde oder zu einer umfassenderen Kompromittierung führte.

Um genauer zu untersuchen, wie sich diese Muster nach der Ausnutzung in verschiedenen Umgebungen zeigen, wird in dieser Analyse die Untersuchung aus der Perspektive der Erkennung beleuchtet.  

Worauf Sie sich weiterhin verlassen können  

Der Axios-Vorfall endet nicht mit der Entfernung eines schädlichen Pakets. Er markiert den Punkt, an dem Gewissheit der Risikobewertung weicht.  

Die meisten Teams können feststellen, ob die betroffenen Versionen vorhanden waren. Weniger Teams können jedoch ermitteln, wo diese ausgeführt wurden oder welche Umgebungen zu diesem Zeitpunkt gefährdet waren. Dieser Unterschied ist entscheidend, da er darüber entscheidet, ob der Vorfall auf einen begrenzten Bereich beschränkt war oder ob dadurch dauerhafter Zugriff ermöglicht wurde.  

Sollte auch nur die geringste Möglichkeit bestehen, dass die kompromittierten Versionen ausgeführt wurden, ist die sicherste Annahme, dass der bisherigen Umgebung nicht mehr vertraut werden sollte. Entwicklerrechner, CI-Runner und Build-Systeme verfügen oft über mehr Zugriffsrechte als beabsichtigt, und diese Zugriffsrechte werden selten vollständig erfasst.  

Die erste Maßnahme ist ganz einfach: Auf eine saubere Version zurücksetzen, die Abhängigkeit entfernen und die betroffenen Systeme neu kompilieren, anstatt eine teilweise Bereinigung zu versuchen. Der schwierigere Schritt besteht darin, zu entscheiden, was danach noch als vertrauenswürdig gilt.  

Anmeldedaten, die mit diesen Umgebungen in Verbindung stehen, sollten als kompromittiert behandelt werden – nicht weil es Beweise für einen Missbrauch gibt, sondern weil es keine zuverlässige Möglichkeit gibt, das Gegenteil zu beweisen. Eine regelmäßige Änderung der Anmeldedaten ist erforderlich, um das Vertrauen wiederherzustellen.  

Dieser Vorfall verdeutlicht zudem strukturelle Probleme beim Umgang mit Abhängigkeiten. CI/CD-Pipelines, die automatisch die neuesten verfügbaren Versionen einbinden, schaffen einen direkten Weg, über den neu veröffentlichte schädliche Pakete sofort ausgeführt werden können. Durch die Einführung einer Verzögerung zwischen Veröffentlichung und Übernahme sowie durch strengere Versionsbindung lässt sich das Risiko verringern, da so vor der Bereitstellung Zeit bleibt, um Probleme aufzudecken.  

Gleichzeitig bleibt die Hauptursache der Identitätsmissbrauch. Konten für die Wartung und Bereitstellung sollten als besonders wertvolle Ressourcen behandelt werden, wobei klar zwischen dem Zugriff für die tägliche Entwicklungsarbeit und den Berechtigungen für die Veröffentlichung unterschieden werden muss. Eine geringere Abhängigkeit von langlebigen Tokens und strengere Kontrollen bei Veröffentlichungsworkflows begrenzen die Auswirkungen dieser Art von Angriffen.  

Die allgemeine Erkenntnis gilt für alle Vorfälle in der Lieferkette gleichermaßen. Der Einstiegspunkt mag zwar eine kompromittierte Abhängigkeit sein, doch die Auswirkungen hängen davon ab, wie der Zugriff anschließend genutzt wird. Die Kompromittierung von Axios war zwar nur von kurzer Dauer, doch die dadurch geschaffenen Bedingungen können weit über das Installationsfenster hinaus bestehen bleiben.