Storm-3168: cómo atacaron Azure con service principals comprometidos y cómo proteger tus identidades de workload

Por Felipe Traina · 28/9/2026 · 7 min · seguridad, azure, cloud, identidades

En unos siete minutos, un service principal comprometido intentó borrar más de 100 cuentas de almacenamiento de Azure, y la mayoría se borraron. Lo que salvó a algunas no fue un detector sofisticado, sino controles simples: resource locks y protección contra borrado a nivel de cuenta. El caso lo publicó Microsoft Security el 25 de septiembre de 2026 y lo atribuye a Storm-3168, el nombre con el que rastrea a JADEPUFFER, un actor que Sysdig documentó en julio como la primera operación de ransomware agéntico conocida.

Más allá de la etiqueta "agéntico", el reporte es un caso de estudio muy claro sobre identidades de workload: credenciales de aplicaciones con demasiados permisos, secretos expuestos y recursos de recuperación sin protección.

Qué pasó, paso a paso

Según Microsoft, en un tenant afectado se observaron dos service principals comprometidos. La secuencia:

  1. Reconocimiento (junio de 2026). El primer service principal enumeró máquinas virtuales, suscripciones, grupos de recursos y recursos durante unas 15 horas y media, con más de 300 lecturas exitosas.
  2. Segundo actor. Unos 90 minutos después, el segundo service principal enumeró VMs y grupos de recursos de dos suscripciones en cinco segundos. Ambos usaban infraestructura vinculada a Storm-3168, la misma huella de red y el user agent python-requests/2.34.2.
  3. Búsqueda de credenciales. Dieciséis horas más tarde, el segundo enumeró los almacenes de configuración de App Service, posiblemente buscando credenciales expuestas.
  4. Destrucción. Menos de un segundo después de un ListKeys fallido, empezó una secuencia destructiva de unos siete minutos, con más de 100 intentos de borrado de storage accounts. También se eliminaron un Key Vault, una Function App y su App Service plan. Los intentos de borrar bases de Azure SQL fallaron porque usaron una versión de API no soportada.
  5. Ataque a la recuperación. Hubo intentos fallidos de eliminar locks de Azure Site Recovery y de Azure Backup.
  6. Robo de claves. Unos 30 minutos después, más de 30 llamadas ListKeys exitosas para obtener las claves de acceso de cuentas de almacenamiento, incluidas algunas de Site Recovery.

Microsoft aclara que no observó una nota de rescate ni confirmó exfiltración de datos, pero que la combinación de destrucción, ataque a la recuperación y recolección de claves es consistente con tácticas de ransomware y extorsión.

Cómo pudo haber empezado

Microsoft dice que no está claro cómo se comprometió el service principal, pero encontró algo revelador: su client ID, client secret y tenant ID habían sido publicados en texto plano en un issue público de GitHub por un empleado de la organización afectada. El issue se editó para quitar el secreto, pero seguía accesible en el historial de ediciones. Microsoft no pudo confirmar que ese secreto se usara en el ataque.

La lección es directa y vale para cualquier nube: borrar o editar un secreto expuesto no lo invalida. Hay que rotarlo o revocarlo.

Qué lo hizo "automatizado"

El reporte muestra indicios de ejecución automatizada: la división del trabajo entre dos identidades, cinco tokens distintos emitidos para el mismo service principal (cuatro para borrar, uno para inventario y claves) y dos tokens de borrado activos en paralelo durante los mismos 70 segundos.

Un dato clave: todas las operaciones siguieron los roles que la identidad ya tenía asignados. Un rol Storage Account Contributor heredado por grupo autorizó los borrados de storage; un Contributor directo autorizó los borrados de la aplicación. El atacante no escaló privilegios: usó los que ya existían.

Checklist para proteger identidades de workload

Estas medidas siguen las recomendaciones de Microsoft en el reporte, llevadas a comandos concretos de Azure CLI.

1. Inventario de permisos de cada service principal

# Roles asignados a una aplicación, en todos los scopes
az role assignment list --assignee <appId> --all -o table

Si ves Contributor u Owner a nivel de suscripción para una app que solo lee un bucket, ahí está tu primer trabajo. Reemplazá roles amplios por roles específicos y con el scope más chico posible.

2. Secretos con fecha de vencimiento (y mejor, sin secretos)

# Credenciales de la app y cuándo vencen
az ad app credential list --id <appId> \
  --query "[].{nombre:displayName, vence:endDateTime}" -o table

# Rotación inmediata si hubo exposición (reemplaza las credenciales existentes)
az ad app credential reset --id <appId>

Donde sea posible, eliminá los secretos de larga duración con workload identity federation (por ejemplo, para pipelines de CI) o identidades administradas para recursos que corren en Azure:

az ad app federated-credential create --id <appId> --parameters credencial.json

3. Locks en lo que no se puede perder

En el ataque, los resource locks frenaron borrados incluso con una identidad con permisos administrativos amplios:

az lock create --name no-borrar --lock-type CanNotDelete \
  --resource-group <rg-critico>

Aplicalos sobre grupos de recursos con datos, backups y recursos de recuperación. Y restringí quién puede quitar locks: si la misma identidad de la app puede borrarlos, pierden gran parte del valor.

4. Menos dependencia de claves de storage

El atacante terminó pidiendo claves de acceso con ListKeys. Si tus aplicaciones pueden autenticarse con Microsoft Entra ID, deshabilitar el acceso por clave compartida reduce ese riesgo:

az storage account update --name <cuenta> --resource-group <rg> \
  --allow-shared-key-access false

Probalo primero en un entorno no productivo: cualquier cliente que todavía use claves o SAS firmadas con clave va a dejar de funcionar.

5. Detectar borrados masivos

# Operaciones de borrado hechas por una identidad en los últimos 7 días
az monitor activity-log list --caller <appId> --offset 7d \
  --query "[?ends_with(operationName.value, '/delete')].{op:operationName.value, recurso:resourceId, fecha:eventTimestamp}" \
  -o table

Una alerta sobre ráfagas de operaciones delete o listKeys desde un service principal es barata y habría marcado esta secuencia.

6. Proteger la recuperación como parte del plan de ransomware

Microsoft recomienda restringir el acceso a los recursos de backup y recuperación y monitorear los intentos de modificar sus protecciones. El atacante apuntó a locks de Site Recovery y a cuentas con nombres relacionados con Terraform y backups: sabía qué buscar.

Qué hacer con esto

El componente "IA" del ataque acelera la ejecución, pero las defensas que funcionaron fueron las de siempre: mínimo privilegio, secretos bien gestionados y controles independientes de la identidad comprometida.

¿Sabés hoy cuántos service principals de tu organización tienen permisos para borrar recursos de producción?

Lecturas relacionadas

En video (Short de menos de 1 minuto): Nvidia lanza OpenShell para contener agentes de IA (el segundo tema es Storm-3168)

Fuentes

← Volver al blog