Phishing EvilTokens: Microsoft alerta sobre ataques al flujo de autenticación

La ciberseguridad corporativa enfrenta una nueva y sofisticada amenaza: la campaña de phishing EvilTokens. Este método, que ha escalado rápidamente en su implementación como un servicio automatizado (Phishing-as-a-Service), está desafiando los pilares tradicionales de la protección de identidad al explotar una característica legítima de los ecosistemas en la nube: el flujo de autenticación de código de dispositivo (Device Code Authentication).

¿Qué es EvilTokens y por qué es tan peligroso?

A diferencia de los ataques de phishing convencionales que intentan robar credenciales de usuario (nombre de usuario y contraseña) mediante páginas de inicio de sesión falsas, EvilTokens adopta un enfoque mucho más sutil y eficaz. Esta plataforma, identificada inicialmente a principios de 2026, automatiza el abuso de la función “Device Code Flow” de Microsoft (basada en el estándar OAuth 2.0, RFC 8628), diseñada originalmente para simplificar el inicio de sesión en dispositivos con capacidades de entrada limitadas, como televisores inteligentes, impresoras o herramientas de línea de comandos (CLI).

En un escenario de ataque típico de phishing EvilTokens, el atacante inicia una solicitud de autorización legítima hacia los servicios de Microsoft. El atacante recibe un código de dispositivo y una URL de validación. Luego, a través de tácticas de ingeniería social —a menudo perfeccionadas mediante IA generativa para personalizar los correos electrónicos según el rol del objetivo—, engaña al usuario para que acceda a la URL legítima de Microsoft y **introduzca el código** que ellos le han proporcionado.

Al introducir el código, el usuario —pensando que está realizando una acción de verificación rutinaria— está **autorizando conscientemente** el dispositivo del atacante. El resultado es devastador: el atacante obtiene un token de acceso y un token de actualización (refresh token) válidos. Estos tokens permiten al atacante suplantar al usuario, acceder a sus correos electrónicos, documentos en SharePoint o Teams, y establecer una persistencia duradera en la cuenta, **sin necesidad de haber conocido nunca la contraseña del usuario ni de intentar saltarse el MFA**, ya que el propio usuario completó la autenticación multifactor legítima durante el proceso.

La anatomía del engaño: Por qué falla el MFA tradicional

El éxito de EvilTokens radica en su capacidad para neutralizar las defensas de MFA tradicionales. Dado que la interacción ocurre dentro de la infraestructura oficial de Microsoft, las herramientas de seguridad basadas en la detección de dominios falsos o intentos de suplantación de identidad suelen ser ineficaces.

• Sesiones validadas: Al ser tokens legítimos, las acciones del atacante parecen provenir de una sesión autenticada con éxito.
• El usuario como cómplice involuntario: El usuario final, al ver una pantalla de inicio de sesión oficial, confía plenamente, anulando la eficacia de la educación básica en seguridad sobre “no introducir contraseñas en sitios desconocidos”.
• Persistencia de los tokens: Una vez obtenido el acceso inicial, el atacante puede refrescar los tokens durante meses, manteniendo el control de la cuenta incluso si el usuario cambia su contraseña.

El límite de la “Resistencia al Phishing” convencional

Es crucial comprender una distinción técnica fundamental: aunque las soluciones de MFA resistentes al phishing, como las claves de seguridad **FIDO2**, son el estándar de oro para proteger contra ataques de Adversario en el Medio (AiTM) que intentan capturar contraseñas o códigos OTP (como SMS), en este escenario específico su eficacia es distinta. Como el ataque de phishing EvilTokens explota el flujo de autorización de dispositivos en un nivel posterior a la autenticación, la mera presencia de una llave de seguridad FIDO2 no impide que un usuario, si es engañado, complete un proceso de vinculación de dispositivo que, en última instancia, otorgue al atacante los permisos necesarios.

La seguridad frente a esta amenaza no reside solo en el “factor” de autenticación, sino en el **control estricto de los flujos de autorización permitidos** dentro del inquilino (tenant) de la organización.

Estrategias de mitigación y defensa proactiva

Para contrarrestar esta amenaza, los equipos de seguridad deben pasar de una mentalidad de “bloquear credenciales” a una de “gestión estricta de identidades y sesiones”. Las siguientes acciones son fundamentales para mitigar el riesgo:

1. Control estricto del Flujo de Código de Dispositivo

La medida de mitigación más efectiva es **desactivar el flujo de código de dispositivo (Device Code Flow)** para todos los usuarios que no lo necesiten estrictamente para sus funciones diarias. Muchas organizaciones mantienen esta funcionalidad activada por defecto, lo que deja una puerta abierta innecesaria.

Utilice las Políticas de Acceso Condicional (Conditional Access) para:

• Bloquear el acceso mediante “Device Code Flow” a nivel de inquilino.
• Si es necesario, permitir este flujo únicamente para dispositivos específicos, ubicaciones de red confiables o un grupo reducido de usuarios que requieran herramientas CLI.
• Implementar una política de “report-only” (solo informe) primero, para identificar qué usuarios o aplicaciones legítimas dependen de este flujo antes de bloquearlo por completo.

2. Monitoreo de comportamiento y análisis de sesiones

Dado que el inicio de sesión es técnicamente “legítimo”, debe enfocarse en detectar anomalías post-autenticación:

• Monitoreo de logs de inicio de sesión: Busque eventos de inicio de sesión de tipo “Device Code” que sean inusuales para el perfil del usuario.
• Análisis de User-Agents: Identifique agentes de usuario sospechosos o inconsistentes tras una autenticación exitosa (ej. uso de librerías como Axios en contextos donde no se espera).
• Detección de “Viajes Imposibles”: Si un usuario autoriza un dispositivo desde una geolocalización drásticamente distinta a su actividad habitual, active alertas inmediatas.

3. Educación centrada en la “Autorización de Dispositivos”

El entrenamiento del usuario debe evolucionar. Ya no basta con decirles que no entreguen su contraseña. Los empleados deben entender qué significa “vincular un dispositivo”.

La regla de oro: Ningún sistema empresarial legítimo solicitará al usuario que tome un código de una pantalla y lo introduzca en otra, a menos que el usuario sea quien explícitamente inició esa vinculación en un dispositivo físico de su propiedad. Si el usuario recibe un prompt de “verificación de código” sin haberlo solicitado, es casi seguro que se trata de un intento de phishing EvilTokens.

Conclusión: Un cambio en el paradigma de seguridad

La proliferación de kits como EvilTokens demuestra que el cibercrimen está profesionalizando la explotación de la confianza inherente en los flujos de trabajo de las plataformas en la nube. La seguridad ya no puede limitarse a proteger el perímetro o la contraseña; debe proteger el **ciclo de vida completo de la sesión y la autorización**.

Para sobrevivir en este panorama, las organizaciones deben adoptar una postura de “Zero Trust” (Confianza Cero) respecto a los flujos de autorización. Al reducir la superficie de ataque —limitando los flujos de código de dispositivo— y al mismo tiempo mejorar la visibilidad sobre el comportamiento post-login, es posible neutralizar esta amenaza antes de que los atacantes logren establecer su persistencia. La tecnología avanza, pero la disciplina en la gestión de identidades sigue siendo el escudo más potente contra la sofisticación del phishing moderno.