Apps OAuth peligrosas: cómo auditar los consentimientos en Entra ID

Qué es un consentimiento OAuth

Cuando una aplicación de terceros quiere acceder a datos de Microsoft 365 (el correo, el calendario, OneDrive), Microsoft muestra una pantalla de consentimiento con los permisos que pide. Si el usuario acepta, la aplicación recibe acceso en su nombre sin conocer su contraseña.

Hay dos tipos:

• Consentimiento de usuario: un usuario concede permisos solo para sus propios datos.
• Consentimiento de administrador: un administrador concede permisos en nombre de toda la organización. Los permisos de aplicación (los que no dependen de un usuario) siempre lo requieren.

Es un mecanismo legítimo y necesario: así funcionan las integraciones con CRM, herramientas de firma o calendarios. El problema es cuando la aplicación es maliciosa.

El phishing de consentimiento

En un ataque de phishing de consentimiento (illicit consent grant), el atacante registra una aplicación con un nombre creíble, como "Visor de documentos" o "PDF Online", y envía al usuario un enlace a la página de consentimiento real de Microsoft. No hay web falsa que detectar ni contraseña que robar.

Si el usuario acepta permisos como Mail.Read o Files.ReadWrite.All, la aplicación puede leer su correo o sus archivos de forma continuada. Y aquí está lo grave:

• El MFA no lo frena: el propio usuario ha autorizado el acceso tras iniciar sesión correctamente.
• Cambiar la contraseña no basta: el consentimiento sigue existiendo hasta que se revoca expresamente.
• Pasa desapercibido: no hay inicios de sesión sospechosos del usuario, solo una aplicación usando la API de Graph.

Qué permisos son peligrosos

No todos los consentimientos son un riesgo. User.Read, openid, profile o email solo permiten identificar al usuario. Los que deben hacer saltar las alarmas son:

• Correo: Mail.Read, Mail.ReadWrite, Mail.Send y MailboxSettings.ReadWrite (este último permite crear reglas de reenvío).
• Archivos: Files.Read.All, Files.ReadWrite.All, Sites.ReadWrite.All.
• Directorio: Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, RoleManagement.ReadWrite.Directory.
• Contactos y calendario: Contacts.Read, Calendars.ReadWrite, útiles para preparar nuevos ataques de phishing.

El permiso offline_access no da acceso a datos por sí solo, pero permite a la aplicación seguir funcionando sin que el usuario vuelva a iniciar sesión.

Cómo auditar los consentimientos

Desde el centro de administración de Entra

En Aplicaciones empresariales > Todas las aplicaciones tienes todas las aplicaciones con acceso a tu tenant. Dentro de cada una, la pestaña Permisos separa los permisos concedidos por un administrador de los concedidos por usuarios. Es útil para revisar una aplicación concreta, pero lento para auditar decenas.

En los registros de auditoría de Entra ID, la actividad "Consent to application" muestra cada consentimiento con la fecha, el usuario y la aplicación. Revisa los de los últimos meses.

Con PowerShell (Microsoft Graph)

Con el módulo Microsoft.Graph y Connect-MgGraph -Scopes Directory.Read.All, lista todos los consentimientos de usuario con sus permisos:

Comando: Get-MgOauth2PermissionGrant -All | Where-Object { $_.ConsentType -eq "Principal" } | Select-Object ClientId, PrincipalId, Scope

El campo ClientId es el identificador de la aplicación (service principal) y PrincipalId el del usuario que consintió. Para los consentimientos de administrador, cambia "Principal" por "AllPrincipals".

Señales de una aplicación sospechosa

• Editor no verificado o desconocido, sobre todo si pide permisos de correo o archivos.
• Nombre genérico o que imita a Microsoft: "Office Viewer", "Microsoft Docs Update", "Secure PDF".
• Pocos usuarios: una aplicación consentida por uno o dos usuarios, justo después de una campaña de correo sospechosa.
• Permisos desproporcionados: un "visor de PDF" que pide Mail.ReadWrite y offline_access.
• Usuarios que consienten de todo: alguien con cinco o más aplicaciones consentidas es un buen candidato a formación.

Cómo limitar los consentimientos

1. Restringe el consentimiento de usuario: en Aplicaciones empresariales > Consentimiento y permisos, elige permitir el consentimiento solo para aplicaciones de editores verificados y para permisos clasificados como de bajo impacto. En entornos muy sensibles, desactívalo por completo.

2. Clasifica los permisos de bajo impacto: marca como bajo impacto los que solo identifican al usuario (openid, profile, email, User.Read, offline_access). El resto pasará a necesitar aprobación.

3. Activa el flujo de solicitud de consentimiento de administrador: cuando un usuario necesite una aplicación que no puede consentir, la solicita y un administrador la revisa. Evita que la restricción se convierta en un bloqueo para el negocio.

4. Revisa periódicamente: los consentimientos antiguos se acumulan. Revoca los de aplicaciones que ya no se usan.

Qué hacer si encuentras una aplicación maliciosa

1. Deshabilita el inicio de sesión de la aplicación: en sus propiedades, desactiva "¿Habilitado para que los usuarios inicien sesión?". Corta el acceso de inmediato y conserva la información para investigar.

2. Revoca los consentimientos: elimina los permisos concedidos, o los grants con Remove-MgOauth2PermissionGrant.

3. Revoca las sesiones de los usuarios afectados y revisa si la aplicación ha creado reglas de bandeja de entrada (ver cómo detectar reglas de reenvío a externos).

4. Investiga el alcance: revisa a qué datos tenía acceso y desde cuándo, y valora si debes notificar el incidente.

Cómo lo revisa 365toControl

365toControl analiza todos los consentimientos delegados del tenant, separa los de administrador de los de usuario y clasifica cada permiso por riesgo. Te avisa de las aplicaciones con permisos críticos o altos consentidos por usuarios, de las aplicaciones de editores no verificados con consentimientos de usuario, de los usuarios que han consentido cinco o más aplicaciones y de los tenants donde los consentimientos de usuario superan con mucho a los de administrador, señal de que falta el flujo de aprobación.