Een groep onderzoekers heeft 77 schadelijke ‘evil twin’ extensies gevonden op het Open VSX-platform. Ze imiteerden populaire of bruikbare ontwikkeltools, maar waren bedoeld om informatie te verzamelen en door te sturen over machines en ontwikkelingomgevingen waarop ze waren geïnstalleerd.
Volgens Manifold Security zijn de betreffende extensies inmiddels van Open VSX verwijderd (status per 3 augustus 2026). De campagne liep grofweg van 26 juli tot 1 augustus 2026 en de extensies stuurden de buit naar één gedeeld exfiltratie-domein.
Wat is er precies gevonden bij Open VSX?
De onderzoekers beschrijven een cluster extensies dat zich presenteerde met namen, namespaces en beschrijvingen die passen bij bestaande Open VSX-tools. Daarbij werden de pakketten gepubliceerd via andere (losstaande) accounts en kregen ze lage versienummers, bijvoorbeeld 0.0.1. In veel gevallen leek het erop dat de functionaliteit in de listing niet overeenkomt met wat de code daadwerkelijk doet.
Wat opvalt: de kwaadwillige code verving de inhoud van het bestand extension.js met functionaliteit die data kan verzamelen en verzenden. De extensies frameerden die activiteit als ‘anonymous usage metrics’, terwijl het in werkelijkheid om reconnaissance en data-exfiltratie gaat.
Waaruit bestond de data-exfiltratie?
De 77 extensies zijn grofweg in twee categorieën onder te verdelen.
- 58 ‘lightweight’ tools: deze verzamelden vooral basisinformatie zoals de hostname. Soms ging het ook om aanvullende details zoals de naam van de workspace-folder of de versie van de editor.
- Reconnaissance payloads: deze gingen verder en leverden een veel rijkere set developer-gerelateerde gegevens. Dat omvatte onder meer lokaal gebruikersnaam, editor-naam en -versie, hostkenmerken en machine-id, platform en architectuur, locale en tijdzone, en informatie over de geopende workspace en de mapstructuur.
Beide varianten deelden dezelfde domeinbestemming voor de uitgaande berichten. In alle geïdentificeerde extensies werd data verzonden naar mangorbit[.]com. Dat domein was volgens de onderzoekers al geregistreerd op 15 juli 2026, dus vóórdat de eerste pakketten verschenen.
Hoe ‘evil twin’ extensies zich voordoen
Bij veel van de misbruikte extensies bestond de zichtbare “functie” vooral uit een statusbalk-item en een melding dat de extensie actief is. Vervolgens vond pas op de achtergrond de datastap plaats.
Een extra signaal voor defenders is dat de extensielisting wel lijkt te wijzen op een bepaalde functionaliteit, maar dat die in de praktijk niet wordt geleverd. In plaats daarvan draait de echte logica om het herkennen van de omgeving en het ophalen van configuratie- en contextdata.
Extra stappen in de recon-variant
De tweede cluster extensies bevatte extra technieken om ontwikkelingstrajecten beter te kunnen doorgronden. Daarbij kwamen onder meer de volgende acties terug:
- Het inspecteren van bestanden in de .git-directory van de workspace om Git remote-hosts en organisaties te achterhalen, inclusief domeinen die bij e-mailconfiguratie horen, de huidige branch en de HEAD-commit SHA.
- Het opsommen van tot 60 geïnstalleerde extension IDs en het bepalen van een proxy-hostnaam uit de omgeving.
- Het detecteren van CI-markers en vervolgens het uitlezen van meerdere CI-variabelen, waaronder o.a. waarden voor GITHUB_REPOSITORY, CI-projectpaden, Azure DevOps-collectie-URI’s, Buildkite-organisatie-slugs, CircleCI-projectgebruikers en Gitpod context.
- Het lezen of de editor-telemetry opt-out aan staat en het doorgeven van die status.
Daarmee richten de extensies zich niet alleen op het systeem, maar ook op de workflow waarin een developer werkt—waardoor ze inzicht krijgen in hoe en waar code wordt gebouwd, gedeeld en gepubliceerd.
Contingentie: fallback via DNS TXT
Verder is er een mechanisme beschreven voor veerkracht als het primaire exfiltratie-domein niet meer bereikbaar is. De malware kan namelijk een DNS TXT record opvragen om een alternatieve uitgaande URL op te halen wanneer de oorspronkelijke bestemming wordt geblokkeerd of wegvalt.
Ook is er een vorm van herhaalpogingen gezien. In de recon-variant werden pogingen om data te verzamelen en te verzenden uitgevoerd met intervallen van ongeveer 15 minuten, 50 minuten en 3,5 uur, waarna het proces later weer doorging. De onderzoekers noemen dat het pas na een periode van zeven dagen stopt, zelfs als de machine offline is, achter een firewall zit, of een proxy de eerste request weghaalt.
Waarom de timing en voorwaarden belangrijk zijn
Deze aanpak wijst op een doel dat verder gaat dan één keer “testen”. Door later opnieuw te proberen, vergroten de aanvallers de kans dat ze de omgeving volledig kunnen observeren wanneer de developer of de omgeving (bijvoorbeeld een editor restart) opnieuw actief wordt.
Daarnaast checkt de recon-variant of de workspace eigen configuratiebestanden een verwijzing bevatten naar de extensie-ID. Dat helpt om onderscheid te maken tussen extensies die door een repository-configuratie zijn binnengehaald en extensies die door een mens handmatig zijn gekozen. Met andere woorden: de code probeert te achterhalen waardoor iemand in de extensie terecht is gekomen.
De lijst met misbruikte extensienaamgeving
De onderzoekers hebben de namen van de 19 extensies uit het tweede cluster gedeeld. Voorbeelden zijn onder meer:
- 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
Ook als je niet direct één van deze namen herkent, blijft het bredere patroon belangrijk: dezelfde handelswijze—naam/omschrijving imiteren en vervolgens de code ombouwen—kan ook binnen andere (andere) ecosystemen terugkomen.
Welke bredere supply chain-aanval hangt hierbij?
De onderzoekers plaatsen deze Open VSX-campagne in het grotere geheel van supply chain aanvallen. In een eerder gerapporteerde context werd genoemd dat er ook npm-gerelateerde compromittering plaatsvond: 450 unieke npm-pakketten (2.244 artifacts) zouden zijn misbruikt om een informatie-stealer te leveren, en bovendien om een gestolen npm-token in te zetten voor het uitbrengen van gemanipuleerde varianten.
In dat rapport werd de campagne ChainDrop genoemd. Daarbij werd beschreven dat schadelijke releases konden bestaan uit varianten van een self-propagating worm-achtige aanpak, die ook gebruik kon maken van gestolen GitHub-credentials om configuratiebestanden te injecteren. Zo ontstaat een extra developer-to-developer infectiepad.
Voor wie zich hier verdiept in de npm- en ecosystem-kant, kan ook dit artikel relevant zijn: ChainDrop: 400+ NPM pakketten besmet.
Waarom 2FA en blokkeren van install scripts niet genoeg is
Uit de duiding blijkt een kernpunt: het beperken van risico’s via alleen “standaard” maatregelen is vaak onvoldoende. OX Security benadrukt dat er een securitylaag nodig is die verder kijkt dan het blokkeren van install scripts of het afdwingen van twee-factor authenticatie voor maintainers.
Concreet wordt het idee genoemd dat pakketten granulaire toestemming zouden moeten vereisen. Dus niet alleen controleren of een maintainer 2FA gebruikt, maar ook afdwingen welke acties een package wel of niet mag uitvoeren—bijvoorbeeld exfiltratie van cloud sleutels en GitHub-credentials.
Wat kun je nu doen als je met Open VSX of vergelijkbare tooling werkt?
Omdat dit soort aanvallen zich richt op de developeromgeving zelf, kun je het beste beginnen bij zichtbaarheid en controle.
- Check geïnstalleerde extensies op ontwikkelworkstations en in buildomgevingen. Let daarbij vooral op extensies waarvan de beschrijving niet klopt met het gedrag.
- Beperk uitrol: voorkom dat iedereen zomaar nieuwe of “verdachte” extensies kan installeren. Werk met een whitelist of gecontroleerde procedure.
- Monitor netwerkuitgaand verkeer van editorcomponenten. Als een editor extensies naar onverwachte domeinen laat communiceren, is dat een alarmsignaal.
- Let op CI-context: gezien de interesse in CI-variabelen en Git-informatie, is het zinvol om CI-secrets en tokens strikt af te schermen en te segmenteren.
Voor meer context over supply chain en aanvallen die juist door de ontwikkelketen heen proberen door te dringen, kan ook dit gerelateerde stuk helpen: Malafide npm-pakketten via supply chain: RAT-alert.
Conclusie: snel reageren op Open VSX evil twin signalen
De verwijdering van 77 Open VSX evil twin extensies laat zien hoe aantrekkelijk de ontwikkelomgeving is voor aanvallers: ze kunnen daar context verzamelen (hostname, workspace, editor- en CI-gegevens) en die vervolgens doorsturen.
De combinatie van misleidende namespaces, het ombouwen van de echte extension-code en het gebruik van een gedeeld exfiltratie-domein maakt dit tot een herkenbaar patroon. Door extensies te controleren, installbeleid aan te scherpen en uitgaande communicatie te bewaken, verklein je de kans dat dit soort campagnes in jouw omgeving voet aan de grond krijgt.
Bron: https://thehackernews.com/2026/08/open-vsx-removes-77-malicious-evil-twin.html
