GlassWorm: el Zig‑dropper que convierte extensiones de VS Code en un ataque a la cadena de suministro

CyberSecureFox

Una nueva fase de la campaña GlassWorm está explotando la confianza de los desarrolladores en las extensiones de Visual Studio Code y su ecosistema. Investigadores de ciberseguridad han descubierto un Zig‑dropper oculto en un complemento falso que consigue comprometer no solo VS Code, sino prácticamente cualquier IDE compatible con extensiones VSIX presente en la estación de trabajo.

Extensión falsa de WakaTime: punto de entrada a la infección en VS Code

El ataque se ha observado en el repositorio Open VSX mediante una extensión llamada «specstudio.code-wakatime-activity-tracker», diseñada para hacerse pasar por el legítimo WakaTime, un popular servicio de seguimiento de tiempo usado por desarrolladores. Aunque el complemento fraudulento ya ha sido retirado del repositorio, los usuarios que lo instalaron deben asumir un riesgo real de compromiso de su entorno de desarrollo.

La extensión maliciosa replica casi por completo la funcionalidad del WakaTime original, lo que dificulta que el usuario detecte anomalías. La carga dañina se esconde en la función activate(), responsable de inicializar el comportamiento del complemento cuando se carga en el IDE.

Zig‑dropper: binarios nativos que eluden la sandbox de JavaScript

Al instalarse, la extensión despliega en el sistema un binario nativo: «win.node» en Windows o «mac.node» (binario Mach‑O universal) en macOS. Se trata de extensiones nativas de Node.js escritas y compiladas en Zig, que se enganchan directamente al runtime de Node. Este enfoque permite evadir la sandbox de JavaScript y obtener acceso de bajo nivel al sistema operativo, con capacidad para leer archivos, ejecutar procesos y modificar la configuración local.

A diferencia de iteraciones anteriores de GlassWorm, en las que el binario nativo actuaba como carga principal, en esta variante el ejecutable funciona como un dropper “proxy” sigiloso. Su misión es desplegar de forma silenciosa otros componentes conocidos de la campaña y propagar el malware a todas las IDE compatibles detectadas en la máquina comprometida.

Propagación masiva: IDE y editores compatibles con VSIX bajo riesgo

Una vez activo, el Zig‑dropper escanea el sistema en busca de entornos de desarrollo que soporten el formato de extensión de VS Code. No solo quedan expuestos Visual Studio Code y VS Code Insiders, sino también forks y derivados como:

  • VSCodium
  • Positron
  • Cursor
  • Windsurf
  • y otros editores con soporte para extensiones VSIX y asistentes de IA integrados

Esta técnica convierte una única instalación de un complemento malicioso en una puerta de entrada para el compromiso de toda la ecosfera de desarrollo en esa estación de trabajo, algo especialmente preocupante en equipos que trabajan con múltiples IDE.

Cadena de infección: de GitHub al robo de datos y al navegador

Descarga encubierta de una extensión VSIX maliciosa desde GitHub

El Zig‑dropper descarga un segundo complemento de VS Code (archivo .VSIX) alojado en un repositorio de GitHub controlado por los atacantes. Este paquete se identifica como «floktokbok.autoimport» y se hace pasar por el legítimo «steoates.autoimport», uno de los módulos de autoimportación más instalados en el marketplace oficial de Visual Studio. El uso de nombres y funcionalidades similares reduce la probabilidad de que un desarrollador o una solución de seguridad detecte la suplantación.

Instalación silenciosa en todas las IDE y capacidades avanzadas de GlassWorm

Una vez descargado, el archivo .VSIX se copia en un directorio temporal y se instala silenciosamente en todas las IDE compatibles detectadas, utilizando sus instaladores de línea de comandos. Este segundo complemento actúa como doppelgänger malicioso y ejecuta funciones de segunda fase críticas:

  • Geo‑filtrado: el código malicioso está configurado para no ejecutarse en sistemas con configuración regional o geolocalización rusa, un patrón frecuente en campañas con motivaciones específicas o restricciones internas.
  • Obtención de C2 mediante la blockchain de Solana: en lugar de usar dominios clásicos, el malware recurre a infraestructura descentralizada en Solana para descubrir la dirección del servidor de comando y control (C2), lo que complica el bloqueo y el rastreo.
  • Exfiltración de información sensible: recopilación y envío de datos confidenciales, potencialmente incluyendo código fuente, configuración de proyectos, historiales de comandos y metadatos de repositorios.
  • Instalación de un RAT (Remote Access Trojan): despliegue de un troyano de acceso remoto para mantener control persistente sobre la máquina comprometida.
  • Despliegue de una extensión maliciosa de Google Chrome: etapa final orientada al robo de credenciales, cookies y datos de sesión del navegador, con impacto directo en cuentas corporativas y servicios en la nube.

Impacto en desarrolladores y en la cadena de suministro de software

La combinación de suplantación de extensiones populares, uso de binarios nativos en Zig y distribución a través del ecosistema VS Code convierte a GlassWorm en un caso representativo de ataque a la cadena de suministro de software. El riesgo va más allá del equipo del desarrollador: se ven amenazados secretos de proyectos como tokens de repositorios Git, claves de API, credenciales de CI/CD y accesos a nubes públicas.

Diversos informes de la industria sobre seguridad en la cadena de suministro (incluyendo análisis de ENISA, Sonatype y proveedores de seguridad comerciales) coinciden en un crecimiento sostenido, de dos a tres dígitos anuales, de incidentes vinculados a dependencias y complementos comprometidos. En un contexto en el que VS Code y sus derivados concentran una parte muy significativa del mercado de IDE, campañas como GlassWorm tienen un potencial de escalado especialmente alto, tanto en empresas como en proyectos open source.

Los desarrolladores que hayan instalado «specstudio.code-wakatime-activity-tracker» o «floktokbok.autoimport» deben actuar como si su entorno estuviera comprometido: eliminar los complementos sospechosos en todas las IDE afectadas, ejecutar análisis con herramientas de seguridad actualizadas para detectar RAT u otros componentes maliciosos, rotar contraseñas y secretos (tokens, claves API, SSH, credenciales de nube) y regenerar accesos en plataformas como GitHub, GitLab y servicios CI/CD. También resulta recomendable revisar y reinstalar extensiones de Chrome, prestando especial atención a módulos desconocidos o instalados sin una acción explícita.

Para reducir el riesgo de incidentes similares, es fundamental adoptar una política estricta de extensiones de confianza: priorizar marketplaces oficiales, verificar el editor, el número de instalaciones y las reseñas, y auditar periódicamente los complementos instalados. Integrar prácticas de Secure Software Development Lifecycle (SSDLC), gestión segura de secretos, principio de mínimo privilegio y monitorización de anomalías en estaciones de desarrollo no solo protege al programador individual, sino que refuerza la seguridad de toda la cadena de suministro de software. Invertir en la seguridad del entorno de desarrollo es, hoy, una de las defensas más efectivas frente a campañas como GlassWorm.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.