Advanced NPM Supply-Chain Attack kombiniert Unicode-Steganografie mit Google Kalender als C2-Kanal

17. Mai 2025

Im Rahmen kontinuierlicher Sicherheitsanalysen wurde kürzlich ein bislang unauffälliges npm-Paket mit dem Namen „os-info-checker-es6“ als Teil einer hochentwickelten mehrstufigen Malware-Kampagne identifiziert. Der vermeintlich legitime Zweck – das Auslesen von Betriebssysteminformationen – diente lediglich als Tarnung für ein ausgeklügeltes Angriffsszenario, das mehrere fortschrittliche Techniken miteinander kombiniert.

Im ersten Schritt nutzen die Angreifer Unicode-basierte Steganografie, um Schadcode direkt im Quelltext des Pakets zu verschleiern. Diese Methode erschwert sowohl statische Analysen als auch automatische Codeüberprüfungen erheblich, da schädliche Anweisungen in scheinbar harmlosen Zeichenketten versteckt sind.

Besonders bemerkenswert ist die Art der Payload-Distribution: Anstelle klassischer Infrastruktur setzen die Angreifer auf einen verkürzten Link zu einem Google Kalender-Eintrag, der dynamisch als Dropper fungiert. Die Kalenderbeschreibung enthält codierte Instruktionen bzw. URLs, über die die eigentliche Malware geladen wird. Damit umgehen die Angreifer gängige C2-Detektionsmechanismen und nutzen eine legitime Cloud-Plattform zur Steuerung der Infektionskette.

Diese Kampagne verdeutlicht einmal mehr die wachsende Komplexität moderner Supply-Chain-Angriffe im Open-Source-Umfeld und unterstreicht die Notwendigkeit tiefgehender Code-Inspektion, selbst bei scheinbar trivialen Bibliotheken.

Hintergrund: Unauffälliger Start mit harmlosen Versionen

Das npm-Paket „os-info-checker-es6“ tauchte erstmals am 19. März 2025 im Registry auf. Auffällig war die rasche Veröffentlichung von insgesamt fünf Versionen innerhalb weniger Stunden – ein Vorgehen, das typischerweise auf aktives Testing oder schnelle Iterationen hindeutet.

Diese ersten Versionen verhielten sich zunächst vollkommen unauffällig. Sie beschränkten sich auf das Testen von Installations-Hooks, einfache Dateischreiboperationen sowie das Erfassen grundlegender Systeminformationen, darunter Plattform, Betriebssystemversion, Architektur und Hostname.

In diesem frühen Stadium konnten keine Hinweise auf Datenexfiltration, Netzwerkaktivität oder anderweitig bösartiges Verhalten festgestellt werden. Die unscheinbare Funktionalität diente offenbar dazu, Vertrauen aufzubauen – oder potenzielle Sicherheitsprüfungen zu umgehen, bevor der eigentliche Schadcode eingebracht wurde.

Google Kalender als widerstandsfähiger Dropper in mehrstufiger Angriffskette

Eine besonders raffinierte Komponente des Angriffs ist die Nutzung von Google Kalender als zwischengeschaltete C2-Infrastruktur. Durch die Einbettung eines Kurzlinks zu einem Google-Kalender-Eintrag wird eine legitime, cloudbasierte Plattform zweckentfremdet, um klassische Blacklisting-Mechanismen zu umgehen und frühzeitige Blockierungsversuche zu erschweren.

