Microsoft desmantela una red de EvilTokens impulsada por IA detrás de 12.000 robos de cuentas de correo electrónico

Microsoft ha desarticulado EvilTokens, una plataforma de phishing como servicio que convirtió un mecanismo legítimo de autenticación de Microsoft en un sistema industrializado para comprometer cuentas de correo electrónico y cometer fraude corporativo por correo electrónico.

La operación se saldó con la incautación de 50 sitios web y la desactivación de más de 150 dominios de apoyo. Microsoft vinculó el desarrollo, la operación y la atención al cliente del servicio con el actor de amenazas que sigue como Storm-2992.

EvilTokens estaba relacionado con más de 12.000 bandejas de entrada comprometidas en más de 10.000 organizaciones de todo el mundo. En lugar de robar directamente las contraseñas, el servicio manipulaba a las víctimas para que autorizaran sesiones controladas por los atacantes mediante el flujo de autorización de dispositivos de Microsoft OAuth 2.0.

La Digital Crimes Unit de Microsoft obtuvo la autorización para la desarticulación del Tribunal de Distrito de Estados Unidos para el Distrito Este de Virginia. Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation y TRM Labs respaldaron la operación.

Una plataforma comercial para el robo de tokens y el compromiso del correo corporativo

Storm-2992 comercializaba EvilTokens a través de Telegram como un servicio empaquetado para ciberdelincuentes. El operador utilizaba canales de mensajería y bots para anunciar productos, distribuir el kit de phishing, comunicar actualizaciones, ayudar a los suscriptores y ofrecer recompensas en criptomonedas por recomendar nuevos clientes.

La plataforma apareció en febrero de 2026. Huntress la documentó en marzo de 2026, mientras que Sekoia describió una oferta lista para usar que se vendía a través de Telegram desde mediados de febrero. Posteriormente, Microsoft rastreó en abril de 2026 una campaña vinculada a EvilTokens.

Entre las cuentas de Telegram identificadas se encontraban los usuarios de administrador @eviltokensadmin, @eviltokensadmins y @EvilTokenscontact, además de los bots de la tienda @EvilTokens_bot y @EvilTokensStorebot. La operación también mantenía el canal público @EvilTokensChannel y un grupo de Telegram independiente.

El kit principal costaba 1.500 dólares, seguido de una suscripción mensual de 500 dólares para acceder a sus componentes de phishing y al panel de control, según el análisis técnico de Microsoft. Entre los demás productos mencionados figuraban Antibot Redirector, B2B Sender, SMTP Sender y Office 365 Capture Link.

Según informaciones independientes atribuidas a Sekoia, B2B Sender costaba 600 dólares y SMTP Sender, 1.000 dólares. El aviso de Microsoft disponible no detallaba de forma independiente esos precios adicionales ni las condiciones de licencia comunicadas.

El panel de clientes permitía hacer mucho más que crear páginas de phishing. Los suscriptores podían configurar dominios y alojamientos, seleccionar idiomas y diseños para las páginas, modificar el comportamiento de CAPTCHA y de las redirecciones, supervisar a las víctimas, gestionar tokens robados, buscar palabras clave concretas en los buzones y recibir alertas a través de Telegram.

Las opciones de despliegue incluían Cloudflare Workers o infraestructura de Bunny, además de alojamientos PHP convencionales. Estas posibilidades ayudaban a los clientes a personalizar sus campañas sin tener que crear sus propios sistemas de distribución y toma de control de cuentas.

Cómo un inicio de sesión legítimo de Microsoft se convirtió en el mecanismo de phishing

El flujo de autorización de dispositivos está diseñado para equipos con capacidades de entrada limitadas, como televisores inteligentes, impresoras, dispositivos de Teams y equipos de videoconferencia. Normalmente, el dispositivo muestra un código breve que el usuario introduce en el navegador de otro sistema para aprobar el inicio de sesión.

EvilTokens aprovechaba la separación entre el navegador que realizaba esa aprobación y la sesión que había solicitado originalmente la autorización.

