150 operaciones destructivas en 35 minutos
Microsoft publicó un análisis de una intrusión en la nube en la que un atacante al que rastrea como Storm-3168 intentó más de 150 operaciones destructivas o de recolección de credenciales dentro de un inquilino de Azure en 35 minutos. La fase de borrado duró unos siete minutos e incluyó más de 100 intentos de eliminar cuentas de almacenamiento.
Sysdig, que documentó al grupo por primera vez en julio, lo rastrea como JADEPUFFER y lo describe como la primera operación de ransomware documentada impulsada por un modelo de lenguaje.
Los objetivos fueron cuentas de almacenamiento de Azure, donde la mayoría de los borrados tuvieron éxito; Key Vaults; bases de datos SQL, donde los intentos fallaron porque las versiones de la API usadas no estaban soportadas; Function Apps y planes de App Service; y los bloqueos de protección de Azure Site Recovery y Azure Backup, es decir, los controles que hacen posible la restauración.
La entrada fue una incidencia pública de GitHub
El punto de entrada es lo que los defensores deberían leer dos veces. Microsoft dice que los atacantes usaron dos entidades de servicio comprometidas en el mismo inquilino: las identidades no humanas que permiten a aplicaciones y herramientas automatizadas autenticarse en Azure.
Sus credenciales, escribe Microsoft, «habían quedado expuestas previamente en texto plano en una incidencia pública de GitHub». El secreto se editó después, pero «siguió siendo accesible a través del historial público de ediciones de la incidencia».
Nada de eso requiere IA. Lo que sugiere orquestación es la velocidad: la cronología de Microsoft sitúa a la primera entidad de servicio enumerando recursos durante 15,5 horas, la segunda empezando 90 minutos después, un escaneo de configuración de App Service a las 16 horas, y luego la fase de destrucción de siete minutos y un barrido de credenciales 30 minutos más tarde.
Sin nota de rescate
El detalle inusual es lo que no ocurrió. Microsoft lo dice sin rodeos: «No observamos una nota de rescate ni confirmamos exfiltración de datos exitosa en la actividad descrita aquí».
Y sin embargo el atacante eliminó primero los bloqueos de copia y recuperación, que es justo lo que hace una operación de extorsión para que pagar sea la única salida. O la exigencia llegó por un canal que Microsoft no vio, o la destrucción era el objetivo.
Microsoft presenta el caso como ejemplo de «ataques orquestados por IA, en los que los actores de amenazas pueden coordinar operaciones complejas posteriores al compromiso en entornos de nube con mayor velocidad y escala». Su propio blog no detalla qué sistema de agentes usó Storm-3168, y conviene señalar la distinción: la velocidad está documentada; atribuir esa velocidad a un modelo es la caracterización que hace Sysdig del grupo, no algo que Microsoft demuestre en esta entrada.
Qué hacer al respecto
Las mitigaciones de Microsoft son poco vistosas y en su mayoría anteriores a los agentes: activar Defender for Cloud, mantener las credenciales fuera de repositorios e hilos de incidencias, rotar de inmediato las credenciales expuestas, aplicar mínimo privilegio a las entidades de servicio y proteger la infraestructura de copias. También recomienda sus propias herramientas de defensa con agentes.
La lección transferible es más estrecha. Un secreto pegado en una incidencia de GitHub hace dos años siempre ha sido un riesgo. Lo que ha cambiado es el poco tiempo que tiene ahora un defensor entre el hallazgo de la credencial y la desaparición de las cuentas de almacenamiento.
