Eine laufende Lieferkettenkampagne zeigt, wie schädliche npm-Pakete Installationsschutzmaßnahmen umgehen können, indem sie sich während der normalen Anwendungsnutzung aktivieren. Das Paket indexed-btree verbirgt seinen Malware-Loader in einer häufig aufgerufenen Funktion, anstatt erkennbare Installationsskripte zu verwenden.
Paket imitiert beliebte Bibliothek
Sicherheitsforscher von Checkmarx entdeckten das schädliche Paket indexed-btree bei einer Untersuchung von Bedrohungen für die npm-Lieferkette.
Das Paket versucht, sorted-btree zu imitieren, eine legitime Bibliothek mit rund zwei Millionen Downloads pro Woche. Angreifer nutzen diese Taktik häufig, um Entwickler zu täuschen, die einen Paketnamen falsch eingeben oder einen Klon mit dem echten Projekt verwechseln.
Indexed-btree präsentiert sich ebenfalls als legitime Softwarebibliothek. Seine Entwickler erstellten ein überzeugendes Repository, bauten eine detaillierte Commit-Historie auf und pflegten das zugehörige Entwicklerkonto sorgfältig.
Daher bemerken Entwickler bei der Überprüfung des Projekts möglicherweise nicht sofort etwas Verdächtiges.
Checkmarx brachte außerdem neun weitere npm-Pakete mit derselben Kampagne in Verbindung. npm hat diese Pakete inzwischen aus seiner Registry entfernt.
npm blockiert nicht genehmigte Installationsskripte
GitHub kündigte im Juni 2026 zusätzliche npm-Schutzmaßnahmen an, nachdem wiederholte Angriffe das Open-Source-Ökosystem beeinträchtigt hatten.
Eine wichtige Maßnahme schränkt Lebenszyklusskripte von Abhängigkeiten ein. Pakete können die Skripte preinstall, install und postinstall nutzen, um während ihrer Installation durch npm Code auszuführen.
Bedrohungsakteure haben diese Skripte häufig missbraucht, um Systeme von Entwicklern zu infizieren. Daher blockiert npm v12 sie, sofern der Benutzer keine ausdrückliche Genehmigung erteilt.
Weitere Schutzmaßnahmen hindern npm daran, Abhängigkeiten ohne Erlaubnis automatisch aus Git-Repositorys oder von Remote-URLs herunterzuladen.
Diese Kontrollen können Malware stoppen, die sich während der Paketinstallation aktiviert. Sie können jedoch nicht vor jedem Ausführungspfad schützen.
Malware wartet bis zur Laufzeit
Indexed-btree verzichtet vollständig auf Lebenszyklusskripte. Daher erscheint die Installation unbedenklich und löst das Genehmigungsverfahren von npm nicht aus.
Stattdessen verbirgt das Paket seinen Loader in der Methode BTree.prototype.set(). Anwendungen nutzen diese zentrale Funktion, um Werte in einer B-Baum-Datenstruktur hinzuzufügen oder zu aktualisieren.
Der schädliche Code aktiviert sich erst, wenn eine Anwendung die Methode mit einem bestimmten Schlüsselwert aufruft. Dadurch kann das Paket während der Installation und der ersten Sicherheitsprüfungen inaktiv bleiben.
Sobald der Auslöser auftritt, startet die Funktion eine verschleierte Datei namens sharedLoad.min.js. Diese Datei enthält die erste Stufe der Malware.
Die Einbettung des Loaders in eine legitime und häufig genutzte Methode erschwert außerdem die Analyse. Statische Scanner könnten die Funktion als normales Verhalten der Bibliothek interpretieren.
Laufzeitauslöser umgeht Sicherheitsscanner
Viele Sicherheitstools für Softwarelieferketten konzentrieren sich auf Installationsaktivitäten, bekannte Schadcodemuster und verdächtige Datenflüsse.
Schädliche npm-Pakete können diese Prüfungen jedoch umgehen, indem sie schädliche Logik in gültigen Anwendungsfunktionen platzieren. Der Code aktiviert sich möglicherweise nur unter bestimmten Laufzeitbedingungen.
Dieser Ansatz reduziert die sichtbaren Anzeichen während der Installation. Zudem macht er automatisierte Analysen weniger zuverlässig, da der Scanner den erforderlichen Auslöser möglicherweise niemals reproduziert.
Darüber hinaus nutzt der Loader Verschleierung, um sein Verhalten zu verbergen. Sicherheitstools müssen daher sowohl die verborgene Aktivierungsbedingung als auch die codierte schädliche Logik identifizieren.
Die Kampagne zeigt, warum eine unauffällige Installation nicht garantiert, dass ein Paket sicher ist.
Malware sammelt Systeminformationen
Nach der Aktivierung sammelt die Malware Details über den infizierten Computer.
Zu den erfassten Informationen gehören Systemarchitektur, Hostname, Prozessor, verfügbarer Arbeitsspeicher und Betriebszeit. Diese Angaben können den Angreifern helfen, die kompromittierte Umgebung zu bewerten.
Die Betreiber könnten die Informationen beispielsweise nutzen, um wertvolle Entwicklungssysteme zu identifizieren oder ungeeignete Ziele zu vermeiden.
Anschließend sendet die Malware die gesammelten Daten über fest einprogrammierte Slack- und Telegram-Kanäle. Diese legitimen Dienste können Bedrohungsakteuren eine praktische Kommunikationsinfrastruktur bieten.
Da viele Organisationen den Datenverkehr zu diesen Plattformen erlauben, könnten sich die Übertragungen in die normale Netzwerkaktivität einfügen.
Ethereum-Vertrag liefert Befehle
Die Malware überprüft außerdem einen Ethereum-Smart-Contract auf Command-and-Control-Informationen.
Konkret fragt sie regelmäßig einen Vertrag im Sepolia-Testnetzwerk ab. Die Angreifer können den Vertrag aktualisieren, um Anweisungen oder Speicherorte für zusätzliche Payloads bereitzustellen.
Dieser dezentrale Ansatz verringert die Abhängigkeit von einem herkömmlichen Command-and-Control-Server. Sicherheitsteams können den Kanal nicht einfach durch die Abschaltung einer einzelnen Domain deaktivieren.
Die Malware verwendet einen X25519-Schlüsselaustausch, um einen Verschlüsselungsschlüssel zu erzeugen. Anschließend setzt sie diesen Schlüssel mit AES-Verschlüsselung ein, um eine im Vertrag gespeicherte Payload der zweiten Stufe zu entschlüsseln.
Dieses Design trägt dazu bei, sowohl die Payload als auch ihre Anweisungen vor Forschern zu verbergen, die die Blockchain überwachen.
Malware kann ihre eigenen Spuren entfernen
Die Kampagne enthält eine Bereinigungsfunktion, mit der die Betreiber ihre Aktivitäten verbergen können.
Wenn die Angreifer eine Infektion beenden wollen, kann die Malware ihre Dateien aus dem betroffenen System löschen. Zudem kann sie den schädlichen Auslöser aus dem Paketcode entfernen.
Diese Fähigkeit könnte spätere forensische Untersuchungen erschweren. Ein Entwickler könnte das kompromittierte Paket behalten, ohne den ursprünglichen Schadcode zu sehen.
Darüber hinaus könnte der Bereinigungsprozess die verfügbaren Beweise für Incident-Response-Teams verringern. Organisationen könnten Schwierigkeiten haben, festzustellen, auf welchen Systemen die Malware ausgeführt wurde und welche Informationen sie gesammelt hat.
Forscher finden neun verwandte Pakete
Checkmarx brachte neun weitere Pakete mit derselben Operation in Verbindung. Zusammen verzeichneten sie Millionen von Downloads:
- ordered-kv-index – 448.184 Downloads
- btree-leaderboard – 493.685 Downloads
- priority-slot-queue – 402.860 Downloads
- btree-range-store – 468.092 Downloads
- btree-core – 1.951.274 Downloads
- btree-time-index – 425.312 Downloads
- btree-lru-cache – 372.185 Downloads
- neighbor-key-map – 366.019 Downloads
- sliding-score-window – 448.024 Downloads
npm hat alle neun Pakete entfernt. Ihre Downloadzahlen zeigen jedoch, dass Lieferkettenkampagnen viele Entwicklungsumgebungen erreichen können, bevor sie entdeckt werden.
Die Zahl der Downloads entspricht nicht zwangsläufig der Anzahl infizierter Systeme. Automatisierte Builds, Spiegelserver und wiederholte Installationen können die Paketstatistiken erheblich erhöhen.
Krypto-Wallet enthält 109 ETH
Checkmarx identifizierte außerdem eine Krypto-Wallet, die mit den Betreibern der Kampagne in Verbindung stand.
Die Wallet enthielt Berichten zufolge 109 ETH. Die Forscher konnten jedoch nicht feststellen, ob die Gelder aus Kryptowährungsdiebstählen oder aus Aktivitäten im Zusammenhang mit dieser Malware stammten.
Der Kontostand allein bestätigt daher nicht, wie viel Geld die Angreifer mit der Kampagne verdienten.
Dennoch deutet die Entdeckung darauf hin, dass finanziell motivierte Bedrohungsakteure mit erheblichen Ressourcen hinter der Operation stehen könnten.
Entwickler benötigen Laufzeitüberwachung
Die Kampagne beweist, dass sich Entwickler nicht allein auf Scans während der Installation verlassen können.
Sicherheitsteams sollten außerdem überwachen, wie sich Pakete von Drittanbietern während der Anwendungsausführung verhalten. Verdächtige Netzwerkverbindungen, Systemerkundung und unerwartete Zugriffe auf Messaging-Plattformen müssen untersucht werden.
Organisationen sollten ihre Abhängigkeitsverzeichnisse überprüfen und nach indexed-btree oder einem der neun verwandten Pakete suchen.
Wer diese schädlichen npm-Pakete installiert hat, sollte Zugangsdaten, Token und andere in der betroffenen Umgebung gespeicherte Geheimnisse erneuern.
Entwickler sollten kompromittierte Systeme nach Möglichkeit auch aus einer vertrauenswürdigen Sicherung wiederherstellen. Das bloße Löschen des Pakets entfernt möglicherweise keine zusätzlichen Payloads und macht nach der Infektion vorgenommene Änderungen nicht rückgängig.
Letztlich können schädliche npm-Pakete normales Laufzeitverhalten ausnutzen, um installationsbezogene Kontrollen zu umgehen. Die Lieferkettensicherheit muss daher untersuchen, was Abhängigkeiten tun, nachdem Entwickler sie in Gebrauch genommen haben.
0 Kommentare zu „Schädliche npm-Pakete umgehen Installationsschutz zur Laufzeit“