A finales de junio y principios de julio de 2026 se ha registrado una campaña de phishing mediante el mecanismo Device Code Flow, dirigida a cuentas de Microsoft 365. Según ZeroBEC, los atacantes utilizaron señuelos en forma de invitaciones a colaborar, redirigiendo a las víctimas a la página legítima de autenticación de Microsoft, en lugar de a un formulario falso de introducción de contraseña. Paralelamente, Cisco Talos ha revelado el panel de operador ARToken, totalmente funcional, para ataques similares. Estos acontecimientos apuntan a un cambio sistémico: la técnica de device code phishing ha pasado de ser un truco aislado a convertirse en un producto comercial en el mercado de «phishing como servicio» (PhaaS), capaz de sortear la autenticación multifactor y posibilitar la toma completa de cuentas.
Cómo funciona el device code phishing
La base del ataque es un mecanismo legítimo de OAuth 2.0: Device Authorization Grant. Según la documentación de Microsoft, este flujo está diseñado para dispositivos con interfaz limitada —televisores inteligentes, impresoras, dispositivos IoT— que no pueden mostrar el formulario de inicio de sesión estándar. El usuario recibe en el dispositivo un código corto, lo introduce en el navegador de otro dispositivo y, de este modo, autoriza la sesión.
Los atacantes explotan precisamente esta separación: ellos mismos inician el flujo de autorización, obtienen el código y lo envían a la víctima mediante un correo de phishing. Cuando el usuario introduce el código en la página legítima microsoft.com/devicelogin, autoriza sin saberlo la sesión del atacante. Como señalan los investigadores de Huntress, el ataque «no compromete el sistema, sino que entra por la puerta principal: sin contraseña, sorteando MFA, transfiriendo el token de sesión directamente al atacante».
La diferencia fundamental con el phishing clásico es que aquí no hay páginas de inicio de sesión falsas ni interceptación de credenciales mediante proxy (AitM). La víctima interactúa exclusivamente con la infraestructura real de Microsoft, lo que hace que el ataque sea extremadamente difícil de detectar con los medios estándar.
Evolución de la técnica: generación dinámica y PhaaS
Según Proofpoint (mayo de 2026), en la mayoría de los ataques modernos el código se genera dinámicamente en el momento en que la víctima hace clic en el enlace de phishing. Esto elimina la limitación del tiempo de vida del código: el correo puede abrirse en cualquier momento y la cadena de ataque se reiniciará. Proofpoint también constata que las implementaciones de device code phishing están disponibles a través de plataformas PhaaS, incluidas EvilTokens y Tycoon 2FA, o bien son desarrolladas por los propios operadores.
Además, los atacantes utilizan la técnica de «saltos a través de cuentas comprometidas» (ATO jumping): una cuenta comprometida se utiliza para enviar enlaces de phishing a los contactos de la víctima, en forma de botones, hipervínculos, adjuntos o códigos QR. Esto multiplica el alcance de la campaña y aumenta la confianza de los destinatarios en el mensaje.
Vínculos con Storm-2372 y formación de un ecosistema de herramientas
Según la evaluación de ZeroBEC, la campaña observada presenta coincidencias significativas con la actividad que Microsoft documentó en febrero de 2025 bajo el identificador Storm-2372. Aquella campaña empleaba señuelos con temática de Microsoft Teams para obtener el device code de las víctimas. Sin embargo, los investigadores subrayan que la coincidencia de tácticas no implica identidad de operadores; se trata más bien de la difusión de un determinado conjunto de procedimientos (tradecraft), que ahora se empaquetan en una infraestructura reutilizable.
Paralelamente, Cisco Talos ha identificado el panel de operador ARToken, que, según los investigadores, comparte infraestructura y contratos de API con la plataforma EvilTokens. El panel ofrece más de 80 endpoints de API para llevar a cabo device code phishing, mantener el acceso mediante Primary Refresh Token (PRT), trabajar con correo electrónico, realizar operaciones de BEC y exfiltrar datos desde SharePoint, todo ello a través de una interfaz en React. Una herramienta independiente, ARTBrowser, permite a los operadores visualizar las sesiones de Microsoft 365 de las víctimas fuera del propio panel.
De acuerdo con Sekoia, la plataforma EvilTokens incluye funciones basadas en inteligencia artificial para automatizar operaciones de BEC: análisis de miles de correos interceptados, identificación de intercambios financieros y generación de mensajes fraudulentos. Esto evidencia la madurez del ecosistema: no se trata de kits de phishing aislados, sino de plataformas completas para la ejecución de campañas de Business Email Compromise (BEC).
La tendencia también se ve confirmada por el informe de eSentire: los operadores de Tycoon 2FA, anteriormente especializados en phishing AitM, han reconvertido su kit para entregar device code phishing a través del flujo OAuth de Microsoft.
Productos afectados y alcance del impacto
Están en riesgo todas las organizaciones que utilicen:
- Microsoft 365 (Exchange Online, OneDrive, SharePoint)
- Microsoft Entra (Azure AD)
- Microsoft Graph API
Un ataque exitoso puede conducir a la toma completa de la cuenta, robo de datos confidenciales, fraude mediante BEC, movimiento lateral dentro de la organización y, en casos extremos, al despliegue de ransomware. Son especialmente vulnerables las organizaciones en las que Device Code Flow está permitido a nivel de tenant sin restricciones adicionales de acceso condicional.
Importante tener en cuenta: el impacto real depende del área de acción (scope) de los tokens emitidos, de la configuración del acceso condicional y de las políticas del tenant. Las afirmaciones sobre un «bypass completo de MFA» solo son correctas en el contexto de la autenticación delegada: el ataque no rompe MFA como tal, sino que utiliza un flujo legítimo en el que el propio usuario ya ha superado MFA.
Recomendaciones prácticas
- Restringir Device Code Flow. En Microsoft Entra, cree una directiva de acceso condicional que bloquee Device Authorization Grant para todos los usuarios, excepto para aquellos que realmente lo necesiten (kioscos, dispositivos IoT). Esta es la medida más eficaz.
- Configurar la monitorización de inicios de sesión anómalos. Supervise los eventos de autenticación con tipo «Device Code» en los Entra Sign-in Logs. Solicitudes masivas de device code desde direcciones IP atípicas o para usuarios que no necesitan este flujo son una señal de posible compromiso.
- Implementar políticas de Token Protection. La vinculación de tokens a dispositivos concretos (token binding) en Entra reduce considerablemente el valor de los tokens interceptados para el atacante.
- Realizar una revisión de los consentimientos OAuth. Revise la lista de aplicaciones con permisos delegados en el tenant. Revoque los consentimientos sospechosos, especialmente aquellos que otorguen acceso a Mail.Read, Files.Read u otros scopes similares.
- Formar a los usuarios. El personal debe saber que las invitaciones legítimas a colaborar en Microsoft 365 nunca requieren introducir un device code. Cualquier solicitud de introducir un código en la página microsoft.com/devicelogin iniciada desde un correo es señal de un ataque.
- Limitar el ATO jumping. Configure reglas de transporte en Exchange Online para detectar envíos masivos desde cuentas comprometidas recientemente y poner automáticamente en cuarentena los mensajes sospechosos.
La aparición de plataformas PhaaS completas en torno al device code phishing —ARToken, EvilTokens, el Tycoon 2FA adaptado— significa que esta técnica ha dejado de ser prerrogativa de grupos avanzados y está al alcance de un amplio abanico de operadores. La acción clave para los defensores es comprobar de inmediato si Device Code Flow está permitido en su tenant de Microsoft Entra y bloquearlo para todos los usuarios que no lo necesiten en su trabajo. Las organizaciones que no hayan restringido este flujo dejan, en la práctica, una puerta abierta por la que el atacante entra con un token legítimo.
