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.

Wenn der Zulieferer zum Einfallstor wird

Ende Mai 2025 wurde Adidas Opfer eines Datenlecks — nicht über die eigenen Systeme, sondern über einen Dienstleister. Kundendaten gelangten in die Hände von Cyberkriminellen, weil ein Drittanbieter kompromittiert wurde. Der Fall ist kein Einzelfall, sondern Symptom eines systemischen Problems: Die digitale Lieferkette ist zum bevorzugten Angriffsvektor geworden.

Das Handelsblatt berichtete am 25. März 2026 unter dem Titel „Attacke durch die Hintertür” ausführlich über die wachsende Bedrohung durch Supply-Chain-Angriffe. Die Zahlen sind alarmierend — und sie bestätigen, was wir bei NEOSEC seit Jahren in der Praxis sehen.

---

Die Zahlen sprechen eine klare Sprache

Laut dem Global Incident Response Report von Palo Alto Networks haben sich Supply-Chain-Attacken seit 2022 um das 3,8-Fache erhöht und machen mittlerweile 23 Prozent aller Angriffe aus. Eine Studie des Branchenverbands Bitkom zeigt: Fast jedes zehnte deutsche Unternehmen (9 %) weiß, dass eigene Zulieferer in den vergangenen zwölf Monaten Opfer von Cyberangriffen wurden. Weitere 19 Prozent hatten zumindest einen Verdachtsfall.

Die Europäische Agentur für Cybersicherheit (ENISA) stuft Supply-Chain-Kompromittierungen in ihrem aktuellen Threat Landscape Report als eine der Top-Bedrohungen ein. Das BSI bestätigt im Lagebericht zur IT-Sicherheit in Deutschland 2024, dass Angriffe über die Lieferkette ein zunehmendes Risiko für die deutsche Wirtschaft darstellen — insbesondere für kritische Infrastrukturen und deren Zulieferer.

Und die Konsequenzen? Laut Bitkom erlitten 41 Prozent der betroffenen Unternehmen Produktionsausfälle, Lieferengpässe oder Reputationsschäden.

---

Der Dominoeffekt: Warum ein Angriff viele trifft

Christoph Demiriz, Geschäftsführer von Digital Recovery, bringt es auf den Punkt: Angriffe auf Unternehmen in der Lieferkette sind für Cyberkriminelle strategisch besonders attraktiv, weil sie einen Dominoeffekt erzeugen.

Die Logik dahinter ist einfach: Wenn ein IT-Dienstleister, ein Softwareanbieter oder ein Managed-Service-Provider kompromittiert wird, sind potenziell Dutzende oder Hunderte seiner Kunden betroffen — gleichzeitig. Zwei Beispiele illustrieren das:

• Ein Systemhaus in Schleswig-Holstein, das die IT von rund 30 Unternehmen betreute, wurde über einen Update-Mechanismus kompromittiert. Angreifer konnten Schadsoftware bei mehreren Kunden gleichzeitig einschleusen und zentrale Systeme verschlüsseln.
• Ein kommunaler Dienstleister in Südwestfalen wurde angegriffen — über 100 Städte und Gemeinden in Nordrhein-Westfalen waren betroffen. IT-Dienste, Websites und Telefonanlagen fielen aus. Die Bearbeitung von Bürgeranträgen verzögerte sich teilweise um mehrere Monate.

Diese Fälle stehen in einer Reihe mit den großen Supply-Chain-Angriffen der letzten Jahre: SolarWinds (2020), Kaseya (2021) und die MOVEit-Schwachstelle (2023) zeigten auf globaler Ebene, wie verheerend ein einziger kompromittierter Dienstleister sein kann.

---

NIS2 macht Lieferkettensicherheit zur Pflicht

Die EU hat reagiert. Mit der NIS2-Richtlinie — in Deutschland umgesetzt durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) — wird Lieferkettensicherheit erstmals explizit zur gesetzlichen Pflicht.

Artikel 21 der NIS2-Richtlinie verlangt von Unternehmen unter anderem:

• Sicherheit der Lieferkette — einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen Unternehmen und ihren unmittelbaren Anbietern oder Diensteanbietern
• Risikobewertung der IT-Sicherheit von Zulieferern und Dienstleistern
• Meldepflichten — 24 Stunden für die Erstmeldung, 72 Stunden für den Detailbericht ans BSI
• Persönliche GF-Haftung bei Nichteinhaltung

IT-Rechtsanwalt Jens Ferner betont: Die Richtlinie verlangt verhältnismäßige Maßnahmen, über die Unternehmen selbst entscheiden müssen. Eine Untersuchung aller technischen Einrichtungen sei nicht erforderlich — aber die Unternehmen müssen nachweisen können, dass sie ihre Lieferkette im Blick haben.

Wer das nicht tut, riskiert Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes — je nachdem, was höher ist.

---

Was Unternehmen jetzt tun müssen

Die Empfehlungen aus verschiedenen Quellen — BSI, ENISA, und unserer eigenen Praxis bei NEOSEC — konvergieren auf dieselben Kernmaßnahmen:

1. Sichtbarkeit schaffen

Wer nicht sieht, kann nicht erkennen. Wer nicht erkennt, kann nicht reagieren. Ein zentrales SIEM-System erfasst alle sicherheitsrelevanten Ereignisse — auch die, die über Schnittstellen zu Dienstleistern und Zulieferern hereinkommen. Ohne SIEM gibt es keine nachweisbare Erkennung, ohne Erkennung keinen NIS2-konformen Nachweis.

2. Netzwerksegmentierung

Wenn ein Zulieferer-Zugang kompromittiert wird, darf der Schaden nicht das gesamte Netz betreffen. Klare Netzwerksegmentierung begrenzt die Ausbreitung — im IT- wie im OT-Bereich.

3. Lieferanten-Audits

Lassen Sie sich die Sicherheitsmaßnahmen Ihrer Partner konkret nachweisen. Nicht mit einem Fragebogen, sondern mit technischen Nachweisen: Penetrationstests, SIEM-Logs, Incident-Response-Pläne, ISO-27001-Zertifizierungen.

4. Backup- und Wiederanlaufstrategie

Notfallkonzepte müssen regelmäßig getestet werden — nicht nur dokumentiert. Viele Firmen verfügen zwar über Datensicherungen, sind jedoch nicht in der Lage, diese im Ernstfall in der erforderlichen Geschwindigkeit einzusetzen.

5. Meldeketten etablieren

Die 24h/72h-Meldepflicht der NIS2 lässt keinen Spielraum für Improvisation. Wer im Ernstfall erst klären muss, wen er anruft, hat bereits verloren.