Startseite / Sicherheit
Sicherheit

Böses npm-Paket imgdecode lädt Shellcode in Windows

Böses npm-Paket imgdecode lädt Shellcode in Windows
← Alle Beiträge

Das npm-Paket imgdecode enthält einen Schadcode-Loader für Windows. Das Paket verbirgt seine zentrale Funktion in einem kompilierten Node.js-Addon: Wird es in einer Windows-Umgebung mit require('imgdecode') geladen, kann die enthaltene DLL verschlüsselten Shellcode von GitHub abrufen, entschlüsseln und in einen neu gestarteten Prozess dllhost.exe injizieren.

imgdecode wurde am 30. September 2026 vom npm-Konto malfexteste8 veröffentlicht. Zum Stichtag 17. Oktober war das Paket laut den vorliegenden Analysen weiterhin verfügbar und 979-mal heruntergeladen worden. Die aktuelle Version ist 1.0.3. Sie ist keine Bereinigung, sondern die bislang eigenständigste Variante des Loaders: Ab dieser Version benötigt imgdecode keine weiteren Pakete der MALFEX-Kampagne mehr.

Für Entwickler und Unternehmen ist deshalb eine Unterscheidung entscheidend: 979 Downloads belegen die Verbreitung des Pakets, aber nicht 979 erfolgreiche Infektionen. Die dokumentierte imgdecode-Kette zielt auf Windows und besitzt keinen Installations-Hook. Der Schadcode wird beim Laden des Pakets ausgeführt. Wo sich nicht mehr sicher klären lässt, ob dies auf einem Entwicklerrechner, Build-System oder CI-Host geschehen ist, sollte das betroffene Windows-System dennoch als potenziell kompromittiert behandelt werden.

Alle bekannten imgdecode-Versionen sind verdächtig

Für imgdecode gibt es weder eine gepatchte Version noch eine CVE oder einen CVSS-Wert. Es handelt sich nicht um eine versehentliche Schwachstelle in legitimer Software, sondern um ein absichtlich bösartiges Paket. Die Versionen 1.0.0 bis 1.0.3 sollten daher nicht weiterverwendet werden.

Die Angriffskette von imgdecode
Angriffskette von imgdecode1. npm-Paket imgdecodeVersionen 1.0.0 bis 1.0.32. require('imgdecode') unter WindowsKein postinstall-Hook erforderlich3. Native 64-Bit-DLLDownload und Entschlüsselung des Shellcodes4. Injektion in dllhost.exe5. Downloader, Stealer und Fernzugriff
Das Schaubild zeigt den Weg vom Laden des npm-Pakets über die native Windows-DLL und den verschlüsselten Download bis zur Prozessinjektion und zum nachgeladenen Stealer oder RAT.

Die technische Entwicklung der Versionen zeigt, wie der Betreiber Abhängigkeiten schrittweise entfernt hat. Version 1.0.0 wartete auf Daten, die von einem weiteren MALFEX-Paket bereitgestellt wurden. In den Versionen 1.0.1 und 1.0.2 konnte die native DLL den verschlüsselten Payload bereits selbst herunterladen und entschlüsseln, rief aber weiterhin imgbundle auf. Version 1.0.3 beseitigte diese Abhängigkeit vollständig.

Das native Addon ist eine mit Microsoft Visual C++ erstellte 64-Bit-DLL. Nach Prüfungen der Ausführungsumgebung lädt sie eine Datei namens banner.jpg aus dem inzwischen nicht mehr erreichbaren GitHub-Konto cavecrew. Der darin versteckte Inhalt wird mit dem Schlüssel nif-runtime-2027 entschlüsselt und anschließend in dllhost.exe injiziert. Entschlüsselt sich der Inhalt zu einer gültigen JPEG- oder PNG-Datei, stoppt der Loader. Der Betreiber konnte die Auslieferung damit offenbar serverseitig abschalten, ohne ein neues npm-Paket veröffentlichen zu müssen.

Die Entfernung eines Pakets beendet die Kampagne nicht

imgdecode gehört zur seit August 2023 beobachteten Kampagne MALFEX. Frühere Pakete wurden unter mehreren Publisher-Konten veröffentlicht und lieferten unter anderem den Overlord RAT sowie einen Node.js-Stealer aus. Zu den bekannten Paketnamen gehören cdn-img-fetch, img-to-native, native-runner, runhelper und imgbundle.

