Bösartiges npm-Paket versteckte Malware im Laufzeitcode

Ein bösartiges npm-Paket namens indexed-btree trug seine Malware in gewöhnlichem Bibliothekscode, der während des Betriebs einer Anwendung ausgeführt wird, und nicht in den Installations-Hooks, die Sicherheitsteams zu überwachen gelernt haben. Das Paket wurde von Checkmarx identifiziert, einem Unternehmen für Sicherheit in der Software-Lieferkette, das angab, der Code ahme sorted-btree nach, ein legitimes Indexierungswerkzeug, das auf einem B-Baum basiert, einer geordneten Datenstruktur, die Anwendungen verwenden, um sortierte Informationen schnell zu speichern und zu durchsuchen. Das Paket und das zugehörige GitHub-Repository sind nicht mehr zum Download von npm verfügbar.

npm ist das wichtigste öffentliche Verzeichnis, aus dem JavaScript- und Node.js-Projekte fertigen Code herunterladen, der von anderen geschrieben wurde. Seit Jahren ist eine der einfachsten Möglichkeiten, dieses Ökosystem anzugreifen, ein Lifecycle-Skript, eine kurze Anweisung wie preinstall oder postinstall, die automatisch ausgeführt wird, wenn ein Paket installiert wird. Checkmarx merkte an, dass diese Hooks ehrliche Verwendungszwecke haben, wie das Kompilieren von Code, das Befüllen einer Datenbank mit Startwerten oder das Einrichten von Konfigurationsdateien, aber dass Angreifer sie häufig missbraucht haben, um bösartigen Code auf einem Rechner auszuführen, ohne dass der Benutzer zugestimmt hat. npm Version 12 führte eine Sicherheitsänderung ein, um zu verhindern, dass Lifecycle-Skripte wie preinstall und postinstall automatisch ausgeführt werden. Die indexed-btree-Kampagne scheint eine direkte Antwort auf diese Änderung zu sein: Das Paket verlässt sich überhaupt nicht auf diese Hooks und läuft stattdessen vollständig aus dem Anwendungscode zur Laufzeit.

Der Loader ist in einer Methode namens BTree.prototype.set() versteckt, einer normal aussehenden Funktion, die die Anwendung eines Entwicklers aufruft, wenn sie einen Wert in der Datenstruktur speichert. Wenn diese Funktion ausgeführt wird, löst sie eine zweite Datei aus, sharedLoad.min.js, eine JavaScript-Nutzlast, die die obfuskierte (absichtlich so verschlüsselte, dass sie schwer zu lesen ist) erste Stufe der Malware einbettet. Laut Checkmarx erstellt diese Stufe einen Fingerabdruck des Rechners, auf dem sie läuft, meldet ihre Ergebnisse an einen fest codierten Slack-Kanal und Telegram-Bot und verwendet dann eine Technik namens EtherHiding, um verschlüsselte Code-Blobs von einem Smart Contract abzurufen, der im Sepolia-Testnetz bereitgestellt wurde, einer Ethereum-Testblockchain. Die Blobs werden zusammengeführt, um die Nutzlast der zweiten Stufe zu erstellen. Sobald dies erledigt ist, löscht die Malware ihre eigenen Artefakte und entfernt den Auslöser aus dem Paketcode, sodass die Spur schwerer zu verfolgen ist.

Von Checkmarx zitierte Statistiken zeigen, dass indexed-btree erstmals am 18. Juni 2026 von einem npm-Benutzer namens charlessadler25 in das npm-Verzeichnis hochgeladen wurde und dass es in kurzer Zeit Millionen von Downloads ansammelte. Die Kampagne könnte dem Betreiber auch Geld eingebracht haben: Checkmarx gab an, dass sie rund 230.933,57 EUR in Kryptowährung generierte, was 109 ETH entspricht.

Checkmarx sagte, indexed-btree sei eines von vielen npm-Paketen, die mit derselben Operation verbunden sind, und alle seien inzwischen von npm entfernt worden: ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, sliding-score-window und mutex-forge.

Um der Bedrohung zu begegnen, empfiehlt Checkmarx Entwicklern, sich nicht allein auf Scans zum Installationszeitpunkt und das Blockieren von Lifecycle-Skripten zu verlassen, sondern auch Laufzeitverhaltensanalysen zu verwenden, also Werkzeuge, die beobachten, was Software tatsächlich tut, während sie läuft. Ensar Seker, Chief Information Security Officer bei SOCRadar, sagte in einer Erklärung, die mit The Hacker News geteilt wurde, die Kampagne zeige, dass Angreifer sich fast sofort an stärkere Verteidigungsmaßnahmen in der Software-Lieferkette anpassen: npm verbesserte die Sicherheit zum Installationszeitpunkt durch die Einschränkung von Dependency-Lifecycle-Skripten, und diese Operation verlagerte die bösartige Ausführung stattdessen in legitim aussehende Laufzeitfunktionalität. Sekers allgemeiner Punkt ist, dass Sicherheitskontrollen das Angreiferverhalten ändern, anstatt die zugrunde liegende Bedrohung zu beseitigen. Das Blockieren von Lifecycle-Skripten sei eine wichtige Verbesserung, argumentierte er, aber Angreifer würden weiter nach alternativen Ausführungspfaden suchen, sodass Verteidiger geschichtete Kontrollen benötigen, die bösartiges Verhalten vor der Installation, während der Ausführung und nach der Bereitstellung erkennen können.

