Microsoft atribuye a Storm-3168 el borrado de recursos Azure con identidades robadas

Microsoft ha vinculado a Storm-3168, el nombre interno que da la compañía al actor conocido como JADEPUFFER, con una campaña destructiva contra un entorno de Azure que usó service principals comprometidos. La operación se extendió unas 18 horas a principios de junio de 2026 y acabó con el borrado de buena parte de los recursos del inquilino atacado: cuentas de almacenamiento, bases de datos SQL, Key Vaults, Function Apps y máquinas virtuales.

Dos identidades, dos trabajos

Los investigadores observaron dos service principals comprometidos del mismo tenant. El primero se dedicó al reconocimiento durante casi 16 horas, enumerando máquinas virtuales, suscripciones, grupos de recursos y recursos, con más de 300 operaciones de lectura. El segundo arrancó su propia fase de descubrimiento 90 minutos después y enumeró máquinas virtuales y grupos de recursos de dos suscripciones en cinco segundos.

Pasadas esas 16 horas, el segundo service principal enumeró los almacenes de configuración de Azure App Service, probablemente en busca de credenciales expuestas. A partir de ahí, más de 150 operaciones destructivas o de recogida de credenciales en 35 minutos. La secuencia de borrado en sí duró unos siete minutos e incluyó más de 100 intentos de eliminar cuentas de almacenamiento.

No todo le salió al atacante según lo previsto. Los intentos de borrar bases de datos Azure SQL fallaron porque usaban una versión de API no soportada para ese tipo de recurso. Y los bloqueos de recursos y la protección de borrado a nivel de cuenta de almacenamiento impidieron la eliminación de algunas cuentas, aunque la mayoría cayeron. Microsoft lo señala como ejemplo de que las salvaguardas independientes siguen funcionando aunque la identidad comprometida tenga permisos administrativos amplios.

Cómo entraron

El origen del compromiso no está del todo claro, pero Microsoft apunta a algo bastante terrenal: el client ID, el client secret y el tenant ID aparecieron en texto plano en un issue público de GitHub, publicado por un empleado de la organización afectada. El secreto se borró después, pero seguía accesible en el historial de edición público.

El actor no es nuevo. Sysdig lo documentó como el primer ransomware ejecutado de principio a fin con ayuda de un LLM, que explotó CVE-2025-3248 en Langflow para entrar, cifró ficheros de configuración de Nacos y borró tablas. Después llegó ENCFORGE, una variante en Go orientada a infraestructura de IA que rastrea cerca de 180 extensiones: checkpoints de modelos, bases de datos vectoriales, datasets de entrenamiento, índices de embeddings, y también llaveros de macOS, proyectos de Xcode y documentos de Pages y Numbers.

Microsoft cree que el objetivo final estaba alineado con el secuestro de datos, porque también se borraron recursos de copia de seguridad y recuperación. Aun así, no se observó nota de rescate ni exfiltración exitosa. La compañía dice además que ha detectado sondeos repetidos desde infraestructura vinculada a Storm-3168 contra varios App Services de distintos clientes, y que el reparto de tareas entre varios service principals y los tiempos entre operaciones apuntan a un ataque automatizado.

Queda una lección operativa incómoda: un secreto que se filtra en un issue de GitHub sigue vivo en el historial mucho después de que alguien lo borre. Y un service principal con permisos amplios puede hacer en siete minutos lo que a un equipo le cuesta semanas reconstruir. Microsoft puede detallar el modus operandi, pero cómo se obtuvieron esas credenciales en otros casos sigue sin respuesta.