Am 30. Januar 2026 wurde in der Open‑VSX‑Registry ein exemplarischer Software-Supply-Chain-Angriff entdeckt: Vier VS‑Code-Erweiterungen des Entwicklers mit dem Alias oorzc erhielten ein Update, das unbemerkt den Malware‑Loader GlassWorm integrierte. Besonders kritisch: Einige dieser Plugins waren über zwei Jahre lang als legitime Tools etabliert, bevor sie in Träger von Schadcode umgewandelt wurden.
Nach Angaben der Sicherheitsforscher von Socket gelang es Angreifern, die Zugangsdaten des Entwicklerkontos zu kompromittieren und so reguläre Updates mit versteckter Malware zu veröffentlichen. Die betroffenen Versionen wurden von Open VSX zwar schnell entfernt, doch der Vorfall zeigt deutlich, wie verwundbar Erweiterungs-Marktplätze sind, sobald ein eigentlich vertrauenswürdiger Konto-Inhaber übernommen wird.
GlassWorm in VS‑Code-Erweiterungen: Technischer Ablauf des Angriffs
Verschleierter Loader und Entschlüsselung des Payloads zur Laufzeit
Die kompromittierten Open‑VSX-Erweiterungen enthielten einen GlassWorm-Loader, der zur Laufzeit einen eingebetteten Payload entschlüsselt und ausführt. Diese Technik erschwert klassische statische Analyse: Der bösartige Code ist im Quelltext stark verschleiert oder nur verschlüsselt vorhanden und wird erst während der Ausführung sichtbar. Sicherheitswerkzeuge, die primär auf Signaturen und statische Muster setzen, erkennen solche Schadlogik oft erst verspätet oder gar nicht.
EtherHiding: Tarnung der Command-and-Control-Infrastruktur
Für die Kommunikation mit seinen Command-and-Control(C2)-Servern nutzt GlassWorm die Technik EtherHiding. Dabei werden Hinweise auf die eigentlichen C2-Adressen in externen, schwer kontrollierbaren Quellen wie verteilten Diensten oder schwer zu zensierenden Plattformen hinterlegt. Der Malware-Loader ruft zunächst diese Zwischenstationen ab und rekonstruiert daraus dynamisch die aktuellen C2-Endpunkte. Das erhöht die Widerstandsfähigkeit der Kampagne: Selbst wenn einzelne Domains oder IP-Adressen blockiert werden, bleibt die Infrastruktur über alternative Pfade erreichbar.
Ziele des Angriffs: Entwickler-Credentials und Krypto-Wallets
Im Fokus von GlassWorm stehen Entwicklungsumgebungen, insbesondere unter macOS. Der entschlüsselte Payload ist darauf ausgelegt, sensible Daten aus dem Arbeitsumfeld von Entwicklern zu exfiltrieren. Im Mittelpunkt stehen zwei Datenkategorien:
1. Zugangsdaten und Tokens aus der Dev-Ökosphäre: GlassWorm durchsucht Konfigurationsdateien und Profile, etwa die npm-Konfiguration auf den Parameter _authToken, sowie Authentifizierungsartefakte für GitHub und andere Zugriffstokens. Mit solchen Credentials erhalten Angreifer potenziell Zugriff auf private Repositories, CI/CD-Pipelines und Secret-Stores und können so Build-Prozesse manipulieren oder weitere Backdoors einschleusen.
2. Daten von Kryptowährungs-Wallets: Parallel scannt GlassWorm das System nach Dateien und Artefakten, die auf Kryptowallets hindeuten. Ziel ist der Diebstahl von Informationen, die zur Übernahme von Wallets und zum Abfluss von Kryptowerten genutzt werden können – ein inzwischen häufiges Zusatzmotiv in modernen Malware-Kampagnen.
Gezielte Opferauswahl: Umgehung russischsprachiger Systeme
Bemerkenswert ist der eingebaute Profilierungsmechanismus der Malware. Vor Aktivierung ihrer Schadfunktionen prüft GlassWorm unter anderem die System-Lokalisierung. Erkennt der Code ein russisches Sprach- oder Ländersetup, werden die bösartigen Routinen nicht ausgeführt. Solche Geofencing- oder Sprachfilter sind aus anderen Kampagnen bekannt und dienen häufig dazu, bestimmte Jurisdiktionen zu meiden, um nicht die Aufmerksamkeit lokaler Strafverfolgungsbehörden zu erregen.
Software-Supply-Chain-Angriffe im Kontext: Von Typosquatting zu Account-Übernahmen
Frühere GlassWorm-Kampagnen setzten primär auf Typosquatting und Brandjacking, also auf gefälschte Pakete und Erweiterungen mit Namen, die populären Projekten täuschend ähnlich sind. Im aktuellen Open‑VSX-Vorfall wurde dagegen ein bereits etablierter, reputationsstarker Entwickler-Account missbraucht. Für Nutzer erscheint ein Update solcher Erweiterungen in der Regel vollkommen unverdächtig, was die Erfolgswahrscheinlichkeit des Angriffs deutlich erhöht.
Branchenberichte wie die ENISA-Studie zum Threat Landscape for Supply Chain Attacks und der jährliche State of the Software Supply Chain von Sonatype dokumentieren seit Jahren einen klaren Anstieg von Angriffen auf Software-Lieferketten. Neben Paket-Repositorien wie npm oder PyPI geraten zunehmend auch IDE-Marktplätze, Build-Server und CI/CD-Systeme in den Fokus. Der GlassWorm-Vorfall passt nahtlos in dieses Muster: Angreifer versuchen, so nah wie möglich an Quellcode und Build-Prozesse heranzukommen, um Malware über grundsätzlich vertrauenswürdige Kanäle zu verteilen.
Schutzmaßnahmen: Was Entwickler, Organisationen und Marktplätze jetzt tun sollten
Für Erweiterungs-Entwickler und Maintainer ergeben sich aus dem Open‑VSX-Incident klare Handlungsfelder:
- Verpflichtende Zwei-Faktor-Authentifizierung (2FA): Für alle Accounts, die Pakete oder Erweiterungen veröffentlichen, sollte 2FA Standard sein.
- Restriktiver Umgang mit Tokens: Zugriffstokens regelmäßig rotieren, zeitlich begrenzen und strikt nach dem Least-Privilege-Prinzip konfigurieren.
- Sichere Secret-Verwaltung: Tokens und Schlüssel nicht in Konfigurationsdateien oder frei zugänglichen Umgebungsvariablen speichern, sondern in dedizierten Secret-Managern.
- Release-Monitoring: Jede veröffentlichte Version aktiv prüfen und auf unerwartete Änderungen in Artefakten und Changelogs achten.
Entwicklungsteams und DevSecOps-Organisationen sollten ergänzend:
- einen Whitelist-Ansatz für VS‑Code-/Open‑VSX-Erweiterungen verfolgen und diese Liste regelmäßig überprüfen,
- SBOMs (Software Bill of Materials) einsetzen, um Abhängigkeiten transparent zu machen und auf Kompromittierungen zu überwachen,
- EDR- und Monitoring-Lösungen nutzen, die auffälliges Verhalten von IDEs und Plugins erkennen (z.B. ungewöhnliche Netzwerkverbindungen oder Zugriffe auf Wallet-Daten).
Marktplätze und Repositories wie Open VSX wiederum sind gefordert, automatisierte und manuelle Reviews zu verstärken: Kombination aus statischer und dynamischer Analyse, verhaltensbasierte Erkennung verdächtiger Updates und robuste Mechanismen zur Absicherung und Verifikation von Entwicklerkonten sind zentrale Bausteine, um ähnliche Vorfälle frühzeitig zu erkennen.
Der GlassWorm-Angriff auf Open VSX macht deutlich, dass selbst langjährig vertrauenswürdige VS‑Code-Erweiterungen kurzfristig zu Einfallstoren für Supply-Chain-Angriffe werden können. Organisationen sollten daher installierte Plugins kritisch prüfen, ungenutzte Erweiterungen entfernen, Updates nur aus vertrauenswürdigen Quellen beziehen und den Schutz von Tokens, Secrets und Entwicklerkonten als geschäftskritische Sicherheitsanforderung behandeln. Wer Erweiterungen, Paketabhängigkeiten und Build-Umgebungen als integrale Teile der eigenen Software-Lieferkette versteht und entsprechend absichert, reduziert das Risiko, bei der nächsten Supply-Chain-Kampagne zum unbeabsichtigten Verteilkanal für Malware zu werden.