Ähnlich wie in früheren Proof-of-Concepts für Google Calendar RATs ruft das kompromittierte Skript dynamische Payloads über einen sekundären C2-Server ab – in diesem Fall eine IP-Adresse (http://140.82.54.223/…), die während der Analyse entweder offline war oder durch Anti-Analyse-Techniken geschützt wurde.

Das Schadskript selbst wurde robust aufgebaut: Es enthält Retry-Mechanismen, Fehlerbehandlung sowie eine Persistenzlogik in Form einer Sperrdatei im temporären Verzeichnis. Diese Maßnahmen dienen der Stabilität und Wiederherstellung der Funktion, falls der Download unterbrochen oder das System gestört wird.

Hohe Reichweite durch Abhängigkeitsnetzwerk im npm-Ökosystem

Die potenzielle Wirkung der Kampagne wird durch die Verbreitung innerhalb des npm-Ökosystems deutlich. Das Paket „os-info-checker-es6“ verzeichnete vor seiner Entfernung rund 655 wöchentliche Downloads und wurde als Abhängigkeit von vier weiteren Paketen eingebunden:

• skip-tot

• vue-dev-serverr

• vue-dummyy

• vue-bit

Auffällig dabei: Alle genannten Pakete wurden von Accounts mit ähnlichen Namensmustern veröffentlicht – darunter „kim9123“, der sowohl „os-info-checker-es6“ als auch „skip-tot“ autorisierte. Dies deutet auf ein gezielt aufgebautes, potenziell schlafendes bösartiges Paketnetzwerk hin, das bereits vor der Aktivierung des eigentlichen Schadcodes existierte.

Ein wachsendes Risiko für die Software-Lieferkette

Dieser Vorfall ist ein weiteres Beispiel für die zunehmende Raffinesse von Supply-Chain-Angriffen. Die Angreifer kombinieren dabei mehrere fortgeschrittene Techniken – darunter Unicode-Steganografie, kompilierte Binärdateien sowie den Missbrauch vertrauenswürdiger Cloud-Dienste – um legitime Plattformen für verdeckte Kommandoübermittlung und Payload-Verteilung zu instrumentalisieren.

Vor der Veröffentlichung wurde die Kampagne dem Sicherheitsteam von npm gemeldet, das entsprechende Gegenmaßnahmen einleitete.

Empfehlung an Entwickler:

Die Sicherheitslage unterstreicht die Dringlichkeit, Abhängigkeiten sorgfältig zu prüfen, insbesondere solche mit Installationsskripten, Postinstall-Hooks oder nativen Binärmodulen. Der Vorfall zeigt, wie wichtig proaktive Maßnahmen und kontinuierliche Überwachung im Umgang mit Open-Source-Komponenten geworden sind – gerade in einer zunehmend komplexen Bedrohungslandschaft.

Die unsichtbare Tinte entlarven: Unicode-Steganografie

Der eigentliche Trick liegt hier in diesem scheinbar harmlosen senkrechten Strich. Bei genauerer Betrachtung zeigt sich, dass es sich nicht nur um | handelt, sondern um |, gefolgt von strukturierten Daten, wie dieser Hexdump zeigt.

Quelle: Veracode

Das sich wiederholende 4-Byte-Muster deutet darauf hin, dass es sich um eine UTF-8-kodierte Sequenz von Unicode-Codepunkten aus der Supplementary Special Purpose Plane handelt, genauer gesagt aus dem Bereich Variation Selectors Supplement (U+E0100 bis U+E01EF). Die allgemeine Kategorie für die Codepunkte in diesem Bereich ist Mn, d. h. ein nicht zu verteilendes Zeichen, das typischerweise als Modifikator für vorangehende Zeichen verwendet wird, oft um spezifische Glyphenvariationen in komplexen Schriften zu ermöglichen (wie verschiedene Emoji-Darstellungen oder Ligaturen in ostasiatischen Sprachen). Diese Variationsselektoren haben jedoch keine Glyphe, wodurch sie praktisch unsichtbar sind – eine ziemlich clevere steganografische Technik.

Nebenbei bemerkt gibt es für die Steganografie vielfältige Anwendungsmöglichkeiten, doch die meisten Menschen scheinen sie sofort mit dem Verstecken von Daten in Bildern in Verbindung zu bringen. Dies ist angesichts ihrer historischen Bedeutung und der visuellen Intuition, die bildbasierte Techniken leichter vorstellbar macht als diese Art der textbasierten Anwendung, eine natürliche Annahme. Schließlich definiert Merriam-Webster sie als „die Kunst oder Praxis, eine Nachricht, ein Bild oder eine Datei in einer anderen Nachricht, einem anderen Bild oder einer anderen Datei zu verbergen“, was klar definiert, womit wir es hier zu tun haben. Das Auffinden einer langen Folge dieser unsichtbaren Selektoren, die an ein einfaches ASCII-Zeichen angehängt sind, ohne dass ihnen ein Zeichen vorangestellt ist, das sie logischerweise verändern, ist höchst ungewöhnlich und in diesem Fall ein Hinweis auf Steganografie.

Wo stehen wir nun? Nun, wir wissen, dass wir eine decode-Funktion in einer undurchsichtigen Binärdatei haben, die eine Reihe unsichtbarer Unicode-Zeichen verarbeitet und eine Base64-kodierte Zeichenfolge zurückgibt. Wie finden wir heraus, was hier vor sich geht? Wir haben mehrere Möglichkeiten:

1. Wir können einfach den Code ausführen und dabei eval durch console.logersetzen. Das ist einfach und gibt uns zwar Auskunft über das „Was“, aber nicht über das „Wie“.
2. Wir können eine der Binärdateien in Ghidra öffnen und dekompilieren.
3. Wir können einen Magier beauftragen, dessen Intuition nach nur wenigen Augenblicken des Betrachtens der rohen Codepunkte vermuten lässt, dass es sich um eine einfache (wenn auch effektive) Low-Byte-Shift-Verschlüsselung handelt.

Es stellte sich heraus, dass wir alle drei Möglichkeiten genutzt haben. Und durch eine Kombination aus Punkt 2 und 3 werden wir uns genau ansehen, wie das funktioniert.

Wenn Sie diesen speziellen Unicode-Bereich untersuchen, werden Sie feststellen, dass die Variationsselektoren das gemeinsame Präfix U+E01haben, was bedeutet, dass die ersten drei Hexadezimalziffern E01sind. Um also sinnvolle Informationen in diesen Zeichen zu verschlüsseln, müssen die Daten im Low-Byte jedes Selektors gespeichert werden – also in xx in U+E01xx. Da die endgültige Ausgabe nach der Decodierung eine Base64-Zeichenkette sein soll (denken Sie an den Aufruf von atob), muss das Low-Byte dieser Unicode-Zeichen irgendwie auf druckbare ASCII-Zeichen abgebildet werden, die für die Base64-Kodierung geeignet sind. Der Suchraum ist sehr klein, sodass wir durch eine Brute-Force-Analyse, bei der wir eine kleine Verschiebung auf diese niedrigen Bytes angewandt haben, herausgefunden haben, dass ein Offset von 0x10 (Subtraktion von 16) und anschließendes Abschneiden auf ein Byte die versteckten Daten offenbart.

Fazit: Eine neue Stufe der Raffinesse im npm-Ökosystem

Die Analyse des Pakets „os-info-checker-es6“ offenbart eine technisch anspruchsvolle, mehrstufige Angriffskette und unterstreicht den Reifegrad moderner Bedrohungsakteure im Open-Source-Umfeld. Was zunächst als einfache Testveröffentlichung erschien, entwickelte sich rasch zu einem komplexen Angriffsszenario mit folgenden Schlüsselmerkmalen:

• Plattformspezifisch kompilierte Binärdateien, maßgeschneidert für verschiedene Zielsysteme.

• Eine Unicode-Steganografie-Technik, die den initialen Loader-Code effektiv tarnt und klassische Analyseverfahren umgeht.

• Ein innovativer Command-and-Control-Mechanismus, bei dem Kurzlinks zu Google-Kalender-Einträgen verwendet werden, um dynamisch Anweisungen abzurufen. Diese Methode erschwert sowohl die Attribution als auch die Blockierung.

• Widerstandsfähige Architektur mit integrierter Fehlerbehandlung, Wiederholungslogik und Persistenzmechanismen zur Sicherstellung der Funktion auch bei Unterbrechungen.

Dieser Vorfall demonstriert eindrucksvoll, wie gezielt und ausgefeilt moderne Angriffe auf die Software-Lieferkette erfolgen. Open-Source-Ökosysteme wie npm geraten dabei zunehmend ins Visier, nicht zuletzt wegen ihrer Reichweite und des häufig unkritischen Vertrauens in veröffentlichte Pakete.

Empfehlung: Entwickler und Sicherheitsteams sollten Abhängigkeiten mit besonderem Augenmerk auf Postinstall-Skripte, native Module und ungewöhnliche Veröffentlichungsmuster prüfen. Automatisierte Sicherheitsscans allein reichen nicht aus – erforderlich ist ein mehrschichtiger Prüfansatz.

Vor der Veröffentlichung dieser Analyse wurde das betroffene Paket an das npm-Sicherheitsteam gemeldet. Die laufende Beobachtung des Angreifers und seiner Infrastruktur wird fortgesetzt, um mögliche Folgeaktivitäten frühzeitig zu erkennen und betroffene Akteure zu informieren.

Redaktion AllAboutSecurity

---

Bild/Quelle: https://depositphotos.com/de/home.html