Das populäre JavaScript-HTTP-Client-Paket Axios, das laut npm-Statistiken rund 100 Millionen Downloads pro Woche verzeichnet, ist Ziel einer präzise vorbereiteten Supply-Chain-Attacke geworden. Statt eine Schwachstelle im Code auszunutzen, kompromittierten Angreifer die Zugangsdaten des Maintainers und veröffentlichten manipulierte Paketversionen – ein Szenario mit erheblichem Risiko für die gesamte JavaScript-Ökosystemkette.
Gezielte Supply-Chain-Attacke auf Axios: Hintergrund und Attribution
Nach aktuellen Analysen wird der Vorfall einer hochgradig zielgerichteten Social-Engineering-Kampagne zugeschrieben, die Sicherheitsforscher mit der nordkoreanischen Gruppe UNC1069 (BlueNoroff) in Verbindung bringen. Diese Gruppe ist bereits durch Angriffe auf Krypto-Unternehmen und Finanzinstitute bekannt. Die aktuelle Operation knüpft an das von Huntress und Kaspersky dokumentierte Kampagnenmuster „GhostCall“ an, bei dem speziell Entwickler, Gründer und technisches Führungspersonal ins Visier genommen werden.
Social Engineering gegen den Axios-Maintainer: Virtuelles Unternehmen als Köder
Der Angriff auf Axios basierte auf Identitäts- und Markenimitation. Die Täter gaben sich als Gründer eines real existierenden, renommierten Unternehmens aus und reproduzierten dessen digitale Identität mit hohem Detailgrad. Dazu gehörten gefälschte Profile, Kommunikationsstil sowie eine speziell eingerichtete Infrastruktur, um Authentizität vorzutäuschen.
Der Maintainer wurde zunächst in einen manipulierten Slack-Workspace eingeladen, der wie eine echte Unternehmensumgebung wirkte: mit Logos, thematischen Kanälen und Links zu tatsächlichen LinkedIn-Beiträgen. Diese Elemente dienten dazu, Vertrauen aufzubauen und die Wahrnehmung einer legitimen Zusammenarbeit zu verstärken.
Missbrauch von Collaboration-Tools: Von Teams-Call zu Remote-Access-Trojaner
In einem nächsten Schritt arrangierten die Angreifer ein angebliches Meeting über Microsoft Teams. Während dieses Gesprächs erschien ein täuschend echt gestalteter „Systemhinweis“, der auf ein angeblich veraltetes Komponenten-Update hinwies. Der Maintainer wurde dazu gebracht, ein vermeintliches Update auszuführen, das in Wirklichkeit einen Remote-Access-Trojaner (RAT) installierte.
Ein RAT ermöglicht Angreifern vollständigen Fernzugriff auf das kompromittierte System, inklusive Tastatureingaben, Dateizugriff und Zugriff auf gespeicherte Zugangsdaten. In diesem Fall konnten so sensible npm-Credentials exfiltriert werden, die für die Veröffentlichung neuer Paketversionen genutzt werden.
Manipulierte Axios-Versionen: WAVESHAPER.V2 im npm-Ökosystem
Mit den gestohlenen Zugangsdaten veröffentlichten die Angreifer zwei trojanisierte Axios-Versionen: 1.14.1 und 0.30.4. Beide enthielten eine Schadkomponente mit der Bezeichnung WAVESHAPER.V2. Dieser Bestandteil war so eingebettet, dass er im normalen Entwicklungsalltag nicht unmittelbar auffällt, aber potenziell als Backdoor oder zur Datenausleitung dienen kann.
Besonders kritisch: Axios fungiert in vielen Projekten als Basisabhängigkeit für andere Bibliotheken. Dadurch verteilt sich ein kompromittiertes Paket nicht nur direkt an Projekte, die Axios explizit einbinden, sondern auch transitiv über nachgelagerte Abhängigkeiten. Vergleichbare Supply-Chain-Vorfälle – etwa beim npm-Paket event-stream (2018) oder ua-parser-js (2021) – zeigen, wie schwierig es ist, den tatsächlichen Verbreitungsradius zu bestimmen.
Systemische Risiken für JavaScript-Supply-Chain-Sicherheit
Moderne JavaScript-Anwendungen basieren häufig auf Dutzenden bis Hunderten von npm-Modulen. Automatisches Dependency-Resolving, Continuous-Integration-Pipelines und Standardpraktiken wie „immer auf die neueste Version aktualisieren“ schaffen eine Umgebung, in der ein einzelner kompromittierter Baustein weitreichende Folgen haben kann.
Der Axios-Vorfall unterstreicht, dass die zentrale Schwachstelle nicht nur im Code liegt, sondern im Vertrauen in die Veröffentlichungs- und Lieferkette. Wird ein Maintainer-Account kompromittiert, verwandelt sich ein eigentlich vertrauenswürdiges Open-Source-Projekt in ein potenzielles Einfallstor – mit Auswirkungen von kleinen Start-ups bis hin zu großen Unternehmensanwendungen.
Reaktion des Maintainers: Stärkung der npm-Veröffentlichungskette
Nach Entdeckung des Vorfalls leitete der Axios-Maintainer mehrere Maßnahmen ein, um die Integrität zukünftiger Releases zu erhöhen. Zunächst erfolgte ein vollständiger Reset von Geräten und Zugangsdaten, einschließlich der npm-Accounts, um versteckte Persistenzmechanismen der Angreifer auszuschließen.
Darüber hinaus wurden „immutable releases“ eingeführt: Einmal veröffentlichte Versionen können nicht mehr nachträglich verändert werden. Dieses Prinzip reduziert das Risiko, dass existierende Artefakte im Nachhinein ausgetauscht oder manipuliert werden – eine Best Practice, die zunehmend auch von Paketregistern selbst gefordert wird.
Ein weiterer zentraler Schritt war der Umstieg auf OIDC-basierte Veröffentlichungen. Anstatt statischer Tokens kommen nun kurzlebige, kontextgebundene Berechtigungen im Rahmen eines OpenID-Connect-Flows zum Einsatz. Dadurch werden gestohlene Tokens weitgehend wertlos, da ihr Einsatz zeitlich und technisch stark eingeschränkt ist.
Begleitend wurden die GitHub-Actions-Workflows nach aktuellen Best Practices gehärtet: Minimierung von Berechtigungen („least privilege“), striktere Kontrolle von Build-Kontexten, Integritätsprüfungen von Artefakten sowie eine engere Validierung aller automatisierten Aktionen im CI/CD-Prozess.
Konkrete Empfehlungen für Entwickler und Unternehmen
Der Angriff auf Axios macht deutlich, dass Supply-Chain-Sicherheit im JavaScript-Bereich nicht länger optional ist. Organisationen sollten mindestens folgende Maßnahmen prüfen und umsetzen: Multi-Faktor-Authentifizierung für alle kritischen Accounts (idealerweise mit Hardware-Sicherheitsschlüsseln), strikte Rollen- und Rechtekonzepte in CI/CD-Pipelines, sowie den Einsatz von Software-Composition-Analysis-(SCA)-Tools, um verwundbare oder kompromittierte Abhängigkeiten frühzeitig zu erkennen.
Ebenso wichtig ist ein systematisches Security-Awareness-Training für Entwicklerteams mit Fokus auf komplexe Social-Engineering-Szenarien, die weit über einfache Phishing-Mails hinausgehen. Gefälschte Slack-Workspaces, künstlich aufgebaute „Unternehmen“ und manipulierte Video-Calls zeigen, dass Angreifer heute signifikant in Täuschungsinfrastruktur investieren, um an Schlüsselzugänge in der Open-Source-Lieferkette zu gelangen.
Wer Open-Source intensiv nutzt oder selbst Pakete veröffentlicht, sollte seine Prozesse jetzt kritisch überprüfen: von der Härtung der Entwicklerendpunkte über kryptographische Signierung von Releases bis hin zu klaren Incident-Response-Plänen für Supply-Chain-Vorfälle. Je schneller diese Praktiken zum Standard werden, desto schwieriger wird es Angreifern, das Vertrauen in Open-Source-Projekte als Waffe gegen Anwender einzusetzen.