El atacante iniciaba primero una solicitud de código de dispositivo. A continuación, EvilTokens enviaba el código resultante a un objetivo a través de una página de phishing, con el fin de convencer a la víctima para que aprobara una sesión controlada por el atacante.

Las campañas utilizaban 44 temas como señuelo, entre ellos facturas, solicitudes de propuestas, documentos compartidos, avisos de caducidad de contraseñas, mensajes de buzón de voz, comunicaciones de eFax, avisos de pago y servicios de firma de documentos. Los enlaces maliciosos podían enviarse directamente o incluirse en archivos adjuntos PDF y HTML.

Después de seguir el señuelo, la víctima llegaba a una página que contenía automatización en segundo plano. Esta se comunicaba con el proveedor de identidad de Microsoft y generaba un código de dispositivo activo. La página mostraba un control «Copy Code» y un botón con la etiqueta «Continue» o «Continue with Microsoft».

Ese botón enviaba a la víctima a la página legítima microsoft.com/devicelogin. El dominio auténtico aportaba una credibilidad que una página clonada para capturar credenciales no podía ofrecer.

La víctima introducía el código generado por el atacante y, si era necesario, completaba las solicitudes habituales de contraseña y autenticación multifactor. A continuación, el servicio de autorización de Microsoft emitía tokens de acceso y de actualización al cliente del atacante.

El operador de EvilTokens no necesitaba conocer ninguna contraseña. La MFA tampoco impedía el compromiso, porque la víctima estaba aprobando una solicitud de autenticación real, aunque no una iniciada por el dispositivo o el servicio al que creía estar accediendo.

Los tokens robados alimentaban un proceso de fraude asistido por IA

Una vez que EvilTokens obtenía tokens válidos, sus clientes podían acceder al buzón de la víctima, exfiltrar mensajes, crear reglas de bandeja de entrada para ocultar correspondencia maliciosa y registrar dispositivos adicionales. Los tokens de actualización y las sesiones activas podían mantener el acceso más allá de la intrusión inicial.

La plataforma también utilizaba Microsoft Graph para examinar usuarios, roles, permisos, estructuras jerárquicas y otras relaciones dentro de la organización. Esa labor de reconocimiento ayudaba a identificar a los empleados con autoridad financiera y a los contactos cuyas identidades resultaban útiles para la suplantación.

Las funciones de IA estaban integradas en este proceso posterior al compromiso. El asistente podía inspeccionar el contenido de los buzones en busca de facturas de proveedores, aprobaciones de pagos, conversaciones financieras, responsabilidades sensibles y personas autorizadas para transferir dinero.

Después podía resumir o traducir mensajes en más de 20 idiomas, identificar relaciones de confianza, proponer estrategias de fraude y redactar mensajes que imitaran a contactos conocidos. El contenido de phishing podía adaptarse al cargo del objetivo y al contexto encontrado dentro del buzón.

Esto convertía EvilTokens en algo más que un kit para sustraer tokens. La plataforma reunía en una sola interfaz el acceso inicial, la obtención de información de los buzones, la selección de objetivos, el mapeo de la organización, la suplantación y la preparación de fraudes corporativos por correo electrónico.

El resultado reducía los conocimientos necesarios para llevar a cabo un fraude dirigido. Un afiliado no tenía que desarrollar un sistema de phishing basado en OAuth, revisar manualmente miles de mensajes ni comprender la organización de la víctima antes de intentar desviar un pago.

Una infraestructura efímera dificultaba la detección

EvilTokens utilizaba redirecciones encadenadas, comprobaciones CAPTCHA falsas y alojamientos serverless para evitar los bloqueos directos de dominios. Entre la infraestructura observada se encontraban Vercel, Cloudflare Workers y AWS Lambda.

En la campaña que Microsoft rastreó en abril de 2026, las plataformas de automatización generaron miles de nodos de sondeo únicos y de corta duración. Una compleja lógica de backend en Node.js respaldaba el proceso, desde la generación del código de dispositivo activo hasta la actividad posterior en la cuenta.

