Durante años, la conversación sobre ciberseguridad se centró en proteger empresas, servidores y usuarios finales.
Pero la semana pasada quedó claro que el nuevo objetivo de los atacantes ya no son solo las compañías… ahora también son las personas que construyen el software que las compañías utilizan.
Google, CrowdStrike y The Shadowserver Foundation confirmaron el desmantelamiento de “Glassworm”, una operación global que llevaba meses comprometiendo herramientas de desarrollo, repositorios open source y entornos utilizados por programadores alrededor del mundo.
La noticia no solo es relevante por el tamaño del ataque, sino por lo que representa: un cambio importante en la forma en la que operan las amenazas modernas.
¿Qué era Glassworm?
Glassworm era una botnet enfocada en ataques de supply chain, es decir, ataques dirigidos a la cadena de suministro de software.
En lugar de atacar directamente a empresas específicas, los operadores comprometían:
- Extensiones de VS Code
- Paquetes npm y Python
- Repositorios GitHub
- Cuentas de desarrolladores
- Herramientas utilizadas diariamente por programadores
El objetivo era distribuir malware de forma silenciosa utilizando software aparentemente legítimo.
Según CrowdStrike, más de 300 repositorios de GitHub fueron contaminados durante la operación.
El verdadero riesgo: la confianza
Este ataque demuestra uno de los mayores problemas actuales en ciberseguridad:
los atacantes ya entendieron que comprometer un solo desarrollador puede abrir la puerta a miles de organizaciones.
CrowdStrike resumió el problema con una frase clave:
“Los adversarios ya no solo atacan productos, atacan a los desarrolladores que los construyen.”
El impacto potencial es enorme porque los desarrolladores tienen acceso a:
- Código fuente
- Pipelines CI/CD
- Infraestructura cloud
- Llaves SSH
- Tokens
- Repositorios privados
- Credenciales corporativas
Un solo entorno comprometido puede escalar rápidamente hacia múltiples empresas downstream.
¿Cómo operaba Glassworm?
Los investigadores identificaron múltiples métodos utilizados por el grupo:
- Paquetes maliciosos
- Extensiones troyanizadas
- Malvertising
- Robo de credenciales
- Secuestro de cuentas legítimas
Pero lo más sofisticado fue su infraestructura de comando y control.
Glassworm utilizaba:
- Blockchain de Solana
- BitTorrent DHT
- Google Calendar
- Servidores VPS tradicionales
Esta arquitectura hizo que la operación fuera especialmente resiliente y difícil de desmantelar.
El supply chain attack ya es prioridad global
Aunque los ataques a la cadena de suministro no son nuevos, Glassworm confirma que este tipo de campañas siguen evolucionando rápidamente.
En los últimos años SolarWinds, 3CX, XZ Utils y ahora Glassworm, han demostrado que comprometer software confiable puede ser más efectivo que atacar directamente a las víctimas finales.
El open source se convirtió en una superficie crítica de riesgo porque gran parte de la infraestructura digital moderna depende de componentes mantenidos por terceros.
Lo que deja esta operación
El desmantelamiento de Glassworm representa una victoria importante para la industria, pero también deja varias conclusiones:
1. Los desarrolladores son objetivos prioritarios: Ya no son solo usuarios técnicos: hoy son puertas de entrada estratégicas.
2. La confianza puede ser explotada: Los atacantes están aprovechando repositorios, extensiones y paquetes considerados legítimos.
3. La seguridad del software ya no termina en producción: Ahora también debe incluir
entornos de desarrollo, dependencias, marketplaces, extensiones, y repositorios open source.
4. La IA y la automatización acelerarán este tipo de ataques: El volumen y sofisticación de campañas supply chain seguirá creciendo.
La nueva conversación en ciberseguridad
Glassworm deja claro que la conversación ya no es únicamente sobre firewalls o antivirus.
Hoy, la seguridad también depende de quién desarrolla el software, qué dependencias utiliza, qué extensiones instala y qué tan protegida está la cadena completa de desarrollo.
Porque en 2026, atacar empresas ya no siempre empieza desde afuera.
Muchas veces empieza desde el código.
