OAuth Consent Phishing: cómo las aplicaciones maliciosas evitan el robo de contraseñas

OAuth consent phishing es un ataque de identidad en el que un usuario o administrador es engañado para conceder permisos a una aplicación OAuth maliciosa. Después de aprobar el consentimiento, el atacante no necesita necesariamente la contraseña del usuario. La aplicación puede acceder a Microsoft 365 u otros recursos protegidos según los permisos concedidos, lo que convierte este escenario en algo distinto del phishing de credenciales, el password spraying o la fatiga de MFA.

El alcance de este artículo es Microsoft Entra ID, Microsoft 365 y el consentimiento de aplicaciones basado en OAuth. No toda autenticación maliciosa es consent phishing. El foco está en el grant de consentimiento: qué recibe la aplicación, cómo pueden verlo los defensores, cómo eliminarlo y cómo impedir que el mismo camino vuelva a aparecer.

¿Qué es OAuth Consent Phishing?

OAuth consent phishing abusa de un modelo legítimo de consentimiento. Microsoft describe el consent phishing como ataques que engañan a los usuarios para conceder permisos a aplicaciones cloud maliciosas. La pantalla de consentimiento muestra los permisos que recibirá la aplicación, pero un nombre creíble, un logotipo familiar o un pretexto de negocio convincente todavía pueden llevar a un usuario o administrador a aprobar un acceso que no debería concederse.

En Microsoft identity platform, OAuth permite que una aplicación solicite acceso a un recurso protegido. RFC 6749 define OAuth 2.0 como un framework que permite a una aplicación de terceros obtener acceso limitado a un servicio HTTP, ya sea en nombre del propietario del recurso o en nombre propio. Microsoft Entra ID implementa ese modelo para recursos como Microsoft Graph, Exchange Online, SharePoint Online y otras API integradas con la plataforma de identidad de Microsoft.

Límites de alcance

El punto clave para defensa es que el consent phishing ataca la autorización, no solo la autenticación. En un incidente de phishing de contraseña, el equipo suele preguntar si se robaron credenciales, si se completó MFA y si existe una sesión sospechosa. En OAuth consent phishing también hay que preguntar si una aplicación recibió un permission grant duradero que sigue siendo relevante después de la sesión interactiva inicial.

El riesgo está cerca del descrito en Azure App Registrations: Over-Privileged Tenant Apps, pero el camino de ataque es distinto. Las aplicaciones legítimas con demasiados privilegios suelen ser un problema de gobernanza interna. OAuth consent phishing es una aplicación maliciosa o engañosa que obtiene acceso mediante una pantalla de consentimiento.

Cómo funciona OAuth Consent Phishing

La cadena de ataque comienza con una solicitud normal de autorización OAuth. Un usuario sigue un enlace o abre una aplicación que lo envía a Microsoft identity platform. El usuario se autentica si es necesario. Si los permisos solicitados todavía no tienen consentimiento, Microsoft Entra muestra un prompt de consentimiento. Ese prompt incluye los permisos solicitados y la información del editor.

Estado de consentimiento, no solo estado de inicio de sesión

Si el usuario o administrador aprueba la solicitud, Microsoft Entra registra un grant para la aplicación. Para permisos delegados de Microsoft Graph, el resultado del consentimiento se representa como OAuth2PermissionGrant. Para permisos de aplicación, el resultado se representa como appRoleAssignment. Estos dos objetos importan porque son los que los defensores deben enumerar, revisar y eliminar durante la limpieza.

Una aplicación maliciosa no necesita pedir todos los permisos de una vez. Microsoft documenta el consentimiento dinámico como un caso en el que una aplicación solicita nuevos permisos durante la ejecución. Por eso la revisión de consentimientos no debe ser solo un control de onboarding. Un tenant puede estar limpio en una revisión inicial y recibir más tarde una solicitud de acceso más amplia si la aplicación está diseñada para pedir scopes adicionales.

Matiz sobre offline_access

