- El phishing mediante códigos de dispositivo abusa de un flujo OAuth legítimo de Microsoft para obtener tokens válidos sin robar contraseñas.
- La técnica se ha industrializado mediante kits PhaaS y es usada por múltiples grupos para BEC, exfiltración y persistencia en Microsoft 365.
- Mitigar el riesgo exige limitar el Device Code flow, reforzar Entra ID y Exchange, y avanzar hacia MFA resistente al phishing.
- Las organizaciones deben vigilar tokens, reglas de buzón y actividad OAuth anómala, además de formar a usuarios en este patrón concreto.
El phishing mediante códigos de dispositivo se ha convertido en uno de los ataques más preocupantes contra empresas que trabajan con Microsoft 365 y Entra ID. No estamos ante el típico correo cutre que intenta robarte la contraseña, sino ante una técnica mucho más sutil: el atacante se cuela aprovechando un flujo de autenticación totalmente legítimo de Microsoft y consigue que sea el propio usuario quien autorice su sesión.
Según investigaciones recientes de Barracuda, Microsoft y Proofpoint, esta modalidad está creciendo a un ritmo brutal, impulsada por la automatización, los modelos de phishing-as-a-service (PhaaS) y el abuso de OAuth. El resultado es grave: toma de control de cuentas, exfiltración de correo, persistencia a largo plazo y movimientos laterales dentro de la organización, todo ello sin necesidad de robar contraseñas clásicas ni disparar muchas de las alertas habituales.
Qué es el phishing mediante códigos de dispositivo y por qué es tan peligroso
El punto de partida es el Device Code Authentication flow, un flujo OAuth totalmente legítimo que Microsoft diseñó para dispositivos con capacidades limitadas: televisores, impresoras, consolas o sistemas donde escribir credenciales completas es incómodo. El proceso habitual es sencillo: el dispositivo muestra un código, el usuario va a una URL de Microsoft en otro equipo o móvil, introduce el código y autoriza el acceso.
El problema llega cuando los atacantes deciden apropiarse de este mecanismo. En lugar de montar una web falsa para robar contraseñas, inician ellos mismos el flujo de autenticación de dispositivo con Microsoft, obtienen un código de dispositivo real y luego engañan a la víctima para que lo introduzca en la página legítima de Microsoft, creyendo que está verificando su identidad, firmando un documento o accediendo a un recurso importante.
En cuanto el usuario completa el proceso, Microsoft genera los tokens OAuth válidos (incluido un refresh token) y se los entrega al dispositivo que inició el flujo… es decir, al atacante. No hace falta interceptar contraseñas, ni romper MFA en el sentido clásico: lo que consiguen es que el propio usuario valide la sesión del adversario.
Investigaciones de Barracuda han detectado en solo cuatro semanas más de 7 millones de intentos de ataque basados en este patrón, lo que deja claro que ya no hablamos de un experimento puntual, sino de una técnica industrializada, escalable y en plena expansión contra entornos de correo y de identidad en la nube.
Para colmo, esta táctica es especialmente efectiva porque se apoya en enlaces legítimos y no requiere páginas de inicio de sesión falsas. El correo de phishing puede contener una URL de Microsoft real, y el usuario acaba en un portal auténtico donde introduce el código. Eso complica la detección tanto para los filtros de correo como para la propia víctima, que ve un dominio de confianza y baja la guardia.
Cambio de modelo: de robar contraseñas a abusar de flujos de confianza
Durante años hemos asociado el phishing a la imagen clásica: página falsa + credencial robada. En el device code phishing, el giro es radical. El atacante ya no necesita copiar la web de Microsoft ni convencerte de que metas tu usuario y tu contraseña en un formulario clonado. Lo que busca es que apruebes una sesión iniciada por él mismo, aprovechando un flujo de autenticación real.
Microsoft ha documentado campañas a gran escala en las que los atacantes automatizaban la generación dinámica de códigos de dispositivo, sincronizándola con los clics de las víctimas para no perder la validez temporal del código. De esta forma, cuando la víctima llega a la página de verificación de Microsoft e introduce el código, el token asociado sigue estando fresco y el atacante puede canjearlo al instante.
Una vez dentro, los actores maliciosos utilizaron Microsoft Graph para hacer reconocimiento de la organización, revisar buzones, acceder a archivos en OneDrive o SharePoint y, muy importante, crear reglas maliciosas en Exchange Online para reenviar, ocultar o filtrar mensajes. Estas reglas de bandeja de entrada son un mecanismo típico de persistencia en ataques de compromiso de correo empresarial (BEC).
CISA lleva tiempo advirtiendo de que no toda la MFA es igual y que los métodos tradicionales pueden ser vulnerables a campañas de phishing modernas, de fatiga o de engaño. Por eso insiste en impulsar la autenticación resistente al phishing, basada en estándares como FIDO/WebAuthn y passkeys, que reducen drásticamente el margen para abusar de credenciales reutilizables o aprobaciones engañosas.
Proofpoint, por su parte, subraya que esta tendencia supone un hito en la evolución del phishing: el foco se desplaza del robo directo de contraseñas hacia el abuso de flujos OAuth y procesos de autenticación de confianza, justo al tiempo que las empresas se van moviendo hacia MFA más robusta. Todo apunta a que el abuso de OAuth y de device code flow seguirá creciendo en paralelo a esa transición.
En un escenario típico descrito por Microsoft y otros proveedores, el flujo del ataque sigue una serie de pasos bien definidos y, en buena parte, automatizados. Lo peligroso es que cada fase se apoya en elementos aparentemente legítimos, lo que hace que muchos usuarios y sistemas bajen la guardia.
1. Selección y perfilado del objetivo. El atacante no dispara a lo loco. Suele identificar cuentas con potencial impacto operativo o financiero: personal de finanzas, compras, dirección, administración de sistemas, etc. Antes de lanzar la campaña, valida qué cuentas existen y recopila información para adaptar el señuelo (temas de facturas, documentos legales, notificaciones internas, etc.).
2. Envío del señuelo de phishing. La primera toma de contacto acostumbra a ser un correo con un botón, un enlace de texto o incluso un código QR integrado en el cuerpo o en un PDF adjunto. En algunos casos, los atacantes aprovechan IA generativa para crear mensajes muy pulidos, con buena redacción y temas ajustados al contexto de la víctima (documento compartido, revisión de contrato, firma pendiente, aviso de Microsoft, etc.).
3. Redirecciones y páginas de transición. Cuando la víctima hace clic, no siempre termina directamente en una página falsa. Es habitual que el tráfico pase por servicios cloud legítimos, dominios de reputación aceptable o infraestructura efímera para difuminar el rastro. El objetivo es llegar a un punto donde se active el flujo de Device Code Authentication sin levantar demasiadas sospechas.
4. Generación del código de dispositivo. En ese momento, la infraestructura del atacante solicita a Microsoft un código de dispositivo en tiempo real. A diferencia de mandar un código ya generado (que podría caducar antes de que el usuario lo use), la generación dinámica sincronizada con el clic del usuario permite maximizar la ventana de validez del código y aumentar la tasa de éxito.
5. Presentación del código como OTP. El usuario ve el código en una landing intermedia, en un segundo correo o incluso embebido en un documento, acompañado de instrucciones del tipo “Introduce este código como contraseña de un solo uso para verificar tu cuenta”. Así, el código de dispositivo se disfraza de OTP legítimo, y la víctima es dirigida a la URL oficial de verificación de Microsoft.
6. Introducción del código en la página real de Microsoft. Aquí está el truco psicológico clave: el dominio y la página son reales, pertenecen a Microsoft, por lo que la percepción de seguridad es máxima. Si el usuario ya tiene sesión iniciada o completa el proceso con su MFA habitual, sin darse cuenta está validando la sesión que el atacante abrió en su lado. No escribe su contraseña en ningún sitio raro, pero aun así ha sido engañado.
7. Emisión de tokens y persistencia. Una vez completada la autorización, Microsoft emite los tokens OAuth correspondientes (access token y refresh token). El atacante recibe estos tokens en su infraestructura y empieza a usarlos para acceder a correo, ficheros y otros recursos. Gracias al refresh token, puede renovar la sesión incluso aunque la contraseña de la cuenta cambie, logrando un acceso de larga duración sin levantar sospechas inmediatas.
En los incidentes analizados, se ha observado que los atacantes realizan reconocimiento con Microsoft Graph, consultan calendarios, obtienen la lista de contactos y crean reglas de buzón maliciosas para ocultar ciertos correos, reenviarlos externamente o borrar mensajes de alerta. Todo ello encaja de lleno con escenarios de BEC, fraude financiero y espionaje corporativo.
Uno de los motivos por los que el phishing mediante códigos de dispositivo se está disparando es su industrialización dentro del modelo phishing-as-a-service (PhaaS). Ya no hace falta ser un experto técnico para montar una campaña sofisticada: hay kits, servicios y herramientas que automatizan prácticamente todo el proceso.
Barracuda menciona plataformas como el kit Evil Tokens, diseñado para explotar flujos OAuth y facilitar la obtención de tokens de acceso válidos. Estos kits suelen incluir generación automática de códigos, plantillas de correos, gestión de infraestructura y paneles de control para monitorizar las víctimas comprometidas.
Proofpoint, por su parte, ha observado el uso de herramientas como SquarePhish2 y Graphish, así como aplicaciones maliciosas a la venta en foros de hacking que permiten ampliar y automatizar campañas de phishing por códigos de dispositivo. Estas soluciones reducen en gran medida las barreras técnicas de entrada: actores con poca experiencia pueden lanzar operaciones muy efectivas con un par de clics.
En cuanto a los grupos implicados, se han identificado campañas ejecutadas por TA2723 y por el colectivo proestado ruso denominado UNK_AcademicFlare, entre otros actores. Además, Proofpoint apunta a que esta técnica se venía utilizando en entornos de red teaming y ataques dirigidos, pero en los últimos tiempos se ha extendido a operaciones más amplias y sistemáticas.
El mensaje de fondo de los proveedores de seguridad es claro: el phishing de códigos de dispositivo ya no es una rareza. Forma parte de la caja de herramientas estándar de muchos grupos, incluidos aquellos con motivación económica y geopolítica, y va a seguir evolucionando conforme se popularicen las autenticaciones resistentes al phishing tradicionales.
Para las organizaciones que tienen su día a día montado sobre Microsoft 365, Entra ID, Exchange Online, Teams, OneDrive y otras aplicaciones SaaS federadas, este tipo de ataque no es un mero dolor de cabeza técnico: afecta de lleno al corazón operativo de la empresa. Un solo compromiso exitoso puede traducirse en robo de información sensible, fraude financiero y daño reputacional.
Cuando el atacante obtiene tokens válidos a través del device code phishing, pasa a operar con un acceso aparentemente legítimo. Desde el punto de vista de muchos sistemas, no hay nada “raro”: un usuario autenticado, con credenciales válidas y MFA superada, que consulta su correo, revisa documentos o accede a aplicaciones corporativas. La línea que separa el uso normal del uso malicioso se vuelve mucho más fina.
Entre los efectos más habituales se encuentran el acceso masivo a buzones, la exfiltración de correos y adjuntos sensibles, el robo de documentos en SharePoint/OneDrive, la identificación de responsables de pagos y autorizaciones y, a partir de ahí, la preparación de fraudes BEC muy creíbles basados en hilos de correo reales.
Además, la persistencia conseguida mediante refresh tokens y reglas de buzón hace que el atacante pueda mantenerse dentro del entorno durante un tiempo prolongado, incluso si la empresa reacciona cambiando contraseñas de forma reactiva. Sin una revisión profunda de sesiones, tokens y reglas de Exchange, es fácil que el intruso siga teniendo una ventana de entrada.
Todo esto se suma a un contexto en el que la identidad es el principal campo de batalla. Los modelos de acceso basados en credenciales reutilizables y MFA débil encajan cada vez peor con unas campañas de ataque centradas en el abuso de flujos legítimos, tokens y consentimiento. De ahí que CISA y otros organismos estén empujando tan fuerte hacia arquitecturas de identidad más maduras y métodos de autenticación resistentes al phishing.
Un problema añadido es que pocas organizaciones van a ver una alerta que, literalmente, diga “device code phishing detectado”. Lo que suele aparecer es un conjunto de síntomas dispersos que, vistos por separado, pueden parecer ruido, pero que en conjunto pintan un cuadro de compromiso de identidad.
Algunas señales preocupantes son accesos atípicos en logs de OAuth o autenticaciones fuera de los patrones normales de la organización; actividad anómala en Exchange Online, como creación o modificación sospechosa de reglas de bandeja de entrada; uso de tokens desde ubicaciones, rangos IP o infraestructuras inusuales; usuarios que comentan haber “verificado su identidad” o metido un código en Microsoft sin recordar bien por qué; o correos reenviados, ocultos o desaparecidos pese a que los accesos parecen legítimos.
Además, conviene dejar algo muy claro: tener MFA no es una garantía absoluta. CISA insiste en que algunos factores tradicionales siguen siendo vulnerables a engaños, interceptación o ataques de fatiga. El device code phishing no “rompe” MFA, pero la rodea: hace que el usuario la aplique en el contexto equivocado, legitimando la sesión del atacante.
Tampoco basta con confiar en un “buen antivirus”, revisar solo contraseñas o quedarse tranquilo porque el usuario acaba en una página de Microsoft. El valor de este ataque está precisamente en explotar flujos legítimos, de modo que muchas defensas clásicas no lo detectan por sí solas. Usar Microsoft 365 no es el problema, pero tampoco es automáticamente la solución.
En ese sentido, si una organización quiere tomarse en serio este riesgo, debe mirarlo desde la óptica de la seguridad de identidad y de OAuth, no solo desde la capa de antiphishing de correo. El enfoque tiene que abarcar flujos de autenticación, tokens, consentimiento, monitorización de aplicaciones y comportamiento de usuarios.
Mitigar este tipo de ataques exige combinar cambios de arquitectura, ajustes de configuración y concienciación muy específica. No vale una campaña genérica de “no hagas clic en enlaces raros”. Hay que atacar el problema en varios frentes y con criterios claros de prioridad.
En primer lugar, conviene priorizar métodos de autenticación resistentes al phishing. CISA recomienda evolucionar hacia FIDO/WebAuthn y passkeys siempre que sea posible. Aunque estos métodos no eliminan el riesgo de abuso de flujos OAuth por sí solos, sí reducen la dependencia de contraseñas y SMS y códigos temporales visibles o aprobaciones demasiado fáciles de manipular.
En segundo lugar, es clave revisar el uso que se hace del Device Code flow. Muchas empresas no necesitan tener este flujo habilitado de forma general. Lo razonable es identificar qué aplicaciones y colectivos lo requieren de verdad, limitarlo a esos casos y, si es posible, bloquearlo completamente allí donde no aporta valor. Proofpoint lo señala como la medida más contundente: desactivar el flujo de códigos de dispositivo cuando no sea estrictamente necesario.
También es fundamental reforzar las capacidades de Entra ID y Conditional Access. Microsoft recomienda políticas basadas en riesgo de inicio de sesión, respuesta automática ante accesos anómalos, revocación de sesiones sospechosas y requerir dispositivos conformes o registrados para determinados flujos, incluyendo OAuth. Esto encaja con una estrategia más amplia de IAM y de postura cloud centrada en reducir el radio de acción de un token comprometido.
Otra pieza crítica es mejorar la vigilancia sobre Exchange Online y Microsoft Graph. Dado que muchas campañas apuntan al correo como primer objetivo, tiene sentido monitorizar con cuidado la creación de inbox rules, reenvíos externos inesperados, cambios silenciosos en buzones y accesos inusuales a datos desde Graph. Defender XDR, Defender for Office 365 y Entra ID Protection pueden aportar señales valiosas si se configuran y se supervisan de forma activa; consulte nuestra guía completa de investigación y análisis de amenazas.
Finalmente, la concienciación debe centrarse en un mensaje muy concreto: “No introduzcas códigos de Microsoft ni valides sesiones que vengan de enlaces o documentos no verificados, aunque la página de destino sea de Microsoft y parezca totalmente legítima”. Este matiz es clave, porque muchos usuarios creen que si ven un dominio oficial ya no puede haber engaño.
Para aterrizar todas estas ideas en acciones concretas dentro de una empresa de tamaño medio, resulta útil trabajar con una lista de verificación clara que permita evaluar el riesgo y priorizar medidas. A partir de las recomendaciones de Microsoft, CISA, Barracuda y Proofpoint, pueden plantearse, entre otras, las siguientes líneas de trabajo:
- Identificar si el Device Code flow es realmente necesario en la organización y, si lo es, en qué escenarios concretos (dispositivos especiales, salas de reuniones, sistemas legacy, etc.).
- Revisar el catálogo de aplicaciones que utilizan OAuth y, en particular, cuáles permiten o requieren el flujo de códigos de dispositivo, con el fin de limitarlo a lo estrictamente imprescindible.
- Evaluar el despliegue actual de MFA: qué porcentaje es resistente al phishing, dónde siguen usándose métodos débiles y qué colectivos críticos (finanzas, compras, dirección, TI) necesitan pasar cuanto antes a FIDO2/passkeys o equivalentes.
- Reforzar las políticas de acceso condicional en Entra, incluyendo sign-in risk, requerimientos de dispositivos conformes y bloqueos para flujos de OAuth que no se consideren necesarios.
- Monitorizar reglas de buzón, reenvíos y actividad anómala en Exchange Online, configurando alertas específicas para cambios que indiquen posible persistencia o exfiltración.
- Comprobar la visibilidad en Defender XDR, Defender for Office y Entra ID Protection para asegurarse de que se detectan patrones asociados a abuso de OAuth y device code.
- Revisar cuentas privilegiadas y de alta exposición, aplicando controles reforzados (MFA fuerte, acceso condicional más estricto, supervisión adicional).
- Formar a usuarios y equipos clave en este patrón concreto de ataque, con ejemplos prácticos de correos, códigos y flujos de aprobación sospechosos y cómo informar de correo electrónico de phishing en Outlook.
- Definir un playbook de respuesta ante sospecha de abuso del flujo de código de dispositivo: revocación de sesiones, invalidación de refresh tokens, revisión de buzones, análisis de actividad en Graph y control de accesos recientes y cómo arreglar la cuenta de Microsoft.
Integrar esta checklist en una auditoría de Microsoft 365 o en una revisión de seguridad específica ayuda a transformar la teoría en cambios tangibles en configuración, procesos y hábitos de los usuarios.
Dentro de esta conversación, los passkeys y la autenticación FIDO/WebAuthn no son solo un “extra de comodidad” para el usuario. Responden directamente a la realidad de ataques como el device code phishing, donde el adversario explota el hecho de que el usuario copie, teclee o apruebe algo reutilizable en el contexto equivocado.
Al eliminar la necesidad de introducir contraseñas o códigos que puedan ser reutilizados, y al vincular fuertemente la autenticación al dispositivo y al dominio correcto, los métodos resistentes al phishing cierran muchas puertas a los ataques que se basan en engañar a la persona para que autorice algo fuera de lugar. No son una bala de plata, pero sí marcan un cambio arquitectónico importante.
CISA lo expresa con claridad: la autenticación resistente al phishing debe ser el objetivo de referencia. Eso no significa que una empresa pueda activar passkeys en una tarde y olvidarse de todo, pero sí que su estrategia de identidad tiene que ir dejando atrás los modelos basados en contraseñas estáticas, SMS, códigos temporales visibles o aprobaciones demasiado fáciles de manipular.
En la práctica, la transición suele ser progresiva: se empieza por los usuarios y sistemas más críticos, se combinan métodos mientras se adapta el parque de dispositivos, y se acompaña con cambios en políticas de acceso condicional, gobernanza de aplicaciones y supervisión de OAuth. Paralelamente, se refuerza la formación para que los usuarios entiendan que “seguridad” ya no es solo “poner una contraseña larga y activar un segundo factor”.
El contexto que pintan Microsoft, Barracuda y Proofpoint es bastante nítido: los atacantes van a seguir explotando flujos legítimos, tokens válidos y contextos de confianza. El device code phishing es uno de los ejemplos más claros de hacia dónde se mueve el juego del compromiso de identidad. Para las organizaciones que dependen de Microsoft 365, la cuestión ya no es si tienen MFA, sino si su modelo de acceso está preparado para soportar campañas modernas que se aprovechan de la propia lógica de autorización de la plataforma.
