CanisterWorm de TeamPCP: destrucción selectiva y persistencia en entornos Kubernetes

Hace días, investigadores de seguridad han desvelado una campaña que mezcla técnicas de movimiento lateral en entornos cloud-native con una carga útil deliberadamente destructiva orientada a sistemas iraníes. El hallazgo, documentado por la firma Aikido, atribuye la operación al grupo conocido como TeamPCP y la relaciona con actividades previas que comprometieron herramientas de código abierto y paquetes NPM bajo el nombre informal “CanisterWorm”.

La amenaza combina dos caras: en entornos Kubernetes se aprovecha de mecanismos nativos para propagarse y persistir; fuera de Kubernetes, activa un mecanismo de borrado masivo que puede dejar máquinas inservibles si detecta ciertas pistas del sistema.

Según el análisis técnico, el malware primero intenta determinar si el equipo corresponde a Irán revisando la configuración de zona horaria y regional. Si detecta esas señales y existe Kubernetes en la máquina, despliega un DaemonSet dentro del espacio de sistema que monta el sistema de ficheros del host y arranca contenedores privilegiados. Cada uno de esos contenedores ejecuta una imagen mínima (Alpine) con un binario que borra las entradas principales del disco del host y fuerza un reinicio, una maniobra que, en la práctica, puede dejar nodos y aplicaciones irreparables.

En contrapartida, cuando el sistema no se identifica como iraní pero sí tiene Kubernetes, la misma infraestructura de propagación se reutiliza para instalar un componente persistente: un backdoor escrito en Python que se deja en el sistema de ficheros y se registra como un servicio systemd para sobrevivir a reinicios. Esta doble estrategia —borrar donde se considera “objetivo” y establecer puerta trasera donde no— confirma el carácter selectivo y orientado de la campaña.

El actor no se limita a Kubernetes: Aikido también documenta variantes que prescinden del movimiento lateral basado en DaemonSets y recurren a mecanismos más tradicionales de propagación por SSH. En estos casos, el malware escanea registros de autenticación en busca de credenciales válidas, reutiliza claves privadas comprometidas y establece conexiones SSH salientes con opciones que evitan comprobaciones de huella del host (por ejemplo, usando StrictHostKeyChecking=no). Otro canal de expansión identificado es el uso de APIs de Docker expuestas (habitualmente el puerto 2375 sin TLS), que permiten arrancar contenedores privilegiados y montar el host como volumen, lo que reproduce el efecto destructivo fuera del ecosistema Kubernetes.

Hay indicadores concretos que conviene vigilar: entre ellos, actividad en la red saliente hacia la infraestructura de comando y control ya asociada a CanisterWorm, la aparición de DaemonSets con nombres sospechosos como “Host-provisioner-iran” o “host-provisioner-std” en el namespace kube-system, contenedores Alpine marcados como “kamikaze”, archivos temporales dejados en rutas tipo /tmp/pglog y conexiones a APIs Docker en el puerto 2375 a hosts de la subred local. Aikido también apunta a un canister específico usado como C2; su reporte ofrece más detalles técnicos y artefactos IOCs para equipos de respuesta: informe de Aikido.

Para contextualizar lo que aprovecha esta campaña, conviene recordar cómo funcionan algunos elementos clave de Kubernetes y Docker. Los DaemonSets son objetos de Kubernetes que garantizan que un pod se ejecute en cada nodo, por lo que, en manos de un atacante con privilegios, son una forma eficaz de ejecutar código en todos los hosts de un clúster; la documentación oficial explica su diseño y riesgos: DaemonSets en la documentación de Kubernetes. Por otro lado, el uso de volúmenes hostPath para montar el sistema de ficheros del host en un contenedor permite al proceso dentro del contenedor manipular directamente archivos del sistema: hostPath en Kubernetes.

Del lado de contenedores y runtimes, exponer la API de Docker sin autenticación (habitualmente a través del puerto 2375) es una práctica conocida y peligrosa: esa API permite gestionar contenedores y montar el host desde la red si no está protegida. Las guías oficiales de Docker incluyen recomendaciones de seguridad para mitigar estos escenarios: seguridad del motor Docker.

¿Qué pueden hacer equipos y administradores ahora mismo? En primer lugar, auditar permisos y accesos a nivel de clúster: revisar quién puede crear DaemonSets o modificar el namespace kube-system, y aplicar controles RBAC estrictos para evitar que procesos no autorizados creen objetos con privilegios elevados. Es fundamental bloquear el acceso no autenticado al API del runtime de contenedores y segmentar la red para que un host comprometido no pueda invocar APIs administrativas en la subred. Monitorizar la creación de recursos inusuales (nombres, imágenes Alpine ejecutadas con privilegios, mounts de /) y establecer alertas sobre conexiones SSH salientes con opciones que deshabilitan comprobaciones de huella son contramedidas prácticas y de alto impacto.

Además, las prácticas básicas de higiene permanecen esenciales: rotación y protección de claves privadas, deshabilitar sudo sin contraseña, aplicar actualizaciones y parches a las herramientas de la cadena de suministro que se utilicen (si el actor ya ha demostrado interés en proyectos de código abierto, proteger esos flujos es crítico) y almacenar registros de auditoría fuera del alcance de nodos individuales para facilitar la investigación post-compromiso.

Esta campaña es un recordatorio de que la seguridad en entornos cloud-native ya no es solo cuestión de aplicar parches: es necesario diseñar defensas que tengan en cuenta mecanismos de orquestación, la exposición de APIs de runtime y la posibilidad de que un adversario combine técnicas de persistencia y destrucción. Para quien quiera profundizar en el análisis técnico y los indicadores, el reporte de Aikido ofrece un desglose detallado: leer el informe de Aikido.

Si gestionas infraestructura crítica o clústeres Kubernetes, actúa con prioridad: revisa las reglas RBAC, cierra y asegúrate de que las APIs de Docker no estén accesibles sin protección, vigila logs y alertas por comportamiento anómalo, y prepara un plan de respuesta que contemple la posibilidad de borrado masivo de datos. La combinación de intención política y técnicas automatizadas que muestra esta campaña eleva el riesgo y exige una respuesta coordinada entre administradores, equipos de seguridad y proveedores de servicios.