GlassWorm-Malware

Eine neue Welle der GlassWorm-Malware-Kampagne zielt aktiv auf Software-Lieferketten ab, indem gestohlene GitHub-Tokens ausgenutzt werden, um Schadcode in Hunderte von Repositories einzuschleusen. Der Fokus dieser Operation liegt primär auf Python-basierten Projekten, darunter Django-Anwendungen, Forschungscode im Bereich maschinelles Lernen, Streamlit-Dashboards und PyPI-Pakete.

Der Angriffsvektor ist trügerisch einfach, aber hochwirksam: Verschleierte Schadsoftware wird an häufig ausgeführte Dateien wie setup.py, main.py und app.py angehängt. Jeder Entwickler, der Abhängigkeiten über pip install installiert oder geklonten Code aus einem kompromittierten Repository ausführt, aktiviert unwissentlich die schädliche Nutzlast.

Stille Übernahmen von Datenspeichern: Die ForceMemo-Technik

Diese Weiterentwicklung der Kampagne, die nun als ForceMemo bezeichnet wird, führt eine schwer erkennbare Methode zur Kompromittierung von Repositories ein. Angreifer verschaffen sich Zugriff auf Entwicklerkonten und manipulieren Repositories, ohne herkömmliche Spuren zu hinterlassen.

Durch das Rebasen legitimer Commits mit Schadcode und das anschließende Force-Pushen auf den Standard-Branch bleiben die ursprünglichen Commit-Metadaten, einschließlich Nachricht, Autor und Zeitstempel, erhalten, wodurch der Einbruch effektiv verschleiert wird. Dieser Ansatz beseitigt sichtbare Indikatoren wie Pull Requests oder verdächtige Commit-Historien und erschwert die Erkennung erheblich.

Angriffsablaufkette: Vom Diebstahl von Zugangsdaten bis zur Auslieferung der Schadsoftware

Die ForceMemo-Kampagne folgt einem strukturierten und mehrstufigen Eindringprozess:

• Die Entwicklerumgebungen werden zunächst durch bösartige Visual Studio Code- und Cursor-Erweiterungen kompromittiert, die GlassWorm-Komponenten enthalten, welche darauf ausgelegt sind, sensible Anmeldeinformationen, einschließlich GitHub-Tokens, zu sammeln.
• Die gestohlenen Zugangsdaten werden dann verwendet, um verschleierte Base64-kodierte Nutzdaten in Python-Dateien in allen mit dem kompromittierten Konto verbundenen Repositories einzuschleusen.
• Die eingebettete Schadsoftware führt Umgebungsprüfungen durch und vermeidet insbesondere die Ausführung auf Systemen mit russischer Gebietsschemaeinstellung. Anschließend fragt sie eine Solana-Blockchain-Wallet ab, um die URL für die Nutzlastauslieferung dynamisch zu ermitteln.
• Es werden zusätzliche Nutzdaten heruntergeladen, darunter verschlüsseltes JavaScript, das für den Diebstahl von Kryptowährungen und die Datenexfiltration entwickelt wurde.

Blockchain-basierte Kommando- und Kontrollsysteme: Eine widerstandsfähige Infrastruktur

Ein charakteristisches Merkmal dieser Kampagne ist die Nutzung der Solana-Blockchain als Command-and-Control-Mechanismus (C2). Anstelle herkömmlicher Server speichern die Angreifer Payload-URLs in Transaktions-Memo-Feldern, die mit bestimmten Wallet-Adressen verknüpft sind.

Die Analyse zeigt, dass die Aktivitäten im Zusammenhang mit der primären Wallet bereits am 27. November 2025 begannen, Monate bevor die Kompromittierung des Repositorys festgestellt wurde. Die Wallet hat Dutzende von Transaktionen verarbeitet, wobei die Speicherorte der Nutzdaten häufig, teilweise mehrmals täglich, aktualisiert wurden. Dieser dezentrale Ansatz erhöht die Ausfallsicherheit und erschwert die Bekämpfung des Systems.

Erweiterung der Angriffsfläche: npm und ökosystemübergreifende Infektionen

Die Kampagne hat sich über Python-Ökosysteme hinaus auf JavaScript-Lieferketten ausgeweitet. Zwei React Native npm-Pakete, react-native-international-phone-number (Version 0.11.8) und react-native-country-select (Version 0.3.91), wurden vorübergehend kompromittiert und mit eingebetteter Schadsoftware verbreitet.

Diese bösartigen Versionen enthielten Preinstall-Hooks, die verschleierten JavaScript-Code ausführten und so eine ähnliche Infektionskette auslösten. Die Malware meidet erneut russische Systeme, ruft die Payload-Anweisungen über eine Solana-Wallet ab und setzt plattformspezifische Bedrohungen ein.

Die Ausführung erfolgt vollständig im Arbeitsspeicher mithilfe von Laufzeittechniken wie `eval()` oder Node.js-Sandboxing, wodurch nur minimale forensische Spuren entstehen. Zusätzlich verhindert ein Persistenzmechanismus eine erneute Infektion innerhalb von 48 Stunden durch lokales Speichern eines Zeitstempels.

Fortgeschrittene Ausweich- und Verteilungstaktiken

Neuere Versionen von GlassWorm zeigen eine gesteigerte Raffinesse bei der Verbreitung und Verschleierung von Schadsoftware. Durch die Nutzung von extensionPack- und extensionDependencies-Mechanismen verteilen Angreifer schädliche Nutzdaten transitiv über vertrauenswürdige Erweiterungsökosysteme.

Frühere Kampagnen desselben Angreifers kompromittierten über 151 GitHub-Repositories, indem sie unsichtbare Unicode-Zeichen zur Verschleierung des Schadcodes verwendeten. Trotz unterschiedlicher Verschleierungs- und Verbreitungsstrategien basierten alle Kampagnen auf derselben Solana-basierten Infrastruktur, was ein einheitliches operatives Framework bestätigt.

Schädliche IDE-Erweiterungen: Angriffe auf Entwicklerumgebungen

Die Kampagne hat sich auch in Entwicklungswerkzeuge eingeschlichen, und zwar über eine bösartige Erweiterung namens reditorsupporter.r-vscode-2.8.8-universal, die es auf die Windsurf IDE abgesehen hat. Getarnt als Plugin zur Unterstützung der R-Sprache, installiert sie einen Node.js-basierten Informationsdiebstahl.

Nach der Installation ruft die Erweiterung verschlüsselte Nutzdaten aus Blockchain-Transaktionen ab, führt sie im Arbeitsspeicher aus und stellt kompilierte Komponenten bereit, um sensible Daten aus Chromium-basierten Browsern zu extrahieren. Die Persistenz wird durch geplante Aufgaben und Änderungen an der Windows-Registrierung gewährleistet, wodurch die Ausführung beim Systemstart sichergestellt wird.

Die Malware zielt gezielt auf Entwicklerumgebungen ab, während russische Systeme ausgenommen sind, was einem Verhalten entspricht, das auch bei anderen GlassWorm-Varianten beobachtet wurde.

Indikatoren für Ausmaß und Wirkung

Sicherheitsanalysen zeigen, dass die Kampagne einen erheblichen Teil des Open-Source-Ökosystems kompromittiert hat und mehr als 433 Projekte auf verschiedenen Plattformen betrifft. Dazu gehören GitHub-Repositories (Python und JavaScript), VS Code-Erweiterungen und npm-Bibliotheken.

Alle Infektionswege laufen letztendlich auf den Einsatz eines JavaScript-basierten Informationsdiebs hinaus, was auf ein einheitliches Endziel der Abgriff auf Zugangsdaten und Datenexfiltration hindeutet.

• Mehr als 433 bestätigte, kompromittierte Projekte und Pakete
• Mehrere Bereitstellungswege, darunter GitHub, npm und IDE-Erweiterungen
• Konsequente Nutzung der Solana-Blockchain-Infrastruktur für die Nutzlastübermittlung
• Wiederholter Ausschluss russischer Systeme in allen Varianten

Strategische Bewertung: Eine neue Ära der Lieferkettenangriffe

Die ForceMemo-Kampagne stellt eine signifikante Eskalation der Bedrohungen für die Software-Lieferkette dar. Ihre Kombination aus unauffälliger Manipulation der Git-Historie, Blockchain-basierter C2-Infrastruktur und plattformübergreifenden Infektionsvektoren zeugt von einem hohen Maß an operativer Reife.

Die Wiederverwendung von Infrastruktur in Verbindung mit sich weiterentwickelnden Bereitstellungsmechanismen deutet auf einen anpassungsfähigen Angreifer hin, der Angriffe ausweiten und gleichzeitig Persistenz und Verschleierung gewährleisten kann. Dieser Wandel von isolierten Kompromittierungen hin zu koordinierten, mehrere Ökosysteme umfassenden Angriffen unterstreicht das wachsende Risiko für moderne Entwicklungsumgebungen und Open-Source-Communities.