Las campañas de **Glassworm** han estado activas desde octubre de 2025, atacando inicialmente a desarrolladores con extensiones maliciosas para **OpenVSX** y **Microsoft VS Code**. Estas extensiones estaban diseñadas para robar billeteras de criptomonedas y credenciales de desarrolladores. Los ataques se expandieron posteriormente a repositorios de **GitHub** y paquetes de **npm**, afectando a más de 400 artefactos de software en una campaña durante marzo. En un ataque reciente, los operadores de **Glassworm** plantaron docenas de extensiones inactivas en **OpenVSX** que activarían sus componentes maliciosos después de una actualización. ## Infraestructura de C2 Resiliente Una de las razones por las que **Glassworm** ha sido tan persistente es su infraestructura de C2. La botnet aprovechó canales de comunicación no tradicionales, lo que dificultó enormemente su desmantelamiento. "La combinación de blockchain, peer-to-peer y servicios web legítimos como capas de resolución fue diseñada para ser resiliente contra los derribos, un frente dinámico que protege los servidores C2 reales detrás de múltiples capas de indirección", señaló **CrowdStrike**. Los investigadores enfatizaron que los operadores de la botnet construyeron específicamente su infraestructura para ser resiliente. El derribo requirió un golpe simultáneo a los cuatro canales de C2: 1. Blockchain **Solana**: Las direcciones de los servidores C2 se codificaron en los campos de memo de las transacciones de la blockchain, creando un "buzón" inmutable y de acceso público. 2. Tabla de Hash Distribuida (DHT) de **BitTorrent**: El **GlasswormRAT** consultó la red peer-to-peer de **BitTorrent** para obtener datos de configuración almacenados contra claves públicas codificadas. 3. Servicio de calendario público: **Glassworm** utilizó los títulos de eventos de **Google Calendar** como ubicaciones de "buzón" para rutas C2 codificadas en Base64. 4. Conexiones directas a servidores: La infraestructura C2 tradicional alojada en proveedores de VPS comerciales sirvió como el mecanismo final de entrega de **payload**.  *Arquitectura de comando y control de Glassworm Fuente: CrowdStrike* Debido a esta arquitectura, la interrupción de un solo canal habría tenido un impacto mínimo, ya que las comunicaciones podrían simplemente cambiar a otro canal, permitiendo al actor de la amenaza mantener el control. ## Derribo Coordinado "Los cuatro canales tuvieron que ser interrumpidos simultáneamente en un esfuerzo coordinado. Como resultado, las máquinas infectadas ya no pueden recibir nuevas instrucciones o **payloads**", afirmó **CrowdStrike**. Tras la interrupción, todas las máquinas comprometidas en el ataque de **Glassworm** ahora están haciendo ping a la dirección IP 164.92.88[.]210, que es operada por **CrowdStrike**. Se aconseja a las organizaciones que busquen este indicador de red y tomen medidas de remediación inmediatas. Los investigadores también han publicado reglas YARA para ayudar a confirmar infecciones en hosts sospechosos. ## La Brecha de Validación: Las Pruebas de Penetración Automatizadas Responden Una Pregunta. Necesitas Seis. Las herramientas de pruebas de penetración automatizadas ofrecen un valor real, pero fueron diseñadas para responder una pregunta: ¿puede un atacante moverse por la red? No fueron diseñadas para probar si tus controles bloquean amenazas, si tus reglas de detección se activan o si tus configuraciones en la nube son seguras. Esta guía cubre las 6 superficies que realmente necesitas validar. [Descargar Ahora](https://hubs.li/Q048zztN0)