GlassWorm ataca OpenVSX: 73 extensiones dormidas que esconden malware y roban tus secretos

Una nueva ola de la campaña conocida como GlassWorm ha vuelto a golpear el ecosistema de extensiones de editor al aparecer 73 paquetes “durmientes” en OpenVSX, de los cuales seis ya han sido activados y entregan carga maliciosa, según la investigación publicada por Socket. La técnica empleada es preocupante por su simplicidad y eficacia: las extensiones se suben inicialmente como artefactos inocuos y, tras una actualización posterior, cambian su comportamiento para descargar e instalar código adicional o para cargar módulos compilados (.node) que contienen la lógica maliciosa.

Lo que hace especialmente insidiosa a esta campaña es la táctica de suplantación visual de listados legítimos: iconos, nombres y descripciones muy parecidos que engañan al desarrollador que confía en la apariencia en lugar de verificar el editor o el identificador único. En muchos casos el primer paquete actúa como un “loader” ligero que, en tiempo de ejecución, descarga paquetes VSIX desde repositorios en GitHub, ejecuta comandos CLI para instalarlos, o ejecuta código JavaScript fuertemente ofuscado que descifra URLs de respaldo y payloads.

El impacto potencial no es solo la ejecución remota de código en la máquina de un desarrollador: se trata de una puerta de entrada a secretos sensibles. Campañas previas de GlassWorm han buscado claves de carteras de criptomoneda, credenciales, tokens de acceso, claves SSH y datos del entorno de desarrollo. Si una sola estación de trabajo comprometida puede exfiltrar credenciales de CI/CD o tokens que conceden acceso a repositorios y servicios en la nube, el alcance puede escalar rápidamente a compromisos de infraestructura y cadenas de suministro.

Si crees haber instalado alguna de las extensiones implicadas, lo primero es asumir una posible exposición y actuar con rapidez: desinstala las extensiones sospechosas, comprueba procesos y conexiones de red inusuales, aísla la máquina afectada y, sobre todo, procede a rotar todas las credenciales y tokens que podrían haber estado accesibles desde ese equipo (tokens de repositorios, claves SSH, credenciales de servicios en la nube, llaves de API y monederos). Socket ha publicado el listado completo de extensiones identificadas y es el punto de partida para identificar instalaciones afectadas: Socket — 73 Open VSX sleeper extensions.

Más allá de la respuesta inmediata, hay medidas prácticas para mitigar este tipo de riesgo en el futuro: aplicar controles de egress (filtrado de salidas) para bloquear descargas automáticas desde URLs no confiables, evitar instalar extensiones desde repositorios no verificados en entornos de producción o CI, y usar entornos aislados (máquinas virtuales o contenedores efímeros) para probar nuevas extensiones antes de incorporarlas al flujo de trabajo. También es aconsejable que las organizaciones implementen políticas de gestión de secretos y rotación automática, y que vigilen la suscripción y permisos de las cuentas que publican extensiones.

Para operadores y mantenedores de ecosistemas como OpenVSX y marketplaces de extensiones, el caso vuelve a subrayar la necesidad de mecanismos más estrictos de verificación de publicadores y detección de clones: firmado de paquetes, validación del publisher ID y detección de similitud visual deberían ser requisitos mínimos, junto con análisis automatizado que detecte comportamientos “durmientes” o patrones de descarga en tiempo de ejecución. Puedes consultar la plataforma OpenVSX para comprobar detalles y políticas del repositorio: OpenVSX.

Desde la perspectiva de cumplimiento y riesgo, las campañas como GlassWorm exigen que los equipos de seguridad integren la revisión de la cadena de suministro de software en los procesos de despliegue: auditorías de dependencias, escaneo de artefactos y creación de SBOMs (listas de componentes) permiten detectar cambios no autorizados y reducir la ventana de exposición. Para orientaciones generales sobre gestión del riesgo en cadenas de suministro, CISA ofrece material útil que puede ayudar a priorizar controles: CISA — Supply Chain Risk Management.

Si detectas evidencia de compromiso, documenta y preserva logs y artefactos antes de limpiar el equipo, notifica a tu equipo de seguridad y a los responsables del marketplace (OpenVSX y, si procede, el equipo de Socket o plataformas equivalentes), y prepárate para una reconstrucción segura del entorno (reinstalación limpia y restauración desde backups verificados). La contención rápida y la rotación de secretos son las acciones que más reducen daño a corto plazo.

GlassWorm es un ejemplo de cómo los atacantes están refinando tácticas de suministro: en lugar de introducir malware directamente, prefieren entrar por la puerta principal con artefactos benignos y activar la carga maliciosa después. Para los desarrolladores y responsables de seguridad esto obliga a cambiar de una mentalidad de confianza por defecto a una de verificación continua — comprobar el publisher ID, monitorizar actualizaciones de extensiones, limitar permisos y automatizar la rotación de secretos son pasos concretos que reducen el riesgo de convertirse en una víctima de esta u otras campañas similares.