Separat gab das Sicherheitsunternehmen Socket an, bösartigen Code in der dev-main-Version von visanduma/nova-two-factor gelöscht zu haben, einem Paket auf Packagist, dem wichtigsten öffentlichen Verzeichnis für PHP-Code, mit mehr als 700.000 kumulierten Downloads. Socket verband diesen Eindringling mit einer laufenden Kampagne, die es PolinRider nennt und die nach seinen Angaben mit Nordkorea in Verbindung steht. Ein definierendes Merkmal der Kampagne ist, dass die Betreiber Entwicklerkonten kompromittieren und bösartige Inhalte in Quellcode-Repositories einschleusen und dann routinemäßige Entwickleraktionen wie das Klonen eines Repositorys oder das Öffnen in einer integrierten Entwicklungsumgebung (IDE, das Programm, in dem Code geschrieben und ausgeführt wird) als Auslöser verwenden, der die Infektionskette startet. Laut Socket beinhaltet dies oft das Umschreiben der Git-Historie, das Verbergen von Nutzlasten in Konfigurations- oder Schriftdateien, das Einrichten bösartiger VS Code-Aufgaben, die von selbst laufen, und die Nutzung schwer zu entfernender Bereitstellung wie EtherHiding und seines auf Stealth ausgerichteten Nachfolgers NullReceiver, um gestaffelte Nutzlasten über eine Blockchain abzurufen.

Socket-Sicherheitsforscher Karlo Zanki sagte, die Analyse der Visanduma-GitHub-Organisation deute darauf hin, dass ihre Repositories seit Mitte Juni 2026 kompromittiert seien, wobei die bösartigen Änderungen über das Entwicklerkonto LaHiRu eingeführt wurden. Eine bemerkenswerte Verschiebung in dieser Iteration ist laut Socket das direkte Einfügen von stark obfuskiertem JavaScript in index.php und dessen Ausführung über die PHP-Funktion shell_exec(). Dieser Ansatz ermöglicht es einem PHP-Einstiegspunkt, die JavaScript-Infektionskette zu starten, und Socket liest dies als Zeichen dafür, dass die Betreiber ihre Ausführungsmethode an das jeweils kompromittierte Projekt anpassen, anstatt einen festen Bereitstellungspfad zu verwenden.

Socket zog auch eine weiterreichende Schlussfolgerung: Die Kompromittierung eines Paketverzeichnisses ist oft eine Folge eines breiteren Git-basierten Eindringens und nicht das Hauptziel der Kampagne. Die Betreiber nutzen die gewöhnliche Quellcode-Zusammenarbeit, um Entwicklerumgebungen zu erreichen, sich in weitere Repositories auszubreiten und den Zugriff über die Zeit aufrechtzuerhalten. Ein kompromittiertes Quell-Repository gibt ihnen die Möglichkeit, Mitwirkende zu infizieren, private Projekte zu erreichen und sich durch normale Entwicklungsworkflows zu bewegen, und die Veröffentlichung eines Pakets wird nur zu einem weiteren Verteilungskanal, wenn dieses Repository eine neue Version erzeugt.

Für Website-Besitzer und IT-Teams ist die praktische Lehre, dass moderne Websites aus Dutzenden, manchmal Hunderten von Komponenten Dritter zusammengesetzt sind, und beide Fälle zeigen, dass eine saubere Installation kein Beweis für Sicherheit ist. Scanner, die Code nur bei der Installation prüfen, können Malware übersehen, die wartet, bis die Anwendung tatsächlich läuft, und ein Quell-Repository kann lange vor der Veröffentlichung eines Pakets kompromittiert werden. Teams sollten ein Inventar darüber führen, wovon ihre Websites und Anwendungen abhängen, auf unerwartetes Verhalten ihrer Server achten, wie ausgehenden Datenverkehr zu Diensten, die niemand konfiguriert hat, und Entwicklerkonten, die Schlüssel zu Release- und Bereitstellungssystemen, mit derselben Sorgfalt schützen wie Produktions-Logins, einschließlich Zwei-Faktor-Authentifizierung. Für Organisationen, die es vorziehen, nicht alles selbst zu überprüfen, wie sie Software erstellen und betreiben, ist AEU-I unser sicherheitsorientierter IT-, Infrastruktur- und Beratungsservice, und seine öffentlichen Seiten beschreiben die Bereiche, die er abdeckt.