El device code phishing se está consolidando como una de las variantes más peligrosas de phishing contra identidades corporativas en Microsoft 365. No destaca porque robe una contraseña “como siempre”, sino porque puede secuestrar una sesión legítima y obtener tokens válidos aprovechando un flujo real de autenticación de Microsoft. En abril de 2026, Microsoft publicó una investigación sobre una campaña a gran escala que abusó precisamente de este mecanismo mediante automatización, generación dinámica de códigos y uso posterior de tokens para exfiltración de correo y persistencia.
Para una empresa, esto cambia bastante la conversación. Ya no basta con pensar en “phishing = página falsa + contraseña robada”. En muchos casos, el problema real es que el atacante consigue que el usuario autorice sin entenderlo una sesión iniciada por el propio atacante, y a partir de ahí opera con acceso legítimo en apariencia. Microsoft describe además que, tras obtener los tokens, los atacantes realizaron reconocimiento con Microsoft Graph y crearon reglas maliciosas de buzón para mantener acceso y ocultar comunicaciones.
Eso explica por qué la defensa de identidad está girando cada vez más hacia métodos de autenticación resistentes al phishing. CISA insiste en que no todos los métodos MFA ofrecen el mismo nivel de protección y señala FIDO/WebAuthn como la vía ampliamente disponible de autenticación resistente al phishing.
Qué es exactamente el device code phishing
El Device Code Authentication flow es un flujo OAuth legítimo pensado para dispositivos con interfaces limitadas, como televisores, impresoras o equipos donde no resulta cómodo completar un inicio de sesión estándar. Microsoft explica que el usuario recibe un código y lo introduce en otro navegador o dispositivo para completar la autenticación. El problema es que este diseño introduce una separación entre el lugar donde se inicia la sesión y el lugar donde el usuario la autoriza.
El ataque aparece cuando un actor malicioso inicia ese flujo por su cuenta, genera el código y convence al usuario para que lo introduzca en la página legítima de Microsoft. El usuario cree que está verificando su identidad o accediendo a un documento, pero en realidad está autorizando la sesión del atacante. Microsoft resume muy bien esta lógica: no hace falta robar la contraseña si logras que la víctima autorice directamente tu sesión.
Por qué este ataque importa tanto en empresa
Importa porque se mueve en un terreno que muchas organizaciones consideran “seguro por defecto”: la propia autenticación legítima de Microsoft. No hablamos solo de una web falsa mal hecha. Hablamos de campañas donde el usuario termina en una ruta real de Microsoft para introducir el código, lo que aumenta muchísimo la credibilidad percibida.
Además, si la organización depende intensamente de Microsoft 365, Entra ID, Exchange Online, Teams, OneDrive y aplicaciones SaaS federadas, el impacto potencial es alto: correo, ficheros, estructura organizativa, persistencia en buzón, movimiento lateral y reutilización de permisos. Microsoft observó exfiltración de correo, creación de inbox rules y reconocimiento vía Graph como parte del post-compromiso.
A esto se suma una realidad más amplia: la identidad sigue siendo uno de los puntos de mayor presión para las organizaciones, y los modelos de acceso basados en credenciales reutilizables o MFA débil tienen cada vez peor encaje frente a campañas modernas. CISA remarca que cualquier MFA es mejor que ninguna, pero subraya que el objetivo debe ser evolucionar hacia MFA resistente al phishing.
Cómo funciona el ataque paso a paso
1. Selección y validación del objetivo
El atacante identifica usuarios con valor operativo o financiero y prepara un señuelo creíble. Microsoft documenta reconocimiento previo y validación de cuentas antes del phishing efectivo.
2. Envío del señuelo
La víctima recibe un correo, un PDF, un HTML o una URL con una excusa creíble: documento compartido, firma pendiente, factura, solicitud urgente, acceso a un archivo o aviso administrativo. Microsoft observó campañas con temáticas personalizadas y uso de IA generativa para aumentar la plausibilidad del mensaje.
3. Redirección a una página de transición
El usuario no siempre aterriza en una página falsa evidente. En la campaña descrita por Microsoft, los atacantes usaron redirecciones, infraestructura efímera y servicios cloud legítimos para mezclarse con tráfico normal y dificultar bloqueos simples por reputación.
4. Generación dinámica del código
Aquí está una de las claves más importantes. En lugar de mandar un código ya generado que podría caducar, los atacantes lo generan en tiempo real cuando la víctima hace clic. Microsoft destaca que esta generación dinámica les permitió eludir la limitación temporal habitual del código.
5. La víctima introduce el código en Microsoft
La persona acaba en el portal legítimo de Microsoft para introducir el device code. Como el dominio es real, las barreras psicológicas bajan muchísimo. Si la víctima ya tiene sesión iniciada o completa el proceso con MFA, termina validando la sesión iniciada por el atacante.
6. Uso de tokens y persistencia
Con los tokens obtenidos, el atacante puede acceder a recursos, consultar correo, explorar permisos, tocar Exchange Online y establecer mecanismos de persistencia. Microsoft observó creación de reglas maliciosas de bandeja de entrada y actividad posterior con tokens válidos.
Qué señales deberían preocupar a una empresa
No todas las organizaciones van a ver una alerta que diga literalmente “device code phishing”. Muchas veces lo que aparece es una combinación de síntomas:
- accesos anómalos ligados a OAuth o a autenticación fuera del patrón habitual;
- actividad inusual en Exchange o Microsoft Graph;
- creación o modificación sospechosa de inbox rules;
- usos de token desde ubicaciones o infraestructuras no habituales;
- usuarios que dicen haber “verificado su identidad” sin recordar haber metido credenciales;
- correos reenviados, ocultos o desaparecidos tras un acceso aparentemente legítimo.
Si queréis revisar esta exposición en vuestro tenant, encaja muy bien con una página de servicio como seguridad Microsoft 365 o con una auditoría de Microsoft 365.
Qué no lo bloquea por sí solo
Conviene decirlo claro: tener MFA no basta siempre. CISA insiste en que no todos los factores son iguales y que métodos más tradicionales siguen siendo vulnerables a campañas de engaño, interceptación o fatiga.
Tampoco basta con:
- “tener antivirus”;
- revisar solo contraseñas;
- fiarse del dominio final si el usuario acaba en una página legítima;
- pensar que el problema desaparece por usar Microsoft 365.
El ataque explota un flujo legítimo y eso obliga a elevar el listón de defensa de identidad.
Cómo bloquear o reducir de verdad este riesgo
1. Prioriza autenticación resistente al phishing
Es la medida más importante. CISA recomienda planificar el salto hacia FIDO/WebAuthn. En vuestro caso, además, podéis reforzar aquí el enlazado al término passkey como pieza educativa complementaria.
2. Revisa el uso permitido de Device Code Flow
No todas las organizaciones necesitan este flujo de forma abierta. Hay que revisar dónde se usa, qué aplicaciones lo permiten, qué colectivos lo necesitan realmente y cómo limitarlo si no aporta valor operativo.
3. Refuerza Entra ID y el análisis de riesgo de inicio de sesión
Microsoft recomienda políticas de sign-in risk, respuesta automática frente a inicios de sesión de riesgo y revocación de sesiones cuando se sospeche abuso. Aquí encaja perfectamente un enlace a IAM y postura cloud.
4. Monitoriza y protege Exchange Online
Si el atacante ya obtuvo tokens, una de sus primeras jugadas puede ser el buzón: reglas de reenvío, ocultación de mensajes, cambios silenciosos y acceso a correos sensibles. Eso obliga a vigilar Exchange más allá del antiphishing tradicional. También puedes enlazar aquí vuestro contenido sobre secuestro de cuentas en Microsoft 365.
5. Activa detección específica en Defender y correlación en SOC
Microsoft describe detecciones y hunting relevantes alrededor de autenticación anómala por device code, uso anómalo de tokens y actividad de inbox rules. Si no existe vigilancia activa, la empresa puede tardar demasiado en verlo.
6. Entrena al usuario en este patrón concreto
No sirve una campaña de concienciación genérica que solo diga “no metas tu contraseña”. Aquí hay que explicar algo mucho más específico:
“No introduzcas códigos de Microsoft ni verifiques sesiones iniciadas a partir de enlaces o documentos no validados, aunque el portal final sea legítimo.”
7. Ten preparado el playbook de respuesta
Si sospechas abuso del flujo, hay que actuar rápido: revocar sesiones, invalidar refresh tokens, revisar buzón, analizar actividad en Graph, revisar consentimiento y controlar accesos recientes. Microsoft recomienda revocar sesiones de inicio de sesión y forzar reautenticación cuando haya indicios de compromiso.
Checklist práctico para una empresa mediana
Si quieres convertir este artículo en acción, este sería un checklist razonable:
- Identificar si vuestra organización usa o necesita realmente Device Code Flow.
- Revisar qué apps y casos de uso lo justifican.
- Evaluar el nivel real de MFA desplegado y cuánta parte es resistente al phishing.
- Planificar despliegue progresivo de FIDO2, passkeys o equivalentes donde encaje.
- Revisar políticas de sign-in risk y Conditional Access en Entra.
- Monitorizar inbox rules, reenvíos y actividad anómala en Exchange Online.
- Validar visibilidad en Defender XDR, Defender for Office y Entra ID Protection.
- Revisar accesos privilegiados y cuentas con mayor exposición.
- Formar a usuarios en este patrón concreto de engaño.
- Tener un procedimiento claro de revocación de tokens y análisis post-incidente.
Aquí tienes un enlace a nuestro post de auditoría de Microsoft 365: checklist completa para empresas.
Dónde encajan passkeys y phishing-resistant MFA
Aquí hay una idea clave: passkeys no son solo una mejora de experiencia de usuario. Son una respuesta seria a una realidad operativa. Cuando el atacante depende de que el usuario escriba, copie o autorice algo reutilizable en el contexto equivocado, la autenticación resistente al phishing reduce drásticamente el margen de éxito.
CISA es muy clara al respecto: la autenticación resistente al phishing debe ser el estándar al que aspirar, y FIDO/WebAuthn es la vía ampliamente disponible.
Esto no significa que una empresa pueda encender passkeys en dos horas y olvidarse del problema. Significa otra cosa: que la arquitectura de identidad debe evolucionar para depender menos de credenciales reutilizables y de aprobaciones fáciles de manipular.
Cuándo deberías revisar ya tu Microsoft 365
Deberías mover esto a prioridad alta si se cumple alguno de estos puntos:
- tenéis Microsoft 365 como núcleo operativo;
- hay usuarios con acceso financiero, dirección o compras;
- dependéis mucho de correo y SaaS federado;
- seguís apoyándoos sobre MFA débil o inconsistente;
- no tenéis visibilidad real sobre tokens, sesiones y actividad anómala;
- no habéis revisado Entra, Exchange o Conditional Access en profundidad en los últimos meses.
Aquí encajan especialmente bien nuestros servicios de seguridad Microsoft 365, auditoría Microsoft 365 e IAM y postura cloud.
El device code phishing no es un truco anecdótico. Es una señal de hacia dónde está evolucionando el compromiso de identidad: menos robo clásico de contraseña y más abuso de flujos legítimos, tokens válidos y confianza en contextos aparentemente correctos. Microsoft ya ha documentado campañas amplias basadas en este patrón, y la respuesta defensiva encaja con lo que CISA viene insistiendo desde hace tiempo: avanzar hacia autenticación resistente al phishing y elevar la madurez real de identidad.
Para una empresa, la pregunta ya no es si “tiene MFA”, sino si su modelo de acceso aguanta campañas modernas que explotan consentimiento, tokens y sesiones legítimas.
CTA
¿Usáis Microsoft 365 y queréis revisar si vuestra configuración actual resiste este tipo de campañas?
En Hard2bit podéis abordarlo desde una auditoría de Microsoft 365, una revisión de seguridad Microsoft 365 o una evaluación de IAM y postura cloud para reducir el riesgo real de secuestro de cuentas, abuso de tokens y exposición de identidad.