La plataforma EvilTokens, que opera bajo el modelo de «phishing como servicio» (PhaaS), según datos de Cloud Security Alliance, explota el mecanismo OAuth device code flow en Microsoft 365 para obtener tokens de actualización (refresh tokens) de larga duración. Las víctimas realizan una autenticación legítima con MFA en el dominio real de Microsoft, pero al mismo tiempo transfieren sin saberlo al atacante un token con acceso al correo, los archivos, el calendario y los contactos. La autenticación multifactor no puede bloquear este ataque, porque para el momento en que se emite el token ya se ha completado. Las organizaciones que utilizan Microsoft 365 deben revisar sus políticas de gestión de consentimientos OAuth y de tokens.

Mecanismo de ataque: device code flow como vector

El ataque utiliza un mecanismo de autenticación estándar de Microsoft —device code flow— diseñado para dispositivos sin un navegador completo. La víctima recibe un mensaje pidiéndole que introduzca un código corto en la página microsoft.com/devicelogin y complete la verificación MFA habitual. Desde el punto de vista del usuario, esto parece una verificación de inicio de sesión normal.

Sin embargo, tras completar la autenticación, el sistema emite el token de actualización no al usuario, sino al operador de la plataforma EvilTokens. Según se indica en la nota de investigación de la CSA, este token:

• Está firmado por un proveedor de identidad legítimo de Microsoft
• Cubre el acceso al buzón de correo, OneDrive, el calendario y los contactos
• Tiene un tiempo de vida determinado por la política del tenant, no por la sesión
• Presumiblemente mantiene su validez incluso después de que el usuario cambie su contraseña

El problema clave es que el atacante no intercepta credenciales ni reproduce una sesión. El token es el resultado del funcionamiento normal del sistema. El evento de inicio de sesión en los registros parece legítimo, ya que la autenticación realmente se realizó en el dominio auténtico de Microsoft con un segundo factor real.

Por qué MFA no es una protección

El phishing tradicional de credenciales requiere volver a reproducir la contraseña, y es precisamente en esta fase donde MFA crea una barrera. Incluso los ataques de tipo «adversary-in-the-middle» (AiTM) dejan en los registros cookies de sesión que las soluciones SIEM pueden correlacionar con la ubicación geográfica y el dispositivo.

En el caso del consent phishing a través de OAuth, el propio usuario completa la autenticación en un proveedor legítimo. MFA se activa y se supera con éxito antes del momento en que se emite el token. El token que recibe el atacante no es el resultado de una intrusión, sino el resultado del consentimiento otorgado por el usuario. Según los investigadores, no basta con cambiar la contraseña para anular ese acceso: se requiere una revocación explícita del token o una política de acceso condicional que exija un nuevo consentimiento.

La normalización del consentimiento como factor de riesgo

El vector de ataque a través del consentimiento OAuth existe desde hace tiempo, pero su eficacia ha aumentado drásticamente debido al cambio en el comportamiento de los usuarios. Cada agente de IA, cada integración para mejorar la productividad, cada extensión de navegador que trabaja con cuentas SaaS solicita un consentimiento OAuth. El volumen de solicitudes de consentimiento legítimas con las que se encuentra un empleado al mes supera con creces el previsto en los modelos de amenazas originales de OAuth.

La redacción de los permisos solicitados agrava el problema. El ámbito (scope) de acceso «Leer su correo» en la práctica abarca todos los mensajes, adjuntos e hilos compartidos de la correspondencia. El ámbito «Acceso a los archivos cuando no esté conectado» significa la emisión de un token de larga duración que funciona sin la presencia del usuario. La brecha entre el lenguaje del consentimiento y el alcance real del acceso es precisamente el espacio en el que operan los atacantes.

Combinaciones tóxicas de permisos

Un grant OAuth individual proporciona al atacante una cabeza de puente limitada en una sola aplicación. El riesgo sistémico surge cuando varios grants se solapan a través de una misma identidad de usuario. Por ejemplo: un empleado del departamento financiero otorga a un asistente de IA acceso al calendario y al correo, a otra herramienta acceso al repositorio corporativo y a una tercera acceso a la base de clientes de la CRM. Cada consentimiento se concede por separado, y ningún propietario de aplicación ha autorizado la combinación en su conjunto. La posible intrusión en una de estas herramientas puede abrir el acceso a contratos y datos de clientes a través de esa misma identidad.

Este riesgo no es visible en ningún registro de auditoría individual de una aplicación, porque el puente entre ellas existe a nivel de identidad, fuera del perímetro de cada aplicación. Los analistas señalan que los servidores Model Context Protocol (MCP) conforman una superficie de ataque similar, al permitir que los agentes de IA obtengan acceso mediante el mismo mecanismo de consentimiento único.

Recomendaciones prácticas

Para protegerse del consent phishing a través de OAuth es necesario trasladar el control desde el nivel de la autenticación al nivel del consentimiento:

1. Restringir el registro de aplicaciones en Entra ID: prohibir que los usuarios otorguen por sí mismos consentimientos de acceso a aplicaciones. Configurar un flujo de trabajo de aprobación administrativa para todos los grants OAuth que soliciten acceso al correo, los archivos y el calendario.
2. Configurar políticas de acceso condicional para los tokens: acortar el tiempo de vida de los refresh tokens, habilitar el requisito de reautenticación para recursos sensibles y configurar políticas de evaluación de acceso continuo (Continuous Access Evaluation).
3. Auditar los grants OAuth existentes: en Entra ID, revisar la sección «Aplicaciones empresariales» → «Consentimientos y permisos». Identificar las aplicaciones con ámbitos de acceso amplios (Mail.Read, Files.ReadWrite.All, offline_access) y revocar los grants no utilizados o sospechosos.
4. Deshabilitar device code flow: si este mecanismo de autenticación no es necesario para los procesos de negocio, bloquearlo mediante políticas de acceso condicional. Esto elimina el vector concreto que utiliza EvilTokens.
5. Monitorizar los eventos de consentimiento: configurar alertas en el SIEM para los eventos de concesión de grants OAuth, especialmente para aplicaciones registradas fuera del tenant y para grants con ámbitos de acceso amplios.
6. Inventariar los solapamientos de grants: identificar a los usuarios cuyos consentimientos OAuth, en conjunto, crean puentes entre sistemas críticos (correo + almacenamiento + CRM) y evaluar el riesgo agregado.

El consent phishing a través de OAuth no es una amenaza teórica, sino un vector de ataque operativo para el que existe una infraestructura comercial. La acción más importante ahora es prohibir que los usuarios otorguen por sí mismos consentimientos OAuth en Microsoft 365 y realizar una revisión de todos los grants existentes con ámbitos de acceso amplios. Las organizaciones que siguen confiando exclusivamente en MFA como frontera de protección de la identidad dejan abierto precisamente el nivel por el que pasan los ataques modernos.