EvilTokens: el kit de phishing que hace que tu MFA sea inútil y ya ha comprometido más de 340 organizaciones Microsoft 365

Desde febrero de 2026, una plataforma de phishing como servicio llamada EvilTokens lleva comprometiendo silenciosamente organizaciones de Microsoft 365 en todo el mundo. Su particularidad es radical: no roba contraseñas, no activa ninguna alerta de MFA y no usa páginas de login falsas. Todo ocurre en infraestructura real de Microsoft. La víctima completa su propio proceso de autenticación multifactor en la página legítima de Microsoft y, sin saberlo, le entrega al atacante un token OAuth válido con acceso persistente a su correo electrónico, OneDrive, SharePoint, Teams, contactos y calendario. The Hacker News lo amplifica hoy con el análisis completo de Bolster AI. Es la amenaza de identidad más significativa de 2026 para las organizaciones que usan Microsoft 365 — y eso es prácticamente todas.

‍

¿Qué es EvilTokens y qué ha pasado?

Los hechos documentados por SEKOIA Threat Detection & Research (31 marzo 2026), Huntress (19 febrero 2026), Bolster AI, Palo Alto Unit 42, AppOmni y The Hacker News son los siguientes:

• Primera actividad observada: 15-19 de febrero de 2026. Huntress detectó los primeros casos activos el 19 de febrero.
• Escala en 5 semanas: en menos de cinco semanas desde su lanzamiento, EvilTokens había comprometido más de 340 organizaciones de Microsoft 365 en siete países: Estados Unidos, Canadá, Francia, Australia, India, Suiza y Emiratos Árabes Unidos.
• Sectores afectados: finanzas, RRHH, logística, ventas, sanidad, servicios legales, administración local, construcción, ONGs, inmobiliario y manufactura.
• Modelo de negocio criminal: PhaaS distribuido vía Telegram con planes desde 299 hasta 499 dólares al mes en criptomoneda. Soporte 24/7. El operador anuncia planes para añadir soporte para Gmail y Okta en próximas versiones.
• Origen técnico: abusa del flujo de autorización OAuth 2.0 Device Code (Device Authorization Grant), un mecanismo legítimo de Microsoft diseñado para que dispositivos sin teclado — televisores inteligentes, impresoras, dispositivos IoT — puedan autenticarse en Microsoft 365.
• El token no se invalida con un cambio de contraseña: los refresh tokens que EvilTokens emite sobreviven a resets de contraseña y permanecen válidos durante semanas o meses dependiendo de la configuración del tenant. Solo la revocación explícita o una política de Conditional Access que exija re-consent cierra el acceso.
• Antecedente estatal: el flujo Device Code Phishing fue utilizado previamente por grupos de Estado como Storm-2372 y APT29 contra gobiernos y organizaciones académicas desde al menos febrero de 2025. EvilTokens es la comercialización de esa técnica: lo que era capacidad de APT ahora está disponible en Telegram para operadores sin conocimientos técnicos avanzados.

‍

Por qué Microsoft 365 es el objetivo más valioso para este tipo de ataque

Un compromiso de Microsoft 365 no es comprometer una cuenta de correo. Es comprometer potencialmente toda la infraestructura digital de una organización. Cuatro factores explican por qué EvilTokens se centra exclusivamente en Microsoft 365:

1. Superficie de impacto máxima con una sola cuenta. Un token OAuth de Microsoft 365 válido da acceso a email (Exchange), archivos corporativos (OneDrive, SharePoint), comunicaciones internas (Teams), agenda (Calendar) y directorio de contactos. Una sola víctima puede abrir la puerta a toda la organización mediante BEC (Business Email Compromise), suplantación interna o exfiltración de documentos críticos.
2. La confianza del usuario en microsoft.com es el vector. A diferencia del phishing clásico, EvilTokens no necesita que la víctima visite una URL falsa. La instrucción es ir a microsoft.com/devicelogin — una URL 100% legítima y verificada. Todos los señales visuales de seguridad que el usuario ha aprendido a comprobar (HTTPS, dominio real, certificado válido) están presentes. Porque el sitio es real.
3. El MFA completo no protege. La víctima completa su factor de autenticación adicional (TOTP, SMS, push notification) en la página real de Microsoft. El MFA funciona exactamente como se espera. El problema es que el resultado — el token — va al atacante, no a la sesión legítima del usuario.
4. El acceso es persistente y silencioso. Con el refresh token, el atacante puede operar durante semanas o meses sin necesidad de nuevas credenciales, sin generar eventos de sign-in sospechosos desde ubicaciones desconocidas, y sin activar las alertas diseñadas para detectar intrusiones basadas en credenciales.

‍

Cómo funciona el ataque: la trampa del Device Code Flow

La cadena de ataque de EvilTokens sigue estos pasos con precisión:

1. El atacante inicia la solicitud de autorización. El operador de EvilTokens envía una solicitud a la API de Microsoft y obtiene un device code real y un user code — exactamente como haría una Smart TV legítima que quiere autenticarse.
2. El señuelo llega a la víctima. EvilTokens genera un email o mensaje con un señuelo creible: una factura pendiente de aprobación, un documento compartido de SharePoint, una notificación de nómina, una alerta de seguridad, una petición de DocuSign o Adobe Acrobat Sign. El mensaje incluye una página de aterrizaje que puede imitar Adobe Acrobat, DocuSign u otro servicio de confianza, y muestra el user code junto a un botón “Continuar con Microsoft”.
3. La víctima completa el MFA en Microsoft real. Al hacer clic en el botón, la víctima es dirigida a microsoft.com/devicelogin, introduce el user code, inicia sesión con sus credenciales corporativas y completa su MFA habitual — push notification, TOTP, o lo que tenga configurado. Desde su perspectiva, todo es exactamente como siempre. Ha “verificado su identidad”.
4. Microsoft entrega los tokens al atacante. En el momento en que la víctima completa la autorización, Microsoft emite un access token y un refresh token válidos para la cuenta de la víctima — y los entrega a la sesión que los solicitó, que es la del atacante.
5. Acceso persistente establecido. Con el refresh token, el atacante tiene acceso continuado a la cuenta de Microsoft 365 de la víctima. Puede leer y enviar emails como la víctima, acceder a todos sus archivos en OneDrive y SharePoint, participar en conversaciones de Teams, descargar la libreta de contactos y el calendario. El token sobrevive al cambio de contraseña.
6. Escalada opcional. El atacante puede registrar un nuevo dispositivo en Microsoft Entra ID, obtener un Primary Refresh Token (PRT) y mantener acceso silencioso y persistente incluso frente a políticas de Conditional Access que no contemplen este escenario.
7. Post-compromiso: BEC y movimiento lateral. EvilTokens incluye una interfaz de webmail integrada que permite al operador actuar directamente desde el buzón comprometido para preparar ataques de Business Email Compromise (BEC), interceptar facturas, manipular transferencias o lanzar nuevos ataques de phishing desde la cuenta legítima de la víctima contra sus propios contactos.

‍

Lecciones clave y checklist de mitigación para responsables IT y CISOs

EvilTokens no se puede detectar ni parar con las defensas clásicas de phishing. Requiere controles específicos sobre el flujo de autenticación de Microsoft 365:

Mitigación inmediata — Bloquear el Device Code Flow:

• En Microsoft Entra ID (Azure AD) → Security → Conditional Access: crear una política que bloquee las solicitudes de autenticación de tipo Device Code para todos los usuarios que no necesiten autenticar dispositivos sin teclado (la gran mayoría de usuarios corporativos). Esta es la mitigación más eficaz disponible hoy.
• Si la organización usa dispositivos IoT, impresoras o smart TV que requieran este flujo, crear una política que lo limite exclusivamente a esos dispositivos gestionados y verifique su cumplimiento (compliant devices).

Detección — Monitorizar Entra ID:

• En Entra ID → Monitoring → Sign-in logs: buscar autenticaciones con el método Device code flow desde IPs o ubicaciones inusuales para la organización.
• Configurar alertas en Microsoft Defender XDR o el SIEM para los eventos “Suspicious Azure authentication through possible device code phishing” y “User account compromise via OAuth device code phishing”.
• Revisar el historial de autorizaciones OAuth activas en el tenant. Cualquier aplicación autorizada que los usuarios no reconocen debe investigarse y revocarse.

Respuesta ante compromiso sospechoso:

• El cambio de contraseña NO invalida el refresh token. La única forma de cerrar el acceso es la revocación explícita del token: en Entra ID → Users → [Usuario] → Revoke sessions.
• Auditar inmediatamente las reglas de bandeja de entrada del usuario comprometido en busca de forwarding no autorizado a cuentas externas.
• Revisar los dispositivos registrados recientemente en Entra ID asociados a la cuenta comprometida.

MFA resistente a phishing:

• Las soluciones TOTP (Google Authenticator, Microsoft Authenticator en modo OTP) y los SMS no protegen contra Device Code Phishing — la víctima los completa ella misma en la página real de Microsoft. Solo los métodos de MFA resistentes a phishing — FIDO2/passkeys, certificados basados en hardware — previenen completamente este ataque.

Concienciación de empleados:

• Entrenar a los empleados para que reconozcan y rechacen cualquier petición de introducir un código de verificación en microsoft.com/devicelogin que ellos no hayan iniciado activamente. Un usuario que entiende que “si yo no inicié la sesión del dispositivo, no debo introducir ningún código” no caerá en este ataque.

‍

La ciberseguridad como prioridad estratégica

EvilTokens confirma la tendencia más importante en ataques de identidad en 2026: los atacantes ya no rompen la autenticación, la redirigen. El MFA sigue siendo una capa de defensa necesaria e imprescindible para la mayoría de amenazas, pero ya no es suficiente si no va acompañado de controles sobre el flujo de autorización OAuth, límites en la vida útil de los tokens y monitorización activa sobre lo que ocurre después del login.

Para las organizaciones españolas, el mensaje es directo: si tu organización usa Microsoft 365 — y la gran mayoría lo hace — y no tienes una política de Conditional Access que bloquee el Device Code Flow para usuarios que no lo necesitan, el vector de EvilTokens está abierto ahora mismo.

‍

Apolo Cybersecurity: protección de identidades y accesos en entornos Microsoft 365

En Apolo Cybersecurity ayudamos a organizaciones a cerrar los vectores de ataque basados en identidad que EvilTokens y técnicas similares explotan: auditoría y hardening de políticas de Conditional Access en Microsoft Entra ID, implementación de MFA resistente a phishing (FIDO2/passkeys), monitorización de flows OAuth y tokens en entornos Microsoft 365, detección de actividad post-compromiso en Exchange y SharePoint, y planes de respuesta que incluyen la revocación correcta de tokens comprometidos.

Si tu organización usa Microsoft 365 y no has revisado si el Device Code Flow está bloqueado en tu Conditional Access, este miércoles por la mañana es el momento de verificarlo.

‍