Qué se anunció y qué consta en la página judicial
El 22 de septiembre de 2026, Microsoft publicó una página titulada «EvilTokens» en su sección de notificaciones de documentos judiciales. El material verificado para esta pieza confirma el título, la ubicación de la página y su fecha de publicación, pero no basta para establecer los detalles de las partes, las medidas solicitadas o el estado procesal. Por eso, no corresponde presentar alegaciones específicas ni una resolución judicial como hechos establecidos a partir de esa página.
La cobertura de CSO Online encuadra el caso en un contexto más amplio de ciberdelito relacionado con la inteligencia artificial. Ese enfoque periodístico no demuestra por sí mismo qué papel, si alguno, tuvo la IA en incidentes concretos. Las fuentes disponibles aquí no ofrecen una auditoría independiente que confirme su uso, alcance o efecto en campañas atribuidas a EvilTokens.
Esta limitación también afecta a las cifras de impacto y al alcance de cualquier acción contra la plataforma. Los documentos verificados no aportan un recuento independiente de cuentas afectadas ni describen qué recursos técnicos se retiraron. La página de Microsoft confirma que existe una publicación sobre EvilTokens en una sección judicial, pero no permite reconstruir todos los detalles del asunto. Separar lo documentado de lo que no se ha podido comprobar evita convertir un anuncio o una referencia periodística en un balance confirmado.
El flujo legítimo que puede convertirse en señuelo
La autenticación por código de dispositivo es un flujo de autorización OAuth legítimo, útil para equipos con interfaces limitadas, como televisores, impresoras o dispositivos IoT. El equipo solicita un código y la persona completa la autenticación en un navegador de otro dispositivo. La documentación de Microsoft explica que el cliente espera la respuesta del servicio de autorización mientras el usuario completa el proceso; el código de usuario tiene una validez limitada.
En términos prácticos, el flujo separa el dispositivo que necesita autenticarse del que la persona utiliza para introducir sus credenciales y aprobar la solicitud. El código vincula ambas partes durante un intervalo limitado. Las consultas del cliente permiten que el dispositivo original sepa si la autorización se completó, sin necesidad de que tenga su propia interfaz de inicio de sesión. Esa comodidad es útil cuando el dispositivo carece de teclado o navegador adecuados, pero también hace importante que el usuario comprenda qué solicitud está aprobando.
La documentación permite describir el mecanismo general, pero las fuentes verificadas para esta pieza no bastan para confirmar que EvilTokens lo utilizara en una campaña concreta ni para reconstruir sus pasos técnicos. Como riesgo general de este tipo de flujo, una persona podría ser inducida a introducir un código y aprobar una solicitud que no inició o no reconoce. Un portal legítimo no garantiza que la solicitud que se está aprobando sea legítima. Esa explicación del riesgo no debe confundirse con una descripción verificada de las tácticas de EvilTokens.
Lo que puede decirse sobre la IA
CSO Online relaciona en su titular la interrupción de EvilTokens con el contexto del ciberdelito impulsado por IA. Sin embargo, las fuentes verificadas disponibles no incluyen una investigación independiente que confirme el uso de capacidades de IA en incidentes concretos. Por eso, no cabe presentar la IA como una explicación demostrada del éxito de una campaña vinculada a EvilTokens.
El riesgo general del flujo se entiende sin atribuirlo a una tecnología específica: una persona puede ser inducida a aprobar una solicitud de autenticación que no reconoce. Si esa aprobación permite crear una sesión válida, los controles centrados únicamente en la contraseña no describen por sí solos todo el riesgo. El mecanismo de autorización y la decisión de aprobar la solicitud importan, pero estas consideraciones generales no prueban cómo operaba un servicio específico.
La IA merece atención, pero no es necesario atribuirle un papel en este caso para explicar la precaución práctica. El material disponible no permite determinar si hubo automatización, qué tareas habría realizado ni cuánto habría contribuido. Del mismo modo, sin una fuente verificable para las cifras de cuentas afectadas, no es responsable reproducir un recuento como si estuviera corroborado. Conviene mantener separadas la cobertura sobre el contexto de IA y las conclusiones que realmente pueden extraerse de la documentación.
Qué significa —y qué no— una interrupción
La página de Microsoft confirma una publicación titulada «EvilTokens», pero la información disponible en las fuentes verificadas no permite detallar el número o tipo de recursos técnicos que pudieran haberse retirado. Tampoco permite afirmar que toda la infraestructura relacionada haya desaparecido. La existencia de una página en una sección de notificaciones judiciales no basta para atribuir un resultado técnico concreto a una operación.
En general, interrumpir una plataforma puede dificultar la continuidad de la actividad que se le atribuye, pero no demuestra que todas sus instancias, operadores o copias hayan sido identificados o eliminados. Tampoco prueba que otros actores no puedan recurrir a infraestructuras distintas o reproducir una técnica similar. Estas son limitaciones generales al interpretar un desmantelamiento, no afirmaciones verificadas sobre el alcance de una acción concreta contra EvilTokens.
Con lo que se ha podido verificar, no corresponde afirmar que se hayan eliminado todos los dominios o servicios relacionados ni establecer qué medidas se tomaron contra cada componente. Interrumpir una operación identificada puede reducir su alcance; no elimina por sí solo una técnica de phishing ni impide que otros la reproduzcan. La distinción entre el estado de una plataforma y la posible continuidad de métodos similares ayuda a evitar conclusiones más amplias que las pruebas disponibles.
Medidas defensivas: evaluar antes de bloquear
Para las organizaciones que no necesitan el flujo de código de dispositivo, Microsoft documenta su bloqueo mediante una política de Acceso Condicional. Antes de aplicarla, conviene revisar si la organización utiliza ese flujo y qué inicios de sesión podrían verse afectados. La documentación sobre flujos de autenticación explica cómo usar ese tipo de flujo como condición en una política; no implica que todas las organizaciones deban aplicar un bloqueo idéntico.
La revisión previa importa porque un bloqueo indiscriminado podría interrumpir dispositivos o procesos que dependan legítimamente de este método. Si hacen falta excepciones, es prudente limitarlas a necesidades identificadas y revisarlas cuando cambien los sistemas o sus usos. La recomendación práctica es reducir los flujos innecesarios sin asumir que el código de dispositivo carece de usos legítimos, y probar la configuración antes de aplicarla ampliamente. Esta es una orientación operativa basada en la documentación del control, no una afirmación de que una política concreta sea adecuada para todos los entornos.
Para las personas usuarias, una señal de alerta útil es recibir una petición inesperada para copiar un código o aprobar un inicio de sesión. Si no se ha iniciado personalmente la autenticación y no se entiende qué dispositivo o aplicación la solicita, conviene no completar el proceso y verificar la petición por un canal conocido. La apariencia del portal no permite determinar por sí sola quién inició la solicitud asociada al código; también importa el contexto. Para los equipos de seguridad, el caso puede motivar la revisión de los flujos habilitados y de los inicios de sesión que resulten inusuales. La recomendación no es abandonar la MFA, sino combinarla con políticas ajustadas a las necesidades y con atención al contexto de cada aprobación.