En febrero de 2025, el actor de amenazas ruso Storm-2372 usó señuelos de invitaciones a reuniones de Microsoft Teams para enviar mensajes de phishing mediante código de dispositivo, robando las sesiones autenticadas de las víctimas. En marzo de 2026, vimos un aumento de ataques de phishing mediante código de dispositivo derivados del kit de modelo de phishing como servicio (PhaaS) llamado EvilTokens. Y más recientemente, otras plataformas populares de PhaaS como Kali365 están integrando el phishing mediante código de dispositivo en sus ofertas de productos de cibercrimen.
El phishing mediante código de dispositivo no es nada nuevo. De hecho, el concepto existe desde hace seis años, y los procesos que abusa (OAuth y la autorización por código de dispositivo) existen desde hace mucho más tiempo.
Pero, como demuestran estas campañas, el phishing mediante código de dispositivo está teniendo su momento ahora mismo.
En el episodio de junio de 2026 de Tradecraft Tuesday, los investigadores principales de producto de Huntress, Jenko Hwong y Dave Kleinatland, mostraron en detalle en qué consiste este ataque, por qué se está volviendo más frecuente y por qué plantea retos particularmente problemáticos para los defensores.
¿Qué es el phishing mediante código de dispositivo? Mostrando su “cara oculta”
Una introducción rápida a OAuth y la autorización por código de dispositivo
Antes de entender el phishing mediante código de dispositivo, primero debemos entender cómo funciona el proceso legítimo de autorización por código de dispositivo.
Todo comenzó hace 14 años con OAuth 2.0, un marco de autorización que permite que una app acceda a recursos en nombre de un usuario sin tocar nunca su contraseña. En lugar de compartir credenciales, el usuario otorga permiso y la app recibe un token de acceso con alcance limitado.
OAuth resolvió el problema de "compartir contraseñas". Antes de que existiera, permitir que una app accediera a los datos de un usuario en otro servicio significaba entregar su nombre de usuario y contraseña reales. Eso abría todo tipo de problemas de seguridad: las apps podían ver las contraseñas de los usuarios y hacer lo que permitieran sus cuentas, y no se podía revocar el acceso sin restablecer la contraseña, lo que rompía todo lo demás.
OAuth reemplazó esto con acceso delegado y limitado: las apps solo obtienen los permisos otorgados, por un tiempo limitado, revocables en cualquier momento sin tocar contraseñas ni otras apps conectadas.
Luego, en 2019, llegó una extensión de OAuth 2.0 llamada concesión de autorización por dispositivo. Este proceso está pensado para dispositivos con entrada limitada o sin navegador, como smart TVs o consolas, y funciona mostrando un código corto y una URL en este tipo de dispositivos. El usuario autoriza desde otro dispositivo, como su teléfono, separando el inicio de sesión del dispositivo restringido.
Todo esto conduce a 2020, cuando el Dr. Nestori Syynimaa (experto en Azure AD/Microsoft 365 y creador del kit de herramientas AADInternals) presentó una técnica de phishing que abusa de este mismo flujo. Y ahí comienza nuestra historia del phishing mediante código de dispositivo.
El ataque en sí
En términos generales, el phishing mediante código de dispositivo abusa de estos flujos legítimos de autenticación de Microsoft. Normalmente, un usuario va a microsoft.com/devicelogin, escribe un código corto de 8 caracteres y autoriza su dispositivo. Los atacantes usan esto en contra de los usuarios generando ellos mismos los códigos de dispositivo y luego usando señuelos de phishing para engañar a las personas para que ingresen esos códigos controlados por el atacante.
Una vez que la víctima envía el código y aprueba la solicitud, el backend del atacante recibe tokens de OAuth válidos al instante.
Esto es preocupante por varias razones. Parte del motivo por el que el phishing mediante código de dispositivo es tan insidioso es que los actores de amenazas se aprovechan de este flujo de autenticación legítimo. Todas esas señales de alerta de phishing que se ha capacitado a los empleados para detectar (como sitios web sospechosos) ya no aplican. La otra parte complicada de este ataque es que, al robar tokens, los actores de amenazas pueden eludir medidas de seguridad que las organizaciones adoptan cada vez más, como la autenticación multifactor (MFA).
El phishing mediante código de dispositivo en el mundo real
Hemos visto el phishing mediante código de dispositivo en varios incidentes.
Una campaña provino de Storm-2372, un presunto actor de amenazas estatal ruso activo desde agosto de 2024, que ha atacado a gobiernos, ONG, organizaciones de defensa, telecomunicaciones, salud y energía en Europa, Norteamérica, África y Medio Oriente. En febrero de 2025, el grupo usó phishing mediante código de dispositivo para robar tokens de OAuth, primero generando confianza con los objetivos a través de WhatsApp, Signal o Teams, haciéndose pasar por personas destacadas, y luego engañándolos para que ingresaran códigos de dispositivo generados por el atacante en las páginas de inicio de sesión legítimas.
En otro incidente que comenzó el 2 de marzo de 2026, Huntress detectó una campaña de phishing mediante código de dispositivo a gran escala dirigida a 344 organizaciones en EE. UU., Canadá, Australia, Nueva Zelanda y Alemania. Los actores de amenazas abusaron de Railway.com, una plataforma PaaS para desarrolladores, como motor de recolección de tokens, explotando su buena reputación de IP para evadir la puntuación de riesgo de Microsoft. Los señuelos de phishing estaban altamente personalizados (propuestas de construcción, DocuSign, notificaciones de correo de voz) y se dirigían a través de cadenas de redirección de múltiples saltos, incluyendo sitios web comprometidos, reescritores de URL de proveedores de seguridad y páginas de Cloudflare Workers.
La campaña se atribuyó más tarde a la plataforma de PhaaS EvilTokens. De hecho, hemos visto varias plataformas de PhaaS que ya integraron el phishing mediante código de dispositivo en sus ofertas de servicio para cibercriminales, incluyendo Kali365. Esto ha llevado a una mayor proliferación de este vector de ataque.
“Esperanza como servicio”
Los actores de amenazas controlan el modelo de phishing como servicio, así que en Huntress nos atribuimos los derechos de un término relacionado con mitigaciones que llamamos “esperanza como servicio”. ;)
No podemos hablar de mitigaciones del phishing mediante código de dispositivo sin mencionar el Acceso condicional, una función de seguridad de Microsoft Entra ID que aplica políticas de acceso según señales como el usuario, la ubicación, el dispositivo y el nivel de riesgo. Las políticas de acceso condicional evalúan cada intento de inicio de sesión y aplican controles para equilibrar la seguridad con la facilidad de uso al acceder a aplicaciones y recursos.
Una política de acceso condicional administrada por Microsoft que bloquea el flujo de código de dispositivo se lanzó en 2025 — aunque una advertencia importante es que bloquear el flujo de código de dispositivo mediante acceso condicional puede interferir con el Device Registration Service (DRS), por lo que los usuarios deben planificar esa excepción con cuidado.
Sorprendentemente, en Huntress hemos visto que alrededor del 25% de las personas que pagaron por acceso condicional aún no lo han configurado, lo que permite que los actores de amenazas podrían colarse entre las grietas. Los usuarios de políticas de acceso condicional deben asegurarse de completar la configuración hasta el final.
Otras mitigaciones para este tipo de ataque incluyen:
- Monitorea los nuevos registros de dispositivos: Los usuarios que no estén monitoreando los dispositivos nuevos agregados a su entorno de Entra deberían empezar ahora. Cuando se registra un dispositivo (incluso por un atacante remoto), se registra un evento y el artefacto del dispositivo aparece en la sección de dispositivos de Entra. Algunos atacantes son perezosos y no cambian los nombres de máquina predeterminados, lo que facilita la detección.
- Vigila el intercambio sospechoso de tokens en los registros: Los registros contienen señales accionables, como nombres de aplicaciones, recursos de backend, IDs de sesión, identificadores únicos de tokens e identificadores PRT. Una señal de alerta clave es cuando se usan tokens de aplicaciones de Office contra Azure Resource Manager.
- Desactiva el flujo de código de dispositivo donde sea posible: Desactivar por completo el flujo de código de dispositivo es una opción, aunque debe sopesarse frente a las necesidades operativas. Desactivar la reescritura de dispositivos (device writeback) en Entra también puede ayudar a prevenir específicamente el abuso del registro de dispositivos.
¿Te gustó lo que acabas de leer? Únete a nosotros cada mes para Tradecraft Tuesday, nuestra transmisión en vivo donde exponemos técnicas de hackers y hablamos de temas técnicos con demostraciones en vivo. ¡Asegura tu lugar ahora!
