Microsoft 365 y Entra ID

Microsoft 365 (Exchange Online, SharePoint, Teams, OneDrive) y Entra ID (antes Azure AD) son la identidad y la productividad de la mayoría de las empresas. Comparten el mismo directorio que Azure (ver Pentesting Azure), así que comprometer M365 puede dar acceso a Azure y viceversa. Los vectores combinan ataques de identidad (phishing, spraying, consentimiento de apps) con abuso de las funciones de colaboración.

Qué es qué

Entra ID         directorio de identidades (usuarios, grupos, apps, roles)
M365 workloads   Exchange Online (correo), SharePoint/OneDrive (ficheros), Teams
# roles clave: Global Administrator (Entra) = control total del tenant

Recon sin credenciales

# ¿el dominio usa M365/Entra? y datos del tenant
https://login.microsoftonline.com/<dominio>/.well-known/openid-configuration
# enumeración de usuarios válidos y del tenant
o365spray --validate --domain target.com
AADInternals (Get-AADIntLoginInformation, tenant info)
# federación: ¿managed o federated? (afecta al ataque de auth)

Acceso inicial (identidad)

# password spraying contra endpoints de M365 (ver ad-spray)
o365spray --spray -U users.txt -P 'Verano2025!' --domain target.com
MFASweep       # ¿qué servicios NO exigen MFA? (brechas de MFA)
# credenciales filtradas (recon-personas/HIBP)
# illicit consent grant: app maliciosa que pide permisos -> el usuario consiente -> tokens

La ausencia de MFA en algún endpoint (o protocolos legacy que la saltan) es el hallazgo clave para el acceso inicial.

Post-compromiso de un usuario

# acceso al correo, ficheros, Teams de la víctima
# reglas de reenvío de correo (exfiltración sigilosa / BEC)
# búsqueda de secretos en correo/SharePoint/OneDrive (contraseñas, documentos)
# enumerar el tenant desde dentro (ROADrecon, AzureHound -> ver cloud-azure)
# phishing interno (desde una cuenta legítima, mayor confianza)

Escalada y puente a Azure

# de un usuario a roles privilegiados (ver cloud-azure):
# - app/Service Principal con permisos excesivos
# - consentimiento ilícito -> tokens de más usuarios
# - rol "Privileged Role Administrator" -> Global Admin
# - Global Admin puede elevarse a controlar las suscripciones Azure

Persistencia

# reglas de reenvío/inbox rules (BEC)
# añadir credenciales a un Service Principal / app con permisos
# registrar un dispositivo o método MFA propio en la cuenta víctima
# backdoors de federación (AADInternals) -> muy sigiloso, requiere Global Admin

Para la defensa

MFA en todo (Conditional Access), bloquear protocolos legacy (IMAP/POP/SMTP básico) que saltan MFA.
Bloquear consentimiento de usuario a apps; revisar apps/Service Principals y sus permisos.
PIM para roles privilegiados; mínimo de Global Admins; alertas de sign-in anómalo.
Detección: reglas de reenvío nuevas, consentimientos, sign-ins imposibles (Entra ID Protection, Defender for Office/Cloud Apps).
SPF/DKIM/DMARC (anti-spoofing, ver Enumeración de correos); formación anti-phishing.

Checklist de prueba

¿El dominio usa M365/Entra? info del tenant (openid-configuration)
Enumerar usuarios válidos (o365spray/AADInternals)
Password spraying contra M365 (Password Spraying)
MFASweep: endpoints sin MFA / protocolos legacy
Illicit consent grant (app maliciosa)
Post-compromiso: correo/ficheros/reglas de reenvío
Enumerar tenant y escalar a Global Admin (Pentesting Azure)
Puente a Azure y persistencia