La interrupción de Microsoft EvilTokens expone una cadena de fraude guiada por IA
Microsoft interrumpió EvilTokens después de que el servicio comprometiera más de 12.000 bandejas de correo en más de 10.000 organizaciones de todo el mundo. La interrupción de Microsoft EvilTokens se dirigió contra infraestructura que respaldaba un sistema empaquetado para phishing, acceso a cuentas, análisis de buzones y fraude financiero.
La operación es relevante porque EvilTokens hizo más que ayudar a delincuentes a redactar mensajes persuasivos. Su asistente de IA examinaba bandejas de entrada robadas, trazaba relaciones comerciales, identificaba la autoridad de pago y recomendaba a quién suplantar.
Esa capacidad comprimió un trabajo que antes exigía paciencia y conocimientos especializados. Sin embargo, desactivar infraestructura no elimina la técnica subyacente. El phishing con código de dispositivo sigue disponible, las sesiones robadas pueden sobrevivir a los restablecimientos de contraseña y servicios relacionados pueden copiar el modelo operativo.
La interrupción de Microsoft EvilTokens golpeó una plataforma integral de fraude
Microsoft y sus socios atacaron la infraestructura que conectaba el phishing inicial con el engaño financiero dirigido.
Microsoft anunció la acción coordinada el 22 de septiembre de 2026. Su Digital Crimes Unit obtuvo autorización judicial para incautar infraestructura activa y redirigir dominios asociados con el servicio.
La acción involucró a Health-ISAC, empresas tecnológicas, investigadores financieros, investigadores de seguridad y fuerzas del orden. Cloudflare desactivó por separado proyectos de Workers y cuentas que respaldaban campañas de EvilTokens.
Según los registros judiciales, Microsoft y Health-ISAC presentaron su caso en el Distrito Este de Virginia. Los demandados identificados son Felix Utomi, Waidi Segun Adams y varias personas no identificadas.
Microsoft atribuyó el desarrollo y soporte de EvilTokens a un actor de amenazas al que rastrea como Storm-2992. La atribución en este contexto representa la evaluación de Microsoft, no una condena penal.
La operación habría incautado 50 sitios web y desactivado más de 150 dominios adicionales. La policía británica también arrestó a dos hombres en relación con EvilTokens, según información independiente.
Los hombres fueron puestos en libertad bajo fianza condicional mientras continuaba la investigación. Sus detenciones no deben interpretarse como declaraciones de culpabilidad.
Cloudflare afirmó que la operación coordinada contra la infraestructura comenzó el 15 de septiembre. La empresa identificó cientos de cuentas de clientes vinculadas con actividad de EvilTokens y desactivó los proyectos de apoyo.
Ese enfoque combinado, legal y técnico, fue necesario porque EvilTokens dependía de servicios operados por proveedores no relacionados. Su infraestructura atravesaba plataformas de alojamiento, registradores de dominios, servicios de comunicación, sistemas de pago y redes en la nube.
EvilTokens surgió a principios de 2026 y ganó rápidamente adopción entre atacantes motivados financieramente. Microsoft lo vinculó con más de 12.000 bandejas de entrada comprometidas en más de 10.000 organizaciones en cuestión de meses.
Las mayores concentraciones de actividad observada entre las víctimas aparecieron en Estados Unidos, Canadá, Reino Unido, Australia, India y Francia. Los sectores afectados incluyeron construcción, finanzas, salud, bienes raíces, distribución mayorista y educación superior.
Estas cifras describen actividad observada, no un censo completo. Algunas cuentas comprometidas pueden seguir sin descubrirse, mientras que una sola organización puede contener varias bandejas de entrada afectadas.
El enfoque empresarial fue especialmente marcado. Datos de SpyCloud citados por periodistas de seguridad clasificaron aproximadamente el 97,5 por ciento de las cuentas identificadas como pertenecientes a dominios corporativos.
EvilTokens también generó ingresos considerables. Coinbase habría rastreado aproximadamente 1,1 millones de dólares en ingresos hasta la operación mientras colaboraba con la investigación.
Estas cifras explican la escala, pero no capturan el cambio central. EvilTokens conectó varias tareas delictivas previamente separadas mediante una única interfaz gestionada.
Los suscriptores recibían herramientas de campaña, plantillas de phishing, gestión de tokens, seguimiento de víctimas, búsquedas en buzones y orientación posterior al compromiso. Los canales de soporte y paneles administrativos hacían que la operación se pareciera a un servicio comercial de software.
La distinción es importante para los defensores. Eliminar un dominio malicioso puede interrumpir una campaña, pero no desmantela un modelo de servicio transferible.
Microsoft describió la acción como una interrupción, no como prueba de que todos los operadores, suscriptores y sistemas relacionados hubieran desaparecido. Por tanto, los equipos de seguridad deben esperar una reducción de la actividad, no una eliminación permanente.
Cómo EvilTokens convirtió un inicio de sesión legítimo en acceso a cuentas
EvilTokens explotó la confianza de los usuarios en la página real de autenticación de Microsoft, en lugar de depender solo de un formulario de inicio de sesión falsificado.
La plataforma se centraba en el phishing con código de dispositivo. Esta técnica abusa de un flujo de autenticación OAuth diseñado para dispositivos que carecen de teclados cómodos o navegadores completos.
Los televisores inteligentes, las impresoras, los equipos de conferencia y algunos dispositivos Teams pueden utilizar este proceso. Un dispositivo muestra un código breve, mientras el usuario completa la autenticación en otra pantalla.
En un flujo malicioso, el atacante inicia la solicitud y envía su código al objetivo. Un mensaje engañoso persuade a esa persona para introducir el código mediante la página legítima de inicio de sesión de dispositivos de Microsoft.
La víctima puede ver un dominio válido de Microsoft y completar la autenticación multifactor habitual. Sin embargo, esa aprobación autoriza la sesión en espera del atacante, no la actividad que esperaba la víctima.
No es necesario que ninguna contraseña pase por un sitio web falsificado. Esa característica debilita los consejos habituales centrados en revisar un dominio o negarse a introducir credenciales en páginas sospechosas.
El panel de EvilTokens ayudaba a los suscriptores a integrar este proceso en señuelos realistas. Microsoft identificó 44 temas que abarcaban facturas, archivos compartidos, solicitudes de firma, avisos de contraseña, prestaciones, propuestas y asociaciones comerciales.
Las campañas utilizaban enlaces, documentos PDF, adjuntos HTML, redirecciones y páginas de verificación imitadas. El servicio también empleaba plataformas legítimas en la nube y sitios web comprometidos para hacer más difícil clasificar la infraestructura.
Una vez que una víctima aprobaba el código, EvilTokens capturaba un token de autenticación. Un token es un artefacto digital que permite a una sesión autorizada acceder a servicios específicos sin repetir la contraseña.
Los tokens robados podían proporcionar acceso al correo electrónico y a recursos relacionados de Microsoft 365. Los operadores también podían actualizar tokens, inspeccionar privilegios administrativos y recibir alertas de palabras clave del buzón a través de Telegram.
Microsoft observó casos en los que los atacantes creaban reglas maliciosas de bandeja de entrada para ocultar mensajes. En algunos incidentes, registraban dispositivos para establecer un acceso más duradero poco después del compromiso inicial.
Esta persistencia cambia la respuesta ante incidentes. Restablecer una contraseña no termina necesariamente una sesión ya autorizada ni elimina un dispositivo registrado.
Los defensores deben revocar sesiones y actualizar tokens, inspeccionar registros de autenticación, eliminar dispositivos no autorizados y examinar las reglas del buzón. De lo contrario, el atacante podría conservar el acceso después de que cambie la credencial visible.
El análisis técnico recomienda bloquear la autenticación con código de dispositivo cuando una organización no la necesite. Las excepciones necesarias deben limitarse a cuentas específicas y dispositivos aprobados.
Las organizaciones también deben vigilar solicitudes inesperadas de código de dispositivo e inicios de sesión de riesgo. Los usuarios deben rechazar códigos asociados a procesos de autenticación que no hayan iniciado personalmente.
La autenticación resistente al phishing, incluidas las passkeys y las claves de seguridad FIDO2, puede reforzar la protección. Sin embargo, una autenticación más sólida por sí sola no puede corregir todas las vías de ingeniería social cuando se engaña a los usuarios para que aprueben una solicitud válida.
Esa limitación representa la disyuntiva de seguridad más profunda. La autenticación con código de dispositivo es compatible con hardware de interfaces limitadas, pero su proceso de aprobación separado debilita la conexión entre la intención del usuario y la sesión solicitante.
Los atacantes no vulneraron el cifrado de Microsoft ni calcularon la contraseña de una víctima. Manipularon un mecanismo de autorización legítimo hasta que la víctima concedió acceso.
La lección va más allá de una plataforma. Todo flujo de trabajo de seguridad que separe una solicitud de su aprobación necesita un contexto claro y controles de política estrictos.
Los usuarios deben entender qué están autorizando, qué aplicación solicitó el acceso y dónde operará la sesión resultante. Las solicitudes de aprobación genéricas abren espacio para el engaño.
EvilTokens hizo que ese engaño fuera repetible. Su aportación no fue inventar el phishing con código de dispositivo, sino empaquetarlo para un uso más amplio y rápido.
La IA pasó de redactar señuelos a elegir objetivos de fraude
La capacidad definitoria de EvilTokens apareció después del compromiso de la cuenta, cuando la IA convirtió un buzón desconocido en un plan de fraude práctico.
La IA generativa suele asociarse con correos de phishing pulidos. EvilTokens la aplicó a un problema más valioso: comprender la organización de una víctima después de obtener acceso.
Un buzón comprometido puede contener años de conversaciones, adjuntos, facturas, aprobaciones, nombres y relaciones jerárquicas. Esa información es valiosa, pero revisarla manualmente exige tiempo y criterio.
EvilTokens automatizó gran parte de ese trabajo. Sus herramientas podían resumir y traducir mensajes, identificar conversaciones financieras, trazar roles organizativos y revelar relaciones externas de confianza.
Las búsquedas predefinidas supuestamente localizaban conversaciones sobre transferencias bancarias, facturas, responsabilidades de pago y empleados que podían autorizar transacciones. Microsoft afirmó que el asistente también podía recomendar a quién debía suplantar un atacante.
La plataforma ayudaba después a generar mensajes que coincidían con el contexto robado. Una solicitud fraudulenta podía hacer referencia a un proyecto, proveedor, gerente, factura o conversación en curso reales.
Este proceso facilita el compromiso de correo electrónico empresarial, o BEC. En un ataque BEC, los delincuentes suplantan a participantes de confianza para redirigir pagos o inducir otras acciones de valor financiero.
El BEC tradicional suele depender de operadores experimentados. Deben estudiar patrones de comunicación, reconocer la autoridad, esperar una transacción útil y construir una intervención plausible.
EvilTokens redujo esa carga de investigación. Según la información sobre la operación, tareas que podrían consumir varios días podían condensarse en horas.
Esa compresión importa más que una mejora marginal de la gramática. Un correo de phishing genérico bien redactado aún debe llegar a la persona adecuada en el momento oportuno.
El análisis del buzón proporciona al atacante oportunidad, contexto y conocimiento organizativo. La IA puede convertir esos detalles dispersos en una lista priorizada de oportunidades prometedoras.
La tecnología también ayudó a suscriptores menos experimentados. Un operador nuevo no necesitaba conocimientos profundos sobre sistemas de identidad, ingeniería social, reconocimiento de correo electrónico y fraude de pagos.
EvilTokens combinó esas especialidades en un flujo de trabajo guiado. Su chatbot actuaba menos como un asistente de redacción y más como un analista que aconsejaba el siguiente paso del atacante.
Microsoft también encontró indicios de que gran parte de la propia plataforma fue construida con programación asistida por IA. Esa conclusión sugiere que la IA redujo las barreras tanto para los desarrolladores de la plataforma como para los clientes.
El hallazgo no significa que la IA haya creado u operado el servicio de forma autónoma. Los humanos siguieron construyendo el negocio, seleccionando objetivos, gestionando la infraestructura y actuando según las recomendaciones del sistema.
Tampoco establece que un modelo comercial concreto proporcionara todas las capacidades de IA. Microsoft afirmó que los investigadores observaron el uso de varios modelos de IA.
Por lo tanto, la evidencia pública respalda una conclusión más acotada. Las herramientas de IA existentes ayudaron a los delincuentes a desarrollar software e interpretar información robada con mayor eficiencia.
Esto representa un cambio significativo en la economía delictiva. Una clasificación más rápida de los buzones permite a un operador examinar a más víctimas sin ampliar proporcionalmente el personal ni los conocimientos especializados.
La escala también mejora la selección. Los atacantes pueden abandonar antes las oportunidades poco prometedoras y concentrarse en cuentas vinculadas al control de pagos, proveedores de confianza o altos ejecutivos.
La interrupción de EvilTokens por parte de Microsoft apuntó a esta capa de conversión entre el acceso no autorizado y la monetización. Esa capa explica por qué el servicio atrajo atención más allá de la infraestructura de phishing convencional.
Un buzón robado ya es perjudicial por sí mismo. Un sistema que explica rápidamente cómo explotar ese buzón puede aumentar tanto la velocidad como el valor esperado de la intrusión.
Este modelo ejercerá presión sobre los equipos de identidad, los proveedores de seguridad del correo electrónico y las empresas de IA. Cada uno controla solo una parte de una cadena de ataque que atraviesa varios servicios independientes.
Los proveedores de IA pueden suspender cuentas abusivas, pero los atacantes pueden cambiar de modelo. Las plataformas de alojamiento pueden retirar infraestructura, pero los operadores pueden trasladarse entre proveedores.
Los proveedores de identidad pueden bloquear sesiones sospechosas, aunque las funciones de autenticación legítimas deben seguir atendiendo a dispositivos reales. Los defensores deben coordinarse a través de esas fronteras más rápido de lo que los delincuentes pueden reconstruirse.
Por qué la desarticulación de EvilTokens no pone fin al phishing mediante códigos de dispositivo
La operación eliminó infraestructura importante, pero la debilidad subyacente de autenticación y la demanda delictiva siguen intactas.
Los informes de seguridad ya han identificado APToken como un servicio relacionado o derivado. Su aparición ilustra cómo los afiliados pueden reproducir un diseño exitoso de phishing como servicio.
La relación exacta entre estos clones y Storm-2992 sigue siendo incierta. Las funciones similares no prueban una propiedad común ni una infraestructura compartida.
Aun así, el riesgo de copia es evidente. EvilTokens demostró la demanda de un producto integrado que combina el robo de tokens, el análisis de buzones y la preparación de fraudes.
Sus operadores también difundieron conocimientos mediante soporte al cliente, tutoriales, interfaces y relaciones con socios. Desactivar servidores no puede borrar las habilidades que ya aprendieron los suscriptores.
Por eso es importante la palabra “interrupción”. Microsoft y sus socios obstaculizaron las operaciones actuales, recopilaron inteligencia, elevaron los costes operativos y respaldaron investigaciones en curso.
Estos logros pueden reducir el volumen inmediato de ataques. No garantizan que todos los clientes perdieran el acceso, que todos los tokens robados fueran revocados o que todas las víctimas recibieran una notificación.
El caso legal podría revelar más sobre la organización y la red financiera de la plataforma. Las investigaciones de las fuerzas del orden también podrían dar lugar a arrestos, acusaciones o incautaciones adicionales.
Hasta entonces, varias afirmaciones centrales dependen principalmente de la telemetría de Microsoft y de las empresas participantes. Su acceso les proporciona una visibilidad valiosa, pero ningún proveedor ve todo el mercado delictivo.
El total de víctimas también puede cambiar a medida que los socios correlacionen registros. Los 12.000 buzones comunicados representan un mínimo documentado vinculado a las observaciones actuales.
Medir la pérdida financiera directa plantea un problema aún más difícil. No todos los buzones comprometidos produjeron un fraude de pago exitoso, mientras que algunas organizaciones pueden evitar la divulgación pública.
El papel de la IA también exige precisión. EvilTokens utilizó IA para el desarrollo de software, la creación de señuelos, la traducción, el análisis de buzones y las recomendaciones de objetivos.
Sin embargo, los informes públicos no cuantifican con qué frecuencia esas funciones produjeron fraude exitoso. Tampoco comparan las tasas de éxito con campañas sin apoyo de IA.
La evidencia muestra integración operativa, no una prueba controlada de eficacia. Por lo tanto, las afirmaciones de que la IA por sí sola causó la escala de la plataforma irían más allá de los datos disponibles.
EvilTokens se benefició de varias capacidades no relacionadas con la IA. Entre ellas figuraban la persistencia de tokens, la infraestructura automatizada, las plantillas reutilizables, las redirecciones evasivas y el acceso a servicios legítimos en la nube.
Su popularidad probablemente reflejaba ese paquete completo. La IA agilizó partes del flujo de trabajo, pero el servicio circundante convirtió esas capacidades en operaciones repetibles.
Los defensores deben evitar responder únicamente con otro producto de IA. Los controles inmediatos siguen siendo las políticas de identidad, la visibilidad de sesiones, la verificación de usuarios, la inteligencia de infraestructura y la respuesta coordinada a incidentes.
Las organizaciones que no requieren autenticación mediante códigos de dispositivo pueden desactivarla. Aquellas que necesitan esta función pueden limitarla mediante Acceso condicional y cuentas de recursos dedicadas.
Los equipos de seguridad también deben buscar registros inesperados de dispositivos, actividad de actualización de tokens, cambios en reglas de buzón, accesos inusuales a Graph y aprobaciones de aplicaciones desconocidas.
La guía sobre códigos de dispositivo de Microsoft ofrece una vía de política para restringir el flujo de autenticación. La implementación sigue requiriendo pruebas con equipos legítimos y procesos empresariales.
Las defensas de correo electrónico deben tener en cuenta los mensajes que llevan a los usuarios a dominios auténticos. Un destino de confianza no puede compensar una solicitud fraudulenta ni un contexto engañoso.
Por ello, la capacitación debe enfatizar el inicio y la intención. Los usuarios deben introducir un código de dispositivo solo cuando hayan iniciado el correspondiente inicio de sesión en un dispositivo conocido.
Las organizaciones también necesitan procedimientos rápidos para casos sospechosos de robo de tokens. Los centros de soporte deben saber que un simple restablecimiento de contraseña puede dejar activa la sesión hostil.
La documentación es importante durante estos incidentes porque los equipos de identidad, correo electrónico, jurídico, finanzas y dirección suelen necesitar la misma evidencia. Una base de conocimiento técnico consultable puede preservar decisiones, indicadores y responsables de remediación.
Esa disciplina operativa ayuda a cerrar la brecha que EvilTokens explotó. Los delincuentes utilizaron la automatización para coordinar su lado, mientras que muchos defensores aún dividen la evidencia entre sistemas desconectados.
Qué sigue tras la interrupción de EvilTokens por parte de Microsoft
Tres señales mostrarán si esta operación produjo presión duradera o solo una reducción temporal de las campañas.
La primera señal es la actividad medible de EvilTokens tras la acción contra la infraestructura. Los proveedores de seguridad deben vigilar una reducción del phishing mediante códigos de dispositivo, cambios de dominios y la migración a otros servicios en la nube.
Un descenso sostenido indicaría que las incautaciones de dominios y la coordinación entre proveedores dañaron algo más que una capa desechable de campaña. Un regreso rápido sugeriría que los operadores conservaron clientes, herramientas e infraestructura alternativa.
La evaluación de amenazas de Cloudflare ofrece indicadores útiles y describe la desarticulación coordinada. Las futuras actualizaciones de los proveedores participantes pueden mostrar si reaparece infraestructura relacionada.
La segunda señal es la adopción por parte de clones y competidores. APToken y servicios similares merecen atención porque pueden preservar el modelo comercial sin reutilizar la marca EvilTokens.
Los investigadores deben comparar sus métodos de autenticación, funciones de análisis de buzones, redes de soporte e infraestructura. El código o los operadores compartidos reforzarían el argumento de continuidad.
Los servicios independientes que adopten el mismo diseño apuntarían a un cambio más amplio del mercado. Mostraría que el análisis posterior al compromiso guiado por IA se ha convertido en una función estándar de los productos delictivos.
La tercera señal es el resultado jurídico e investigativo. El caso civil de Microsoft identifica a presuntos operadores, mientras que las autoridades británicas continúan su investigación independiente.
Las presentaciones judiciales adicionales podrían aclarar la propiedad, los flujos de ingresos, las relaciones con clientes y el control de la infraestructura. Las acusaciones penales o las incautaciones financieras aumentarían la presión tanto sobre los operadores como sobre los compradores del servicio.
Un resultado débil de la aplicación de la ley no invalidaría la interrupción técnica. Sin embargo, podría limitar la disuasión si los operadores de reemplazo creen que el riesgo legal sigue siendo manejable.
Los defensores también deben vigilar la respuesta de producto de Microsoft. EvilTokens abusó de un flujo de trabajo legítimo, no de una vulnerabilidad de software con una corrección sencilla.
Microsoft puede mejorar los avisos, la detección, los controles de tokens y la visibilidad de los administradores. Sin embargo, debe preservar la autenticación mediante códigos de dispositivo para equipos compatibles y escenarios de inicio de sesión accesibles.
Ese equilibrio vuelve especialmente importantes los valores predeterminados de las políticas. Los valores predeterminados seguros pueden reducir la exposición sin exigir que todas las organizaciones comprendan una técnica especializada de abuso de OAuth.
Los proveedores de nube e identidad afrontan una cuestión de diseño más amplia. Las pantallas de aprobación deben comunicar qué dispositivo, aplicación y sesión recibirán acceso.
Los usuarios también necesitan una advertencia clara cuando el contexto solicitante difiere de su dispositivo actual. Un contexto mejor puede hacer que una página de inicio de sesión legítima sea menos útil como prueba social para los atacantes.
Las empresas de IA tienen otro papel. La detección de abusos puede identificar cuentas que analizan repetidamente correspondencia robada, generan mensajes de suplantación o automatizan flujos de trabajo delictivos conocidos.
Esos controles no detendrán los modelos operados fuera de las principales plataformas. Aun así, pueden elevar los costes y aportar evidencia cuando los delincuentes dependen de servicios comerciales.
La contienda más amplia enfrenta la automatización delictiva empaquetada con una defensa coordinada. EvilTokens tuvo éxito porque combinó abuso de identidad, infraestructura en la nube, análisis de IA y experiencia en fraude.
La respuesta utilizó un modelo igualmente conectado. Microsoft combinó autoridad judicial, inteligencia de amenazas, aplicación de políticas de plataforma, rastreo financiero y cooperación con las fuerzas del orden.
Esa simetría es la lección central de la interrupción de EvilTokens por parte de Microsoft. Ningún producto de seguridad individual puede abordar una cadena de ataque construida sobre varios sistemas legítimos.
Las organizaciones deben comenzar confirmando si la autenticación mediante códigos de dispositivo es necesaria y luego revisar las políticas, los procedimientos de revocación de sesiones y la cobertura de monitorización. También deben probar con qué rapidez los equipos de finanzas pueden validar solicitudes de pago inusuales.
El próximo servicio malicioso puede usar otro nombre, modelo o proveedor de alojamiento. La pregunta importante es si los defensores pueden reconocer el flujo de trabajo antes de que la comunicación robada se convierta en un plan de fraude convincente.
