Abuso de identidades administradas en Azure
Cómo abusan los atacantes de entidades de servicio e identidades administradas de Azure: secretos filtrados, robo de tokens IMDS, credenciales federadas.
En resumen. Las identidades no humanas son la mayoría silenciosa de los autores de llamadas en Azure y el disfraz favorito de los intrusos. Tres patrones: una entidad de servicio cuyo secreto se filtró (variables de CI/CD, un repositorio, un portátil) usada desde una IP nueva; un token de identidad administrada obtenido del Instance Metadata Service de la VM (169.254.169.254) y reutilizado desde otro sitio; y la persistencia mediante credenciales federadas, runbooks de Automation, Logic Apps o Functions que se ejecutan con una identidad privilegiada. En los logs, la claim xms_mirid identifica una identidad administrada, y «misma identidad, IP nueva» es la señal individual más fuerte que tienes.
Cuando reviso una suscripción comprometida, las cuentas humanas suelen ser fáciles: pocas, con horarios previsibles, MFA en las claims. Lo difícil son las decenas de identidades de aplicación que llaman a Azure Resource Manager todo el día. Ahí es donde se camuflan los atacantes.
Entidades de servicio e identidades administradas, vistas desde los logs
| Identidad | Qué es | Cómo aparece en las claims del Activity Log |
|---|---|---|
| Entidad de servicio (registro de aplicación) | Identidad de aplicación autenticada con un secreto de cliente, un certificado o una credencial federada | appid + object ID, a menudo idtyp: app; caller es un GUID |
| Identidad administrada | Entidad de servicio gestionada por Azure, vinculada a un recurso (asignada por el sistema) o independiente (asignada por el usuario) | Lo mismo, más xms_mirid = ID del recurso VM / aplicación / identidad al que pertenece |
| Usuario | Cuenta humana | UPN, nombre, amr (p. ej. pwd, mfa) |
El analizador Azure Forensics clasifica a los autores de esta forma (primero las claims, después principalType, después los autores con forma de GUID) y muestra el tipo en la pestaña Entidades. En los logs de Key Vault y de almacenamiento, las mismas claims aparecen en identity.claim e identity.requester.
Patrón 1: un secreto de entidad de servicio filtrado
El acceso inicial ocurre fuera de Azure: un secreto subido a un repositorio, impreso en un log de CI o robado del equipo de un desarrollador. Microsoft Entra ID ve el inicio de sesión (registros de inicio de sesión de entidades de servicio); Azure ve lo que viene después.
Señales en los logs de Azure:
- La entidad llama a ARM desde una IP que nunca había usado. Los runners de CI tienen un conjunto pequeño y estable de IP o un rango cloud conocido; el VPS de un atacante no es ninguna de las dos cosas.
- La entidad hace algo que nunca había hecho: asignaciones de roles, Run Command,
listKeys, cambios de directivas de acceso. - El momento: las entidades de despliegue actúan cuando se ejecutan las canalizaciones. Una ráfaga a las 02:14 de un domingo sin ninguna ejecución de canalización es reveladora.
MITRE ATT&CK: T1078.004 Cloud Accounts. Cómo se filtró el secreto, y si se añadieron nuevos secretos a la aplicación (T1098.001 Additional Cloud Credentials), queda en el registro de auditoría de Entra ID, que analiza la herramienta hermana m365forensics.com.
Patrón 2: robo de tokens de identidad administrada mediante IMDS
Cualquier proceso de una VM puede pedir al Instance Metadata Service un token de la identidad administrada de la VM:
GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/
Metadata: true
Microsoft describe el límite de seguridad sin rodeos: todo código o script que se ejecute en una máquina virtual puede solicitar y obtener tokens de cualquier identidad administrada disponible en ella (usar identidades administradas en una VM para obtener un token de acceso). El encabezado Metadata es una mitigación frente a SSRF, no un control de autorización.
Así, la ejecución de código en una VM, mediante Run Command, una web shell o un SSRF capaz de fijar encabezados, se convierte en una identidad cloud. El atacante copia el token de portador y lo usa desde su propia máquina hasta que caduca (T1528 Steal Application Access Token).
La señal es sencilla y potente: una identidad administrada usada desde una IP que no es la de su host. La identidad administrada de una VM llega normalmente a Key Vault y al almacenamiento desde la IP privada de la VM (mediante un punto de conexión de servicio o privado) o desde una IP pública de salida estable. El mismo object ID apareciendo con una dirección residencial o de VPS, y un user agent curl, es reutilización de tokens.
Patrón 3: persistencia a través de identidades
Con una identidad privilegiada en la mano, el atacante quiere otra que sobreviva a los cambios de contraseña y a la rotación de secretos:
| Persistencia | Operación en el Activity Log | MITRE |
|---|---|---|
| Credencial federada en una identidad administrada asignada por el usuario (permite a un IdP externo obtener tokens para ella) | Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write | T1098.001 |
| Runbook o webhook de Automation, ejecutado con la identidad de la cuenta de Automation | Microsoft.Automation/automationAccounts/runbooks/write, …/webhooks/write, …/jobs/write | T1648 |
| Código de Logic App o de Function modificado | Microsoft.Logic/workflows/write, Microsoft.Web/sites/functions/write, claves de función escritas | T1648 |
| Nuevo secreto o certificado en un registro de aplicación | Registro de auditoría de Entra ID, no el Activity Log | T1098.001 |
Las credenciales federadas son legítimas y habituales (GitHub Actions, identidad de carga de trabajo de AKS). La pregunta es siempre la misma: qué emisor y qué sujeto, quién los creó y si alguien se hace responsable.
Qué marca el analizador
| Regla | Detecta | Nivel |
|---|---|---|
AZ-ID-001 | Entidad de servicio que llama a ARM desde una IP no vista durante el periodo de aprendizaje de 72 horas | Medio |
AZ-ID-002 | Identidad administrada usada desde una IP nueva: Activity Log, Key Vault o almacenamiento | Alto |
AZ-RBAC-002 | Entidad de servicio o identidad administrada que recibe Owner, Contributor o un rol de gestión de accesos | Alto |
AZ-PER-001 | Runbook, webhook o trabajo de Automation creado | Medio |
AZ-PER-002 | Código de Logic App o Function modificado | Bajo |
AZ-PER-003 | Credencial federada añadida a una identidad administrada | Alto |
Las reglas de «IP nueva» necesitan historial: con menos de 72 horas de logs antes de la actividad sospechosa no pueden ejecutarse, y el bloque de cobertura lo indica. Falsos positivos conocidos: runners de CI con IP cambiantes, VM redesplegadas con una IP privada nueva.
Lista de triaje
- Enumera cada identidad no humana con un hallazgo en la pestaña Entidades y abre sus eventos.
- Establece la referencia de cada una: IP, operaciones y horarios habituales. La primera desviación marca el inicio de tu cronología.
- En una identidad administrada: ¿a qué recurso está vinculada (
xms_mirid)? ¿Hubo ejecución de código en ese recurso poco antes (Run Command, extensión, despliegue)? - En una entidad de servicio: ¿cuándo se añadió su última credencial y quién lo hizo? (Registro de auditoría de Entra.)
- ¿Qué tocó? Lecturas de Key Vault, lecturas de almacenamiento, asignaciones de roles. Cada una abre una nueva rama de la investigación.
Remediación
- Rota los secretos y certificados de las entidades de servicio comprometidas; elimina las credenciales que no tengan responsable.
- Una identidad administrada no tiene secreto que rotar. Contén el host (aísla y reconstruye la VM) y reduce las asignaciones de roles de la identidad. Los tokens de acceso ya robados siguen siendo válidos hasta que caducan, así que vigila durante un tiempo la actividad de la identidad desde IP ajenas, y rota los secretos que podía leer.
- Elimina credenciales federadas, runbooks y webhooks desconocidos.
- Reduce privilegios: nada de Contributor en toda la suscripción para la identidad de una aplicación web.