Die laufende GlassWorm-Kampagne markiert einen neuen Eskalationsschritt bei Angriffen auf Entwicklerumgebungen. Angreifer tarnen ein bösartiges Visual-Studio-Code-Plugin als legitimes Produktivitaetstool und setzen einen in Zig kompilierten Dropper ein, um nahezu jede kompatible IDE auf einem Entwicklerrechner unbemerkt zu infizieren.
GlassWorm zielt auf Entwickler: Manipuliertes WakaTime-Tracking fuer VS Code
Im Zentrum der aktuellen Welle steht eine gefälschte Erweiterung im Open‑VSX‑Katalog mit dem Namen „specstudio.code-wakatime-activity-tracker“. Sie imitiert den weit verbreiteten Dienst WakaTime, der Nutzungszeit und Aktivität in IDEs misst. Obwohl das schädliche Plugin inzwischen aus dem Repository entfernt wurde, bleiben bereits installierte Instanzen ein erhebliches Risiko.
Die Funktionalität des Fake‑Plugins deckt sich weitgehend mit dem Original, was eine schnelle Erkennung erschwert. Die schädliche Logik ist gezielt in der Funktion activate() versteckt, die beim Start des Plugins ausgeführt wird. Für den Entwickler wirkt das Verhalten normal, während im Hintergrund die Kompromittierung der Umgebung beginnt.
Technische Analyse: Zig-basierter Node-Dropper mit Vollzugriff auf das System
Bei der Installation platziert die Erweiterung ein natives Node.js‑Modul auf dem System: „win.node“ für Windows bzw. „mac.node“ (Universal‑Mach‑O‑Binary) für macOS. Diese Module sind in Zig geschrieben und als native Node-Erweiterungen kompiliert, die direkt in den Node‑Runtime eingebunden werden.
Der entscheidende Punkt: Native Module umgehen die JavaScript‑Sandbox und erhalten direkten Zugriff auf Betriebssystemfunktionen, Dateisystem, Prozesse und Netzwerk. GlassWorm hatte bereits früher kompilierten Code in Erweiterungen eingesetzt, doch nun agiert der Binary nicht mehr als alleiniger Payload, sondern als unauffälliger „Proxy‑Dropper“. Seine Hauptaufgabe ist es, die bekannten Komponenten der Kampagne nachzuladen und auf alle kompatiblen IDEs zu verteilen.
Ausbreitung auf mehrere IDEs und AI-Editoren
Nach dem Start scannt der Dropper das System nach Entwicklertools, die VS‑Code‑kompatible Erweiterungen (VSIX) unterstützen. Neben Microsoft Visual Studio Code und VS Code Insiders sind unter anderem folgende Umgebungen betroffen:
- VSCodium
- Positron
- Cursor
- Windsurf
- weitere IDEs und KI‑unterstützte Editoren mit VSIX‑Support
Damit verwandelt eine einzige Installation des gefälschten Plugins den Entwicklerrechner in einen Multiplikator fuer Malware innerhalb der gesamten Entwicklungsumgebung. Dieser Ansatz entspricht einem typischen Software‑Supply‑Chain‑Angriff, bei dem nicht nur einzelne Nutzer, sondern ganze Projekte und Organisationen kompromittiert werden können.
Mehrstufige Infektionskette: Von GitHub bis zur Browser-Extension
Nachladen eines manipulierten VSIX von GitHub
Der Zig‑Dropper lädt im nächsten Schritt ein weiteres VS‑Code‑Paket (.VSIX) aus einem von den Angreifern kontrollierten GitHub‑Repository. Das Paket trägt den Namen „floktokbok.autoimport“ und tarnt sich als populäre Erweiterung „steoates.autoimport“, die im offiziellen Visual Studio Marketplace Millionen von Installationen verzeichnet. Durch die Imitation von Name und Funktionsumfang sinkt die Chance, dass Nutzer oder Sicherheitslösungen die Anomalie erkennen.
Zweite Stufe: Geofilter, Solana-C2, RAT und Chrome-Malware
Die heruntergeladene .VSIX‑Datei wird zunächst in einen temporären Ordner geschrieben und anschliessend still über die CLI‑Installer in alle gefundenen IDEs installiert. Dieses zweite, ebenfalls bösartige Plugin übernimmt mehrere Aufgaben:
- Geografische Filterung: Der Payload wird nicht auf Systemen mit russischer Lokalisierung oder Geodaten ausgeführt.
- Command‑and‑Control über die Solana‑Blockchain: Die Adresse des Steuerungsservers (C2) wird mittels dezentraler Blockchain‑Infrastruktur bestimmt, was Blockierung und Abschaltung deutlich erschwert.
- Exfiltration sensibler Daten: Sammlung und Abfluss vertraulicher Informationen wie Zugangsdaten, Konfigurationsdateien oder Projektartefakte.
- Installation eines Remote-Access-Trojaners (RAT): Aufbau eines dauerhaften Fernzugriffs auf das System des Opfers.
- Deployment einer bösartigen Google‑Chrome‑Erweiterung: Fokus auf die Abgreifung von Credentials, Cookies und Browsing‑Daten.
Durch die Kombination aus IDE‑Kompromittierung, RAT und Browser‑Malware entsteht ein breiter Angriffsvektor, der sowohl Entwicklerkonten als auch persönliche und unternehmensbezogene Daten erfasst.
Auswirkungen auf Software-Supply-Chain und Unternehmen
Angriffe wie GlassWorm zeigen die Verwundbarkeit moderner Entwicklungsökosysteme. Entwickler‑IDEs sind in der Regel mit Repository‑Tokens, API‑Schlüsseln, CI/CD‑Zugängen und Cloud‑Credentials verknüpft. Gelangen Angreifer an diese Informationen, können sie Quellcode manipulieren, Build‑Pipelines kompromittieren oder interne Dienste missbrauchen.
Branchenberichte zur Software‑Supply‑Chain‑Security (unter anderem von Sonatype und GitHub) verzeichnen seit Jahren einen starken Anstieg bösartiger Artefakte in Ökosystemen wie npm, PyPI oder VS Code Marketplace. Bekannte Vorfälle – etwa manipulierte npm‑Pakete oder der SolarWinds‑Vorfall – verdeutlichen, dass solche Angriffe häufig erst spät erkannt werden und dann weite Teile einer Lieferkette betreffen.
Konkrete Massnahmen fuer betroffene und nicht betroffene Teams
Nutzer, die „specstudio.code-wakatime-activity-tracker“ oder „floktokbok.autoimport“ installiert haben, sollten vorsorglich von einer vollstaendigen Kompromittierung ihrer Entwicklungsumgebung ausgehen und umgehend handeln:
- Entfernung der genannten sowie weiterer unbekannter oder verdächtiger Erweiterungen aus allen IDEs auf dem System.
- Vollständiger Malware‑Scan mit aktuellen Sicherheitslösungen, insbesondere auf RATs und persistente Komponenten.
- Rotation aller Credentials und Secrets: Passwörter, API‑Schlüssel, SSH‑Schlüssel, Cloud‑Zugänge und CI/CD‑Tokens.
- Neuerstellung kompromittierter Zugriffstokens bei GitHub, GitLab, Azure DevOps und anderen Entwicklerplattformen.
- Überprüfung und Neuinstallation von Chrome‑Erweiterungen, mit besonderem Fokus auf unerwartet hinzugefügte Add‑ons.
Zur Prävention zukünftiger Vorfälle empfiehlt sich eine Policy fuer vertrauenswürdige Erweiterungen: ausschliessliche Nutzung offizieller Marktplätze, Prüfung des Herausgebers, der Installationszahlen und der Bewertungen sowie regelmässige Audits installierter Plugins. Ergänzend sollten Teams in Secure Software Development Life Cycle (SSDLC), Secret‑Scanning, Prinzip der minimalen Rechtevergabe und Monitoring von Anomalien investieren. Dadurch steigt nicht nur die Sicherheit einzelner Entwickler, sondern die Resilienz der gesamten Software‑Supply‑Chain.
