- Campaña activa con extensiones de VS Code y OpenVSX que roban credenciales y se autorreplican.
- Infraestructura C2 resiliente: IP directa, blockchain Solana y Google Calendar.
- Lista de versiones afectadas, IOCs y acciones para contener y prevenir el ataque.
Lo que vuelve especialmente peliaguda esta familia es la suma de tres pilares técnicos: código invisible, C2 en blockchain y abuso de credenciales. Las muestras insertan caracteres Unicode no imprimibles para esconder su lógica, consultan transacciones de Solana y hasta recurren a Google Calendar como canal de respaldo. Todo ello, unido al robo automático de tokens de npm, GitHub y OpenVSX, facilita que el malware se propague por la cadena de suministro con muy poca fricción.
Qué es GlassWorm y por qué importa
GlassWorm es un gusano de la cadena de suministro enfocado a extensiones de VS Code documentado inicialmente por Koi Security en octubre. No hablamos de un troyano cualquiera: su rasgo definitorio es que se replica por sí mismo comprometiendo cuentas y proyectos de desarrolladores, lo que le permite alcanzar nuevas víctimas sin intervención humana.
De acuerdo con los reportes disponibles, al menos 35.800 instalaciones fueron comprometidas mediante versiones maliciosas subidas a OpenVSX el 17 de octubre de 2025, y dos días más tarde había todavía una decena de extensiones que seguían distribuyendo carga maliciosa. El 19 de octubre se detectó además una extensión infectada en el marketplace oficial de Microsoft VS Code que continuaba activa.
El arte de camuflaje de GlassWorm reside en su inyección de código con caracteres Unicode invisibles (incluidas zonas de uso privado), haciendo que líneas cruciales “desaparezcan” durante una revisión normal. Esta ofuscación, combinada con la entrega por actualizaciones automáticas de extensiones, elevó el impacto: muchos usuarios recibieron la versión nociva sin hacer nada.
Para sostener la campaña, los operadores han montado una infraestructura de C2 de triple capa: direcciones IP directas, mensajes anclados en la blockchain de Solana y eventos de Google Calendar como mecanismo de contingencia. Este enfoque refuerza la resiliencia: si caen unos servidores, la red infectada recibe nuevas instrucciones a través de un canal alternativo.
Cronología, evolución y alcance de la campaña
El 17 de octubre se publicaron en OpenVSX versiones contaminadas de distintas extensiones, totalizando alrededor de 35.800 descargas. El 19 de octubre, se comprobó la presencia de una extensión infectada en el marketplace de Microsoft, aún operativa en ese momento. Pocos días después, el 21 de octubre, OpenVSX comunicó la eliminación de los paquetes maliciosos y la rotación o revocación de tokens asociados, aunque el actor volvió a la carga.
Ya en noviembre, nuevos informes señalaron tres extensiones adicionales vinculadas a GlassWorm que seguían disponibles para descarga, evidenciando la persistencia de los atacantes. Koi Security observó que el operador publicó una transacción fresca en Solana para actualizar el endpoint de segunda fase, confirmando la fortaleza de un C2 basado en blockchain: por una fracción de céntimo, todas las máquinas comprometidas consultan el nuevo destino incluso si se retiran los servidores anteriores.
Más allá de la técnica, hubo un hallazgo inquietante: un endpoint expuesto accidentalmente en la propia infraestructura del atacante permitió observar una lista parcial de víctimas en EE. UU., Sudamérica, Europa y Asia, con la presencia incluso de una entidad gubernamental relevante en Oriente Medio. La telemetría incluye trazas de un keylogger del propio operador, y los indicios apuntan a un actor con perfil rusoparlante y uso de la plataforma RedExt como parte del andamiaje C2 para extensiones de navegador.
La campaña no se ha limitado a las extensiones: Aikido Security ha descrito movimientos en repositorios de GitHub donde, presuntamente, se usaron credenciales robadas para empujar commits maliciosos. Este salto a plataformas de control de versiones refuerza el carácter de “gusano” de la amenaza, capaz de multiplicarse explotando la confianza y el automatismo del ecosistema de desarrollo.
Productos y versiones afectadas
Listado de extensiones OpenVSX con versiones maliciosas detectadas en los informes iniciales y posteriores (tal cual identificadas):
- codejoy.codejoy-vscode-extension@1.8.3
- codejoy.codejoy-vscode-extension@1.8.4
- l-igh-t.vscode-theme-seti-folder@1.2.3
- kleinesfilmroellchen.serenity-dsl-syntaxhighlight@0.3.2
- JScearcy.rust-doc-viewer@4.2.1
- SIRILMP.dark-theme-sm@3.11.4
- CodeInKlingon.git-worktree-menu@1.0.9
- CodeInKlingon.git-worktree-menu@1.0.91
- ginfuru.better-nunjucks@0.3.2
- ellacrity.recoil@0.7.4
- grrrck.positron-plus-1-e@0.0.71
- jeronimoekerdt.color-picker-universal@2.8.91
- srcery-colors.srcery-colors@0.3.9
- sissel.shopify-liquid@4.0.1
- TretinV3.forts-api-extention@0.3.1
Extensión en Microsoft VS Code Marketplace
Además se reportó una extensión activa en el ecosistema de Microsoft: cline-ai-main.cline-ai-agent@3.1.3, incluida en la lista de hallazgos relativos a la campaña.
Técnicas, tácticas y procedimientos observados
El arsenal técnico de GlassWorm destaca por varios frentes. Para esconderse, la carga abusa de caracteres invisibles Unicode y zonas PUA, con lo que bloques de lógica maliciosa pasan inadvertidos ante revisiones manuales o comparativas superficiales. Para comunicarse, el malware consulta transacciones en Solana y, si falla, recupera instrucciones desde eventos de Google Calendar preparados por los atacantes; como tercera ruta, mantiene IPs y rutas HTTP directas.
Una vez en la máquina, el implante roba credenciales y tokens de npm, GitHub, Git y OpenVSX, configura un proxy SOCKS para convertir el equipo en infraestructura de terceros y puede instalar un servidor VNC oculto con capacidades de control remoto completo. Para el control del host y movimientos posteriores se ha asociado el componente “ZOMBI” RAT, con funciones de reconocimiento de red interna y persistencia.
La parte más preocupante es su comportamiento de gusano: con credenciales válidas en mano, el sistema comprometido modifica paquetes y extensiones, empuja nuevas versiones y enciende más puntos de infección, todo de forma casi autónoma. El resultado es un efecto bola de nieve alimentado por cadenas de confianza y por autoactualizaciones en los entornos de desarrollo.
Complementariamente, los informes señalan que la infraestructura de GlassWorm aprovecha un triple escalón C2 que se refuerza mutuamente: IP directa, blockchain y calendario. Si una capa cae, otra toma el relevo de manera transparente para los operadores y prácticamente invisible para las defensas tradicionales.
Estado de explotación y acciones recomendadas
La campaña sigue marcada como activa. Por ello, conviene aplicar medidas de contención y endurecimiento en estaciones de desarrollo y en la cadena de suministro de software. A partir de lo publicado por varias fuentes, estas son las recomendaciones clave:
- Realiza una auditoría completa de extensiones instaladas; busca conexiones de red anómalas, dependencias vulnerables y uso sospechoso de APIs.
- Escanea todas las extensiones nuevas antes de instalarlas, y limita su número para minimizar la superficie de ataque.
- Instala extensiones solo si son necesarias y elimina las que no uses; mantén un inventario actualizado.
- Evalúa reputación del editor, histórico de versiones y reseñas antes de darles luz verde.
- Piensa dos veces el uso de autoactualizaciones en entornos críticos; valora pasar a revisión manual.
- Estudia implementar una lista de permitidos centralizada para VS Code en tu organización.
- Rota credenciales (tokens de npm y GitHub) si sospechas exposición o si has usado extensiones potencialmente afectadas.
- Vigila señales de actividad no autorizada en monederos de criptomonedas y accesos de Git.
En paralelo, conviene reforzar detecciones en endpoints con reglas específicas para IOCs asociados a GlassWorm e implementar controles de salida que bloqueen comunicaciones hacia los dominios, IPs y rutas identificadas en la campaña.
Indicadores técnicos útiles (IOCs y TTPs)
A continuación se recogen los indicadores de compromiso y puntos de control más relevantes publicados hasta la fecha. Úsalos para buscar, bloquear y monitorizar:
Comando y Control (C2) y exfiltración
- IP C2 principal: 217.69.3.218
- Endpoint de exfiltración: 140.82.52.31:80/wall
- Billetera Solana empleada: 28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2
- Transacción asociada: 49CDiVWZpuSW1b2HpzweMgePNg15dckgmqrrmpihYXJMYRsZvumVtFsDim1keESPCrKcW2CzYjN3nSQDGG14KKFM
- Google Calendar (C2 de respaldo): calendar.app.google/M2ZCvM8ULL56PD1d6 — Organizador: uhjdclolkdn@gmail.com
URLs de payload
- http://217.69.3.218/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D
- http://217.69.3.218/get_arhive_npm/
- http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D
Mecanismos de persistencia observados (Windows)
- HKCU\Software\Microsoft\Windows\CurrentVersion\Run
- HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Recuerda validar estos IOCs en tu entorno y alimentar tus listas de bloqueo, SIEM y EDR, teniendo en cuenta falsos positivos y variaciones por ofuscación.
Análisis del impacto
Las máquinas infectadas quedan expuestas a un abanico de riesgos: desde el robo de credenciales de npm, GitHub y Git hasta el drenaje de fondos de 49 tipos de extensiones de monederos de criptomonedas. La instalación de un servidor VNC encubierto y la activación de un proxy SOCKS convierten el equipo en infraestructura controlada por terceros, con posibilidad de reconocimiento de la red corporativa.
En términos de negocio, el vector es especialmente delicado porque ataca directamente a los entornos de desarrollo. Un desarrollador comprometido puede empujar código contaminado, publicar paquetes envenenados o filtrar secretos, alimentando un ciclo de infección en cascada a lo largo de toda la cadena de suministro.
El precedente de “Shai Hulud” en npm, descubierto apenas un mes antes, marcó el inicio de una tendencia hacia gusanos de supply chain. GlassWorm confirma esa evolución, con automatismos orientados a extender su alcance sin depender de la interacción del usuario final.
Detección y respuesta: capacidades y cobertura
Firmas del sector han señalado que sus motores detectan las técnicas de ofuscación Unicode y el abuso de Google Calendar como C2 vistas en GlassWorm. En concreto, se ha publicado investigación sobre análisis de JavaScript con caracteres invisibles (capaz de atravesar hasta 12 capas de ofuscación) y campañas que usan enlaces cortos de Calendar como droppers dinámicos.
Si bien no todas las soluciones dan cobertura directa al registro de extensiones de OpenVSX, varias han verificado que detectarían la misma carga maliciosa si llegara al ecosistema npm. Además, hay monitorización activa para cortar reapariciones del gusano y variantes imitadoras.
Para los equipos internos, la receta pasa por combinar controles de inventario, listas de permitidos, revisión de cambios en extensiones menos mantenidas y rotación de credenciales cuando haya sospechas. En paralelo, resulta clave instrumentar los pipelines CI/CD con escaneos de supply chain, validación de integridad y políticas de firma de artefactos.
Herramientas prácticas para análisis, pruebas y forense
A la hora de investigar campañas como GlassWorm o de fortalecer tus procesos, un conjunto variado de utilidades puede marcar la diferencia. A continuación tienes una selección amplia de herramientas de testing ético, depuración, reversing y análisis que resultan útiles en escenarios de respuesta e investigación de amenazas:
- Burp Suite (interceptar y probar APIs web).
- OWASP ZAP (escáner open source de aplicaciones web).
- Wireshark (inspección profunda de tráfico).
- Fiddler (depuración HTTP/HTTPS y repetición de tráfico).
- Frida (instrumentación dinámica en tiempo de ejecución).
- Ghidra (suite gratuita de ingeniería inversa).
- IDA Pro (desensamblador avanzado).
- x64dbg (depurador interactivo para Windows).
- Radare2 / Cutter (toolkit de reversing con interfaz gráfica).
- Procmon (monitoreo de procesos, archivos y registro).
- Cheat Engine (inspección de memoria para depuración en entornos controlados).
- apktool (decompilar y reconstruir paquetes Android).
- JADX (decompilar APKs a Java legible).
- Mitmproxy (proxy interceptador programable).
- SharkFest / tcpreplay (reproducción de tráfico para pruebas).
- SteamCMD (gestión y pruebas de instancias de servidores Steam).
- OSQuery (visibilidad del host para integridad del sistema).
- Splunk / ELK Stack (ingesta de logs y correlación forense).
- Volatility (forense de memoria para triaje).
- GDB (depurador GNU para procesos nativos en Linux).
- AFL / LibFuzzer (fuzzing de protocolos y parsers).
- Binwalk (análisis de firmware y paquetes).
- Hopper (desensamblador para macOS y móviles).
- CFF Explorer (inspección y manipulación de binarios PE).
- John / Hashcat (auditoría de contraseñas y hashes).
- Maltego (mapeo de superficie de ataque y relaciones).
- Recon-ng (recon automatizado para dominios e infra).
- Shodan (descubrimiento de servicios expuestos).
- Nikto (escaneo de servidores web).
- Toolkit personalizado (scanners, crawlers y validadores a medida).
Nota importante: todas estas herramientas deben emplearse exclusivamente en pruebas autorizadas y entornos controlados, con consentimiento por escrito y salvaguardas de seguridad; varias firmas ofrecen servicios de pentest, red team y auditoría de pipelines de publicación de software, particularmente útiles para endurecer cadenas de suministro y revisar extensiones antes de su puesta en producción.
Privacidad y transparencia en sitios de referencia
Como apunte adicional, algunos de los portales que han cubierto esta campaña avisan de que usan cookies propias y de terceros con fines analíticos y publicitarios (generales y personalizados) basados en perfiles de navegación. Normalmente facilitan un panel para configurar o deshabilitar cookies y optimizar la web, así como para gestionar la valoración de servicios por parte de los usuarios.
Contexto: un panorama con múltiples frentes
El caso GlassWorm llega en medio de un flujo incesante de incidentes y vulnerabilidades. Entre otras noticias, se han señalado fallos en Microsoft Teams, la cooperación entre distintos grupos delictivos y una “falla global” vinculada al ecosistema React. Este ruido de fondo evidencia que las superficies de ataque crecen y que la vigilancia continua no es opcional para equipos de ingeniería y seguridad.
Fuentes y enlaces de interés
Consulta la investigación técnica inicial y las actualizaciones sobre GlassWorm en el blog de Koi Security: koi.ai/blog/glassworm. También resultan útiles los análisis publicados sobre ofuscación Unicode y el uso de Google Calendar como infraestructura C2 en campañas previas sobre npm, así como los avisos de Aikido Security sobre actividad en GitHub.
Queda patente que la combinación de extensiones de editor, repositorios y paquetes ofrece a los atacantes una autopista para el movimiento lateral entre proyectos. Si sumamos actualizaciones automáticas y credenciales con permisos amplios, la ventana de oportunidad para campañas de este tipo es demasiado generosa.
Vista en conjunto, la operación GlassWorm demuestra que la seguridad del desarrollo debe tratarse como un sistema: inventario y gobierno de extensiones, análisis de cadena de suministro, controles de salida y telemetría de endpoints, además de políticas claras de revisión y publicación. Solo así se puede cortar el circuito de autorreplicación que pretende explotar el adversario y limitar los daños cuando se produzca el siguiente intento.