Axios Supply-Chain-Angriff: Was Admins jetzt prüfen müssen

Am 31. März 2026 wurde das npm-Paket Axios — mit rund 100 Millionen wöchentlichen Downloads eine der meistgenutzten JavaScript-Bibliotheken weltweit — durch einen Supply-Chain-Angriff kompromittiert. Die trojanisierten Versionen waren nur zwei bis drei Stunden online, bevor sie entfernt wurden. Trotzdem: Bei dieser Verbreitung reicht ein kurzes Zeitfenster, um tausende Entwicklungsumgebungen zu infizieren.

Google Threat Intelligence hat den Angriff der nordkoreanischen Gruppe UNC1069 zugeordnet. Es handelt sich nicht um einen opportunistischen Angriff, sondern um eine sorgfältig vorbereitete Operation mit plattformübergreifender Malware, Anti-Forensik-Mechanismen und mehrstufiger Verschleierung.

Was passiert ist

Die Angreifer kompromittierten den npm-Account des Hauptmaintainers von Axios und veröffentlichten zwei trojanisierte Versionen:

• axios@1.14.1
• axios@0.30.4

Beide Versionen enthielten eine neue Abhängigkeit namens plain-crypto-js@4.2.1 — ein sogenanntes Phantom-Dependency: im Manifest gelistet, aber nirgends im eigentlichen Code verwendet. Dieses Paket enthielt einen verschleierten postinstall-Hook, der beim Installieren automatisch ein Dropper-Skript ausführte.

Das Skript lud plattformspezifische RAT-Payloads (Remote Access Trojaner) nach:

• macOS: Binary in /Library/Caches/com.apple.act.mond, Gatekeeper-Bypass via codesign, C2-Callback alle 60 Sekunden
• Windows: PowerShell-Payload als %PROGRAMDATA%\wt.exe, Persistenz via Registry-Key „MicrosoftUpdate”
• Linux: Python-Skript als /tmp/ld.py, ausgeführt via nohup

Nach der Infektion löschte die Malware ihre Spuren: Das kompromittierte package.json wurde durch eine saubere Kopie ersetzt, die Version 4.2.0 statt 4.2.1 meldet. Ein npm list zeigt dann fälschlicherweise eine unbedenkliche Version an.

Wer betroffen ist

Potenziell betroffen ist jedes Projekt, das Axios als direkte oder transitive Abhängigkeit nutzt. Laut Wiz betrifft das rund 80 % aller Cloud- und Code-Umgebungen. Fast 175.000 npm-Pakete listen Axios als Dependency.

Konkret betroffen sind Umgebungen, in denen zwischen dem 31. März (ca. 00:00 UTC) und ca. 03:00 UTC ein npm install, npm update oder ein CI/CD-Build ohne fixiertes Lockfile lief und dabei eine der beiden Versionen gezogen wurde.

Umgebungen mit einem intakten package-lock.json oder yarn.lock, in denen im Zeitraum kein ungelockerter Install stattfand, sind mit hoher Wahrscheinlichkeit nicht betroffen.

Sofortmaßnahmen für Admins

1. Lockfiles und node_modules prüfen

In jedem Node.js-Projekt auf allen Entwicklungs-, Build- und Produktionsservern:

# Nach der Phantom-Dependency suchen
grep -r "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# Installierte Axios-Version prüfen
npm list axios 2>/dev/null | head -20

# In node_modules direkt suchen
find . -path '*/plain-crypto-js' -type d 2>/dev/null

Wenn plain-crypto-js auftaucht oder Axios in Version 1.14.1 bzw. 0.30.4 installiert ist: Umgebung als kompromittiert betrachten.

2. Kompromittierte Systeme isolieren — nicht bereinigen

Infizierte Entwicklungsrechner und Build-Server sofort vom Netz nehmen. Nicht versuchen, die Malware manuell zu entfernen. Der RAT hat möglicherweise bereits Credentials exfiltriert. Stattdessen:

• System isolieren und forensisch sichern
• Von einem bekannt sauberen Snapshot oder Image neu aufsetzen
• Erst nach dem Rebuild wieder ans Netz nehmen

3. Credentials rotieren — alle

Auf betroffenen Systemen gespeicherte Zugangsdaten als kompromittiert betrachten:

