Ataque de phishing Microsoft: Alerta por la campaña EvilTokens

La ciberseguridad corporativa se enfrenta a una evolución alarmante. En el panorama actual de 2026, las amenazas no solo han aumentado en volumen, sino en sofisticación técnica, alejándose de los ataques tradicionales de suplantación de identidad para adoptar tácticas que explotan la confianza inherente en los flujos de trabajo legítimos de las plataformas en la nube. Un ejemplo crítico de esta nueva era es la campaña de phishing Microsoft impulsada por el kit “EvilTokens”, una amenaza que ha logrado evadir las medidas de seguridad convencionales al secuestrar un protocolo de autenticación legítimo diseñado para facilitar la interoperabilidad de dispositivos.

La anatomía de un ataque invisible: El abuso del Device Code Flow

Para comprender por qué esta campaña es tan efectiva, debemos desglosar cómo funciona la autenticación de dispositivos con Microsoft Entra ID. El flujo de código de dispositivo (*device code flow*) fue creado para resolver una limitación técnica: cómo autenticar dispositivos con capacidades de entrada reducidas, como smart TVs, impresoras o dispositivos IoT, donde no es práctico ingresar credenciales complejas. En este flujo, el dispositivo genera un código alfanumérico y solicita al usuario que lo ingrese en un navegador desde otro dispositivo (un equipo o teléfono) para completar la autenticación.

La genialidad —y el peligro— de “EvilTokens” radica en su simplicidad operativa: no crea una página de inicio de sesión falsa, ni intenta interceptar contraseñas. En su lugar, el atacante inicia un flujo de autenticación legítimo con Microsoft para obtener un código de dispositivo real. Posteriormente, mediante técnicas avanzadas de ingeniería social, induce a la víctima a ingresar ese código en la página oficial *microsoft.com/devicelogin*.

Desde la perspectiva del usuario y del sistema de seguridad, el proceso es impecable: la víctima se autentica en la infraestructura legítima de Microsoft y completa su propia autenticación multifactor (MFA). El resultado para el atacante es devastador: recibe un token de sesión legítimo que le otorga acceso persistente a los recursos de la víctima, incluyendo correo electrónico, archivos en SharePoint, OneDrive y el historial de Microsoft Teams, sin haber tocado nunca las credenciales de acceso del usuario.

EvilTokens: El salto hacia el phishing como servicio automatizado

Lo que diferencia a esta campaña de incidentes anteriores es el uso de un ecosistema de automatización avanzada bajo el modelo de phishing como servicio (PhaaS). La plataforma EvilTokens, identificada por investigadores de seguridad a finales de marzo de 2026, ha estandarizado y masificado el abuso del *device code flow* mediante varias capas de automatización:

• Generación dinámica de códigos: A diferencia de scripts estáticos, la infraestructura de EvilTokens genera códigos de dispositivo en tiempo real solo cuando la víctima interactúa con el enlace, lo que permite eludir las ventanas de expiración estándar (usualmente de 15 minutos) y aumentar la tasa de éxito.
• Lures hiperpersonalizados: Utilizando modelos de lenguaje generativo (LLM), los atacantes crean correos electrónicos de phishing altamente convincentes que se adaptan al rol del usuario, imitando notificaciones de Adobe Sign, avisos de cuarentena de correo, invitaciones de calendario o solicitudes de acceso a documentos internos.
• Infraestructura distribuida: El uso de plataformas en la nube para desplegar miles de nodos de sondeo efímeros permite a los atacantes procesar grandes volúmenes de objetivos sin que las direcciones IP o los dominios sean rápidamente bloqueados por las listas negras de reputación tradicionales.
• Post-compromiso automatizado: Una vez capturado el token, la plataforma automatiza las acciones posteriores: desde el espionaje de correos electrónicos financieros hasta la creación de reglas de reenvío de bandejas de entrada para ocultar la actividad persistente.

Por qué los métodos de defensa tradicionales fracasan

La efectividad de este tipo de phishing Microsoft se debe a que la mayoría de los controles de seguridad están diseñados para detectar anomalías en la página de inicio de sesión o intentos de suplantación de identidad (AitM). Dado que la víctima nunca interactúa con una página maliciosa, los filtros de URL y las herramientas de detección de *phishing* basadas en la reputación de dominios suelen permitir el tráfico hacia el portal legítimo de Microsoft.

Además, al ser el usuario quien completa su propio proceso de MFA, los mecanismos de doble factor no actúan como una barrera, sino como el paso final que sella la brecha de seguridad. Para el sistema de registro de eventos (logs), la actividad parece una sesión iniciada por un dispositivo reconocido o legítimamente autorizado, dificultando su identificación sin un análisis correlacionado profundo.

Estrategias de mitigación en entornos Entra ID

La mitigación contra el abuso del *device code flow* requiere un cambio de paradigma hacia un enfoque de “Zero Trust” (Confianza Cero) más estricto, donde la autenticación no sea considerada segura solo porque el flujo es legítimo.

1. Desactivación proactiva: La recomendación fundamental de Microsoft es limitar el uso del *device code flow* tanto como sea posible. Si no existen requisitos operativos que lo justifiquen en toda la organización, esta funcionalidad debería ser bloqueada de forma preventiva mediante políticas de Acceso Condicional (Conditional Access).
2. Políticas de Acceso Condicional (CAP): Para organizaciones que requieren este flujo, se deben implementar políticas de Acceso Condicional que restrinjan su uso. Se pueden configurar políticas para bloquear la autenticación basada en *device code* excepto para aplicaciones específicas o grupos de usuarios definidos, combinando esta restricción con requisitos de cumplimiento de dispositivo (ej. dispositivos administrados o unidos a Intune/Entra ID).
3. Análisis de comportamiento y logs: Los equipos de seguridad deben monitorear los registros de inicio de sesión (*sign-in logs*) de Entra ID buscando explícitamente el uso del método de autenticación “Device code”. Se deben establecer alertas de alta prioridad para cualquier uso de este flujo que no provenga de direcciones IP conocidas, dispositivos gestionados o patrones de uso esperados.
4. Capacitación de usuario de nueva generación: Las sesiones de concienciación deben evolucionar. Ya no es suficiente pedir a los usuarios que “no hagan clic en enlaces sospechosos”. Deben entender que incluso cuando se les dirige a una página oficial de Microsoft, la legitimidad de la URL no garantiza la seguridad si el usuario está siendo guiado por un tercero para autorizar un “dispositivo” desconocido.

Conclusión: Un reto de identidad persistente

El auge de EvilTokens y campañas similares pone de relieve una verdad ineludible en el entorno de TI actual: la conveniencia tecnológica es a menudo el talón de Aquiles de la seguridad. El *device code flow*, aunque extremadamente útil para la interoperabilidad en un mundo de dispositivos diversos, se ha convertido en una vía de ataque de bajo esfuerzo y alta recompensa para los actores de amenazas.

La lucha contra este tipo de phishing Microsoft no se ganará con una única solución tecnológica, sino mediante una estrategia de defensa en profundidad. La restricción explícita de los flujos de autenticación, la aplicación rigurosa de políticas de cumplimiento de dispositivos y el monitoreo granular de los registros de identidad son pilares necesarios para cerrar las brechas que los atacantes aprovechan para mantener una persistencia silenciosa. A medida que avanzamos en 2026, la resiliencia organizacional dependerá de nuestra capacidad para cuestionar no solo lo que es malicioso, sino también lo que es “demasiado conveniente” dentro de nuestras infraestructuras de identidad.