Durch die Laufzeit ausgelöste npm-Malware umgeht Schutzmechanismen für Installationsskripte

Eine schädliche npm-Kampagne hat ihre Ausführungslogik von Installations-Hooks in das normale Verhalten einer Bibliothek verlagert. Dadurch können Pakete Kontrollen passieren, die gefährliche Lifecycle-Skripte blockieren sollen.

Die Forscher von Checkmarx konzentrierten ihre Untersuchung auf indexed-btree, ein Paket, das der legitimen Bibliothek sorted-btree nachempfunden ist. Laut Berichten über die Erkenntnisse der Forscher erreichte indexed-btree rund zwei Millionen Downloads pro Woche und sorgte damit für eine erhebliche Angriffsfläche in Entwicklerumgebungen.

Das Paket verwendet weder preinstall noch install oder postinstall. Stattdessen ist sein Loader in BTree.prototype.set() verborgen, einer normalen B-Tree-Operation, und wird während der Ausführung einer Anwendung aktiviert, sobald ein bestimmter Schlüsselwert übergeben wird.

Dieses Design zielt auf eine Lücke zwischen Installationssicherheit und Laufzeitüberwachung. Ein npm-Paket kann installiert werden, ohne die Genehmigung zur Ausführung eines Lifecycle-Skripts anzufordern, und später dennoch schädlichen Code ausführen, wenn eine Anwendung seine exportierten Funktionen aufruft.

Der schädliche Pfad beginnt in einer routinemäßigen Bibliotheksmethode

Die erstmalige Installation von indexed-btree wirkt unauffällig, weil das Paket keine Dependency-Lifecycle-Skripte verwendet, um seine Payload zu starten. Das schädliche Verhalten beginnt erst, wenn eine Software, die die Bibliothek nutzt, BTree.prototype.set() mit dem erforderlichen Triggerwert aufruft.

Der genaue Trigger-Schlüssel wurde nicht veröffentlicht. Auch die betroffenen Paketversionen sind nicht bekannt, was die Eingrenzung für Unternehmen erschwert, die mehrere Releases in Paket-Caches oder Lockfiles vorhalten.

Nach der Aktivierung ruft die Methode sharedLoad.min.js auf, das eine obfuskierte Payload der ersten Stufe enthält. Indem dieser Loader in einer häufig verwendeten Operation einer Datenstruktur platziert wird, lässt er sich zwischen Code verbergen, der scheinbar zum angegebenen Zweck des Pakets passt.

Checkmarx bewertete die Technik als geeignet, viele statische Scanner und herkömmliche Systeme zur Taint-Analyse zu umgehen. Solche Tools untersuchen möglicherweise Installations-Hooks, verdächtige Erstellung von Subprozessen oder offensichtliche Datenflüsse von nicht vertrauenswürdigen Eingaben zu gefährlichen Funktionen. In diesem Fall ist der schädliche Zweig in einer scheinbar legitimen API verborgen und bleibt inaktiv, bis die Bedingungen zur Laufzeit erfüllt sind.

Die Betreiber sorgten außerdem für einen umfassenderen Anschein von Seriosität. Sie erstellten ein überzeugendes GitHub-Repository, statteten es mit einer authentisch wirkenden Commit-Historie aus und pflegten ein sorgfältig kuratiertes Entwicklerkonto. Diese Signale können sowohl automatisierte Reputationssysteme als auch Entwickler beeinflussen, die eine schnelle manuelle Prüfung vornehmen.

Die Schutzmechanismen von npm v12 decken die normale Laufzeitausführung nicht ab

Im Juni 2026 kündigte GitHub npm-Sicherheitsmaßnahmen an, die auf Supply-Chain-Angriffe reagieren sollen, von denen Open-Source-Ökosysteme seit Ende 2025 wiederholt betroffen waren. Zu diesen Maßnahmen gehört, dass npm v12 Dependency-Lifecycle-Skripte blockiert, sofern ein Benutzer sie nicht ausdrücklich autorisiert.

Die Schutzmechanismen schränken außerdem den automatischen Abruf von Dependencies aus Git-Repositories oder von Remote-URLs ohne Genehmigung ein. Dadurch wird die Wirksamkeit von Paketen reduziert, die sofort während der Installation Code ausführen oder über Dependency-Deklarationen externen Code abrufen.

indexed-btree umgeht diese Sicherheitsgrenze vollständig.