El scope offline_access también cambia el modelo de defensa. Microsoft documenta offline_access como acceso a recursos en nombre del usuario durante un tiempo extendido. En la página de consentimiento, esta capacidad aparece como mantener acceso a los datos a los que la aplicación ya recibió acceso. Microsoft también indica que, si se concede cualquier permiso delegado, offline_access se concede implícitamente, y que los refresh tokens son de larga duración. Esto no significa que el atacante tenga acceso permanente. Significa que la respuesta a incidentes debe incluir eliminación de grants y limpieza de tokens o sesiones, no solo restablecimiento de contraseña.

Por eso OAuth consent phishing está cerca, pero no dentro, de otros ataques de identidad en Entra. Device Code Phishing: How OAuth Device Flow Compromises Entra ID Accounts abusa de otro flujo OAuth. Ambos ataques giran alrededor de OAuth, pero device code phishing autoriza una sesión mediante el device code flow, mientras que consent phishing concede permisos a una aplicación.

Permisos delegados vs permisos de aplicación

La separación técnica más importante es entre permisos delegados y permisos de aplicación.

Acceso delegado

Los permisos delegados se usan cuando una aplicación actúa en nombre de un usuario conectado. Microsoft los describe como permisos que permiten a una aplicación actuar en nombre del usuario, sin poder acceder a nada que el usuario conectado no pudiera acceder. Si un usuario concede un permiso delegado para leer correo, el acceso de la aplicación depende de lo que ese usuario pueda leer. Si un administrador privilegiado concede permisos delegados mientras está conectado, el impacto puede ser mucho mayor porque los privilegios del usuario son mayores.

Acceso app-only

Los permisos de aplicación, también llamados app roles o permisos app-only, se usan cuando no hay un usuario conectado. Microsoft describe el acceso app-only como una aplicación que actúa con su propia identidad. Los permisos de aplicación pueden permitir amplio acceso a datos del tenant mediante Microsoft Graph u otra API de recurso. Microsoft indica que, en general, solo un administrador o el propietario del service principal de una API puede consentir a los permisos de aplicación expuestos por esa API.

Triage por tipo de permiso

La distinción guía la prioridad de investigación. Un grant delegado sospechoso de un usuario con pocos privilegios puede exponer su buzón, archivos o recursos accesibles. Un permiso de aplicación sospechoso puede ser tenant-wide, según el permiso y la API de recurso. Microsoft usa Files.Read.All para ilustrar la diferencia: Files.Read.All delegado permite a la app leer archivos a los que el usuario puede acceder personalmente, mientras que Files.Read.All como permiso de aplicación puede leer cualquier archivo del tenant mediante Microsoft Graph una vez concedido.

No conviene mezclar ambos casos bajo un riesgo genérico de aplicación OAuth. El objeto de limpieza, el blast radius, el camino de aprobación y la validación son distintos.

Por qué MFA no detiene por sí sola el abuso de consentimiento

MFA sigue siendo importante. Reduce la probabilidad de que un atacante pueda iniciar sesión como usuario, aprobar prompts como ese usuario o completar otras acciones interactivas. El problema es más específico: MFA no vuelve automáticamente inofensivo un permiso OAuth ya concedido.

Cuando una aplicación maliciosa tiene un grant delegado válido, puede solicitar tokens según ese grant y el contexto usuario/recurso. Cuando una aplicación tiene permisos de aplicación, puede operar sin usuario conectado para los datos cubiertos por esos permisos. Conditional Access y las políticas MFA pueden seguir afectando cómo se emiten tokens en escenarios concretos, pero la existencia del consent grant debe investigarse directamente.

Es la misma lección general de Azure Identity Security: Why MFA Alone Is Not Enough. MFA es un control. No sustituye la gobernanza de app consent, la revisión de permisos, la monitorización de audit logs, la evaluación del publisher ni la revocación de grants sospechosos. Si tu equipo también sigue ingeniería social basada en notificaciones push, MFA Fatigue: Detection and Prevention for Microsoft Entra ID cubre un patrón separado que puede aparecer antes o junto al abuso de consentimiento.

