Microsoft detalló cómo un ransomware manejado con IA borró recursos de una empresa en Azure en siete minutos
El atacante, conocido como JadePuffer y descripto como el primer ransomware operado por agentes de inteligencia artificial, usó dos identidades de aplicaciones comprometidas para mapear la nube de una empresa y después intentó borrar más de 100 cuentas de almacenamiento en unos siete minutos. Microsoft no descarta que haya entrado por una credencial expuesta en GitHub.
El atacante, conocido como JadePuffer y descripto como el primer ransomware operado por agentes de inteligencia artificial, usó dos identidades de aplicaciones comprometidas para mapear la nube de una empresa y después intentó borrar más de 100 cuentas de almacenamiento en unos siete minutos. Microsoft no descarta que haya entrado por una credencial expuesta en GitHub.
Microsoft publicó el 25 de septiembre un informe sobre un ataque contra la nube de una empresa en Azure atribuido a JadePuffer, el grupo que la firma de seguridad Sysdig presentó en julio como la primera operación de ransomware «agéntica» documentada, es decir, manejada por agentes de inteligencia artificial y no por una persona frente al teclado. Microsoft lo rastrea con el nombre Storm-3168. Según el informe, a principios de junio de 2026 el atacante recorrió durante horas los recursos de la empresa y después, en una secuencia de unos siete minutos, intentó borrar más de 100 cuentas de almacenamiento, además de bases de datos y protecciones de respaldo.
La mayoría de las cuentas de almacenamiento atacadas se borraron. Algunas se salvaron gracias a los bloqueos de recursos de Azure y a la protección contra borrado configurada en esas cuentas. También se eliminaron un Key Vault (el servicio donde se guardan claves y secretos), una Function App y un plan de App Service. Microsoft aclaró que no encontró una nota de rescate ni pudo confirmar que se hayan robado datos.
Cómo funcionó el ataque, paso a paso
El atacante no usó cuentas de personas, sino dos «service principals» comprometidos: identidades que usan las aplicaciones y los procesos automáticos para conectarse a Azure. Las dos pertenecían a la misma empresa. Una se dedicó a reconocer el terreno; la otra, a reconocer, destruir y recolectar credenciales.
- Reconocimiento. La primera identidad enumeró máquinas virtuales, suscripciones, grupos de recursos y recursos durante unas 15 horas y 30 minutos, con más de 300 operaciones de lectura exitosas. Unos 90 minutos después de que empezara, la segunda identidad revisó máquinas virtuales y grupos de recursos de dos suscripciones en cinco segundos.
- Última revisión. Dieciséis horas más tarde, la segunda identidad inventarió los almacenes de configuración de App Service, posiblemente en busca de credenciales expuestas, según Microsoft.
- Destrucción. Setenta segundos después pidió las claves de una cuenta de almacenamiento que no existía y, menos de un segundo más tarde, empezó a borrar. En 35 minutos intentó más de 150 operaciones destructivas o de robo de credenciales; la fase de borrado propiamente dicha duró unos siete minutos.
- Robo de claves. Unos 30 minutos después del último borrado, hizo más de 30 pedidos exitosos de las claves de acceso de cuentas de almacenamiento, incluidas algunas vinculadas a Azure Site Recovery, el servicio de recuperación ante desastres.
Toda la actividad observada ocurrió en una ventana de unas 18 horas, según la línea de tiempo que publicó la empresa.
El atacante también intentó borrar varias bases de datos Azure SQL en paralelo, pero todos esos intentos fallaron porque usó una versión de la API que Azure no admite para ese tipo de recurso. Tampoco pudo eliminar los bloqueos de Azure Site Recovery y de Azure Backup que protegían cuentas de almacenamiento. Para Microsoft, apuntar a la vez a bases de datos y a almacenamiento sugiere «un esfuerzo por ampliar el impacto destructivo» sobre distintos servicios de datos, y atacar los respaldos indica que buscaba dificultar la recuperación.
Por dónde entró
Microsoft no pudo determinar cómo se comprometió la primera identidad. Sí encontró que su ID de cliente, su secreto y el ID de la organización habían quedado expuestos en texto plano en un issue público de GitHub, publicado por un empleado de la empresa atacada. El issue se editó después para sacar el secreto, pero siguió visible en el historial público de ediciones. La empresa aclaró que no pudo confirmar si ese secreto fue el que se usó en el ataque.
Además, desde principios de este año Microsoft detectó sondeos desde infraestructura vinculada al grupo contra aplicaciones de App Service de distintos clientes, buscando rutas sensibles de WordPress, PHP-CGI y Langflow, aunque esos objetivos no coincidieron con la empresa afectada.
Por qué es un antes y un después
Para Microsoft, los tiempos entre operaciones, el reparto de tareas entre las dos identidades y el uso de varios tokens en paralelo (cinco para la identidad que destruyó, dos de ellos activos a la vez) indican con fuerza una ejecución automatizada. La empresa enmarca el caso en «un cambio más amplio hacia ataques orquestados por IA», en los que los atacantes pueden coordinar operaciones complejas en la nube «con mayor velocidad y escala».
El antecedente es el informe que Sysdig publicó el 1 de julio, en el que describió a JadePuffer como el primer caso documentado de ransomware manejado de punta a punta por un modelo de lenguaje. En aquel ataque, contra otra víctima, el agente entró por una falla de Langflow, cifró 1.342 elementos de configuración, dejó una nota de rescate con una dirección de Bitcoin y generó una clave que nunca guardó, por lo que los datos no se podían recuperar ni pagando. Según Sysdig, el código que ejecutaba estaba lleno de comentarios en lenguaje natural que explicaban cada paso, y en una secuencia pasó de un inicio de sesión fallido a una solución que funcionaba en 31 segundos. Michael Clark, director de investigación de amenazas de Sysdig, resumió que el piso de conocimiento necesario para lanzar un ransomware bajó a «lo que cueste hacer funcionar un agente».
Qué recomienda Microsoft
- Activar los planes de Microsoft Defender for Cloud para las cargas críticas: Resource Manager, Storage, Key Vault, App Service y bases de datos.
- No guardar credenciales de aplicaciones, claves de almacenamiento ni cadenas de conexión en código, archivos de configuración, repositorios públicos o issues.
- Rotar de inmediato cualquier credencial expuesta: borrarla del lugar donde se publicó no la invalida, porque puede quedar en historiales, cachés o archivos. Investigar además cómo se usó.
- Aplicar el mínimo privilegio a las identidades de aplicaciones y revisar sus permisos en Azure.
- Proteger la infraestructura de respaldo y recuperación, restringir el acceso y vigilar cualquier intento de modificar o quitar sus protecciones.
El caso mostró, según la empresa, el valor de esas protecciones independientes: los bloqueos que se configuraron de antemano siguieron funcionando aunque el atacante tenía amplios permisos de administración.