Entra ID (Azure AD):

el directorio de la nube y sus rutas de escalada

Seguridad en la nube / Identidad  |  unfantasmaenelsistema.com

En el artículo sobre el modelo de seguridad de Active Directory vimos que un dominio no cae por un exploit, sino por una cadena de permisos que nadie había mapeado. Entra ID —el servicio que Microsoft llamaba Azure AD hasta 2023— es el equivalente en la nube, y hereda ese mismo problema con una vuelta de tuerca: aquí no hay un controlador de dominio en tu sala de servidores, sino una API pública (Microsoft Graph) a la que se puede llegar desde cualquier navegador del mundo con las credenciales adecuadas.

Mucha gente asume que Entra ID es «Active Directory pero alojado en Azure». No lo es. No hay Kerberos, no hay LDAP clásico, no hay GPO. El modelo de identidad, de permisos y de ataque es distinto, y confundir uno con otro lleva a puntos ciegos serios. Este artículo explica en qué se parecen y en qué no, cuáles son los tres planos de permisos que hay que vigilar, y qué herramientas defensivas usar para auditar tu propio tenant.

1. Qué es Entra ID y en qué NO se parece a AD on-prem

Un tenant de Entra ID es una instancia del directorio dedicada a una organización, creada automáticamente en cuanto alguien contrata Microsoft 365 o Azure. Contiene los usuarios, los grupos, las aplicaciones registradas y las políticas de acceso. Todo se administra y se consulta a través de Microsoft Graph, una API REST accesible en graph.microsoft.com, y la autenticación se hace con OAuth 2.0 y OpenID Connect, emitiendo tokens JWT de acceso.

Esa es la diferencia de fondo. En AD on-prem, para atacar el directorio hay que estar dentro de la red y hablar con un controlador de dominio. En Entra ID, la superficie de autenticación (login.microsoftonline.com) y la de administración (Graph) están en internet por diseño. La primera línea de defensa deja de ser el perímetro de red y pasa a ser la identidad: MFA, Conditional Access y el principio de mínimo privilegio sobre los roles.

2. Los objetos: identidades humanas y no humanas

El grafo de Entra ID tiene menos tipos de nodo que el de AD, pero los que hay son densos en permisos. Conviene distinguirlos bien porque las rutas de escalada casi siempre pasan por las identidades no humanas, que son las que menos se revisan.

• Usuarios: cuentas de personas (miembros del tenant) o invitados B2B de otra organización. Los invitados suelen tener más permisos de lectura sobre el directorio de los que la gente espera
• Grupos: de seguridad o de Microsoft 365. Los grupos asignables a roles (isAssignableToRole) son especialmente sensibles: quien pueda modificar su pertenencia hereda el rol
• App registrations: la definición de una aplicación (su identidad, sus permisos solicitados, sus URIs de redirección). Vive en el tenant donde se creó
• Service principals: la instancia local de una aplicación dentro de tu tenant, con sus permisos concedidos y sus credenciales (secretos de cliente o certificados). Es el objeto que de verdad «actúa»
• Managed identities: un service principal gestionado por Azure y ligado a un recurso (una VM, una Function). Azure rota sus credenciales; el riesgo es qué permisos se le han dado y quién puede ejecutar código en ese recurso

3. Tres planos de permisos que se solapan

Esta es la parte que más cuesta a quien viene de on-prem. En Entra ID / Azure conviven tres sistemas de autorización distintos, con administradores distintos, y un fallo en cualquiera de ellos puede ser suficiente:

Los cruces peligrosos entre planos son conocidos. User Access Administrator o el permiso de elevación del Global Administrator permiten saltar del plano de Entra al plano de Azure RBAC sobre todas las suscripciones. Un service principal con RoleManagement.ReadWrite.Directory en Graph puede autoasignarse el rol de Global Administrator. Y Application Administrator o el rol propietario sobre una app permite añadirle una credencial nueva y autenticarse como esa app, heredando todo lo que ella tenga concedido. Ninguno de estos pasos es un exploit: son permisos funcionando como están documentados.

4. El consentimiento de aplicaciones y el «illicit consent grant»

Cuando una aplicación de terceros quiere leer tu correo o tu calendario, te redirige a una pantalla de Microsoft que pide tu consentimiento para unos permisos concretos (scopes). Si aceptas, se crea o se actualiza un objeto de concesión de permisos (oauth2PermissionGrant o appRoleAssignment) y la app recibe tokens para actuar en tu nombre —o, si son permisos de aplicación, en nombre de toda la organización.