• npm-Tokens
• SSH-Schlüssel
• Cloud-Provider-Keys (AWS, Azure, GCP)
• CI/CD-Secrets (GitHub Actions, GitLab CI, Jenkins)
• API-Keys und Service-Accounts
• Datenbank-Zugangsdaten

Wichtig: Nicht in-place rotieren. Alte Credentials widerrufen, neue auf sauberen Systemen generieren.

4. CI/CD-Pipelines absichern

# postinstall-Hooks in CI/CD-Builds deaktivieren
npm ci --ignore-scripts

# Danach nur gezielt Scripts ausführen, die bekannt sicher sind

Zusätzlich: minimumReleaseAge in der npm-Konfiguration aktivieren. Diese Funktion blockiert die Installation von Paketen, die jünger als ein definierter Zeitraum sind — hätte in diesem Fall den Angriff verhindert, da plain-crypto-js weniger als 24 Stunden existierte.

5. IOCs prüfen

Netzwerk-Logs und Endpoint-Monitoring auf folgende Indikatoren prüfen:

• Outbound-Verbindungen zu unbekannten Domains, die am 30./31. März registriert wurden
• Prozesse namens com.apple.act.mond (macOS), wt.exe (Windows), ld.py (Linux)
• Registry-Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate
• Dateien in /Library/Caches/com.apple.act.mond

Präventivmaßnahmen

Lockfiles konsequent einsetzen

package-lock.json bzw. yarn.lock sind keine optionale Bequemlichkeit, sondern die wichtigste Verteidigungslinie gegen Supply-Chain-Angriffe dieser Art. In CI/CD immer npm ci statt npm install verwenden — ersteres installiert exakt die im Lockfile festgeschriebenen Versionen.

Trusted Publishing nutzen

Beim Axios-Angriff war zwar OIDC Trusted Publishing für die 1.x-Linie konfiguriert, aber ein langlebiger Legacy-Token hatte Vorrang. Prüfen Sie für Ihre eigenen Pakete: Verwenden Sie ausschließlich kurzlebige OIDC-Tokens? Sind Legacy-Tokens widerrufen?

Dependency-Monitoring etablieren

Tools wie npm audit, Snyk, Socket oder Dependabot erkennen kompromittierte Pakete oft innerhalb von Minuten. Wer kein automatisches Monitoring hat, erfährt erst durch Zufall oder Medienberichte davon.

Entwicklungsumgebungen härten

Entwicklerrechner sind hochwertige Ziele, weil sie typischerweise SSH-Keys, Cloud-Credentials und Repository-Zugang bündeln. Segmentierung, Least-Privilege-Prinzipien und separate Build-Umgebungen reduzieren den Blast Radius erheblich.

Erweiterte Angriffsfläche: KI-Tools

Ein oft übersehener Aspekt: KI-gestützte Entwicklungstools wie Claude Code oder OpenAI Codex nutzen ebenfalls npm-Pakete und installieren diese teils automatisiert. Damit erweitert sich die Angriffsfläche über klassische Entwicklerumgebungen hinaus auf alle Arbeitsplätze, an denen solche Tools zum Einsatz kommen — auch bei Nicht-Entwicklern.

Einordnung

Dieser Angriff zeigt, wie fragil das Vertrauensmodell im npm-Ökosystem nach wie vor ist. Ein einziger kompromittierter Account — in diesem Fall der des Hauptmaintainers — reicht aus, um Schadcode in hunderttausende nachgelagerte Projekte zu schleusen. Die Attribution zu einer nordkoreanischen APT-Gruppe unterstreicht: Supply-Chain-Angriffe sind kein theoretisches Risiko, sondern ein aktiv genutzter Angriffsvektor staatlicher Akteure.

Für Unternehmen, die Node.js-basierte Anwendungen entwickeln oder betreiben, ist die konsequente Absicherung der Software-Lieferkette keine Kür mehr — sie ist Pflicht. Wer ein SIEM betreibt, sollte die genannten IOCs in seine Detektionsregeln aufnehmen. Wer keins betreibt, hat ein grundsätzlicheres Problem.

---

Sie wollen sicherstellen, dass Ihre Entwicklungs- und Produktionsumgebungen sauber sind? NEOSEC unterstützt Sie bei der forensischen Analyse, dem Incident Response und der nachhaltigen Absicherung Ihrer Software-Lieferkette. Sprechen Sie uns an.