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/).
Preguntas frecuentes
¿Qué era EvilTokens y desde cuándo funcionaba?
▾
Un servicio de phishing por suscripción anunciado en Telegram desde comienzos de 2026 (Microsoft lo fecha en febrero; Cloudflare, en enero) que vendía por 1.500 dólares de alta y 500 al mes un panel para robar tokens de Microsoft 365 mediante device code phishing. Lo distinguía del resto un chatbot que analizaba el buzón comprometido y preparaba el fraude: identificaba a quien autorizaba pagos, localizaba facturas pendientes y redactaba el correo de suplantación. Microsoft atribuye su desarrollo al actor que sigue como Storm-2992.
¿Cuántas organizaciones se vieron afectadas y de dónde salen las cifras?
▾
Microsoft vincula el servicio a más de 12.000 buzones en más de 10.000 organizaciones. SpyCloud, con los datos que recuperó de la infraestructura del kit, contabiliza 8.708 cuentas en 6.585 dominios corporativos de 79 países; las dos cifras se solapan y miden lo mismo desde dos observatorios distintos, así que no se suman. Las pérdidas conocidas son parciales: Microsoft correlacionó 13 denuncias ante el IC3 por unos 1,7 millones de dólares y advierte de que es una estimación a la baja.
¿En qué se diferencia un desmantelamiento de infraestructura de una remediación en mi inquilino?
▾
Son dos operaciones sobre cosas distintas. El desmantelamiento actúa sobre lo que era del delincuente: dominios, Workers, el panel y las cuentas en Telegram. Lo que el delincuente obtuvo de cada víctima (tokens de actualización, un dispositivo registrado, una regla de buzón) vive en el inquilino de la víctima, y ahí ni Microsoft ni el tribunal han tocado nada. Por eso la incautación puede dejar a un comprador del kit con acceso operativo a un buzón durante semanas, y por eso la remediación tiene que hacerla cada organización dentro de su propio inquilino.
¿Por qué el device code phishing funciona aunque la empresa tenga MFA?
▾
Porque la MFA la satisface la víctima y el token lo recibe otro. Para el registro de inicio de sesión de Entra ID, lo que ocurrió es un inicio de sesión legítimo, con contraseña y segundo factor correctos, en una página de Microsoft; lo único distinto es el protocolo de autenticación, que aparece como código de dispositivo. Eso explica por qué el control eficaz es bloquear ese flujo o exigir métodos resistentes al phishing, y por qué añadir un segundo factor más al mismo flujo no cambia el resultado.
¿Qué rastro deja el chatbot en los registros de Microsoft 365?
▾
Tres eventos en un orden concreto: un inicio de sesión cuyo protocolo es código de dispositivo, un pico de peticiones a Microsoft Graph en la hora siguiente (el panel pedía hasta 5.000 correos) y, después, un registro de dispositivo o una regla de buzón nueva. Cada uno por separado es ruido; la secuencia es el chatbot. Microsoft tiene alertas para cada eslabón en Defender, y quien use otro SIEM puede reconstruir la misma secuencia con los registros de inicio de sesión de Entra ID y el registro de auditoría de Microsoft 365.
¿Debo bloquear el device code flow en mi inquilino de Entra ID?
▾
Sí, salvo que tengas un motivo documentado para no hacerlo. Microsoft recomienda bloquear el flujo de código de dispositivo mediante una política de acceso condicional; si la organización usa dispositivos Teams o salas de reuniones que dependen de él, la excepción debe limitarse a sus cuentas de recursos y excluir el servicio de registro de dispositivos. Antes de bloquearlo, revisa en los registros de inicio de sesión quién lo ha usado recientemente (Entra ID los conserva 30 días con licencia P1 o P2; si los exportas a un SIEM, puedes mirar más atrás): si la respuesta es nadie, la política no romperá nada.
¿Qué hago si sospecho que una cuenta de mi empresa fue capturada por EvilTokens?
▾
Tratarla como una intrusión de identidad completa, no como un phishing de contraseña. En la práctica: deshabilitar la cuenta antes que solo revocar sesiones, retirar los dispositivos y métodos de autenticación añadidos en la ventana sospechosa, borrar reglas de buzón y aplicaciones autorizadas, y reconstruir con el registro de auditoría qué correos se leyeron y a quién se escribió desde la cuenta. Con esa lista, avisar a las personas y proveedores con los que el atacante ha podido conversar en nombre de la víctima, porque el fraude suele llegar por un correo posterior, ya coherente con todo lo leído.
¿Quién participó en la operación contra EvilTokens y qué sigue pendiente?
▾
Microsoft y Health-ISAC como demandantes, con autorización del tribunal federal del distrito este de Virginia, junto a Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, Shadowserver y TRM Labs; en Londres, la Policía Metropolitana detuvo a dos hombres que siguen en libertad bajo fianza. Cada socio aportó su propia pieza: Cloudflare desactivó Workers y cuentas, Coinbase y TRM Labs siguieron el dinero, SpyCloud aportó los datos de víctimas; de OpenAI y Railway, Microsoft no detalla el papel. Lo que no cubre la operación son los suscriptores del servicio: la coalición ha compartido con la policía información sobre algunos de ellos, pero no consta ninguna detención.