El error práctico es cerrar el incidente después de restablecer una contraseña o confirmar que MFA estaba habilitado. En un caso de consent phishing, eso es incompleto. La respuesta debe responder si existe un service principal, qué grants tiene asociados, qué usuarios dieron consentimiento, si hubo admin consent y si la aplicación fue deshabilitada, eliminada o bloqueada para recibir nuevos grants.

La cadena de ataque

Una cadena realista de OAuth consent phishing tiene varias fases. El señuelo exacto puede variar, pero los puntos de control son consistentes.

1. El atacante prepara o controla una aplicación que puede solicitar permisos de Microsoft identity platform.
2. Un usuario o administrador recibe una URL de autorización que muestra una experiencia de inicio de sesión y consentimiento alojada por Microsoft.
3. El consent prompt lista permisos e información del publisher. El usuario o administrador aprueba la solicitud.
4. Microsoft Entra registra el grant. Los permisos delegados aparecen como OAuth2PermissionGrant; los permisos de aplicación aparecen como appRoleAssignment.
5. La app usa access tokens, y potencialmente refresh tokens cuando están disponibles, para llamar API como Microsoft Graph según los permisos concedidos.
6. El atacante conserva acceso hasta que los defensores revocan grants, deshabilitan o eliminan el service principal malicioso cuando corresponde, bloquean el re-consentimiento, invalidan sesiones/tokens relevantes o Microsoft deshabilita una aplicación que viola sus condiciones de servicio.

Lo que no es

Esta cadena no es password spraying, donde el atacante prueba credenciales contra muchas cuentas. No es Kerberoasting, donde el objetivo es material de tickets de servicio Kerberos en Active Directory. Tampoco es OAuth device code phishing normal, donde el atacante convence al usuario de completar una autorización por device code. Estas diferencias importan porque la telemetría y la remediación cambian.

Para defensa, el objetivo de la cadena es identificar estado duradero. Un inicio de sesión sospechoso se investiga con sign-in logs. Un grant de consentimiento sospechoso se investiga con objetos de aplicación, permission grants, audit logs y controles de app governance.

Detección

Ningún evento único de Microsoft Entra prueba OAuth consent phishing por sí solo. Un administrador legítimo puede consentir a una aplicación legítima. Un usuario legítimo puede aprobar un permiso delegado de bajo riesgo. La detección requiere correlacionar actividad de consentimiento, metadatos de app, permisos, contexto de usuario y comportamiento API posterior.

Pivots en audit logs

Empieza con los audit logs de Microsoft Entra. Microsoft documenta estas actividades de permisos de aplicación en el servicio Core Directory y la categoría ApplicationManagement:

Preguntas de correlación

Usa estos eventos como pivots, no como veredictos finales. Una detección útil pregunta:

• ¿La app fue añadida recientemente al tenant?
• ¿El publisher está verificado y coincide con el propósito de negocio?
• ¿Qué permisos se pidieron, y son permisos de bajo riesgo o de alto impacto sobre datos?
• ¿El actor era usuario normal, admin, cuenta break-glass o una cuenta fuera de su comportamiento normal?
• ¿El consentimiento ocurrió poco después de un sign-in sospechoso, señal de impossible travel, risky user o reporte de phishing?
• ¿La aplicación empezó a llamar Microsoft Graph, Exchange, SharePoint u otras API de forma incompatible con un workflow aprobado?
• ¿Varios usuarios autorizaron la misma aplicación poco común?

Defender for Cloud Apps puede añadir otra capa si está disponible. Microsoft documenta OAuth app policies que pueden alertar sobre aplicaciones con alto nivel de permisos, muchos usuarios autorizadores, uso poco común, nombres engañosos, nombres de publisher engañosos o consentimiento OAuth potencialmente malicioso. Trata esas alertas como señales de priorización y revisa igualmente el service principal y los grants subyacentes.

