Concesión de consentimiento ilícita: apps OAuth en M365
Cómo detectar un consentimiento OAuth ilícito en el registro de auditoría unificado y en la auditoría de Entra, qué permisos importan y cómo quitar el acceso.
En resumen. En una concesión de consentimiento ilícita (illicit consent grant), un usuario pulsa Aceptar en una solicitud de consentimiento y la aplicación de un atacante obtiene acceso delegado a su buzón o a sus archivos, con sus propios tokens de actualización. Busque Consent to application (además de Add delegated permission grant, Add app role assignment to service principal, Add service principal) en el UAL o en la auditoría de Entra, lea ConsentAction.Permissions en busca de permisos como Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, offline_access y compruebe ConsentContext.IsAdminConsent. Ni el restablecimiento de la contraseña ni la MFA eliminan ese acceso; revocar la concesión, sí.
El phishing de consentimiento resulta atractivo porque se salta la contraseña por completo. La guía de Microsoft lo dice claro: las medidas de corrección habituales, como restablecer contraseñas o exigir MFA, no son eficaces contra este ataque porque la aplicación es externa a la organización (Microsoft Learn). En casos de BEC también lo veo como un segundo paso: el atacante, que ya está en el buzón gracias a una sesión robada, da consentimiento a una aplicación de «sincronización de correo» para mantener el acceso cuando se revoque la sesión. MITRE lo asocia a Steal Application Access Token (T1528).
Cómo es el rastro de auditoría
Un solo consentimiento suele producir varios registros en uno o dos segundos:
Operación (auditoría de Entra / UAL AzureActiveDirectory) | Significado |
|---|---|
Add service principal | La aplicación aparece en el tenant (primer consentimiento, sea de quien sea) |
Add delegated permission grant | Permisos delegados concedidos (un oauth2PermissionGrant) |
Add app role assignment to service principal | Permisos de aplicación concedidos (consentimiento de administrador) |
Consent to application | El propio consentimiento, con su contexto |
En el UAL, los nombres suelen terminar en punto (Consent to application.). Los detalles están en ModifiedProperties:
| Propiedad | Qué leer |
|---|---|
ConsentContext.IsAdminConsent | True: un administrador dio consentimiento para el tenant; Microsoft lo señala como posible concesión amplia |
ConsentContext.OnBehalfOfAll | True: consentimiento para todos los usuarios |
ConsentAction.Permissions | Los permisos, p. ej. Scope: Mail.ReadWrite Mail.Send offline_access User.Read, y ConsentType: Principal (un usuario) o AllPrincipals |
TargetId.ServicePrincipalNames | El ID de la aplicación |
| Nombre para mostrar del destino | El nombre de la aplicación, a menudo genérico («Mail Sync», «PDF Viewer», «Secure Docs») |
Anote también el actor, la IP y la hora. Un consentimiento desde la misma IP o sesión que un inicio de sesión reutilizado es actividad del atacante, aunque «el usuario» hiciera clic.
Permisos que deberían preocuparle
| Permiso | Por qué |
|---|---|
Mail.Read, Mail.ReadWrite | Leer (y modificar) el buzón a través de Graph |
Mail.Send | Enviar como el usuario: la carga útil del BEC |
MailboxSettings.ReadWrite | Crear reglas y reenvíos a través de la API |
Files.Read.All, Files.ReadWrite.All, Sites.Read.All | Todo lo que el usuario alcanza en OneDrive y SharePoint |
offline_access | Un token de actualización: acceso duradero sin el usuario |
full_access_as_user, EWS.AccessAsUser.All, IMAP.AccessAsUser.All | Acceso completo al buzón por protocolos heredados |
Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All | Toma del tenant si los concede un administrador |
User.Read solo (inicio de sesión y perfil) es normal en las aplicaciones de «Iniciar sesión con Microsoft». offline_access junto con cualquier permiso de correo, en una aplicación que nadie reconoce, no lo es.
Confirmar y delimitar
La guía de detección y corrección de Microsoft propone inventariar las concesiones por usuario (centro de administración de Entra → Users → el usuario → Applications), con PowerShell en todo el tenant o pidiendo a los usuarios que revisen sus aplicaciones en myapps.microsoft.com. Para la revisión, señala los consentimientos AllPrincipals de aplicaciones que no son de Microsoft, los permisos Read/Write/All, los usuarios de alto valor y los nombres de aplicación sospechosos.
Después delimite lo que hizo la aplicación. Su actividad se registra con la identidad de la aplicación: registros MailItemsAccessed con el AppId / ClientAppId de la aplicación, actividad de Graph si dispone de los registros de actividad de Microsoft Graph e inicios de sesión de la entidad de servicio. El aviso de CISA/FBI sobre la intrusión en Exchange Online de 2023 explica que fueron valores ClientAppID y AppID inesperados en registros MailItemsAccessed los que delataron la actividad (AA23-193A). Consulte MailItemsAccessed: qué demuestra.
Persistencia del lado de las aplicaciones
Los atacantes con derechos de administrador van más allá del consentimiento:
Add service principal credentials/Update application – Certificates and secrets management: un secreto o certificado añadido a una aplicación existente, que permite al atacante autenticarse como la aplicación (T1098.001).Add application: un nuevo registro de aplicación en el tenant.Add member to rolecon una aplicación como miembro: un rol privilegiado para la aplicación.
Todo ello sobrevive a los restablecimientos de contraseña del usuario y merece la misma revisión.
Cómo lo marca M365 Forensics
El analizador en el navegador tiene cuatro hallazgos relacionados:
| Hallazgo | Gravedad | Disparador |
|---|---|---|
| Consentimiento concedido a una aplicación con acceso al correo o a archivos | Alta | Consentimiento, concesión delegada o asignación de rol de aplicación cuyas propiedades incluyen un permiso de su lista de riesgo (Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, offline_access, full_access_as_user…) |
| Consentimiento concedido a una aplicación | Baja | Cualquier otro consentimiento: compruebe que es esperado |
| Credenciales añadidas a una aplicación | Alta | Secreto o certificado añadido a una aplicación o entidad de servicio |
| Nueva aplicación o entidad de servicio | Baja | Aplicación registrada o entidad de servicio añadida |
Si el consentimiento procede de la IP o la sesión de un inicio de sesión sospechoso, el hallazgo de correlación añade una «acción realizada desde la sesión del atacante» de nivel crítico. La lista de remediación incluye entonces Quitar la aplicación consentida y Restringir el consentimiento de los usuarios.
Remediación
- Revocar la concesión: en Entra, el usuario → Applications → la aplicación → Remove; o
Remove-MgOauth2PermissionGrantpara las concesiones delegadas yRemove-MgServicePrincipalAppRoleAssignmentpara las asignaciones de rol de aplicación (ambos citados en la guía de Microsoft). - Eliminar o deshabilitar la entidad de servicio si la aplicación no es legítima, para que nadie más pueda usarla.
- Revocar también las sesiones del usuario: el atacante que dio el consentimiento probablemente tenía una sesión.
- Restringir el consentimiento de los usuarios: permitir solo el consentimiento a editores verificados y permisos de bajo riesgo, y activar el flujo de consentimiento de administrador (configurar el consentimiento de los usuarios).
- Revisar credenciales, propietarios y roles de aplicaciones añadidos en el mismo periodo.
Preguntas frecuentes
¿Qué es una concesión de consentimiento ilícita?
Un ataque en el que se engaña a un usuario, o a un administrador, para que conceda a una aplicación controlada por el atacante acceso a sus datos, por ejemplo leer y enviar correo. La aplicación accede después a los datos con sus propios tokens, sin la contraseña del usuario.
¿Qué eventos de auditoría muestran un consentimiento?
Consent to application en el registro de auditoría unificado y en la auditoría de Entra, normalmente con Add delegated permission grant o Add app role assignment to service principal, y a menudo Add service principal cuando la aplicación es nueva en el tenant.
¿Restablecer la contraseña elimina el acceso de la aplicación?
No. El consentimiento y los tokens de actualización de la aplicación son independientes de la contraseña del usuario. Elimine la concesión de permisos y borre la entidad de servicio si la aplicación no es legítima.
Para saber más
- Microsoft Learn: Detectar y corregir concesiones de consentimiento ilícitas
- Guía de investigación de BEC en Microsoft 365
- Las aplicaciones OAuth también son una vía de persistencia en GitHub: githubforensics.com.