Ein kritischer Angriff auf die Lieferkette hat die weit verbreitete JavaScript-Bibliothek Axios betroffen, nachdem das npm-Konto des Hauptverantwortlichen kompromittiert wurde. Die Angreifer nutzten das gekaperte Konto, um zwei bösartige Versionen zu veröffentlichen, axios@1.14.1 und axios@0.30.4, die eine bösartige Abhängigkeit einführten (plain-crypto-js@4.2.1). Diese Abhängigkeit war nicht Teil der legitimen Axios-Codebasis und diente nur dazu, ein Nachinstallationsskript auszuführen, das einen plattformübergreifenden Remote Access Trojaner (RAT) installierte.
Der Angriff war hochgradig koordiniert. Die bösartige Abhängigkeit wurde im Voraus erstellt und später innerhalb eines kurzen Zeitrahmens sowohl in den aktuellen als auch in den alten Axios-Versionszweig injiziert, um die Auswirkungen zu maximieren. Da sich der Schadcode in einer transitiven Abhängigkeit und nicht in Axios selbst befindet, würde eine herkömmliche Codeüberprüfung oder diff-basierte Erkennung die Gefährdung wahrscheinlich nicht erkennen. Außerdem ist die Malware so konzipiert, dass sie sich nach der Ausführung selbst entfernt und Beweise im Paketverzeichnis ersetzt, was die forensische Analyse erheblich erschwert.
Nach der Installation kontaktiert das Dropper-Skript einen Command-and-Control-Server (sfrclak[.]com) und ruft eine auf das jeweilige Betriebssystem zugeschnittene Nutzlast der zweiten Stufe ab. Unter macOS wird eine als System-Cache-Daemon getarnte Binärdatei bereitgestellt; unter Windows wird PowerShell über eine getarnte Binärdatei ausgeführt; und unter Linux wird eine Python-basierte Backdoor bereitgestellt. Diese Nutzlasten ermöglichen die Ausführung von Remote-Befehlen, die Exfiltration von Daten und die Bereitstellung weiterer Nutzlasten. Obwohl die Malware standardmäßig keine Persistenz aufzubauen scheint, können Angreifer mit ihren Fähigkeiten schnell den Zugriff ausweiten oder zusätzliche Mechanismen einsetzen.
Da sich der Dropper selbst löscht, erfordert die Identifizierung einer Gefährdung eine Kombination aus Abhängigkeitsanalyse, Überprüfung von Systemartefakten und Protokollprüfung. Unternehmen sollten installierte Pakete und Lockfiles für die betroffenen Axios-Versionen untersuchen, überprüfen, ob das plain-crypto-js-Verzeichnis existiert oder existierte, und Endpunkte auf Indikatoren wie /Library/Caches/com.apple.act.mond, %PROGRAMDATA%\wt.exe oder /tmp/ld.py überprüfen. Die Netzwerkprotokolle sollten auch auf die Kommunikation mit der bekannten Befehls- und Kontrollinfrastruktur überprüft werden. Jeder bestätigte Indikator sollte als Beweis für eine vollständige Systemkompromittierung angesehen werden.
Wenn in Ihrer Umgebung eine der bösartigen Axios-Versionen installiert ist, sollten Sie von einer Gefährdung ausgehen und entsprechend reagieren. Die Systeme sollten nicht an Ort und Stelle gereinigt werden, da das volle Ausmaß der Angreiferaktivitäten nicht zuverlässig ermittelt werden kann. Stattdessen müssen die betroffenen Rechner von einer vertrauenswürdigen, als gut bekannten Basislinie neu aufgebaut werden, um die vollständige Beseitigung aller bösartigen Komponenten sicherzustellen.
Alle Anmeldedaten, die auf den betroffenen Systemen möglicherweise offengelegt wurden, müssen sofort ausgetauscht werden. Dazu gehören npm-Tokens, Anmeldedaten von Cloud-Anbietern, SSH-Schlüssel, API-Schlüssel, Umgebungsvariablen und alle in CI/CD-Pipelines verwendeten Geheimnisse. Besonderes Augenmerk sollte auf Build-Systeme und Automatisierungspipelines gelegt werden, da diese oft Zugang zu hochsensiblen Anmeldeinformationen haben und das bösartige Paket möglicherweise während Routine-Builds ausgeführt haben.
Im Rahmen der Eindämmung sollten Unternehmen die ausgehende Kommunikation mit der identifizierten Command-and-Control-Domain und den zugehörigen IP-Adressen blockieren. Sicherheitsteams sollten außerdem die Protokolle auf verdächtige ausgehende Verbindungen, ungewöhnliche Prozessausführungen oder Anzeichen von Datenexfiltration während des Zeitraums, in dem die Schadpakete verfügbar waren, überprüfen.
Zur Wiederherstellung sollte Axios auf eine bekannte sichere Version wie 1.14.0 oder 0.30.3 herabgestuft und die bösartige Abhängigkeit entfernt werden, falls vorhanden. Die Abhängigkeiten sollten dann mit sichereren Methoden neu installiert werden, z. B. durch die Deaktivierung von Lebenszyklus-Skripten, wo dies möglich ist. CI/CD-Pipelines sollten sichere Standardeinstellungen wie npm ci --ignore-scripts übernehmen, um das Risiko zu verringern, dass ähnliche Angriffe in Zukunft automatisch ausgeführt werden.
Längerfristig sollten Unternehmen die Sicherheit ihrer Software-Lieferkette verbessern. Dazu gehören die Durchsetzung eines strikten Abhängigkeits-Pinning, die Überprüfung direkter und transitiver Abhängigkeiten sowie die Implementierung von Tools, die bösartige Pakete in Echtzeit erkennen können. Es ist von entscheidender Bedeutung, das implizite Vertrauen in Paketregistrierungen und -betreuer zu verringern, da dieser Vorfall zeigt, wie ein einziges kompromittiertes Konto kaskadenartige Auswirkungen auf Tausende von nachgelagerten Anwendungen haben kann.
Dieser Angriff unterstreicht die zunehmende Raffinesse der Bedrohungen in der Lieferkette innerhalb des Open-Source-Ökosystems. Durch die Nutzung vertrauenswürdiger Vertriebskanäle können sich Angreifer mit minimalem Aufwand weitreichenden Zugang verschaffen, was eine proaktive Überwachung, eine schnelle Reaktion und eine tiefgreifende Verteidigung zu wesentlichen Bestandteilen einer modernen Cybersicherheitsstrategie macht.
Wenn Sie sich über eine der in diesem Bulletin beschriebenen Bedrohungen Sorgen machen oder Hilfe benötigen, um herauszufinden, welche Schritte Sie unternehmen sollten, um sich vor den größten Bedrohungen für Ihr Unternehmen zu schützen, wenden Sie sich bitte an Ihren Kundenbetreuer oder nehmen Sie Kontakt mit uns auf, um zu erfahren, wie Sie Ihr Unternehmen schützen können.