CanisterWorm un gusano autodesplegable que redefine la seguridad de npm con canisters de Internet Computer

Publicada 7 min de lectura 135 lecturas

En los últimos días la comunidad de desarrolladores ha recibido una alerta seria: una cadena de compromiso iniciada en el popular escáner Trivy parece haber derivado en una ola de paquetes npm manipulados que albergan un gusano autorreplicante nunca antes documentado, bautizado por los investigadores como CanisterWorm. Lejos de ser una infección clásica, este ataque combina técnicas tradicionales de malware con una pieza novedosa: el uso de un canister de la cadena de bloques Internet Computer (ICP) como un “dead drop” descentralizado para gestionar el comando y control.

Según el análisis publicado por el equipo de investigación de Aikido Security, la intrusión inicial aprovechó credenciales comprometidas para publicar versiones maliciosas de proyectos relacionados con Trivy (entre ellos trivy, trivy-action y setup-trivy) que contenían un credential stealer. A partir de ahí los atacantes, atribuidos de forma provisional a la operación conocida como TeamPCP por firmas de inteligencia como Cyble, empezaron a propagar código capaz de instalar un backdoor en Python, establecer persistencia y contactar periódicamente al canister de ICP para descargar la siguiente etapa del ataque.

CanisterWorm un gusano autodesplegable que redefine la seguridad de npm con canisters de Internet Computer
Imagen generada con IA.

La mecánica técnica es inquietante por su robustez: durante la instalación el paquete malicioso ejecuta un hook de postinstall que lanza un cargador. Este cargador deja un backdoor en Python que, además de mantenerse activo gracias a un servicio de systemd configurado con Restart=always, consulta cada 50 minutos al canister de ICP usando un User‑Agent falsificado. El canister responde con una URL en texto plano que apunta al binario a descargar y ejecutar. El control a través del canister es especialmente problemático porque, al ser infraestructura descentralizada, resulta resistente a las acciones de mitigación clásicas: el controlador del canister puede cambiar la URL para desplegar nuevas cargas sin volver a tocar los equipos infectados.

Los investigadores notaron además un “interruptor” curioso usado por los atacantes: si la URL que devuelve el canister contiene youtube[.]com, el dropper la ignora y no descarga nada, funcionando así como estado de latencia. En los momentos que se reportó el análisis, la URL activa era un vídeo de broma (un típico “rickroll”), pero el canister cuenta con métodos que permiten actualizar el enlace y servir un binario real en cualquier momento. El tablero público del canister y los métodos expuestos por él (como get_latest_link y update_link) fueron verificados por los analistas y confirman la capacidad de modificar el comportamiento sobre la marcha.

La dimensión de la contaminación del ecosistema npm es significativa: se han detectado decenas de paquetes afectados, incluidos 28 paquetes bajo el scope @EmilGroup y 16 bajo @opengov, además de nombres concretos como @teale.io/eslint-config, @airtm/uuid-base32 y @pypestream/floating-ui-dom. En una primera versión de la campaña el atacante usaba una herramienta llamada "deploy.js" ejecutada manualmente con tokens npm robados para publicar versiones comprometidas de múltiples paquetes y ampliar su radio de impacto. Esta variante ya era peligrosa: un operador con tokens válidos puede, programáticamente y a gran escala, publicar paquetes infectados y comprometer la cadena de suministro de proyectos que dependen de ellos.

Lo que eleva aún más la gravedad del incidente es que se observó una evolución del gusano hacia un comportamiento completamente autónomo. En versiones maliciosas recientes (por ejemplo, en @teale.io/eslint-config v1.8.11 y v1.8.12) la lógica de propagación fue incorporada directamente en index.js. Allí existe una función que busca tokens npm en el entorno del desarrollador durante el postinstall y lanza la propia rutina de despliegue en segundo plano, transformando así la infección en un verdadero worm que ya no requiere la ejecución manual del atacante para escalar: cualquier máquina de desarrollo o canal CI que instale el paquete y tenga un token accesible puede convertirse en un nuevo vector de publicación para más paquetes infectados.

