GlassWorm la campaña multietapa que roba credenciales vacía billeteras y toma control con una extensión de Chrome disfrazada de Google Docs Offline

Investigadores en seguridad han detectado una nueva y más elaborada iteración de la campaña conocida como GlassWorm, que combina técnicas de cadena de suministro maliciosa con un ataque multi-etapa diseñado para robar credenciales, vaciar billeteras de criptomonedas y mantener acceso remoto persistente a los equipos comprometidos. En esta ocasión, los atacantes han ido un paso más allá: además de distribuir malware a través de paquetes contaminados en repositorios de desarrolladores, terminan forzando la instalación de una extensión de Google Chrome que se hace pasar por la versión offline de Google Docs y que, en realidad, exfiltra datos sensibles.

El primer punto de entrada sigue siendo el ecosistema de código abierto: paquetes maliciosos publicados en npm, PyPI, GitHub y el marketplace Open VSX, además de actualizaciones comprometidas en proyectos legítimos cuya cuenta de mantenedor fue usurpada. Desde ahí, la campaña descarga componentes específicos según el sistema operativo de la víctima, consultando fuentes ocultas que actúan como “dead drops”. Los investigadores de Aikido describen cómo los operadores usan transacciones en la blockchain de Solana para ocultar la dirección del servidor de comando y control (C2), un método que complica la detección y atribución (ver documentación de Solana) y que ya ha sido documentado en el informe técnico publicado por Aikido aquí.

La cadena de ataque se descompone en varias fases. La segunda etapa instala un marco de robo de información: busca credenciales, intenta extraer billeteras de criptomonedas y recopila perfiles del sistema. Toda la información recolectada se empaqueta y se envía a un servidor remoto. A partir de ese momento, el intruso puede descargar dos módulos adicionales: un binario .NET orientado a eludir la seguridad de hardware wallets y un RAT (Remote Access Trojan) basado en JavaScript que se comunica por WebSocket para capturar datos de navegadores y ejecutar código arbitrario.

El componente .NET monitoriza eventos de hardware mediante la infraestructura de Windows Management Instrumentation (WMI) para detectar cuando se conecta un dispositivo USB. Si el dispositivo parece ser un Ledger o un Trezor, se muestra una ventana de phishing que emula la interfaz del fabricante e insta al usuario a introducir las 24 palabras de la frase de recuperación. Además, el malware puede terminar procesos legítimos del gestor de la billetera (por ejemplo, Ledger Live) y reexhibir la ventana fraudulenta si el usuario intenta cerrarla. El objetivo final es capturar la frase de recuperación y enviarla a una dirección controlada por los atacantes. Microsoft mantiene documentación sobre WMI que ayuda a entender cómo se aprovechan estas capacidades aquí, mientras que los fabricantes de hardware wallet advierten permanentemente contra introducir la seed en el ordenador o aplicaciones no verificadas, como explica Ledger y Trezor.

El RAT JavaScript complementa el escenario con un abanico de capacidades que incluyen la descarga de un módulo HVNC para control remoto oculto, el establecimiento de un proxy SOCKS mediante WebRTC, y la extracción masiva de datos de navegadores: cookies, historial, marcadores, almacenamiento local y la estructura DOM de la pestaña activa. Para asegurarse el acceso a largo plazo, el malware fuerza la instalación de una extensión de Chrome llamada “Google Docs Offline”. Esta extensión actúa como un caballo de Troya: comunica con el C2 y puede enviar cookies y tokens de sesión, capturar pulsaciones de teclas, tomar capturas de pantalla y exfiltrar datos del portapapeles.

La extensión también puede aplicar reglas de vigilancia selectiva: trae desde el servidor listas de sitios a monitorizar y, en los casos observados, venía preconfigurada para vigilar servicios de criptomonedas como Bybit, buscando cookies específicas (por ejemplo, secure-token o deviceid). Si detecta una sesión válida, dispara un webhook hacia el servidor atacante con las cookies y metadatos de la página. Además, el C2 puede enviar reglas de redirección para forzar que la pestaña activa apunte a páginas controladas por el atacante, facilitando ataques de sesión y phishing en tiempo real. Para comprender mejor qué puede exponer una extensión, los desarrolladores pueden revisar la documentación oficial de extensiones de Chrome aquí.

En cuanto a los mecanismos de obtención del servidor de control, los autores usan varias estrategias: una tabla hash distribuida (DHT) como primera opción y, si falla, una resolución mediante memos en la blockchain de Solana. En otros casos se han aprovechado URLs públicas de eventos de Google Calendar como “dead drops” para recuperar la dirección del payload. El uso de estas capas de sigilo —DHT, blockchains y recursos públicos— añade complejidad a la respuesta y al bloqueo del tráfico malicioso; para entender la génesis y funcionamiento de DHT puede consultarse una explicación técnica aquí.

Otra novedad es el movimiento de los actores hacia el ecosistema de Model Context Protocol (MCP), donde empezaron a publicar paquetes npm que suplantan servicios reputados del ámbito de IA para distribuir código infectado. Investigadores de Koi han señalado que, en un contexto de desarrollo cada vez más asistido por IA y con alta confianza depositada en servidores MCP, este vector es preocupante y probablemente se reproducirá.

Para facilitar la detección local, la empresa polaca AFINE ha liberado una herramienta de código abierto llamada glassworm-hunter que escanea archivos locales en busca de artefactos ligados a la campaña sin realizar peticiones de red durante el análisis. La herramienta y su base de indicadores de compromiso están disponibles en el repositorio oficial de GitHub aquí, y AFINE explica su metodología en este artículo técnico aquí. El informe de Aikido sobre la extensión de Chrome y el RAT aporta más detalles técnicos y puede consultarse en su blog aquí.

Si eres desarrollador o responsable de seguridad, las lecciones son claras: no confíes ciegamente en un paquete por su número de descargas; verifica el historial del publicador, activa la autenticación fuerte en las cuentas de mantenedor, firma y bloquea dependencias críticas, y realiza revisiones de integridad antes de desplegar. Además, aislar entornos de desarrollo y mantener controles de detección y respuesta puede limitar el impacto de este tipo de infraestructuras ofensivas. Para un enfoque institucional sobre cadenas de suministro de software conviene considerar las guías de organismos oficiales como CISA y NSA sobre seguridad en la cadena de suministro.

Finalmente, si usas billeteras de hardware, recuerda que nunca debes introducir la frase de recuperación en un ordenador o en una ventana emergente, y que la única forma segura de recuperar acceso es siguiendo los procesos oficiales del fabricante. Las firmas legítimas y las actualizaciones oficiales siguen siendo la barrera más eficaz contra campañas que combinan ingeniería social y abuso técnico. Mantenerse informado, limitar privilegios y validar fuentes es hoy la defensa más sensata frente a amenazas como GlassWorm.