Instaló un paquete y lo perdió todo: hallan en PyPI un módulo espía con función de autodestrucción

En PyPI se encontraron versiones maliciosas del paquete durabletask, relacionado con Durable Task Framework para entornos Python en la nube y automatizados. El ataque es peligroso porque la infección pudo comenzar sin signos visibles: bastaba con instalar una de las versiones afectadas e importar la biblioteca.

Según Rafael Silva de la empresa Aikido, el código malicioso llegó a durabletask versiones 1.4.1, 1.4.2 y 1.4.3. Al paquete le añadieron un cargador que se activaba al importar en sistemas Linux, descargaba el archivo rope.pyz desde el dominio check.git-service[.]com y lo ejecutaba en un proceso en segundo plano. Los errores se ocultaban, por lo que el desarrollador podría no haber notado nada sospechoso.

Con cada nueva versión los atacantes ampliaron el número de archivos infectados. En 1.4.1 el código estaba solo en durabletask/__init__.py, en 1.4.2 añadieron task.py, y en 1.4.3 el cargador ya se ejecutaba desde cinco puntos de entrada. Ese enfoque aumentaba la probabilidad de activación incluso con un uso parcial de la biblioteca.

El módulo principal rope.pyz actuaba como exfiltrador de datos y gusano de red. Antes de ejecutarse comprobaba si era Linux, el número de núcleos de CPU y la presencia de las dependencias necesarias. Tras la verificación, el programa recopilaba secretos de AWS, Azure, GCP, Kubernetes, HashiCorp Vault, Docker, SSH, npm, pip, Terraform, configuraciones VPN, archivos .env y gestores de contraseñas populares, incluidos 1Password y Bitwarden.

Los datos robados se comprimían, se cifraban y se enviaban a un servidor de control. Si el canal principal no estaba disponible, el malware buscaba en GitHub commits con la cadena FIRESCALE, donde podía estar un servidor de respaldo firmado. Ese mecanismo permitía a los operadores cambiar rápidamente la infraestructura tras bloqueos.

Una parte separada del código se encargaba de la propagación. En AWS el programa podía usar SSM para ejecutar cargas en otras instancias EC2, y en Kubernetes intentaba ejecutar el mismo escenario dentro de otros pods. Para protegerse contra una reinfección se creaban marcadores ~/.cache/.sys-update-check y ~/.cache/.sys-update-check-k8s.

La función más peligrosa se activaba solo tras una orden del servidor de control. Al detectar indicios de configuraciones de sistema israelíes o iraníes, el programa, con una baja probabilidad, reproducía un archivo de audio a todo volumen y luego iniciaba la eliminación del sistema de archivos. Ese escenario indica no solo el robo de datos sino también la disposición de los atacantes a destruir las máquinas infectadas.

Se recomienda a los administradores que instalaron durabletask 1.4.1, 1.4.2 o 1.4.3 considerar esos hosts comprometidos. Deben comprobar los marcadores de infección, los archivos pgmonitor.py, el servicio pgsql-monitor.service, las conexiones de red a check.git-service[.]com y t.m-kosche[.]com, y luego reemplazar las claves de la nube, las claves SSH, los tokens de GitHub, los secretos de Kubernetes, de Vault y los datos de las configuraciones locales.