Un desarrollador infectado permitió a hackers infiltrarse en miles de empresas: el botnet Glassworm arrasó el código corporativo durante un año

CrowdStrike anunció la interrupción del funcionamiento de la botnet Glassworm, que atacaba a desarrolladores mediante extensiones para editores de código, paquetes npm y Python, así como repositorios de GitHub infectados. La operación se realizó junto con Google y Shadowserver Foundation: los especialistas atacaron simultáneamente los cuatro canales de mando y control a través de los cuales los operadores de Glassworm enviaban a las máquinas infectadas instrucciones y nuevos módulos maliciosos.

El principal peligro de Glassworm no residía solo en la escala de la botnet. La campaña mostró lo fácil que se ha vuelto convertir a los desarrolladores en un objetivo. Un equipo de trabajo infectado puede dar a los delincuentes acceso al código fuente, a plataformas en la nube, a los canales CI/CD, a credenciales y a registros de paquetes. A partir de ahí el problema deja de ser local: el código malicioso puede propagarse por la cadena de suministro de software y afectar a empresas que ni siquiera conocen el primer contagio.

Según CrowdStrike, los operadores de Glassworm al menos desde principios de 2025 han perseguido sistemáticamente a desarrolladores. Los atacantes publicaban extensiones troyanizadas para VSCode en el catálogo OpenVSX y las disfrazaban como herramientas habituales, como rastreadores de tiempo y formateadores de código. Esas extensiones afectaban no solo a VSCode, sino también a Cursor, Positron, Windsurf, VSCodium y otros editores compatibles con ese ecosistema.

La segunda línea de ataque se realizaba mediante paquetes npm y Python. El código malicioso se ejecutaba durante la instalación habitual de dependencias: a través de hooks postinstall y scripts de instalación. Para el desarrollador ese proceso podía parecer una actualización rutinaria de una librería, aunque ya se estuviera ejecutando código ajeno en la máquina.

La tercera vía fueron los repositorios de GitHub. CrowdStrike indica que los operadores de Glassworm envenenaron más de 300 repositorios utilizando credenciales de desarrolladores robadas en infecciones previas. Los atacantes, mediante force push, sobrescribían ramas por defecto y añadían código malicioso donde otros usuarios esperaban encontrar un proyecto normal.

La campaña funcionaba en Windows, macOS y Linux. El conjunto de capacidades incluía robo de información, recolección de credenciales y una herramienta completa de acceso remoto en Node.js, que CrowdStrike denomina GlasswormRAT. RAT en este contexto significa herramienta de acceso remoto: el programa otorga al operador control remoto sobre el sistema infectado.

La infraestructura de Glassworm estaba pensada para la resiliencia. Los operadores no se limitaron a un único servidor de mando, que podría desconectarse rápidamente a través del proveedor de alojamiento. En su lugar, la botnet utilizaba 4 canales distintos, cada uno de los cuales ayudaba a localizar servidores de control o a obtener la configuración.

El primer canal pasaba por la blockchain Solana. Las direcciones de los servidores C2, es decir, los servidores de mando, se registraban en el campo memo de las transacciones de la blockchain. Ese esquema funciona como un escondite público: los datos son visibles en la red y no desaparecen tras una reclamación al proveedor, porque ya están escritos en la cadena de bloques.

El segundo canal empleaba la tabla de hash distribuida de BitTorrent, DHT. GlasswormRAT consultaba la red peer-to-peer de BitTorrent y buscaba datos de configuración mediante claves públicas embebidas. Esa red no tiene un único punto de fallo, por lo que desconectarla de la forma habitual resulta mucho más difícil.

El tercer canal se ocultaba en un servicio web legítimo. Glassworm utilizó los encabezados de eventos de Google Calendar como lugar para transferir rutas a los C2, codificadas en Base64. Para los defensores ese tráfico resulta problemático: el calendario en sí no es un servicio malicioso, por lo que bloquear simplemente el dominio puede afectar al uso normal por parte de los usuarios.

El cuarto canal estaba más cerca del esquema clásico. La infraestructura maliciosa se conectaba a servidores C2 directos alojados en proveedores comerciales de VPS. A través de esos servidores los operadores podían entregar cargas maliciosas finales a las máquinas infectadas.

