Abuso de asignaciones de roles en Azure y elevateAccess
Cómo escalan los atacantes con asignaciones de roles de Azure y elevateAccess, cómo son los eventos roleAssignments/write en el Activity Log y cómo priorizar.
En resumen. La escalada de privilegios en Azure es, sobre todo, una operación: Microsoft.Authorization/roleAssignments/write. Lo que la hace sospechosa es el rol (Owner, User Access Administrator, Role Based Access Control Administrator, o Contributor concedido a una identidad no humana), el autor (una entidad de servicio, o una entidad que se asigna un rol a sí misma) y el ámbito (suscripción o raíz). La versión nuclear es Microsoft.Authorization/elevateAccess/action: un Administrador global se concede User Access Administrator en el ámbito raíz /, sobre todas las suscripciones. Ese evento se escribe en el log de nivel de tenant, así que una exportación de suscripción no lo muestra.
Las asignaciones de roles son la columna vertebral de la autorización en Azure y, por tanto, lo primero que un intruso con algo de acceso intenta ampliar. También son administración rutinaria, por eso una lista en bruto de eventos roleAssignments/write no sirve de nada. Este artículo trata de distinguir una cosa de la otra.
Cómo funciona la escalada con Azure RBAC
Una asignación de roles une tres elementos: una entidad de seguridad, una definición de rol y un ámbito. Quien tenga Microsoft.Authorization/roleAssignments/write en un ámbito puede crear asignaciones en él. Entre los roles integrados, eso incluye Owner, User Access Administrator y Role Based Access Control Administrator.
Rutas de escalada que veo con frecuencia:
| Punto de partida | Escalada | Por qué funciona |
|---|---|---|
| Secreto filtrado de una entidad de servicio de CI/CD a la que se dio User Access Administrator «para desplegar asignaciones de roles» | Se concede Contributor u Owner en la suscripción | Automatización con privilegios excesivos |
| Administrador global comprometido en Entra ID | elevateAccess → User Access Administrator en / → Owner en cualquier suscripción | Entra y Azure RBAC están separados, pero los Administradores globales pueden tender un puente |
| Contributor en un Key Vault con directivas de acceso | Se añade a la directiva de acceso del almacén | No es RBAC, pero la idea es la misma: ver el artículo de Key Vault |
| Owner de una cuenta de Automation o de una VM con una identidad administrada privilegiada | Ejecuta código como esa identidad | Tratado en abuso de identidades administradas |
MITRE ATT&CK registra la concesión como T1098.003 Additional Cloud Roles y el uso de identidades cloud legítimas como T1078.004 Cloud Accounts.
Qué es elevateAccess y dónde se registra
La elevación de acceso es una función documentada y legítima: un Administrador global de Microsoft Entra ID puede activar «Access management for Azure resources» y recibir el rol User Access Administrator en el ámbito raíz /. Desde ahí puede asignarse cualquier rol en cualquier suscripción y grupo de administración del tenant. Microsoft recomienda retirar ese acceso en cuanto termine la tarea (elevar el acceso para administrar todas las suscripciones de Azure).
La trampa forense está en dónde se registra. Según la misma página, las entradas de elevación de acceso aparecen en los registros de auditoría del directorio de Microsoft Entra (servicio «Azure RBAC (Elevated Access)», en versión preliminar en el momento de escribir esto) y en la vista Directory Activity del Activity Log, es decir, el log de nivel de tenant. La operación es Microsoft.Authorization/elevateAccess/action con ámbito /providers/Microsoft.Authorization. Un az monitor activity-log list por suscripción no la devuelve. Exporta el nivel de tenant con az rest como se explica en la guía de exportación.
No es una ruta exótica. El análisis de Microsoft sobre Storm-0501 describe cómo el actor usó elevateAccess/action para obtener User Access Administrator y después roleAssignments/write para hacerse con Owner en las suscripciones.
Leer un evento roleAssignments/write
En el esquema REST / CLI, los detalles que necesitas están repartidos entre el evento y el cuerpo de la solicitud:
| Campo | Dónde | Por qué importa |
|---|---|---|
caller y claims | Evento | Quién creó la asignación. Un autor con forma de GUID y claim appid es una entidad de servicio; una claim xms_mirid indica una identidad administrada |
httpRequest.clientIpAddress | Evento | Desde dónde llegó la llamada |
properties.requestbody → PrincipalId, RoleDefinitionId, Scope | Cuerpo de la solicitud | Quién recibió qué rol y dónde |
authorization.evidence.role | Esquema de logs de recursos | Qué rol permitió al autor hacerlo |
status.value | Evento | Started / Succeeded / Failed: los fallos también interesan |
RoleDefinitionId es un GUID. Los identificadores de los roles integrados son fijos y están documentados en roles integrados de Azure; por ejemplo, Owner es 8e3af657-a8ff-443c-a75c-2fe8c4bcb635, Contributor b24988ac-6180-42a0-ab88-20f7382dd24c y User Access Administrator 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9.
Dos señales baratas pero potentes:
- El autor se asigna un rol a sí mismo. Compara el object ID del autor con
PrincipalIden el cuerpo de la solicitud. Algunos scripts de arranque legítimos lo hacen de vez en cuando; los atacantes, constantemente. - El destinatario no es humano y el rol es amplio. Una entidad de servicio o identidad administrada que recibe Owner o Contributor sobre toda una suscripción merece un responsable y un número de ticket.
Qué marca el analizador
El analizador Azure Forensics implementa cuatro reglas de RBAC, todas sobre el Activity Log:
| Regla | Detecta | Nivel |
|---|---|---|
AZ-RBAC-001 | Asignación de Owner, User Access Administrator o Role Based Access Control Administrator | Medio |
AZ-RBAC-002 | Entidad de servicio o identidad administrada que recibe Owner, Contributor o un rol de gestión de accesos | Alto |
AZ-RBAC-003 | Entidad que se asigna un rol a sí misma (object ID del autor = destinatario) | Alto |
AZ-RBAC-004 | elevateAccess/action: un Administrador global se eleva al ámbito raíz | Alto |
Combínalas con AZ-ID-001 (entidad de servicio usada desde una IP nueva) y la cadena suele leerse sola: IP nueva → autoasignación → lo que venga después.
Lista de triaje
Para cada asignación marcada:
- ¿Hay un ticket de cambio? Pregunta al equipo de plataforma antes de dar nada por hecho; muchas asignaciones «sospechosas» son arreglos de viernes por la tarde.
- ¿Quién es el autor y es su comportamiento habitual? Pivota sobre el autor en la pestaña Entidades. Una entidad de despliegue que nunca había asignado roles es una señal fuerte.
- ¿Desde qué IP? Compárala con las IP de referencia del autor. Los runners de CI cambian de IP; los atacantes cambian de IP y de horario.
- ¿Qué pasó después con los nuevos permisos? Revisa la hora siguiente de eventos del destinatario. Un rol que nadie usa es un error; un rol usado en minutos para ejecutar comandos o leer secretos es un ataque.
- ¿Se eliminó? A veces los atacantes limpian con
roleAssignments/delete. La eliminación también queda registrada. - Para
elevateAccess: ¿qué Administrador global, desde qué inicio de sesión? Es una cuestión de Entra ID para m365forensics.com.
Remediación
- Elimina las asignaciones creadas durante el incidente (
az role assignment delete) y revisa quién tiene Owner y User Access Administrator en cada ámbito. - Retira la asignación de User Access Administrator en
/creada por la elevación de acceso; Microsoft documenta tanto el interruptor del portal como la eliminación por CLI / REST. - Rota las credenciales de cualquier entidad de servicio que haya creado o recibido una asignación sospechosa.
- Reduce los privilegios permanentes: nada de User Access Administrator para identidades de CI/CD; valora Privileged Identity Management para las personas.