Die Abfolge Ende September verdeutlicht das operative Problem für Paketregister und Sicherheitsteams. npm entfernte native-runner und img-to-native am 28. September. Zwei Tage später erschienen mit runhelper und imgbundle Ersatzpakete. Nur wenige Stunden nach der Entfernung von runhelper wurde imgdecode veröffentlicht. Als npm anschließend imgbundle und cdn-img-fetch entfernte, folgte am 11. Oktober imgdecode 1.0.3 ohne diese Abhängigkeiten.

Eine Sperre wirkt damit zunächst nur gegen einen konkreten Paketnamen und eine konkrete technische Kette. Der Akteur konnte nicht nur Namen austauschen, sondern auch die Ausführung verändern: Statt eines auffälligen postinstall-Skripts oder einer vollständig in JavaScript sichtbaren Logik liegt der relevante Code in einem nativen Windows-Modul. Prüfungen, die hauptsächlich Paketmetadaten und Installationsskripte bewerten, erfassen diesen Teil der Lieferkette nur unvollständig.

Vom Downloader zum vollständigen Zugriff

Eine archivierte Aufnahme der inzwischen entfernten GitHub-Datei weist laut der Analyse auf denselben Go-basierten Downloader hin, der in früheren MALFEX-Ketten verwendet wurde. Dieser lud den als movinlike bezeichneten Stealer und Fernzugriffstrojaner von 104.234.65[.]75:700. In der untersuchten Anwendung war außerdem die C2-Adresse 104.234.65[.]75:7007 hinterlegt.

Der Payload prüft auf virtuelle Maschinen, Sandboxes und Analysewerkzeuge wie Process Monitor und Wireshark. Er sucht nach Dateien mit Seed-Phrasen sowie nach Dateitypen wie .kdbx, .pem, .ppk und .env. Hinzu kommen Daten aus Chromium-Browsern, Discord, Telegram, Kryptowährungswallets und Spieleplattformen. Über eine WebSocket-Verbindung kann die Malware unter anderem Befehle ausführen, Dateien übertragen, Prozesse steuern, Screenshots anfertigen sowie auf Zwischenablage, Maus und Tastatur zugreifen.

Zur Persistenz setzt sie einen Registry-Run-Key und legt eine geplante Aufgabe mit dem Namen MicrosoftEdgeUpdateService an. Die Analyse belegt damit einen funktionsfähigen Schadcode und eine veröffentlichte Angriffskette. Aus den vorliegenden Informationen geht jedoch nicht hervor, wie viele Systeme tatsächlich erfolgreich kompromittiert wurden.

Eine Deinstallation ist keine Bereinigung

Betroffene Teams sollten zunächst in package-lock.json, yarn.lock, pnpm-lock.yaml, lokalen node_modules-Verzeichnissen und Build-Umgebungen nach imgdecode und den weiteren MALFEX-Paketen suchen. Relevant sind nicht nur Entwicklerrechner, sondern auch Windows-basierte CI-Runner und Build-Hosts, auf denen Abhängigkeiten geladen oder Tests ausgeführt wurden.

Wurde imgdecode auf einem Windows-System ausgeführt oder lässt sich das nicht ausschließen, reicht das Löschen des Pakets nicht. Das System sollte isoliert und auf den geplanten Task MicrosoftEdgeUpdateService, verdächtige Registry-Run-Einträge, dllhost.exe-Kindprozesse sowie Verbindungen zu den genannten IP-Adressen und Ports untersucht werden. Zugangsdaten, Browser-Sitzungen, API-Schlüssel und Entwicklungstoken sind von einem sauberen Gerät aus zu widerrufen oder zu rotieren. Falls Seed-Phrasen auf dem Rechner gespeichert waren, sollten Bestände in neue Wallets übertragen werden.

Der entscheidende Mechanismus dieser Kampagne liegt damit nicht allein im einzelnen Paket. MALFEX verbindet austauschbare Paketnamen mit einer veränderbaren Ausführungskette und extern ausgelieferten Payloads. Für die Praxis bedeutet das: Eine Paketentfernung stoppt die weitere Verteilung, beseitigt aber weder bereits gestarteten Code noch dessen Persistenz und gestohlene Zugangsdaten.

J

Über den Autor

Jens Könnig

Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?

Alle Artikel von Jens Könnig →