En el panel de EvilTokens había un chatbot que leía el buzón robado y le decía al estafador quién movía el dinero, qué facturas estaban pendientes y a quién suplantar para que la transferencia saliera. El 15 de septiembre de 2026 un tribunal federal de Virginia autorizó a Microsoft a incautar los dominios del servicio. El día 22, Microsoft anunció el resultado: 50 sitios incautados y más de 150 dominios de apoyo desactivados, y dos hombres de 32 y 38 años detenidos en Londres por la Policía Metropolitana como presuntos administradores.
EvilTokens funcionaba desde febrero, según Microsoft, y en ese tiempo había dejado más de 12.000 buzones de Microsoft 365 en manos de sus clientes.
Lo que lo distingue de otros kits no está en esas cifras. La técnica de entrada, el device code phishing, se documenta desde 2020: el atacante inicia en Entra ID un flujo de autorización pensado para dispositivos sin teclado, le pide a la víctima que introduzca el código en la página real de Microsoft y, cuando esta completa contraseña y segundo factor, es el programa del atacante el que recibe los tokens.
Lo nuevo era lo que venía después. Steven Masada, director general de la Unidad de Delitos Digitales (DCU) de Microsoft, lo resumió en su comunicado: la IA no se limitaba a ayudar a los atacantes a escribir mensajes más convincentes; les ayudaba a decidir a quién atacar, a quién suplantar y cómo explotar la relación para sacar el máximo dinero.
Buena parte del debate sobre IA y phishing se ha centrado en el señuelo: correos sin faltas y páginas de inicio de sesión indistinguibles de la real. EvilTokens indica que donde la IA cambia de verdad la economía del fraude es en la fase posterior, cuando el atacante ya tiene un buzón abierto y necesita entenderlo antes de que le corten el acceso.
Lo que dicen los datos
El volumen y el precio
Según Microsoft, EvilTokens arrancó en febrero de 2026 y en unos meses estaba vinculado a más de 12.000 buzones comprometidos en más de 10.000 organizaciones. Un portavoz de la compañía dijo a CyberScoop que alrededor de mil delincuentes usaron el servicio y que Microsoft pudo correlacionar al menos 13 denuncias ante el IC3 del FBI con actividad del kit, que suman unos 1,7 millones de dólares en pérdidas declaradas. La propia Microsoft considera esa cifra conservadora: muchos incidentes no se denuncian y no todas las víctimas pueden vincularse a una campaña concreta.
El acceso se vendía por Telegram: 1.500 dólares de alta y 500 al mes, con módulos aparte para el envío masivo y el redirector antibot. Coinbase, que participó en la investigación, rastreó unos 1,1 millones de dólares de ingresos en cuatro direcciones de Tron atribuidas a la plataforma, procedentes de más de 1.000 depósitos desde más de 700 direcciones distintas. Coinbase sitúa esa actividad entre octubre de 2025 y junio de 2026, varios meses antes de que el kit se anunciara en Telegram, un desfase que ninguna de las fuentes explica.
Las víctimas eran empresas, y pocos clientes hacían casi todo el daño
SpyCloud aportó a la demanda los datos que había recuperado de la infraestructura del kit y los publicó el mismo día: 8.708 cuentas únicas capturadas desde el 18 de febrero, en 6.585 dominios corporativos de 79 países. El 97,5 % pertenecía a dominios de empresa; solo 216 eran cuentas de correo gratuito. Las capturas siguen la jornada laboral norteamericana: un día laborable acumula de media unas siete veces más que un día de fin de semana.
Lo más revelador de ese informe es la concentración: los diez clientes más activos de EvilTokens acumulan el 60 % de las víctimas, y los veinticinco primeros, el 85 %. Los doce de mayor volumen sacan de media el 74 % de sus víctimas de un único país, lo que SpyCloud interpreta como campañas dirigidas a determinados tipos de empresa y no como distribución oportunista. Microsoft cifra en unos mil los delincuentes que usaron el servicio, pero en los datos de SpyCloud la mayor parte del daño se concentra en un par de decenas de ellos.
Lo que hacía la IA con el buzón
Según el análisis de Sekoia que cita SpyCloud, el panel descargaba hasta 5.000 correos recientes de la víctima a través de Microsoft Graph, analizaba el entorno, identificaba las oportunidades de fraude y redactaba el correo de suplantación. Trabajaba en más de veinte idiomas y detectaba si la cuenta capturada tenía rol de administrador global. El informe de Cloudflare añade que incluía un "asesor" de IA que orientaba al cliente sobre formularios fiscales estadounidenses, fraude del CEO y el formato habitual de facturas y correspondencia contable.
El análisis técnico de Microsoft Threat Intelligence aporta la cronología desde dentro de los incidentes. En algunos casos, a los diez minutos del compromiso el atacante ya había registrado un dispositivo nuevo para obtener un Primary Refresh Token y asegurarse la persistencia; en otros esperó varias horas antes de crear reglas de buzón o exfiltrar correo, para no disparar alertas inmediatas. En uno de los incidentes analizados, el actor usó las funciones de IA del kit para filtrar, entre las cuentas ya capturadas, las de perfil financiero, directivo o administrativo, y reservó la lectura a fondo para quienes tenían autoridad de pago.
La infraestructura era la de cualquier empresa
Cloudflare cuenta que los clientes de EvilTokens podían pegar su propia clave de API de Cloudflare en el panel, que con ella les desplegaba un Worker con la página de captura. Microsoft observó además Vercel, Cloudflare Workers y AWS Lambda como capas de redirección: el tráfico de phishing se mezclaba con el tráfico legítimo de nube y esquivaba las listas de bloqueo por dominio. El desmantelamiento tuvo también un límite jurídico: parte de los dominios estaban en registradores de jurisdicciones que no cooperan, y para esos Cloudflare interpuso páginas de advertencia en lugar de incautarlos.
¿Qué ha cambiado respecto a hace un año?
El primer cambio es que la técnica se vende como producto. SpyCloud describe el device code phishing como una vía de entrada a Microsoft 365 documentada desde al menos 2020, y a EvilTokens como el primer kit comercial que la ofreció a escala, copiado por otras plataformas en cuestión de meses. Ya en abril, Microsoft dijo a The Register que desde el 15 de marzo observaba entre 10 y 15 campañas nuevas cada 24 horas. Que una técnica pase de unos pocos grupos avanzados a mil suscriptores cambia, para cualquier defensor, la probabilidad de que le toque.
El segundo cambio está en el papel de la IA. EvilTokens también la usaba para adaptar el señuelo al cargo de la víctima, sobre 44 temáticas prediseñadas, pero lo que lo separa de kits anteriores ocurre después, dentro del buzón. TRM Labs, que siguió el dinero, lo describe como una compresión del tiempo entre el compromiso y la monetización. Trevor Hilligoss, de SpyCloud, fue más directo: leer buzones en más de veinte idiomas para encontrar la conversación que merece la pena secuestrar era la parte del fraude que exigía a una persona y cuyo rendimiento dependía de su pericia. EvilTokens la ofrecía a cualquiera por 500 dólares al mes.
El tercero es la composición de la coalición. Junto a Microsoft y Health-ISAC, que se personó como codemandante porque había hospitales entre las víctimas, están Cloudflare, Railway, OpenAI, Coinbase, SpyCloud, Shadowserver y TRM Labs: plataformas de alojamiento en la nube, un proveedor de modelos de IA, una plataforma de criptomonedas y firmas de inteligencia de amenazas. Es la cuadragésima acción judicial de la unidad de Microsoft en casi dos décadas y, según Masada, la primera contra un servicio criminal con IA de extremo a extremo.
Por qué revocar la sesión no basta: la lección de EvilTokens
Lo que sigue vale también para otros kits de robo de tokens, como los de adversario en el medio (AiTM). Si un atacante entiende un buzón en minutos, una guía de respuesta que reserva horas para "evaluar el alcance" llega tarde.
La guía de Microsoft describe un problema concreto: en las campañas recientes, la revocación estándar de sesiones invalida los tokens de actualización, pero deja activos hasta una hora los tokens de acceso ya emitidos, y los operadores de estos kits aprovechan esa ventana con frecuencia. Por eso su recomendación, poco habitual, es deshabilitar temporalmente la cuenta comprometida aunque interrumpa el trabajo de alguien. Si hay indicios de que el atacante registró un dispositivo, también hay que deshabilitarlo: es lo que deja sin efecto el Primary Refresh Token, algo que la revocación de tokens por sí sola no consigue.
SpyCloud aporta la otra mitad: los tokens de actualización tienen una ventana de inactividad de 90 días sin caducidad máxima, así que un uso regular prolonga el acceso sin límite. Restablecer la contraseña los invalida en inquilinos gestionados desde la nube, pero en configuraciones híbridas y federadas la revocación puede no propagarse, y todo lo que el atacante registró mientras tanto sigue intacto. Un desmantelamiento de infraestructura no altera ese estado: los tokens ya emitidos a clientes de EvilTokens pueden seguir siendo válidos hasta que cada organización los revoque.
En Hard2bit Cybersecurity el caso ha servido para revisar una suposición que estaba en varias guías de respuesta a incidentes: que restablecer la contraseña y forzar MFA pone fin a una intrusión de identidad. Con device code phishing no lo hace, y la comprobación que faltaba es la de dispositivos, métodos de autenticación y reglas de buzón añadidos durante la ventana de acceso.
¿Qué controles siguen funcionando después de EvilTokens?
Conviene empezar por dos respuestas que todavía aparecen en los cuestionarios de proveedores y que, por sí solas, ya no bastan. "Tenemos MFA activado": el flujo de código de dispositivo completa la autenticación y el segundo factor en la página legítima de Microsoft, así que el atacante recibe tokens con la MFA ya satisfecha. "Bloqueamos los dominios de phishing conocidos": el señuelo se sirve desde Workers, Vercel o Lambda con infraestructura de vida corta; en una sola campaña de abril, Microsoft contó miles de nodos de sondeo efímeros.
Los controles que sí resisten actúan sobre el flujo y sobre lo que pasa después. El primero es bloquear el flujo de código de dispositivo en el acceso condicional de Entra ID salvo para las cuentas de recursos de dispositivos Teams que lo necesiten, con la exclusión que Microsoft documenta para el servicio de registro de dispositivos. Es el control más barato de la lista y, con frecuencia, se encuentra sin aplicar. Los pasos detallados están en nuestra guía sobre cómo bloquear el device code phishing en Microsoft 365.
El segundo es la autenticación resistente al phishing con passkeys o llaves de seguridad FIDO2 para las cuentas con capacidad de pago y administración, que Microsoft, SpyCloud y Cloudflare recomiendan por separado. El tercero es la evaluación continua de acceso (CAE), para que un cambio de riesgo termine la sesión sin esperar a que caduque el token.
En detección, Microsoft ha publicado las alertas con las que cubre esta cadena, y sirven como lista de lo que un SIEM debería cubrir aunque no use Defender: autenticación anómala por código de dispositivo, intercambio de token tras esa autenticación, registro de dispositivo después de un inicio de sesión sospechoso, volumen anómalo de peticiones a Microsoft Graph tras ese inicio de sesión y creación de reglas de buzón a continuación. La secuencia Graph y reglas de buzón es el rastro del chatbot: para leer 5.000 correos hay que pedirlos, y esa petición queda registrada.
Un SOC que correlacione el protocolo de autenticación del inicio de sesión con el volumen de llamadas a Graph de la hora siguiente ve la cadena completa; uno que solo mire el inicio de sesión ve a un usuario legítimo con MFA.
Fuera de la tecnología queda la medida que Masada destaca como lección para las organizaciones, junto a una buena protección de identidades: verificar por un segundo canal de confianza cualquier petición de cambio de datos de pago, desvío de fondos o aprobación de una transacción fuera de lo habitual. Si el atacante ha leído el hilo entero de la negociación, el correo que envía será coherente con todo lo anterior, de modo que la coherencia ya no sirve como prueba.
Lo que sobrevive al desmantelamiento
Lo reconocen los propios participantes. SpyCloud recuerda que existen otras plataformas de phishing como servicio que usan la misma técnica, y Masada advierte de que el modelo demostrado no desaparece con la infraestructura. Las cifras de adopción de los controles que lo frenan no las publica nadie, así que sobre ese punto solo hay observación de campo: en los inquilinos de Microsoft 365 que revisa el equipo de Hard2bit durante una auditoría o una respuesta a incidente, el flujo de código de dispositivo suele seguir habilitado para todos los usuarios porque nadie lo necesitaba y nadie lo bloqueó. Nuestro servicio de seguridad para Microsoft 365 empieza por ahí.
La operación deja dos incógnitas. La primera es cuántos de los 12.000 buzones siguen abiertos a sus compradores: Microsoft ha notificado a los clientes afectados, pero la revocación depende de cada organización. La segunda es qué pasa con los clientes del servicio: la coalición ha compartido con la policía información sobre algunos de ellos, pero no consta ninguna detención. Tampoco coincide la fecha de las detenciones en Londres: The Register y CyberScoop la sitúan el 18 de septiembre; TRM Labs, miembro de la coalición, y The Hacker News, el 11.
Este artículo tiene finalidad divulgativa y defensiva y refleja la información disponible en su fecha de publicación. Los datos sobre EvilTokens proceden de las divulgaciones públicas de Microsoft, SpyCloud, Cloudflare, TRM Labs y los medios citados; las cifras de víctimas, ingresos y pérdidas son las que cada organización ha publicado y pueden evolucionar con la investigación, igual que la atribución a los detenidos, que a fecha de hoy están en libertad bajo fianza y no han sido condenados. No constituye asesoramiento para un caso concreto: si quieres revisar la exposición de tu inquilino de Microsoft 365 al device code phishing, [contacta con el equipo de Hard2bit](/contacto/).