Forscher der Sicherheitsfirma Socket haben im npm-Ökosystem das Paket fezbox als bösartig eingestuft. Die Besonderheit: Der Angreifer versteckt den obfuskierten JavaScript-Code in einem QR‑Bild, das zur Laufzeit von einem externen Server geladen und maschinell geparst wird. Bis zur Entfernung durch die npm-Administratoren wurde das Paket laut Socket mindestens 327‑mal heruntergeladen – ein weiterer Beleg für die anhaltende Relevanz von Supply‑Chain‑Angriffen auf Open‑Source‑Abhängigkeiten.
Angriffsaufbau: JavaScript-Payload in einem QR-Bild
Die Analyse zeigt, dass die Hauptlogik in dist/fezbox.cjs (z. B. Version 1.3.0) verankert ist. Obwohl der Code stark minimiert wurde, lässt sich nach Formatierung klar nachvollziehen: Der Client lädt ein ungewöhnlich dichtes QR‑JPG und extrahiert daraus die zweite Stufe der Payload. Solche QR‑Codes sind nicht für Smartphone‑Scanner gedacht, sondern für programmgesteuertes Parsing, um versteckte Instruktionen einzuschleusen.
Zweistufige Ausführung mit Verzögerung
Stufe 1: Das Paket lädt das dichte QR‑Bild vom Angreifer‑Server. Der Zielinhalt ist im Bild kodiert und durch Obfuskation verschleiert.
Stufe 2: Nach einer bewussten Verzögerung von ca. 120 Sekunden und Umgebungsprüfungen extrahiert fezbox den JavaScript‑Code und führt ihn aus. Der Fokus liegt auf Cookie‑Diebstahl via document.cookie, potenziell inklusive Benutzername und Passwort.
Taktiken zur Erkennungsevasion und Tarnung
Die Malware prüft, ob sie in Entwicklungs- oder virtualisierten Umgebungen läuft, um Analysen zu erschweren. Außerdem werden Strings revers abgelegt („drowssap” → „password”) und URLs umgekehrt gespeichert, um einfache Signatur‑Scans (z. B. auf http/https‑Muster) zu umgehen. Diese Techniken sind simpel, aber effektiv gegen statische Analysen und automatisierte Erkennung.
Datenabfluss und Command-and-Control
Wenn Cookies sowie optional Benutzername/Passwort gefunden werden, sendet fezbox die Daten per HTTPS‑POST an https[:]//my-nest-app-production[.]up[.]railway[.]app/users. Fehlen diese Felder, beendet der Code die Ausführung leise, um keine forensischen Spuren zu hinterlassen. Das „Image‑Load‑Masking” tarnt die Kommunikation als regulären Abruf einer Grafik – ein Muster, das in Proxy‑ und Monitoring‑Systemen häufig weniger Aufmerksamkeit erzeugt.
Risikoeinordnung für Entwickler und Unternehmen
Die Kombination aus Abhängigkeitsmissbrauch, QR‑basiertem Payload‑Transport und Obfuskation bedroht vor allem Teams, die Build‑Pipelines automatisiert betreiben und Client‑seitige Bundles aus Drittpaketen generieren. Branchenberichte wie der ENISA Threat Landscape und Sonatypes State of the Software Supply Chain warnen seit Jahren vor dieser Angriffsklasse: Angriffe verlagern sich zunehmend in die Software‑Lieferkette, da sie mit einem kompromittierten Paket eine große Breitenwirkung erzielen.
Praktische Schutzmaßnahmen: Von Cookies bis CI/CD
Abhängigkeiten härten: Versionen pinnen (Lockfiles), SCA‑Tools einsetzen, Post‑Install‑Skripte prüfen, ungenutzte Pakete entfernen und Drittcode nur mit minimalen Rechten ausführen. Eigenständige Mirror/Registries und Signaturen (z. B. Sigstore) erhöhen die Integrität.
Cookies absichern: HttpOnly, Secure, SameSite konsequent setzen. HttpOnly verhindert das Auslesen via document.cookie selbst bei XSS‑ähnlichen Szenarien und reduziert das Exfiltrationspotenzial erheblich.
Netzwerk- und Build‑Kontrollen: CI/CD isolieren, ausgehende Verbindungen per deny‑by‑default beleidern, verdächtige Endpunkte blockieren und JPG‑Downloads mit anschließender Codeausführung als IOC werten. Telemetrie auf DNS/HTTP‑Ebene hilft, untypische Abrufmuster früh zu erkennen.
Forensik und Incident Response: Projekte, die fezbox genutzt haben könnten, sollten Logs auf Abrufe Richtung Railway[.]app prüfen, Session‑Cookies auf HttpOnly verifizieren und betroffene Token/Passwörter rotieren.
Der Fall fezbox illustriert die Weiterentwicklung von Supply‑Chain‑Taktiken: Eine QR‑Code‑Payload erschwert statische Analysen und tarnt Netzwerkverkehr. Organisationen sollten ihre Abhängigkeitsstrategie schärfen, Cookie‑Konfigurationen durchgängig härten und CI/CD‑Egress strikt reglementieren. Jetzt ist ein guter Zeitpunkt, SCA flächendeckend auszurollen, Post‑Install‑Hooks zu überwachen und Telemetrie‑Regeln für „Bild lädt, Code folgt”-Anomalien zu etablieren.
