Eine der am weitesten verbreiteten JavaScript-Bibliotheken für HTTP-Anfragen, Axios, ist Ziel einer gezielten Supply-Chain-Attacke geworden. Die Google Threat Intelligence Group führt die Kompromittierung des npm-Pakets offiziell auf die finanziell motivierte nordkoreanische Gruppe UNC1069 zurück, die seit Jahren Krypto-Unternehmen und Entwickler ins Visier nimmt.
Supply-Chain-Angriff auf Axios: Ablauf und Technik
Die Angreifer verschafften sich nach aktuellem Kenntnisstand Zugang zum npm-Konto eines Maintainers und veröffentlichten zwei manipulierte Versionen von Axios: 1.14.1 und 0.30.4. Anstatt den Axios-Quellcode direkt zu verändern, wurde eine neue Abhängigkeit eingeführt: das Paket plain-crypto-js, das die eigentliche Schadfunktionalität enthielt.
Kritisch für den Angriff war die Nutzung des postinstall-Mechanismus in der package.json von plain-crypto-js. Bei Installation einer der kompromittierten Axios-Versionen führt npm automatisch das definierte postinstall-Skript aus. Für Entwickler wirkt dies wie ein normales Update, im Hintergrund wird jedoch unbemerkt beliebiger Code ausgeführt und die Infektionskette gestartet.
SILKBELL-Dropper und plattformübergreifende Backdoor-Payloads
Das Paket plain-crypto-js fungierte als Transportmittel für einen stark verschleierten JavaScript-Dropper namens SILKBELL (Datei setup.js). Dieser Dropper verband sich mit einem entfernten Command-and-Control-Server (C2) und lud je nach Betriebssystem der Zielumgebung unterschiedliche Payloads nach: PowerShell-Malware für Windows, einen Mach-O-C++-Binary für macOS sowie einen Python-Backdoor für Linux.
Besonders problematisch ist die integrierte Selbstbereinigung. Nach Ausführung ersetzte SILKBELL die package.json von plain-crypto-js durch eine „saubere“ Version ohne postinstall-Hook und entfernte Spuren der ursprünglichen Malware. Dadurch wird forensische Analyse erheblich erschwert, weil offensichtliche Artefakte im Nachgang fehlen.
UNC1069 und der Backdoor WAVESHAPER.V2
Forscher von Google und Mandiant ordnen die über Axios ausgerollte Haupt-Payload einer Weiterentwicklung des C++-Backdoors WAVESHAPER zu, intern als WAVESHAPER.V2 bezeichnet. Elastic Security Labs hatte zuvor auf funktionale Überschneidungen mit früheren Kampagnen gegen Krypto-Unternehmen hingewiesen.
WAVESHAPER.V2 kommuniziert mit dem C2-Server über JSON-formatierte Daten, sammelt detaillierte Systeminformationen und unterstützt einen erweiterten Befehlssatz. Charakteristisch bleiben das Abfrageintervall von rund 60 Sekunden, die dynamische Übergabe der C2-Adresse über Kommandozeilenargumente sowie ein selten verwendeter User-Agent-String. Beide Versionen legen zusätzliche Payloads in ähnlichen temporären Pfaden ab, etwa /Library/Caches/com.apple.act.mond auf macOS.
UNC1069 ist laut öffentlich zugänglichen Analysen mindestens seit 2018 aktiv und fokussiert sich auf finanzielle Ausbeutung, insbesondere Kryptodiebstahl. Die Bereitstellung angepasster Payloads für Windows, macOS und Linux deutet auf eine gut vorbereitete, breit angelegte Kampagne hin, die vor allem Entwicklerumgebungen und CI/CD-Pipelines treffen soll.
Risiken für npm-, PyPI- und NuGet-Ökosysteme
Axios wird in unzähligen Webanwendungen, internen Tools und Automatisierungs-Workflows eingesetzt. Eine kompromittierte Version kann daher schnell in Build-Pipelines, Container-Images und Produktionsumgebungen diffundieren. Sicherheitsforscher bewerten die Aktion als skalierbare Musterkampagne, nicht als Einzelfall: schnelle Veröffentlichung manipulierte Releases in zwei Versionszweigen, plattformübergreifende Payloads und eingebaute Tarnmechanismen sprechen dafür.
Die Attacke reiht sich ein in eine Serie prominenter Supply-Chain-Vorfälle, von event-stream im npm-Ökosystem bis zur SolarWinds-Kompromittierung im Unternehmensumfeld. Branchenberichte von Organisationen wie ENISA und Anbietern wie Sonatype zeigen seit Jahren einen deutlichen Anstieg von Angriffen auf Software-Lieferketten. Hinweise auf mögliche Nachahmerpakete in PyPI und NuGet unterstreichen, dass Angreifer Ökosystem-übergreifend denken.
Konkrete Sicherheitsmaßnahmen für Entwickler und Organisationen
1. Sofortige Prüfung von Abhängigkeiten. Entwicklungs- und Security-Teams sollten den Abhängigkeitsbaum auf die Axios-Versionen 1.14.1 und 0.30.4 sowie auf das Paket plain-crypto-js im Verzeichnis node_modules untersuchen. Bei Fund ist ein Rollback auf bekannte sichere Versionen und ein Neuaufbau aller Artefakte erforderlich.
2. Version-Pinning und kontrollierte Updates. Die eingesetzte Axios-Version sollte in package-lock.json oder vergleichbaren Lockfiles fixiert werden, um unerwartete Updates zu verhindern. Der Einsatz privater Registry-Proxys mit Richtlinien für Vertrauenswürdigkeit und zusätzliche Prüfmechanismen reduziert das Risiko manipulierter Pakete.
3. Blockierung der Angreifer-Infrastruktur. Sicherheitsverantwortliche sollten den Domainnamen sfrclak[.]com und die IP-Adresse 142.11.206[.]73 in Firewalls, Web-Proxys und EDR-Lösungen blockieren. Netzwerk- und Proxy-Logs sollten auf Verbindungen zu diesen Indikatoren sowie ähnliche C2-Muster untersucht werden.
4. Incident Response und Geheimnis-Rotation. Potenziell betroffene Systeme sind zu isolieren, verdächtige Prozesse zu terminieren und Entwickler- wie CI/CD-Umgebungen vollständig zu aktualisieren und zu prüfen. Alle Zugangsdaten (Repository-Tokens, CI-Schlüssel, Paket-Registry-Credentials usw.), die von kompromittierten Hosts erreichbar waren, müssen als gefährdet gelten und unverzüglich rotiert werden.
5. Härtung der Software-Lieferkette. Organisationen sollten Software Composition Analysis (SCA), die Erstellung und Verifizierung von Software Bill of Materials (SBOM) sowie verpflichtende Multi-Faktor-Authentifizierung für npm-, PyPI-, NuGet- und Git-Konten einführen. Minimale Rechte für Service-Accounts und Automatisierungs-Agents reduzieren den potenziellen Schaden bei einer Kompromittierung erheblich.
Der Vorfall um Axios zeigt eindrücklich, dass selbst etablierte Open-Source-Projekte kein Garant für eine sichere Software-Lieferkette sind. Entwicklungs- und Sicherheitsabteilungen sollten die Absicherung von Build-Pipelines, Paketquellen und Maintainer-Accounts als zentralen Bestandteil ihrer Cybersecurity-Strategie behandeln. Wer jetzt Abhängigkeiten inventarisiert, SBOMs etabliert und DevSecOps-Prozesse schärft, reduziert nicht nur das Risiko ähnlicher Supply-Chain-Angriffe, sondern erhöht langfristig die Resilienz der gesamten Anwendungslandschaft.