La combinación de blockchain, BitTorrent, Google Calendar y servidores convencionales daba a Glassworm redundancia. Si los defensores desconectaban solo un canal, los operadores podían cambiar las máquinas infectadas a otra vía y recuperar rápidamente el control. Por eso CrowdStrike, Google y Shadowserver Foundation interrumpieron sincronizadamente el funcionamiento de los cuatro canales. Tras ello las máquinas infectadas perdieron la capacidad de recibir nuevas órdenes y cargas útiles de los operadores.

CrowdStrike subraya que Glassworm evolucionó durante más de un año. Los operadores cambiaron lenguajes de programación, pasando de JavaScript a Rust y Zig, ampliaron los ataques a distintas ecosistemas y construyeron infraestructura de reserva para el caso de desconexiones. Esa persistencia resulta especialmente peligrosa en ataques contra desarrolladores: los tokens robados, los accesos a repositorios y los entornos de trabajo pueden conducir a la compromisión de proyectos usados por miles de otras organizaciones.

La empresa también considera que los delincuentes probablemente estaban vinculados a la seguridad de la cadena de suministro. Las pruebas son indirectas: el malware al ejecutarse comprobaba la configuración regional, el idioma y la zona horaria de la víctima, y luego finalizaba silenciosamente si el sistema estaba en un país de la CEI. Esa técnica suele emplearla grupos cibercriminales de la región para no atacar objetivos cercanos. En el código fuente también aparecieron comentarios en ruso. CrowdStrike aclara por separado que ningún indicio por sí solo demuestra el origen de los operadores: la comprobación de la configuración regional puede copiarse y los comentarios en el código pueden deberse a herramientas de IA. Pero el conjunto de evidencias, según la compañía, se mantuvo coherente durante más de un año de observación.

Tras la interrupción de la infraestructura CrowdStrike publicó un indicador de red para comprobar infecciones. Todas las máquinas infectadas por Glassworm ahora se conectan a una dirección IP segura gestionada por CrowdStrike: 164.92.88[.]210. La empresa aconseja a las organizaciones revisar los registros de red y la telemetría de las estaciones de trabajo. Cualquier coincidencia con esa dirección indica que el host requiere una verificación y limpieza inmediatas.

Indicador Glassworm:

164.92.88[.]210

Qué verificar:
- registros de red;
- telemetría de los dispositivos finales;
- conexiones de estaciones de trabajo de desarrolladores a la dirección indicada;
- equipos en los que se instalaron recientemente extensiones de OpenVSX, paquetes npm o paquetes Python de fuentes no verificadas.

Para confirmar una infección CrowdStrike también proporcionó dos reglas YARA. La primera regla busca cadenas características en el script GlasswormRAT. La segunda regla ayuda a detectar el instalador ofuscado de Glassworm para Python.

La historia de Glassworm muestra una debilidad en la protección actual de la cadena de suministro de software. Detectar el problema tras los hechos llega demasiado tarde: un paquete malicioso puede instalarse en segundos, y la defensa a menudo se activa después del robo de tokens o de la ejecución del script malicioso.

El problema se agrava por la propia estructura de los ecosistemas de desarrollo. npm, PyPI, OpenVSX y GitHub contienen millones de proyectos, extensiones y dependencias. Los mecanismos de verificación incorporados son limitados, y un atacante puede publicar rápidamente un paquete nuevo, incrustar código malicioso en el script de instalación y conseguir las primeras víctimas casi inmediatamente después de que la dependencia aparezca en el registro. Glassworm aprovechó precisamente esa velocidad y con frecuencia cambiaba de plataforma, manteniendo el acceso a las máquinas de desarrolladores.

Buscar solo archivos maliciosos no basta para mitigar esta amenaza. La defensa debe incluir control de dependencias, verificación de extensiones para editores, limitación de permisos de tokens, monitorización de entornos CI/CD y respuesta rápida a credenciales robadas. Pero también es necesario desmantelar la infraestructura ya establecida: si los operadores siguen controlando hosts infectados, pueden volver a enviar cargas maliciosas, cambiar herramientas y continuar el ataque por otro canal.

Glassworm se construyó alrededor de una idea simple: llegar al desarrollador y, a través de él, alcanzar el camino hacia código ajeno y usuarios ajenos. Los operadores usaron la confianza en las herramientas de desarrollo, las actualizaciones, los paquetes y los repositorios como mecanismo de entrega. Interrumpir los cuatro canales de mando y control no elimina el riesgo de estaciones de trabajo infectadas, pero ofrece a las empresas una ventana para comprobar, eliminar componentes maliciosos y cambiar los accesos robados.