Los detalles de persistencia y camuflaje son prácticos y poco sofisticados a la vez: el servicio de systemd se hace pasar por una herramienta de PostgreSQL llamada “pgmon” para evitar levantar sospechas, y el backdoor no mata procesos antiguos cuando adopta una nueva URL, lo que significa que versiones previas permanecen en ejecución. Aikido también reporta que el autor probó el flujo de propagación con una cadena de prueba ("hello123") antes de poner un binario real, estrategia habitual para asegurarse de que toda la cadena de infección funciona antes de activar la carga maliciosa real.

Frente a esta amenaza, la respuesta para desarrolladores y equipos de seguridad debe ser rápida y multifacética. Es imprescindible revocar y rotar tokens npm comprometidos de manera inmediata y revisar las integraciones de los pipelines de CI para asegurarse de que no almacenan tokens con permisos innecesarios. Las cuentas y credenciales utilizadas para publicar paquetes deben someterse a una auditoría, y conviene inspeccionar los entornos de desarrollo y runners por señales de persistencia: servicios de systemd con nombres sospechosos en el espacio de usuario, ficheros como deploy.js, index.js con lógica de captura de tokens, y procesos Python que realizan conexiones periódicas a dominios o endpoints inusuales. Para entender y mitigar el riesgo de tokens en npm, la documentación oficial sobre tokens puede servir de guía, por ejemplo la página de tokens de npm.

También conviene recordar que este ataque combina elementos de comunicación remota con infraestructuras poco convencionales; por ello es útil conocer el concepto de “dead drop resolver” dentro del marco MITRE ATT&CK (T1102.001) y cómo los canisters de Internet Computer están siendo utilizados aquí como ese tipo de canal resistente a la toma abajo. La propia documentación de los canisters ayuda a comprender por qué su tamper‑proof y descentralización los hacen atractivos para abusos de este tipo: documentación de ICP.

CanisterWorm un gusano autodesplegable que redefine la seguridad de npm con canisters de Internet Computer
Imagen generada con IA.

Para equipos de respuesta e infraestructuras críticas, medidas prácticas incluyen bloquear versiones afectadas a nivel de registro o feed interno, purgar dependencias comprometidas de los caches y lockfiles, auditar cadenas de suministro con herramientas de análisis de dependencias y aplicar políticas que minimicen la exposición de credenciales en runners e imágenes de build. GitHub y otros proveedores tienen guías sobre cómo proteger tokens y secretos en pipelines; revisar y aplicar buenas prácticas de gestión de secretos es clave para limitar la blast radius de este tipo de ataques (guía de GitHub sobre tokens y secretos).

La campaña CanisterWorm pone de manifiesto varias tendencias preocupantes: la sofisticación creciente de las operaciones criminales en la cadena de suministro del software, la reutilización de infraestructuras descentralizadas para hacer más resiliente el control remoto del malware, y la facilidad con la que los tokens y el acceso de publicación pueden transformar una cuenta comprometida en un multiplicador de daños. Los análisis públicos —como el informe técnico de Aikido Security que documenta estos hallazgos— son recursos valiosos para comprender la telemetría y los indicadores de compromiso y se pueden consultar para obtener información técnica detallada (análisis de Aikido).

Estamos ante un desarrollo activo: las defensas deberán moverse con rapidez para neutralizar las publicaciones maliciosas, retirar paquetes infectados del registro público y cortar el acceso de los atacantes. Mientras tanto, la comunidad de desarrolladores debe asumir que cualquier paquete comprometido puede ser una puerta de entrada para una propagación automática y actuar en consecuencia: auditar dependencias, rotar credenciales expuestas y endurecer pipelines. La combinación de vigilancia, rotación de credenciales y políticas de menor privilegio sigue siendo la mejor defensa frente a este tipo de amenazas que se aprovechan de la confianza inherente en el ecosistema open source.

Cobertura

Relacionadas

Mas noticias del mismo tema.