La infraestructura en constante cambio reducía el valor de los indicadores estáticos y de las firmas sencillas. Un dominio identificado en un mensaje podía desaparecer o dejar de ser relevante mientras el mismo flujo de backend reaparecía a través de otro endpoint serverless.

SpyCloud aportó datos de phishing recuperados que cubrían 8.708 cuentas de víctimas únicas vinculadas a 6.585 dominios de correo corporativo en 79 países. Las capturas recuperadas más antiguas estaban fechadas el 18 de febrero de 2026.

Las mayores concentraciones de víctimas observadas se registraron en Estados Unidos, Canadá, Reino Unido, Australia, India y Francia. Entre los sectores afectados se encontraban la distribución mayorista, la construcción, los servicios financieros, el sector inmobiliario, la educación superior y la sanidad.

Los informes de los socios también atribuyeron aproximadamente 1,1 millones de dólares de ingresos de la plataforma a cuatro direcciones de Tron entre octubre de 2025 y junio de 2026. Según los informes, Coinbase identificó más de 1.000 depósitos procedentes de más de 700 direcciones de criptomonedas. Microsoft no cuantificó por separado esos datos financieros en su aviso.

Una retirada respaldada por un tribunal y acompañada de dos detenciones

La Digital Crimes Unit de Microsoft utilizó la orden del tribunal federal de Virginia para incautar 50 sitios web implicados en la operación de EvilTokens y desactivar más de 150 dominios relacionados.

Según informaciones sobre la operación coordinada, la Metropolitan Police Service detuvo el 11 de septiembre de 2026 a dos hombres de 32 y 38 años en relación con la operación comercial. El material disponible no facilitó sus nombres.

Microsoft publicó su análisis el 22 de septiembre de 2026. La retirada elimina una parte importante de la infraestructura, pero no se ha divulgado una lista completa de las cuentas afectadas, las identidades de los clientes ni los sistemas que aún controlan los afiliados.

Por tanto, las organizaciones deben investigar una posible exposición en lugar de considerar la interrupción de la infraestructura como una solución para los tenants ya comprometidos.

Los equipos defensivos deben revocar los tokens, no limitarse a restablecer las contraseñas

Microsoft recomienda bloquear la autenticación mediante código de dispositivo allí donde no sea necesaria desde el punto de vista operativo. Las organizaciones pueden utilizar Conditional Access para desactivar este flujo o restringirlo estrictamente.

Cuando el hardware de Teams dependa de la autenticación mediante código de dispositivo, las excepciones deben limitarse a las cuentas de recursos designadas para dispositivos de Teams. Microsoft también recomienda excluir el recurso Device Registration Service de la política de Conditional Access correspondiente.

Ante una sospecha de compromiso, los equipos defensivos deben revocar las sesiones activas y los tokens de actualización, eliminar los registros de dispositivos no autorizados y restablecer las credenciales. Un cambio de contraseña por sí solo puede dejar intacto el acceso existente del atacante respaldado por tokens.

Los equipos de seguridad también deberían examinar:

• Dispositivos registrados recientemente y autorizaciones OAuth sospechosas.
• Reglas maliciosas de la bandeja de entrada, mensajes ocultos y redirecciones inusuales.
• Consultas anómalas de Microsoft Graph relacionadas con usuarios, roles, permisos o la estructura organizativa.
• Enlaces no solicitados que utilicen plataformas serverless como Vercel, Cloudflare Workers o AWS Lambda.
• Señuelos relacionados con facturas, RFP, archivos compartidos, caducidad de contraseñas, pagos, mensajes de buzón de voz, eFax y firma de documentos.
• Conectores de terceros que puedan permitir que mensajes suplantados eludan las protecciones habituales del correo.

Los usuarios deben considerar sospechosas las instrucciones inesperadas para introducir un código en microsoft.com/devicelogin, aunque el sitio sea legítimo. La cuestión decisiva es si el propio usuario inició un proceso de autenticación de dispositivo aprobado.

Esa distinción fue fundamental en EvilTokens: el inicio de sesión de Microsoft era real, el código era válido y la MFA funcionaba tal como estaba diseñada. El engaño consistía en determinar la sesión de quién estaba autorizando la víctima.