Device Code Phishing: la amenaza que hace inútil la MFA

Si la autenticación multifactor ya no es una barrera suficiente, la explicación se llama device code phishing. La técnica explota el device authorization grant de OAuth 2.0 (RFC 8628) para robar tokens de acceso a sesiones ya autenticadas, eludiendo cualquier segundo factor: passkeys, tokens hardware, códigos OTP. Ya no es una curiosidad presentada en 2020: hoy es un fenómeno industrial, alimentado por kits listos para usar y cada vez más generados con ayuda de modelos de lenguaje.

Cómo se elude la MFA, incluso con passkeys

El mecanismo elude por completo la fase de autenticación porque explota la confianza depositada en el flujo de autorización de dispositivos. El atacante inicia el procedimiento de device code en un servicio (por ejemplo Microsoft Entra ID), obteniendo un código alfanumérico y una URL de verificación. Luego engaña a la víctima para que visite esa URL – una dirección perfectamente legítima, como login.microsoftonline.com – e introduzca el código. El usuario, al ver la página auténtica del proveedor, inicia sesión con sus credenciales y completa la MFA, otorgando sin saberlo el consentimiento OAuth. En ese momento, el cliente del atacante recibe los tokens (de acceso y de actualización) que garantizan acceso persistente, sin que se haya clonado nunca una página de inicio de sesión.

La defensa clásica, basada en el reconocimiento de URL falsificadas, es ineficaz. Toda la cadena se desarrolla en dominios de confianza; el phishing consiste en convencer a alguien para que introduzca un código, no en robar una contraseña.

La escalada: de actores estatales a 7 millones de ataques en cuatro semanas

Tras las primeras descripciones tímidas de 2020, el device code phishing hizo su aparición en el terreno con actores estatales en 2024. La verdadera industrialización llegó en 2025 con la campaña de ShinyHunters contra Salesforce: más de 1.000 organizaciones comprometidas y 1.500 millones de registros exfiltrados. Fue la señal de que la técnica se había convertido en un arma de consumo masivo.

En febrero de 2026, el kit EvilTokens redujo aún más la barrera de entrada, haciendo el ataque replicable incluso para delincuentes sin conocimientos avanzados. En abril, Microsoft reportaba entre 10 y 15 nuevas campañas al día, y en las frenéticas cuatro semanas siguientes Barracuda contabilizó 7 millones de ataques. En mayo, la plataforma PhaaS Tycoon2FA integró de forma nativa el flujo de device code. Hoy, Push Security rastrea más de 25 familias de kits dedicados, un ecosistema al que se suman kits como ARToken, capaz de obtener Primary Refresh Token (PRT) para garantizar persistencia, acceso al correo, exfiltración desde SharePoint y automatismos BEC.

El FBI emitió un aviso independiente sobre el kit Kali365, la primera comunicación federal estadounidense dedicada a un servicio específico de phishing-as-a-service. Mientras tanto, la generación asistida por inteligencia artificial – el llamado “vibe‑coding” – acelera la aparición de nuevas variantes, haciendo la amenaza cada vez más difícil de contener.

Ya no solo es el inicio de sesión: el cambio de paradigma hacia la autorización

El fenómeno forma parte de una tendencia más amplia que desplaza el objetivo de la autenticación a la autorización. Técnicas como ConsentFix, aparecida a finales de 2025, apuntan directamente al abuso del consentimiento OAuth, y el propio device code phishing opera en el nivel de concesión de permisos en lugar de la captura de credenciales. El resultado es una clase de ataques que los sistemas tradicionales de detección de intrusiones, calibrados para la fase de inicio de sesión, no interceptan.

Actualmente, el 99% de los ataques observados tiene como objetivo cuentas de Microsoft, pero el flujo de device code también es compatible con GitHub, AWS y otros proveedores de nube, que se convierten automáticamente en blancos potenciales. El compromiso no se limita al acceso inicial: el robo de PRT permite mantener presencia en el tenant durante largos períodos. Y los datos muestran que el daño ya es real, no solo una proyección.

Qué puede hacer una organización

Dado que la MFA ya no representa un escudo, las defensas deben trasladarse al control de la autorización.

• Limitar el device grant: deshabilitar el flujo de autorización de dispositivo para todas las aplicaciones que no lo necesiten realmente. Cuando no sea posible, aplicar políticas de acceso condicional que bloqueen las solicitudes de device code desde IPs, dispositivos o contextos no reconocidos.
• Supervisar los consentimientos OAuth: prestar atención a cada concesión de permisos a aplicaciones desconocidas, incluso si la autenticación subyacente parece legítima. Plataformas como Microsoft Entra ID permiten activar alertas sobre nuevos consentimientos y revocarlos automáticamente con la detección de consent phishing.
• Formar a los usuarios: explicar que nunca se debe introducir un código de emparejamiento recibido por correo electrónico, SMS o chat, aunque el enlace lleve a una página de inicio de sesión conocida. La presencia de la MFA no es garantía de seguridad.
• Integrar la autorización en los SOC: introducir reglas de detección que observen patrones anómalos en los flujos OAuth y en los tokens de actualización. Las defensas centradas en la autenticación, por sí solas, son ciegas ante un ataque que comienza cuando el usuario ya ha iniciado sesión.

El device code phishing no es una evolución marginal: es la evidencia de que el juego se ha desplazado definitivamente más allá del perímetro de la contraseña. Ignorar este cambio significa dejar la puerta abierta después de haber reforzado la cerradura.