El illicit consent grant es el abuso de ese mecanismo: en lugar de robar una contraseña, el atacante monta una aplicación con un nombre plausible y envía a la víctima un enlace de consentimiento legítimo de Microsoft. La víctima hace clic, aprueba «leer tu correo y enviar en tu nombre», y el atacante obtiene acceso persistente que sobrevive al cambio de contraseña y, según los scopes, al MFA, porque el token de refresco ya está emitido. Es una técnica de phishing que no toca la credencial.

5. Conditional Access: potente, pero con huecos clásicos

Conditional Access (CA) es el motor de decisión de acceso de Entra ID: un conjunto de políticas del tipo «si el usuario X accede a la aplicación Y desde una condición Z, entonces exige MFA / dispositivo conforme / bloquea». Bien hecho, es la columna vertebral de un despliegue Zero Trust. Mal hecho, da una falsa sensación de cobertura. Los huecos que más se repiten:

La recomendación de Microsoft es partir de las políticas de seguridad predeterminadas (security defaults) o de las plantillas de CA, y de ahí construir un juego mínimo: MFA para todos, MFA resistente a phishing para administradores, bloqueo de legacy auth, y bloqueo por geografía o riesgo. Enlaza bien con nuestros artículos de passkeys/FIDO2 y de Zero Trust.

6. Sincronización híbrida: el puente que va en los dos sentidos

Muchas organizaciones no son «solo nube»: tienen un AD on-prem y lo sincronizan con Entra ID mediante Entra Connect (antes Azure AD Connect) o el agente ligero Cloud Sync. Ese servidor de sincronización es uno de los activos más críticos del entorno, porque conecta los dos directorios y, según la configuración, puede ser una ruta de ataque en ambas direcciones:

• De on-prem a la nube: el servidor de Entra Connect tiene una cuenta en el tenant con permisos de sincronización de directorio muy amplios. Si se compromete el servidor, se accede a esa cuenta y a lo que puede tocar en Entra
• De la nube a on-prem: si está habilitado el Password Hash Sync, en el servidor residen materiales sensibles relacionados con las credenciales del dominio local; comprometerlo tiene impacto en el AD interno
• Pass-through Authentication y federación (ADFS): introducen sus propios objetivos —los agentes de PTA y, sobre todo, el certificado de firma de tokens de ADFS, cuyo robo permite falsificar tokens (el patrón del incidente Golden SAML / «Solorigate»)

7. Auditar tu propio tenant: herramientas defensivas

La buena noticia es que casi todo lo anterior se puede inventariar en modo lectura. Estas son las herramientas que un equipo defensivo debería pasar sobre su tenant de forma periódica:

Ejemplos de consultas de solo lectura con Microsoft Graph PowerShell para el inventario básico —quién tiene roles privilegiados y qué aplicaciones tienen permisos peligrosos concedidos:

# Requiere: Connect-MgGraph -Scopes 'RoleManagement.Read.Directory','Directory.Read.All','Application.Read.All'
 
# 1) Miembros de roles de directorio activos (p. ej. Global Administrator)
Get-MgDirectoryRole | ForEach-Object {
  $role = $_
  Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id |
    Select-Object @{n='Rol';e={$role.DisplayName}},
                  @{n='Miembro';e={$_.AdditionalProperties.userPrincipalName}}
}
 
# 2) Service principals con permisos de aplicacion de alto impacto en Graph
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id |
  Select-Object PrincipalDisplayName,
                @{n='Permiso';e={($graph.AppRoles | Where-Object Id -eq $_.AppRoleId).Value}}
 
# 3) Aplicaciones con secretos o certificados a punto de caducar (o ya caducados)
Get-MgApplication -All |
  Select-Object DisplayName,
                @{n='SecretExp';e={($_.PasswordCredentials.EndDateTime) -join ', '}},
                @{n='CertExp';e={($_.KeyCredentials.EndDateTime) -join ', '}}

Conclusión

Entra ID no es Active Directory movido a un centro de datos de Microsoft: es un directorio con una API pública, tres planos de permisos que se solapan y un mecanismo de consentimiento que el phishing sabe aprovechar sin tocar una sola contraseña. Los conceptos de AD que sí se conservan —mínimo privilegio, tiering, vigilar las identidades no humanas, tratar el puente híbrido como Tier 0— siguen siendo la guía correcta.

Para un equipo defensivo el trabajo es medible y casi todo de lectura: contar administradores globales, inventariar service principals y sus permisos de Graph, revisar exclusiones de Conditional Access y pasar una línea base como ScubaGear cada trimestre. Igual que en on-prem, la mayoría de las rutas de escalada se cierran quitando un permiso sobrante, no comprando un producto nuevo.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)