Una detección madura también vigila la deriva de gobernanza. Si se relajan los user consent settings, cambian las app consent policies o se eliminan reviewers del admin consent workflow, el tenant se vuelve más fácil de abusar. Esos cambios no prueban por sí solos una app maliciosa, pero reducen la fuerza de control sobre futuras solicitudes de consentimiento. Combina este monitoreo con How to Audit Microsoft Entra ID Security para revisar app consent junto con Conditional Access, roles privilegiados, usuarios de riesgo y configuración tenant-wide.

En investigaciones híbridas, mantén clara la frontera: este artículo se centra en actividad de auditoría Entra, pero Active Directory Monitoring: Security Event IDs That Matter puede ayudar a correlacionar actividad de identidad on-premises cuando el mismo usuario o administrador está implicado.

Remediación

La remediación tiene dos líneas: eliminar el acceso malicioso confirmado y cerrar el camino de consentimiento que lo permitió.

Eliminar grants existentes

Primero identifica el objeto de aplicación y el service principal en Enterprise Applications. Revisa las pestañas Admin consent y User consent para ver permisos concedidos. Microsoft documenta que los administradores pueden revocar permisos de toda la organización en la pestaña Admin consent, mientras que los grants de user consent pueden requerir Microsoft Graph API o PowerShell. Para limpieza completa, enumera tanto permisos delegados como permisos de aplicación.

Para permisos delegados, elimina objetos OAuth2PermissionGrant sospechosos. Para permisos de aplicación, elimina entradas appRoleAssignment sospechosas. La documentación de Microsoft sobre revisión de permisos ofrece rutas Graph y PowerShell para ambos casos. Si usuarios o grupos estaban asignados a la aplicación, revísalos y elimínalos como parte de la contención.

Contener el service principal

Después deshabilita o elimina el service principal cuando la aplicación esté confirmada como maliciosa o no autorizada. Ten cuidado con aplicaciones que tienen uso sospechoso y legítimo al mismo tiempo; eliminar un service principal puede romper workflows de negocio. Si Microsoft deshabilita una aplicación OAuth por violar condiciones de servicio, Microsoft documenta que nuevas solicitudes de token y refresh token son denegadas, pero los access tokens existentes siguen siendo válidos hasta expirar. Por eso la respuesta no debe depender de una sola acción.

Luego trata tokens y sesiones. Para abuso delegado, revoca refresh tokens o invalida sesiones de usuario cuando corresponda. Para abuso app-only, céntrate en eliminar app role assignments, retirar credenciales del service principal si es propiedad del tenant, deshabilitar el service principal y validar que no queda ningún grant app-only. Restablecer contraseña puede ser relevante si el usuario también fue phished, pero no elimina un grant OAuth por sí solo.

Endurecer consentimientos futuros

Finalmente endurece la gobernanza del consentimiento:

• Revisa user consent settings y evita consentimiento amplio de usuarios para aplicaciones y permisos que deberían requerir revisión admin.
• Usa app consent policies para restringir a qué pueden consentir los usuarios según criterios como verified publisher y riesgo de permisos.
• Habilita y configura admin consent workflow para que los usuarios pidan acceso a apps que requieren aprobación en lugar de usar canales informales.
• Limita quién puede conceder tenant-wide admin consent. Microsoft recomienda roles de menor privilegio y advierte que Global Administrator es un rol altamente privilegiado.
• Evalúa publisher verification como una señal, no como una aprobación completa de seguridad. Microsoft indica explícitamente que el badge de verified publisher no implica criterios de calidad, certificaciones, cumplimiento ni mejores prácticas de seguridad.
• Usa OAuth app policies de Defender for Cloud Apps cuando estén disponibles para alertar sobre apps riesgosas, poco comunes, muy privilegiadas o potencialmente maliciosas.

No crees una regla global que bloquee todas las apps de terceros sin proceso de excepción. Eso suele llevar a workarounds no gestionados. El enfoque más fuerte es un camino controlado de consentimiento: permisos delegados de bajo riesgo permitidos, revisión admin para scopes delegados sensibles y permisos de aplicación, y revisión periódica de apps ya aprobadas.