Da sein schädlicher Loader Bestandteil des normalen Laufzeitpfads des Pakets ist, stößt npm auf kein Installationsskript, das eine Genehmigung erfordern würde. Die Installation kann daher abgeschlossen werden, ohne die Warnung oder den Autorisierungsschritt auszulösen, den Verteidiger von einem herkömmlichen schädlichen Paket erwarten könnten.

Das bedeutet nicht, dass npm v12 durch eine Softwareschwachstelle umgangen wurde. Vielmehr werden die Grenzen einer Kontrolle sichtbar, die sich auf eine einzelne Ausführungsphase konzentriert. Einschränkungen für Lifecycle-Skripte können nicht genehmigtes Verhalten während der Installation stoppen. Sie können jedoch nicht feststellen, ob jede aufrufbare Funktion in einer Dependency sicher ist.

Eine erfolgreiche Installation ohne Warnungen ist daher kein Beleg dafür, dass der installierte Code harmlos ist.

Auf die Aufklärung folgt eine verschlüsselte Blockchain-Payload

Nach der Aktivierung erstellt die Malware ein Profil des Hosts. Zu den erfassten Informationen gehören:

• Systemarchitektur
• Hostname
• CPU-Details
• Speicherinformationen
• Systemlaufzeit

Die Daten werden über fest codierte Slack- und Telegram-Kanäle exfiltriert. Konkrete Kanal-IDs, Ziele und Netzwerkindikatoren wurden nicht veröffentlicht.

Für Command and Control fragt die Operation einen auf dem Sepolia-Testnetz bereitgestellten Ethereum-Smart-Contract ab. Dadurch können die Betreiber Payload-Material über eine Blockchain-Infrastruktur speichern oder verteilen, anstatt ausschließlich auf einen herkömmlichen Command-and-Control-Server angewiesen zu sein.

Die Malware verwendet einen X25519-Schlüsselaustausch, um einen AES-Schlüssel abzuleiten. Anschließend entschlüsselt sie eine zweite Payload-Stufe, die aus dem Smart Contract abgerufen wurde. Der Inhalt und die vollständigen Fähigkeiten dieser zweiten Stufe wurden nicht veröffentlicht. Die bestätigten Auswirkungen sollten daher nicht über den beobachteten Mechanismus zur Bereitstellung und Ausführung hinausgehen.

Die Ermittler identifizierten außerdem eine mit der Operation verknüpfte Ethereum-Wallet, die 109 ETH enthielt. Es gibt keine belastbaren Belege dafür, dass diese Gelder aus dem Diebstahl von Kryptowährungen oder aus über diese Pakete kompromittierten Systemen stammen.

Die Malware verfügt zusätzlich über eine vom Betreiber kontrollierte Bereinigungsfunktion. Bei ihrer Aktivierung kann sie ihre Dateien löschen und den schädlichen Trigger aus dem Paketquellcode entfernen. Dadurch kann eine zuvor betroffene Umgebung bei einer späteren Untersuchung unauffällig wirken, insbesondere wenn relevante Telemetriedaten zu Prozessen, Netzwerkverbindungen und Dateisystem nicht gespeichert wurden.

Neun verwandte Pakete vergrößerten die Reichweite der Kampagne

Checkmarx brachte neun weitere npm-Pakete mit derselben Operation in Verbindung. Alle neun wurden nach ihrer Entdeckung von npm entfernt.

Paket	Gemeldete Downloads
ordered-kv-index	448.184
btree-leaderboard	493.685
priority-slot-queue	402.860
btree-range-store	468.092
btree-core	1.951.274
btree-time-index	425.312
btree-lru-cache	372.185
neighbor-key-map	366.019
sliding-score-window	448.024

Der Entfernungsstatus von indexed-btree selbst wurde nicht angegeben. Auch die gemeldete Zahl von rund zwei Millionen Downloads pro Woche sollte nicht direkt mit den Downloadzahlen der anderen Pakete verglichen oder zu ihnen addiert werden. Bei diesen handelt es sich um gemeldete Downloadzahlen ohne dieselbe wöchentliche Einschränkung.

Downloadstatistiken belegen die Verbreitung, nicht eine Kompromittierung. Sie zeigen weder, wie viele Downloads zu Installationen führten, wie viele Anwendungen die veränderte Methode aufriefen noch bei wie vielen Ausführungen der erforderliche Trigger-Schlüssel übergeben wurde.

