Der Angriff zeigt eine Raffiniertheit, die Sicherheitsexperten als bemerkenswert organisiert beschreiben. Die Angreifer hatten zuerst das NPM-Konto des Hauptentwicklers Jason Saayman kompromittiert und dann ein langlebiges Zugangstoken verwendet, um die Malware-Versionen direkt über die NPM-Befehlszeile zu veröffentlichen. Dies gelang ihnen, obwohl Sicherheitsmechanismen wie GitHub Actions OIDC-basierte CI/CD-Workflows aktiviert waren — ein kritisches Detail: Als beide Authentifizierungsmethoden verfügbar waren, nutzte NPM bevorzugt das Legacy-Token statt der modernen OIDC-Credentials.
Die Malware wurde über eine fingierte Abhängigkeit namens plain-crypto-js verbreitet, die 18 Stunden vor dem Angriff veröffentlicht wurde. Dies sollte eine legitime Publishing-Historie vortäuschen. Die eigentliche Schädlingsvariante (Version 4.2.1) enthielt ein Post-Install-Skript, das als Cross-Platform-RAT-Dropper fungierte und platform-spezifische Payloads für Windows, macOS und Linux ausführte — ohne Benutzerinteraktion. Besonders gerissen: Die Malware löschte ihre Spuren nach der Ausführung und meldete sich selbst als die saubere Version 4.2.0, um Erkennungssysteme zu täuschen.
Die Payloads ermöglichten Remote-Shell-Zugriff, Code-Injection, Verzeichnis- und Prozess-Enumeration sowie umfassende Systemaufklärung. Google Threat Intelligence attributierte den Angriff UNC1069, einer nordkoreanischen Gruppe, die seit 2018 bekannt ist und sich auf Kryptowährungs- und DeFi-Ziele konzentriert.
Der Angriff war hochgradig zielgerichtet: Beide Axios-Versionen wurden innerhalb von 40 Minuten veröffentlicht, mit vorbereiteten Payloads für drei Betriebssysteme und integrierter forensischer Selbstzerstörung. Sicherheitsexperten warnen, dass betroffene Systeme als kompromittiert zu behandeln sind. Organisationen müssen sofort ihre Dependencies überprüfen, auf sichere Versionen downgraden, alle zugänglichen Anmeldedaten wechseln und auf Malware-Artefakte scannen.
Das Besorgnis erregende: Selbst Entwickler, die Versionspinning praktizierten und Lockfiles verwalteten, könnten betroffen sein, wenn ihre IDE-Erweiterungen die infizierte Abhängigkeit im Hintergrund zogen. Dies unterstreicht ein fundamentales Vertrauensproblem in der Software-Supply-Chain — nicht mehr einzelne Code-Fehler sind das Problem, sondern die Frage, wie vertrauenswürdig Pakete wirklich sind.