Eine neue Kampagne zeigt, wie schnell sich Schadsoftware im JavaScript-Ökosystem verbreiten kann: Fast 800 bösartige npm-Pakete wurden im npm-Registry veröffentlicht, um als scheinbar harmlose Abhängigkeiten zu dienen. Das Ziel: RAT und Infostealer über Windows, macOS und Linux zu liefern.
Besonders bemerkenswert ist dabei der Ausführungsweg. Anders als viele frühere npm-orientierte Angriffe, die typischerweise über Installations-„Lifecycle“-Hooks wie preinstall oder postinstall Code anstoßen, setzt diese Kampagne auf einen Lesehinweis im README, der Entwickler zum bewussten Laden der Pakete auffordert.
Warum die bösartigen npm-Pakete so schwer zu stoppen sind
Die Pakete wirken zunächst wie klassische Typosquatting-Varianten: Namen, die per generierter Schreibweise oder „AI-ähnlichem“ Füllmaterial nahe an legitimen Paketen liegen, um entdeckt zu werden. Laut den beteiligten Forschern liefern sie jedoch durchgehend denselben Kernmechanismus: einen Downloader und anschließend eine plattformspezifische Payload.
Der entscheidende Unterschied zu vielen Supply-Chain-Angriffen: Die Ausführung wird nicht automatisch über Installationstrigger erzwungen. Stattdessen enthält das README eine Anleitung, die darauf abzielt, das Paket über require() zu laden – also über die eingebaute Node-Importfunktion für Module und lokale Dateien.
Für Teams, die Pakete nur automatisiert installieren, kann das zunächst „harmlos“ erscheinen. Für Entwickler oder Tools, die nach Lesehinweisen arbeiten oder Beispielcode ausführen, steigt jedoch das Risiko erheblich.
So läuft der Infektionsprozess ab
Nach dem Laden startet die Schadsoftware einen Downloader namens WEL1DROPPER. In dieser Phase ermittelt sie Betriebssystem und CPU-Architektur des Hosts und lädt danach eine passende Weiterstufe nach.
Stufe 1: Abruf über Cloudflare Workers
Der Downloader versucht zunächst, über drei Cloudflare-Worker-Domains eine kompatible Payload zu beziehen:
- oob-worker.cf103-070.workers[.]dev
- oob-worker.cf102-baf.workers[.]dev
- oob-worker.cf99-9b3.workers[.]dev
Wenn dieser HTTPS-basierte Abruf fehlschlägt, wechselt die Malware zu einem DNS-basierten Verfahren.
Stufe 2: DNS TXT als „Chunk“-Lieferkanal
Dann nutzt der Schadcode DNS TXT-Records und bezieht die nächste Stufe aus dem Domain-Umfeld wel1[.]ru. Für jede Plattform und Architektur existieren dabei spezifische Ziel-Domains:
- Linux x64: sdk.dl.wel1[.]ru
- Linux ARM64: ext.dl.wel1[.]ru
- macOS: pkg.dl.wel1[.]ru
- Windows: net.dl.wel1[.]ru
Der Ablauf ist dabei technisch präzise: Die Malware fragt zunächst einen TXT-Record von c.<domain> ab. Aus der Antwort wird eine Anzahl von Payload-Chunks extrahiert – zulässig sind Werte von 1 bis 2.000. Anschließend werden TXT-Records mit fortlaufenden Nummern angefragt, die Strings zusammengesetzt und per Base64 in einen binären Puffer dekodiert.
Damit wird die eigentliche Weiterstufe in viele kleine Teile zerlegt, was Netzeinsicht und statische Erkennung erschwert.
Finale Ausführung: pro Betriebssystem unterschiedliche Ketten
In der letzten Phase schreibt die Malware die Payload in ein temporäres Verzeichnis und startet sie anschließend. Dabei unterscheiden sich die Startkommandos nach Plattform:
- Linux und macOS: Ausführung über /bin/sh
- Windows: Ausführung über cmd.exe
Windows: Persistenz und Eingriffe in Überwachung
Für Windows beschreibt die Analyse, dass die finale Stufe als detached process gestartet wird. Zusätzlich unternimmt sie Schritte, um die Überwachung zu beeinträchtigen, unter anderem durch Eingriffe rund um Event Tracing for Windows (ETW) und Antimalware Scan Interface (AMSI). Ziel ist es, Logging und Erkennung zu erschweren.
Darüber hinaus kontrolliert die Malware Hinweise auf Sandboxen oder virtuelle Umgebungen. Anschließend etabliert sie Persistenz über einen Registry Run Key und eine geplante Aufgabe. Die Schadkomponente lädt danach eine verschlüsselte Datei (genannt „/pkg/update_win.exe“) und startet sie.
macOS: Debugging-Erkennung, LaunchAgent und Remote-Stage
Die macOS-Infektionskette ist ähnlich aufgebaut. Zunächst versucht die Malware, einen passenden Payload-Teil direkt von einem Remote-Server abzurufen (genannt: „/pkg/beacon_mac.bin“). Wenn das scheitert, greift sie auf das zuvor beschriebene DNS-TXT-Lieferverfahren zurück.
Für die Persistenz verwendet sie außerdem einen LaunchAgent. Danach startet sie die ausführbare Datei erneut als separater Prozess im Hintergrund.
Linux: UPX-ELF, Cloudflare Worker und Sliver
Unter Linux liegt ein Beispiel als UPX-verschlüsselte ELF-Datei vor. Diese ist so konfiguriert, dass sie weitere Hilfspayloads von einer Cloudflare-Worker-URL herunterlädt (im Bericht u. a. erwähnt: oob-worker[.]cf99-9b3.workers[.]dev). Das führt letztlich zur Bereitstellung von Sliver, einem Open-Source-Command-and-Control-(C2)-Framework.
Telemetrie-Noise als Tarnung in den Paketen
Ein weiteres Detail erhöht die Wahrscheinlichkeit, dass Teams die Gefahr übersehen: In den Paketen befindet sich eine Datei namens lib/telemetry.js. Diese implementiert eine Art „plausibel aussehendes“ Telemetrie-SDK. Gleichzeitig enthält sie jedoch dieselbe Downloader-Logik wie in der eigentlichen Schadkette.
Wichtig ist: Der Einstiegspunkt des Pakets importiert diese Datei nicht. Für schnelle Reviews wirkt das wie ungenutzter Code. Genau das scheint beabsichtigt zu sein: Durch überdimensionierte Implementierungen soll die bösartige Absicht wie native Profiling- oder Analytics-Funktionalität wirken.
Mögliche Zielbranchen: Hinweise aus Domains
Im macOS-Payload-Kontext tauchen Domains wie tcsbank[.]ru und cloudpayments[.]ru auf. Das wird im Bericht als Indiz gewertet, dass die Kampagne potenziell russische Finanzinstitutionen oder mobile Zahlungsstrukturen ins Visier nehmen könnte.
Darüber hinaus gibt es Hinweise, dass die aktuelle Entwicklung eine Weiterstufe einer früher beobachteten Dependency-Confusion-Kampagne mit dem Codenamen Moika sein könnte. Dabei wurden im April bereits über 250 Pakete veröffentlicht, um Umgebungsinformationen zu stehlen und eine zweite Stufe auszuliefern, die vom Betriebssystem abhängt.
Ein größeres Bild: Angriffe auf npm und PyPI sowie Browser-Extensions
Die Entdeckung der bösartigen npm-Pakete passt in ein breiteres Muster: Weitere Kampagnen zielten auf das npm-Registry und zusätzlich auf den Python Package Index (PyPI) ab. Dazu zählten unter anderem Pakete, die einen obfuskierten Kryptostealer und einen Remote-Access-Trojaner nachladen. Der Bericht nennt dabei Mechanismen, bei denen Payload-URLs in JSON und per obfuskiertem IIFE-Code rekonstruiert werden.
Auch andere Vorfälle beschreiben Credential-Exfiltration aus Cloud-Umgebungen, das Stehlen von Wallet-Keys für Solana über Telegram, das Abgreifen von .env-Dateigeheimnissen sowie Social-Engineering-Elemente wie Fake-CAPTCHA. Zusätzlich wurden Angriffe berichtet, die Discord-Tokens oder GitHub-Actions-CI/CD-Credentials ausnutzen.
Außerdem beobachteten Experten Kampagnen mit Chrome-Extensions, die als Game-Emulatoren, Passwortmanager oder Tools zur Produktivität vermarktet wurden. Diese Erweiterungen können den Browser als Web-Crawling-Proxy missbrauchen. Die Crawl-Kommandos werden dabei über eine dauerhafte WebSocket-Verbindung remote gesteuert; zur Datenerfassung wird ein Webbandbreite-Sharing-SDK eingebunden, das Seiteninhalte im Hintergrund in Markdown umwandelt und an einen entfernten Backend-Dienst sendet.
Wie Sie reagieren: praktische Schutzschritte
Wenn in Ihrem Projekt bösartige npm-Pakete im Spiel sind, zählt schnelle Reaktion. Beginnen Sie mit einer Bestandsaufnahme: Welche Dependencies nutzen Sie, aus welchen Versionen und aus welchen Quellen werden sie installiert? Prüfen Sie zusätzlich, ob in README-Dateien Anweisungen stehen, die ausdrücklich zum Laden über require() oder zu atypischem Beispielcode ermutigen.
Erstellen Sie dann eine Quarantäne- und Bereinigungsroutine. Entfernen Sie verdächtige Pakete, sperren Sie betroffene Versionen und aktualisieren Sie Abhängigkeiten nur gezielt. Nutzen Sie Tools zur Dependency-Analyse und setzen Sie — wo möglich — restriktive Policies für die Freigabe von Drittpaketen um.
Schließlich hilft Monitoring: Achten Sie auf ungewöhnliche Netzwerkzugriffe, insbesondere auf DNS-TXT-basierte Abfragen oder wiederkehrende Downloads, die nicht zu Ihrem erwarteten Verhalten passen.
Fazit: npm ist weiterhin ein attraktives Angriffsziel
Die Entdeckung von fast 800 bösartigen npm-Paketen macht deutlich, wie wandelbar moderne Supply-Chain-Angriffe sind. Die Kampagne setzt nicht primär auf klassische Installationshooks, sondern auf einen aufmerksamkeitsintensiven Ausführungsweg über README-Anleitungen und require(), gefolgt von plattformspezifischen Downloaddatenströmen über HTTPS oder DNS TXT.
Wer Dependencies ernsthaft verwaltet, Reviews konsequent durchzieht und ungewöhnliche Lade- oder Netzwerkmuster überwacht, reduziert das Risiko deutlich. Lassen Sie dabei nicht nur die Installation prüfen, sondern auch, was nach dem Laden im Code passiert.
Quelle: https://thehackernews.com/2026/08/nearly-800-malicious-npm-packages.html