Validación después de la limpieza

La validación es donde muchas respuestas a consent phishing fallan. Un ticket no debe cerrarse porque la app desapareció de una vista visible del portal. Debe cerrarse porque se comprobaron los caminos duraderos de autorización.

Checklist de cierre

Usa esta secuencia de validación:

1. Confirmar que el service principal sospechoso está deshabilitado o eliminado cuando la app se confirma maliciosa.
2. Confirmar que no queda ningún OAuth2PermissionGrant delegado sospechoso para el client service principal.
3. Confirmar que no queda ningún appRoleAssignment sospechoso para permisos app-only.
4. Confirmar que se eliminaron asignaciones de usuarios y grupos a la aplicación si contribuían al acceso.
5. Confirmar que los audit logs muestran los eventos esperados de eliminación, como grants delegados o app role assignments eliminados.
6. Confirmar que user consent settings, app consent policies y admin consent workflow coinciden con el modelo de control previsto.
7. Confirmar que usuarios relevantes tuvieron sesiones/tokens revocados cuando hubo acceso delegado.
8. Confirmar que Defender for Cloud Apps o app governance, si están desplegados, ya no muestran la app como autorizada o activa.
9. Confirmar que nuevos intentos de conceder el mismo camino de permisos requieren el workflow admin esperado o están bloqueados por policy.

Para investigaciones tenant-wide, combínalo con Azure Identity Protection: Blocking Leaked Credentials. Consent phishing no es lo mismo que credenciales filtradas, pero señales de risky user y risky sign-in pueden ayudar a decidir si el usuario que concedió consentimiento también estaba comprometido.

Cómo EtcSec detecta exposición relacionada

EtcSec debe tratar OAuth consent phishing como un patrón de exposición entre inventario de aplicaciones, gobernanza de identidad y preparación de monitoreo. La pregunta útil no es solo si existe una app maliciosa. La pregunta útil es si el tenant facilitaría obtener consentimiento malicioso, dificultaría detectarlo o haría lenta su revocación.

Señales de exposición

Los checks relevantes incluyen:

• Enterprise Applications con permisos delegados amplios o permisos app-only amplios de Microsoft Graph.
• Aplicaciones autorizadas por muchos usuarios sin owner claro ni justificación de negocio.
• Aplicaciones sin verified publisher, especialmente cuando solicitan permisos sensibles.
• User consent settings que permiten aprobar más que permisos delegados de bajo riesgo.
• Admin consent workflow ausente o débil.
• Falta de revisión recurrente de admin consent y user consent grants.
• Permisos de aplicación incoherentes con el propósito declarado de la app.
• Usuarios privilegiados que consintieron aplicaciones de terceros desde dispositivos o contextos de menor confianza.
• Brechas de monitoreo alrededor de Consent to application, Add delegated permission grant y Add app role assignment to service principal.

Este tema es adyacente a Azure Conditional Access: MFA Bypass With Stolen Passwords, pero la remediación es distinta. Conditional Access sigue siendo parte de la defensa de identidad, pero el hardening de OAuth consent requiere app governance, revisión de permisos, consent policies y limpieza de service principals.

Controles relacionados

OAuth consent phishing se gestiona mejor como un conjunto de controles, no como un único interruptor.

Estos controles también reducen la exposición de aplicaciones legítimas con exceso de permisos. La gobernanza del consentimiento es parte de las operaciones normales de seguridad Entra, no solo una respuesta después de un reporte de phishing.

Referencias primarias

Las afirmaciones técnicas de este artículo se basan en documentación primaria y estándares:

• Microsoft Learn: Protect against consent phishing
• Microsoft Learn: Permissions and consent overview
• Microsoft Learn: Scopes and permissions in the Microsoft identity platform
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Manage app consent policies
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: View activity logs of application permissions
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: Publisher verification
• Microsoft Defender for Cloud Apps: Create policies to control OAuth apps
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations