Una campaña de extensiones maliciosas “evil twin” en el marketplace Open VSX ha terminado con la retirada de paquetes sospechosos. En total, se identificaron 77 extensiones que se hacían pasar por herramientas habituales del ecosistema de desarrollo, pero que en realidad recopilaban y transmitían información sobre los sistemas donde estaban instaladas.
Según reportes de investigadores, varios de estos paquetes se subieron entre el 26 de julio y el 1 de agosto de 2026, y Open VSX los eliminó del repositorio el 3 de agosto de 2026. El objetivo no era ofrecer la funcionalidad anunciada, sino exfiltrar datos y, en algunos casos, diferenciar entre instalaciones provocadas por la configuración del repositorio y las elegidas por una persona.
Qué se encontró en las extensiones “evil twin”
Las extensiones detectadas imitaban nombres, espacios de nombres y descripciones de herramientas reales publicadas en Open VSX. Sin embargo, estaban alojadas en cuentas no relacionadas y con números de versión muy bajos (por ejemplo, 0.0.1). Este patrón facilita que, si alguien confía en el nombre, acabe instalando un paquete que no corresponde a la herramienta legítima.
La diferencia clave estuvo en el contenido del archivo extension.js. En lugar de ejecutar lo esperado por la ficha del paquete, se reemplazaron capacidades para capturar y transmitir datos, camuflando el comportamiento bajo la etiqueta de “métricas de uso anónimas”.
Señales claras: “muestran que están activas” y luego envían datos
En todos los casos revisados, las extensiones no entregaban la utilidad prometida. En vez de eso, presentaban un elemento en la barra de estado con un mensaje de que estaban “activas” y, a continuación, ejecutaban el paso de exfiltración.
El flujo de datos terminaba enviándose al dominio mangorbit[.]com. De acuerdo con el análisis, ese dominio se registró el 15 de julio de 2026, 11 días antes de que empezaran a publicarse los primeros paquetes en el repositorio.
Dos variantes: recolección ligera y reconocimiento profundo
Los investigadores observaron que el conjunto no era uniforme. En particular, se identificaron dos grandes grupos: una variante “ligera” enfocada en datos básicos y una variante de “recon” orientada a levantar un perfil mucho más detallado del entorno de desarrollo.
Variante de exfiltración ligera (58 extensiones)
De las 77 extensiones identificadas, 58 fueron descritas como herramientas “ligeras” cuyo objetivo era extraer información mínima. En muchos casos, el paquete enviaba como dato principal el hostname del equipo. En ocasiones, también añadía el nombre de la carpeta del workspace o la versión del editor.
Variante de reconocimiento (19 extensiones)
El segundo grupo, formado por 19 extensiones, actuaba como carga de reconocimiento. Además de recopilar el hostname y el nombre de usuario del sistema operativo, obtenía múltiples detalles del entorno de desarrollo, incluyendo:
- Nombre y versión del editor
- Tipo de host e identificador de máquina
- Plataforma, arquitectura, configuración regional y zona horaria
- Ruta del workspace: nombre de la carpeta y ruta completa del sistema de archivos
En conjunto, la información levantaba un retrato del sistema y de la configuración de trabajo, lo que puede facilitar ataques posteriores o permitir que el atacante mida el impacto según el perfil de la víctima.
Lista de extensiones identificadas
Los nombres de las 19 extensiones asociadas al clúster de reconocimiento incluyeron (tal como se reportaron):
- 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
Reconocimiento con pasos extra y capacidad de “contingencia”
Más allá de los datos del equipo, las extensiones del grupo de reconocimiento aplicaban una secuencia adicional de pasos para profundizar en el contexto del proyecto.
Entre las acciones reportadas se incluyeron:
- Revisar archivos en el directorio .git del workspace para obtener hosts remotos, organizaciones, el dominio del correo configurado, la rama actual y el hash del commit HEAD.
- Enumerar hasta 60 identificadores de extensiones instaladas y extraer un hostname proxy desde el entorno.
- Detectar marcadores de CI y recopilar variables asociadas, como GITHUB_REPOSITORY, CI_PROJECT_PATH, la URI de Azure DevOps, el “slug” de Buildkite, el usuario del proyecto en CircleCI, el nombre de Codespace y el contexto de Gitpod.
- Consultar la configuración del propio editor sobre el opt-out de telemetría, verificar si está habilitada, y enviar esa información.
Además, el análisis indica que el código malicioso tenía planes de contingencia. En caso de que el dominio principal se bloqueara o dejara de estar disponible, el malware podía consultar un registro DNS TXT para recuperar una URL alternativa de exfiltración.
Reintentos y persistencia temporal
Otra característica relevante del componente de reconocimiento fue un mecanismo de reintentos que no se limitaba a una sola ejecución. Los investigadores describieron que los intentos ocurrían aproximadamente después de 15 minutos, 50 minutos y tres horas y media, y luego continuaban cada 7 u 8 horas. También se reanudaba tras reinicios del editor y el proceso cesaba solo después de siete días.
El objetivo, según el análisis, iba más allá de un experimento de una sola vez: incluso si el equipo estaba sin conexión, detrás de un firewall o un proxy que descartaba la primera solicitud, el código volvía a intentarlo durante una semana.
Distinguir instalaciones inducidas por el repositorio
El análisis también sugiere que las extensiones del grupo de reconocimiento podían distinguir por qué se instalaron. En concreto, verificaban si el workspace mencionaba el ID de la extensión en archivos como devcontainer.json o .vscode/extensions.json, y reportaban esa condición como una bandera única.
La interpretación que hacen los investigadores es directa: el atacante no solo quería saber qué entorno existía, sino entender cómo llegó a ese entorno la instalación. Esa señal puede ser útil si el propósito es evaluar si la extensión se introdujo por una configuración del repositorio o si una persona la eligió manualmente.
Un movimiento más amplio en la cadena de suministro
Este caso no se presentó como un incidente aislado. El reporte menciona que, de manera simultánea, 450 paquetes npm con miles de artefactos habrían sido comprometidos como parte de un ataque a la cadena de suministro para distribuir un robo de información. La campaña recibió el nombre ChainDrop.
En lo relacionado con npm, Microsoft describió un componente de malware con variantes y mecanismos de ejecución. Según el análisis mencionado, el código malicioso podía activarse durante un hook del ciclo de vida de npm (preinstall) antes de que completara la instalación.
Además, se informó que el malware podía utilizar credenciales robadas para introducir archivos de configuración en repositorios, lo que ayudaría a crear persistencia y a abrir una ruta adicional de contagio de desarrollador a desarrollador.
Por qué es importante ahora
El reporte enfatiza que este tipo de actividad obliga a mirar la protección de forma más amplia. Bloquear scripts de instalación o exigir autenticación multifactor en cuentas de mantenedores puede ayudar, pero no basta cuando el objetivo es que un paquete “cumpla” aparentemente con lo esperado y ejecute acciones de recolección de datos una vez instalado.
Los comentarios de expertos apuntan a la necesidad de controles más granulares: que el software pueda limitar qué permisos se conceden y qué acciones puede realizar un paquete, en especial cuando se trata de exfiltrar credenciales o datos sensibles.
Conclusión: Open VSX retira 77 extensiones y el problema sigue
Open VSX retira 77 extensiones maliciosas que suplantaban herramientas reales y actuaban como “evil twin” para enviar información del entorno de desarrollo. La combinación de nombres engañosos, versiones “baratas”, reemplazo de código en extension.js y recolección tanto ligera como profunda explica por qué esta campaña representó un riesgo relevante para desarrolladores y equipos.
Aunque los paquetes fueron eliminados del repositorio, el incidente deja una lección clara: en entornos de desarrollo, la cadena de suministro y el ecosistema de dependencias deben evaluarse con herramientas y políticas que reduzcan la superficie de ataque antes de que el código malicioso tenga oportunidad de operar.
Fuente: https://thehackernews.com/2026/08/open-vsx-removes-77-malicious-evil-twin.html