Dennoch deuten die Paketnamen auf eine Ausrichtung auf Softwareentwicklungs-Anwendungsfälle mit Indizes, Warteschlangen, Caches, Maps und Scoring-Systemen hin. Die potenzielle Angriffsfläche umfasst Entwicklerarbeitsplätze, CI-Runner, Build-Server und andere Systeme, auf denen npm-Dependencies mit Zugriff auf Quellcode oder Zugangsdaten ausgeführt werden.

Das Hauptrisiko geht über ein einfaches Host-Profiling hinaus

Es wurde weder ein CVSS-Score noch eine Bewertung des Schweregrads durch einen Anbieter vergeben. Es handelt sich um eine Kampagne mit schädlichen Paketen und nicht um eine herkömmliche Schwachstelle mit einer veröffentlichten CVE-Kennung.

Aus betrieblicher Sicht ist das Risiko hoch, da der Code eine breite Verbreitung, verzögerte Aktivierung zur Laufzeit, Host-Aufklärung, die verschlüsselte Bereitstellung einer zweiten Payload-Stufe und die Beseitigung von Spuren miteinander verbindet. Eine kompromittierte Entwicklungsumgebung kann mehr offenlegen als die Systemmetadaten, die in der ersten Stufe direkt erfasst werden.

Abhängig von den lokalen Berechtigungen könnte eine schädliche zweite Stufe möglicherweise auf Token für die Paketveröffentlichung, Zugangsdaten für die Quellcodeverwaltung, Cloud-Schlüssel, CI-Secrets, Signaturmaterial oder Anwendungskonfigurationen zugreifen. Der Zugriff auf diese Ressourcen wurde nicht bestätigt. Unternehmen sollten sie jedoch berücksichtigen, wenn sie feststellen, welche Daten und Systeme für einen betroffenen Prozess verfügbar waren.

Die Selbstbereinigung erschwert zudem die Eingrenzung eines Vorfalls. Das Fehlen schädlicher Dateien bei einer Untersuchung beweist nicht, dass keine Ausführung stattgefunden hat.

Betroffene Unternehmen sollten vor einem Neuaufbau Beweise sichern

Unternehmen sollten Dependency-Inventare, Lockfiles, interne Registries, Build-Caches, Container-Layer und Software Bills of Materials nach indexed-btree und allen neun damit verbundenen Namen durchsuchen. Da die betroffenen Versionsbereiche unbekannt sind, sollten Ermittler nicht davon ausgehen, dass ein bestimmtes Release sicher ist, ohne seinen Inhalt unabhängig zu überprüfen.

Vor dem Neuaufbau von Systemen sollten Incident-Responder verfügbare Paketartefakte, Prozesstelemetrie, Befehlshistorien, Netzwerkprotokolle, CI-Aufzeichnungen und Dateisystembelege sichern. Andernfalls könnte der Bereinigungsmechanismus Informationen löschen, die benötigt werden, um festzustellen, ob der Laufzeit-Trigger ausgelöst wurde.

Zu den empfohlenen Maßnahmen gehören:

1. Potenziell betroffene Entwicklungs- und Build-Systeme isolieren.
2. Alle Secrets rotieren, auf die diese Umgebungen zugreifen konnten, einschließlich Zugangsdaten für Quellcodeverwaltung, Registries, Cloud, Deployment und CI.
3. Systeme aus einem bekannten sicheren Backup oder einem sauberen Image wiederherstellen, anstatt dem eigenen Entfernungsverhalten der Malware zu vertrauen.
4. Laufzeitverbindungen zu Slack, Telegram und der Sepolia-Infrastruktur untersuchen, wobei zu berücksichtigen ist, dass auch legitime Tools diese Dienste nutzen können.
5. Nach unerwarteten X25519-Schlüsselaustausch- und AES-Entschlüsselungsaktivitäten suchen, die mit Node.js oder betroffenen Build-Prozessen verbunden sind.
6. Die Ausführung von Anwendungen und nicht nur die Paketinstallation überprüfen, insbesondere Aufrufe veränderter Bibliotheksmethoden und das Laden von sharedLoad.min.js.
7. Eine sandboxbasierte Laufzeitanalyse in das Screening von Paketen aufnehmen, insbesondere wenn Dependencies obfuskierten Code enthalten oder häufig verwendete API-Pfade verändern.

Das Blockieren von Lifecycle-Skripten bleibt sinnvoll, deckt jedoch nur einen Punkt in der Ausführungskette einer Dependency ab. Diese Kampagne zeigt, dass schädliche Maintainer die Aktivierung in die Anwendung selbst verlagern können, wo der Paketcode das Vertrauen und die Zugriffsrechte erbt, die der normalen Software bereits gewährt wurden.