Auf dem Open-VSX-Marketplace sind 77 bösartige „Evil Twin“-Extensions aufgetaucht, die sich wie echte Entwickler-Tools tarnten. Laut Sicherheitsforschern haben die Pakete nach der Installation Informationen über die betroffenen Systeme und Entwicklungsumgebungen abgegriffen und an einen externen Server übertragen. Open VSX hat die Erweiterungen inzwischen wieder entfernt.
Besonders kritisch: Die Angreifer nutzten Namen, Namensräume und Beschreibungen realer Extensions, veröffentlichten die Plagiate jedoch über nicht zugehörige Konten und vergaben sehr niedrige Versionsnummern. Damit erhöhten sie die Wahrscheinlichkeit, dass Nutzer die Pakete als harmlos einstufen.
Was sind Open VSX Evil Twin Extensions?
„Evil Twin“-Extensions sind täuschend ähnliche Nachahmungen legitimer Tools. Im konkreten Fall handelten die Pakete so, als würden sie Funktionen bereitstellen, die in ihrer Marketplace-Ansicht versprochen wurden. Tatsächlich führten sie aber schädliche Abläufe aus, sobald sie in der Entwicklungsumgebung aktiv waren.
Die betroffenen Erweiterungen wurden laut Manifold Security zwischen dem 26. Juli und dem 1. August 2026 hochgeladen. Am 3. August 2026 waren sie bereits wieder aus dem Open-VSX-Repository entfernt.
Welche Daten wurden abgegriffen?
Die Analyse zeigt zwei Muster: eine Reihe von sehr schlanken Paketen und ein zweiter Teil, der deutlich mehr Reconnaissance betrieb. Insgesamt wurden Informationen gesammelt, die für Angreifer besonders nützlich sind, um Entwicklungs-Workflows zu verstehen und gezielt weitere Angriffe zu planen.
In vielen Fällen reichte der Umfang bereits für einen groben „Fingerabdruck“ des Systems. In einzelnen Paketen wurde vor allem der Hostname versendet. Bei anderen kam zusätzlich Kontext hinzu, etwa der Name des Workspaces oder Versionen der verwendeten Editor-Komponenten.
Bei 19 identifizierten Erweiterungen war das Vorgehen detaillierter: Neben dem Hostnamen wurden unter anderem eine genaue Beschreibung des Systems, der im Editor geöffnete Repository-Kontext sowie das CI-Setup übermittelt, in dem der Editor möglicherweise lief.
Reconnaissance-Varianten: deutlich mehr Kontext
Die übrigen Erweiterungen dienten als Reconnaissance-Payload. Dafür sammelten sie unter anderem:
- lokalen Hostname und Benutzernamen des Betriebssystems
- Name und Version des Editors
- Host-Typ und Machine-ID
- Plattform und Architektur
- Locale und Zeitzone
- Ordnername und vollständigen Pfad des geöffneten Workspaces
Durch diese Kombination lässt sich viel über die Laufumgebung ableiten. Außerdem können Angreifer später ihre Einschätzung verfeinern, etwa um Nutzern in bestimmten Setups gezielter zu begegnen.
So wurden die bösartigen Pakete getarnt
Ein auffälliges Detail: Die Angreifer übernahmen Namen, Namensräume und auch die Beschreibungen echter Open-VSX-Erweiterungen. Gleichzeitig veröffentlichten sie die „Evil Twin“-Varianten über andere Konten und wählten niedrige Versionsnummern (zum Beispiel 0.0.1).
Technisch bestand der Kernwechsel laut Analyse darin, dass der Inhalt der gebündelten extension.js-Datei ausgetauscht wurde. Anstatt die beworbene Funktion zu erfüllen, implementierten die Pakete das Sammeln und Übertragen von Daten. Dabei wurde das Ganze als „anonymous usage metrics“ (anonyme Nutzungsmetriken) gerahmt.
Im Marketplace-Listing suggerierten die Pakete zwar konkrete Funktionen. In der Realität zeigten sie lediglich einen Statusleisten-Eintrag mit einer Meldung, dass sie aktiv seien. Direkt danach erfolgte jedoch der Schritt zur Datenexfiltration.
Wohin wurden die Daten gesendet?
In allen 77 identifizierten Erweiterungen wurde die Datenübertragung an die Domain mangorbit[.]com durchgeführt. Diese Domain war laut den Forschern am 15. Juli 2026 registriert worden – also bereits 11 Tage, bevor die ersten Pakete hochgeladen wurden.
Die Planungen wirkten damit nicht improvisiert, sondern eher vorbereitet: Die Infrastruktur stand frühzeitig bereit.
Zusätzliche Schritte in einer zweiten Angriffswelle
Die Erweiterungen aus einem zweiten Cluster gingen noch systematischer vor. Sie führten weitere Schritte aus, um Informationen aus der Entwicklungsumgebung zu extrahieren – insbesondere aus Versionierungs- und CI-bezogenen Daten.
- Sie inspizierten Dateien im .git-Verzeichnis des Workspaces, um Git-Remote-Hosts und Organisationen zu ermitteln sowie Details wie aktuelle Branches und den HEAD-Commit-SHA-Wert zu sammeln.
- Sie ermittelten bis zu 60 installierte Extension-IDs und zogen aus der Umgebung einen Proxy-Hostname.
- Sie identifizierten CI-Marker und lasen getrennt verschiedene Variablen aus CI-Umgebungen aus, darunter Werte wie GITHUB_REPOSITORY, CI_PROJECT_PATH, Azure-DevOps-Collection-URIs, Buildkite-Organisation-Slugs, CircleCI-Projektbenutzernamen sowie Codespace- und Gitpod-Kontext.
- Sie prüften das Telemetrie-Opt-out des Editors, überprüften den Status und übermittelten diesen ebenfalls.
Solche Informationen helfen Angreifern dabei, Entwicklungspipelines zu verstehen und später etwa gezielte Angriffsflächen zu wählen. Außerdem können sie nachvollziehen, ob eine Installation durch einen Menschen erfolgte oder durch eine Konfiguration im Repository angestoßen wurde.
Ausfallszenarien: DNS TXT als Fallback
Weiterhin deutet die Analyse darauf hin, dass die Malware für den Fall eines Ausfalls vorbereitet war. Es gab eine Kontingenz-Planung: Über einen DNS-TXT-Record sollte im Problemfall eine alternative Exfiltrations-URL abgefragt werden, etwa wenn die primäre Domain blockiert oder abgeschaltet wird.
Bei der Reconnaissance-Variante existierte außerdem ein Retry-Mechanismus. Dadurch wurde das Sammeln nicht zwingend nur einmal ausgelöst, sondern in zeitlichen Abständen erneut versucht.
Zeitverhalten und „Flag“, ob die Installation automatisch oder manuell war
Die Forscher beschrieben das Zeitverhalten so, dass Versuche in ungefähr 15 Minuten, 50 Minuten und nach rund 3,5 Stunden starten und danach alle sieben bis acht Stunden fortgesetzt werden. Abbrechen würde das Paket erst nach etwa sieben Tagen.
Auch eine offline Umgebung, Firewalls oder Proxys, die die ersten Anfragen verwerfen, wurden dabei berücksichtigt: In solchen Fällen wird laut Analyse über einen längeren Zeitraum weiter nachgesetzt.
Zusätzlich prüfte die Reconnaissance-Variante, ob in devcontainer.json oder .vscode/extensions.json im Workspace die eigene Extension-ID referenziert wird. Das Ergebnis wurde als einzelnes Flag gemeldet.
In klaren Worten: Dadurch lässt sich unterscheiden, ob ein Repository-Setup eine Installation veranlasst hat oder ob ein Nutzer die Extension bewusst ausgewählt hat. Genau diese Erkenntnis ist für Angreifer besonders relevant, wenn sie verstehen wollen, wie häufig ihre Pakete durch bestimmte Projekte „mitgeschleppt“ werden.
Welche konkreten Erweiterungen betroffen waren
Im Bericht sind die Namen von 19 der identifizierten „Evil Twin“-Extensions aufgelistet. Unter anderem werden genannt:
- amd.gaia-vscode
- artsy.artsy-studio-extension-pack
- configcat.configcat-feature-flags
- iotaledger.iota-move
- marketplace.visualstudio
- obyte.oscript-vscode-plugin
- openeuphoria.vscode-euphoria
- oss.sfmc-devtools-vscode
- rumbledb.jsoniq-vscode
- ssagov.uef-snippets
- taskfile.vscode-task
- doi.fileheadercomment
- mengsiCode.vscode-django-boilerplate
- move.move-analyzer
- uavcan.dsdl
- vs-publisher-988541.apexsql-power-tools
- casualjim.gotemplate
- jcamp.dotnet-test-provider-view
- superposition.supertoml-analyzer
Die restlichen 58 Extensions wurden als eher „leichtgewichtig“ beschrieben, während die übrigen eher als Reconnaissance-Payload eingeordnet wurden.
Ein größeres Bild: Lieferkettenangriffe und npm
Die Offenlegung zu Open VSX steht nicht allein: Der Bericht ordnet die Erkenntnisse in eine breitere Entwicklung von Software-Lieferkettenangriffen ein. Dabei wurden laut Microsoft zudem kompromittierte npm-Pakete beschrieben, die Tausende Artefakte betrafen und als „ChainDrop“ bezeichnet werden.
In dem Zusammenhang wird ein Informationsdiebstahl beschrieben, der über npm-Lifecycle-Hooks starten kann. Außerdem wird erwähnt, dass gestohlene GitHub-Credentials genutzt werden könnten, um Konfigurationen in Repositories zu platzieren und so dauerhafte Zugriffe oder zusätzliche Infektionswege zu ermöglichen.
Obwohl das Tradecraft in Teilen an früher beobachtete Muster erinnert, bleibt die Zuordnung der Aktivität zur Urheberschaft zum Zeitpunkt der Veröffentlichung offen.
Was Nutzer jetzt tun sollten
Auch wenn Open VSX die 77 Pakete bereits entfernt hat, sollten Entwickler und Teams ihre Umgebung prüfen. Besonders wichtig ist eine saubere Kontrolle von installierten Extensions und die Bewertung, ob eine der „Evil Twin“-Varianten eingesetzt wurde.
- Überprüfen Sie in Ihrem Editor, ob verdächtige Erweiterungen installiert sind, die sich als bekannte Tools ausgeben.
- Stellen Sie sicher, dass Ihre Entwicklungsumgebungen und CI-Systeme aktuell und nach Bedarf aktualisiert sind.
- Beobachten Sie Logs und Signale, die auf ungewöhnliche Datenübertragung oder CI-Auslesevorgänge hindeuten.
- Prüfen Sie zusätzlich die npm-Umgebungen Ihres Projekts, falls in Ihren Build-Pipelines externe Abhängigkeiten eingebunden sind.
Gerade bei Supply-Chain-Szenarien ist es sinnvoll, nicht nur Blocklisten zu nutzen, sondern auch die Berechtigungen und Fähigkeiten von Paketen und Dependencies genauer zu begrenzen.
Fazit
Die Entdeckung der Open-VSX-„Evil Twin“-Extensions zeigt, wie wirkungsvoll gutes Social Engineering mit technisch gezielter Manipulation zusammenspielen kann. Obwohl die Pakete wie legitime Developer-Tools aussahen, zielten sie auf das Sammeln und Exfiltrieren von System- und Entwicklungsdaten. Mit der Entfernung aus dem Marketplace am 3. August 2026 ist der unmittelbare Zugriff gestoppt – dennoch bleibt die wichtigste Lehre: Ein gründlicher Check der installierten Extensions und der gesamten Lieferkette in Build- und CI-Prozessen ist jetzt besonders wichtig.
Quelle: https://thehackernews.com/2026/08/open-vsx-removes-77-malicious-evil-twin.html
