CanisterWorm: el grupo de hackers que usa contratos inteligentes para infectar sistemas y tiene en el punto de mira a Irán
Hay campañas de ciberseguridad que parecen salidas de un guión de thriller tecnológico, pero esta es real y está pasando ahora mismo. Un grupo de hackers llamado TeamPCP lleva meses causando estragos en Internet, y lo que empezó como una operación de minería de criptomonedas y robo de credenciales ha evolucionado hasta convertirse en algo mucho más inquietante: un gusano autopropagado que destruye datos en máquinas ubicadas en Irán.
Si trabajas en desarrollo de software, en entornos cloud o simplemente tienes curiosidad por cómo se mueven los actores de amenazas más sofisticados hoy en día, esto te interesa. Y mucho.
Quién es TeamPCP y cómo empezó todo esto
TeamPCP apareció en el radar de los investigadores de seguridad en diciembre de 2024, cuando la firma Flare detectó que estaban desplegando un gusano dirigido a plataformas alojadas en la nube que no estaban bien securizadas. El objetivo era construir una infraestructura distribuida de proxies y escaneo para luego comprometer servidores y utilizarlos con múltiples propósitos: exfiltración de datos, despliegue de ransomware, extorsión y minería de criptomonedas.
Lo que distingue a este grupo no es solo la motivación económica, que tampoco es ninguna novedad en el mundo del crimen digital, sino su capacidad para la automatización a gran escala y la integración de técnicas de ataque bien conocidas combinadas de formas creativas y eficientes.
Dicho de forma directa: no estamos ante script kiddies. Estamos ante un grupo organizado, con recursos y, lo más preocupante, con capacidad para adaptarse y evolucionar rápidamente.
El ataque a la cadena de suministro de Trivy
Para entender CanisterWorm, hay que entender el contexto que lo precedió.
A finales de febrero de 2025, TeamPCP comprometió la infraestructura de Aqua Security, la empresa detrás de Trivy, uno de los escáneres de vulnerabilidades de código abierto más utilizados en entornos DevSecOps. Esta primera brecha no fue detectada ni contenida del todo, y eso tuvo consecuencias graves.
Semanas después, aprovechando que la rotación de credenciales comprometidas había sido incompleta, TeamPCP tomó el control de la cuenta de GitHub de Aqua Security y utilizó el acceso para comprometer prácticamente todas las versiones de Trivy en un ataque de cadena de suministro. Si usas Trivy en tus pipelines de CI/CD y no revisaste qué versión tenías instalada a finales de marzo, tienes un problema.
Y eso fue solo el principio. Durante el fin de semana siguiente, el grupo fue más allá: comprometió también la cuenta de Docker Hub de Aqua Security y publicó 2 actualizaciones maliciosas del escáner. Además, accedieron a una segunda cuenta de GitHub de la compañía y desfiguraron, renombraron y publicaron 44 repositorios internos, incluyendo código fuente de Tracee, forks internos de Trivy, pipelines de CI/CD, operadores de Kubernetes y bases de conocimiento del equipo.
Aqua Security dijo que estaba realizando una purga más exhaustiva de credenciales. Lo que está claro es que sus primeros intentos de contención no funcionaron, y eso subraya algo que en ciberseguridad repetimos constantemente: una respuesta a incidentes incompleta puede ser casi tan peligrosa como no responder en absoluto.
CanisterWorm: el gusano que usaba contratos inteligentes para sobrevivir
Aquí es donde la cosa se pone técnicamente interesante, y también bastante preocupante.
Durante el fin de semana del 22 y 23 de marzo de 2025, investigadores de la firma Aikido observaron a TeamPCP distribuyendo un nuevo malware al que han bautizado como CanisterWorm. Lo que lo hace especial no es solo que sea un gusano autopropagado, sino el mecanismo de control que utilizaba.
Cómo se propagaba
El gusano infectaba una máquina y a continuación buscaba tokens de acceso al repositorio npm. Si los encontraba, comprometía los paquetes publicables disponibles creando nuevas versiones con el código malicioso incrustado. Aikido observó al gusano infectando 28 paquetes en menos de 60 segundos. Eso no es un error de medición: es una velocidad de propagación que deja muy poco margen de reacción.
La lógica de infección era inquietantemente simple: cualquier desarrollador o pipeline de CI/CD que instalara uno de esos paquetes comprometidos y tuviera un token de npm accesible se convertía automáticamente en un nuevo vector de propagación. Sus paquetes se infectaban, sus usuarios downstream los instalaban, y si alguno de ellos también tenía tokens… el ciclo volvía a empezar. Es una cadena de confianza convertida en arma.
El mecanismo de control: contratos inteligentes y blockchain
Este es el detalle que me parece más revelador sobre la sofisticación de TeamPCP. En lugar de usar servidores de comando y control tradicionales, que pueden ser detectados, bloqueados y dados de baja con relativa rapidez, CanisterWorm utilizaba un canister de Internet Computer Protocol (ICP).
¿Qué es eso exactamente? Un canister es una forma de contrato inteligente autoejecutado que, por diseño, está pensado para ser imposible de eliminar o modificar por terceros. El canister apuntaba a URLs en constante cambio donde se alojaban los binarios maliciosos, lo que daba a los atacantes la capacidad de cambiar los servidores en cualquier momento sin perder el control sobre las máquinas infectadas. Las máquinas comprometidas se reportaban al canister cada 50 minutos.
Es una arquitectura de C2 (command and control) ingeniosamente resistente a la censura. O al menos eso era la teoría. En la práctica, el investigador de Aikido Charlie Eriksen confirmó que el canister fue dado de baja el domingo por la noche. «No era tan fiable o indestructible como esperaban», escribió Eriksen. Pero durante el tiempo que estuvo activo, el potencial de daño era real.
El giro que nadie esperaba: un wiper contra Irán
Hasta aquí, TeamPCP encajaba en el perfil habitual de un grupo motivado económicamente. Luego llegó el sábado por la tarde y todo cambió.
Se detectó una actualización de CanisterWorm que añadía un payload adicional: un wiper que actuaba exclusivamente sobre máquinas ubicadas en Irán. La lógica era sencilla y brutal, usando las propias palabras de Eriksen:
- Kubernetes + Irán: Despliega un DaemonSet que borra cada nodo del clúster.
- Kubernetes + otros países: Despliega un DaemonSet que instala el backdoor de CanisterWorm en cada nodo.
- Sin Kubernetes + Irán: Ejecuta
rm -rf / --no-preserve-root, es decir, borra todo el sistema de archivos raíz. - Sin Kubernetes + otros países: Sale. No hace nada.
Al componente wiper lo han bautizado internamente como Kamikaze. El nombre no deja mucho margen para la interpretación.
Eriksen reconoció que, a fecha de redacción de este artículo, no hay evidencia de que el wiper haya causado daño real en máquinas iraníes, pero sí existe «un claro potencial de impacto a gran escala si logra una propagación activa».
¿Por qué Irán? La pregunta que nadie sabe responder todavía
Este es el punto donde las cosas se vuelven ambiguas, y prefiero no especular más de lo necesario. Lo que sí está claro es que la elección de Irán como objetivo resulta llamativa para un grupo cuya motivación ha sido consistentemente financiera. Un wiper no genera beneficio económico. No roba credenciales, no mina criptomonedas, no extorsiona.
Eriksen lo planteó con honestidad: podría haber un componente ideológico, o podría ser simplemente una forma deliberada de llamar la atención. «Históricamente, TeamPCP ha parecido estar motivado financieramente, pero hay señales de que la visibilidad se está convirtiendo en un objetivo en sí mismo», escribió. Al atacar herramientas de seguridad y proyectos de código abierto ampliamente utilizados, como Checkmarx, el grupo está enviando una señal deliberada al sector.
Yo, personalmente, no descartaría ninguna hipótesis todavía. Que un grupo cambie de motivación no es imposible, pero que lo haga tan abruptamente y con un objetivo geopolítico tan específico merece seguimiento.
Qué deben hacer los equipos de desarrollo ahora
Si gestionas pipelines de CI/CD, usas paquetes npm en producción o tienes Trivy integrado en tu infraestructura, este no es el momento de esperar a que alguien te mande un correo de alerta.
Tanto Aikido como Socket han publicado indicadores de compromiso (IoCs) que puedes utilizar para determinar si tu organización ha sido afectada. La recomendación mínima pasa por:
- Revisar qué versiones de Trivy tienes instaladas y si corresponden con versiones comprometidas (especialmente v0.69.5 y v0.69.6 en Docker Hub).
- Auditar los tokens de npm accesibles desde tus entornos de CI/CD y rotar los que no puedas justificar.
- Revisar los paquetes npm de tu supply chain en busca de versiones recientes no esperadas.
- Comprobar si alguna máquina de tu entorno ha realizado conexiones a canisters ICP o a URLs inusuales en los últimos días.
La cadena de ataque de CanisterWorm es un recordatorio de algo que el sector lleva repitiendo años: la seguridad de la cadena de suministro de software no es un problema opcional. Es una superficie de ataque real, activa y, como hemos visto, extremadamente difícil de contener una vez que un actor motivado la empieza a explotar.
