Device Code Phishing: abuso OAuth en Entra ID

El device code phishing abusa de un flujo legítimo de autorización de dispositivo de OAuth para que una víctima autorice una sesión controlada por el atacante. En Microsoft Entra ID, el usuario introduce un código breve en la página real de inicio de sesión de dispositivo, completa la autenticación normal e incluso cumple el MFA, mientras el cliente que espera el token pertenece al atacante.

Esa distinción importa. El device code phishing no es password spraying, ni OAuth consent phishing, ni MFA fatigue, ni una página genérica de robo de credenciales. Es una vía de ataque centrada en tokens contra un flujo de autenticación válido, diseñado originalmente para dispositivos con entrada de datos limitada. Los equipos de defensa deben evaluarlo desde Conditional Access, la telemetría de inicio de sesión, la investigación de tokens y la actividad posterior a la autenticación.

Para los equipos que ya revisan MFA fatigue, password spraying, por qué el MFA por sí solo no basta o los controles más amplios de auditoría de seguridad de Microsoft Entra ID, el device code phishing merece un trato diferenciado: la interacción inicial del usuario y la sesión resultante no se parecen a un sitio de phishing clásico con página de inicio de sesión falsa.

¿Qué es Device Code Phishing?

El device code phishing es una técnica de ingeniería social que abusa de la concesión de autorización de dispositivo de OAuth 2.0: el atacante inicia un flujo de device code desde un cliente propio, recibe del servidor de autorización un código de usuario (user_code) y una URI de verificación (verification_uri), y engaña a la víctima para que lo introduzca en un navegador. Si completa la autenticación, el cliente del atacante recibe los tokens del recurso y los ámbitos solicitados.

El flujo legítimo de autorización de dispositivo existe para dispositivos que no pueden mostrar un navegador completo ni aceptar una entrada rica, como un smart TV, un dispositivo IoT o una impresora. El dispositivo muestra un código, el usuario inicia sesión en otro dispositivo, y el cliente consulta periódicamente el endpoint de tokens hasta completarse o expirar la autorización.

El device code phishing invierte ese diseño: el dispositivo que solicita la autorización no es un televisor corporativo ni una impresora frente al usuario, sino una sesión de cliente controlada por el atacante. Se pide a la víctima que introduzca un código en una página legítima de Microsoft, dificultando distinguir la experiencia del inicio de sesión normal.

Por eso la expresión «bypass de MFA» exige cuidado: en muchos casos de device code phishing el MFA se completa de forma genuina, sin romperse criptográficamente, durante el inicio de sesión de Microsoft. El problema es que el usuario está autorizando la sesión de device code del atacante, de modo que cumplir el MFA no demuestra que la sesión resultante pertenezca a un dispositivo, ubicación o flujo de trabajo de confianza.

Cómo funciona OAuth Device Code Flow

La concesión de autorización de dispositivo de OAuth está definida en RFC 8628: el cliente solicita una autorización al servidor de autorización y recibe valores como device_code, user_code, verification_uri, un valor de expiración y un intervalo de consulta. Se indica al usuario que visite la URI de verificación e introduzca el código, y mientras se autentica, el cliente consulta periódicamente el endpoint de tokens con el device_code.

La plataforma de identidad de Microsoft implementa este patrón mediante el device code flow: una respuesta de token exitosa puede incluir un token de acceso, un token de ID cuando se solicita openid, y un token de actualización cuando el ámbito original incluía offline_access. Ese material de tokens es el objetivo del atacante: si la víctima completa el flujo, no necesita conocer su contraseña.

El flujo tiene tres propiedades de seguridad que los equipos de defensa deben comprender:

Propiedad	Significado defensivo
La autenticación del usuario ocurre en un navegador separado	No es necesariamente el dispositivo o cliente que recibirá los tokens.
El cliente solicitante consulta periódicamente para obtener tokens	Puede esperar a que el usuario termine de autenticarse.
Los tokens son material portador salvo que estén vinculados o restringidos	Debe incluir el uso del token y la actividad en cargas de trabajo, no solo el inicio de sesión original.

El RFC 8628 aborda explícitamente el phishing remoto: el flujo puede iniciarse en un dispositivo en posesión de un atacante, quien podría enviar un mensaje pidiendo a la víctima que visite la URL de verificación e introduzca el código. El RFC recomienda que los servidores de autorización informen al usuario de que está autorizando un dispositivo, y confirmen que ese dispositivo está en su posesión.

En qué se diferencia Device Code Phishing de ataques similares

El device code phishing se sitúa cerca de otros ataques de identidad, pero el mecanismo subyacente es distinto.

Ataque	Qué se abusa	Por qué se diferencia
Password spraying	Contraseñas débiles o reutilizadas en muchas cuentas	Prueba directa de contraseñas, con bajo volumen por cuenta.
MFA fatigue	Solicitudes de MFA repetidas o presión social	El atacante ya tiene credenciales y presiona al usuario a aprobar un inicio de sesión.
OAuth consent phishing	Consentimiento del usuario o del administrador a una aplicación maliciosa	El usuario concede permisos a una app; el problema es el consentimiento, no un código de autorización de dispositivo.
AiTM phishing (adversary-in-the-middle)	Un proxy inverso captura credenciales, cookies o tokens	El atacante actúa como proxy de la ruta de inicio de sesión; el device code phishing usa la página de verificación real sin proxy.
Device code phishing	Concesión de autorización de dispositivo de OAuth	La víctima autoriza una sesión de device code controlada por el atacante al introducir un código de usuario.

Estas distinciones importan para la remediación: un tenant con controles de contraseñas robustos puede seguir expuesto al device code phishing si el flujo está permitido ampliamente, y uno con MFA habilitado puede sufrir compromiso de cuentas si los usuarios autorizan sesiones que no controlan. Bloquear el flujo de device code no elimina la necesidad de abordar las brechas en Conditional Access, las políticas de riesgo de Identity Protection o los registros de aplicaciones con privilegios excesivos.

Por qué Device Code Phishing funciona contra cuentas Entra ID

El ataque funciona porque la víctima no ve un dominio evidentemente controlado por el atacante, sino una página de verificación real de Microsoft con solicitudes de autenticación que le resultan familiares. La formación en seguridad centrada solo en dominios falsos o páginas sospechosas de contraseñas no cubre este patrón de ataque.

La investigación de Microsoft (2025-2026) sobre campañas de device code phishing describe el mismo comportamiento central: los actores abusan del flujo legítimo, hacen que la víctima autentique la sesión del atacante y reciben tokens válidos sin robar la contraseña directamente. Microsoft observó una evolución en 2026, con automatización y generación dinámica de códigos para mantener válido el device code de corta duración mientras el usuario interactúa con el señuelo.

La técnica es relevante para Entra ID y Microsoft 365, porque los tokens resultantes pueden usarse contra recursos en la nube como Exchange Online, Microsoft Graph, SharePoint Online o Teams, según la aplicación, el recurso y los ámbitos. Esto no significa que todo inicio de sesión mediante device code sea malicioso, sino que los equipos de defensa deben saber si el flujo se usa en su tenant, por qué aplicaciones, desde qué ubicaciones y bajo qué decisiones de Conditional Access.

Un error habitual es tratar el éxito del MFA como prueba de legitimidad, aunque en el device code phishing el evento de MFA sea perfectamente real. Lo relevante es la intención del usuario de autorizar al cliente que recibió el token. Por eso la revisión de inicios de sesión debe incluir el protocolo de autenticación, la aplicación, el recurso, la IP, los detalles del dispositivo, el estado de Conditional Access, las detecciones de riesgo, los identificadores de sesión y la actividad posterior en las cargas de trabajo.

Cadena de ataque

Una cadena típica de device code phishing tiene el siguiente aspecto:

El atacante inicia una autorización de dispositivo desde infraestructura o herramientas propias.
La plataforma de identidad devuelve un código de usuario, una URI de verificación, un valor de expiración y un intervalo de consulta.
El atacante entrega el código a la víctima por correo electrónico, chat, una invitación de colaboración, un documento señuelo u otro canal social.
La víctima visita la página de verificación, introduce el código, inicia sesión y completa la autenticación requerida.
El cliente del atacante consulta periódicamente el endpoint de tokens y los recibe al completarse la autorización.
El atacante usa el acceso resultante para leer correo, consultar Microsoft Graph, enumerar datos del tenant, crear reglas de bandeja de entrada, acceder a archivos o intentar otras acciones según el token y los privilegios de la cuenta.
El equipo de defensa puede observar el inicio de sesión inicial como un flujo de device code exitoso, seguido de uso no interactivo del token y actividad en las cargas de trabajo.

La cadena no debe reducirse a un único indicador: un valor de protocolo deviceCode es importante, pero solo indica el flujo usado para la autenticación y no demuestra por sí solo intención maliciosa. La investigación se fortalece cuando ese evento se combina con una ubicación no habitual, una aplicación inusual, detalles de inicio de sesión de riesgo, acceso inesperado a recursos, creación de reglas de correo, actividad en la API de Graph, o un usuario que no suele usar el flujo de device code.

Detección

Establecer una línea base del uso legítimo de device code

La detección debe comenzar con una línea base de lo conocido y legítimo. Muchas organizaciones tienen poca o ninguna necesidad legítima del flujo de device code; otras lo usan para herramientas legacy específicas, dispositivos de salas de reuniones, flujos de desarrolladores o escenarios de registro de dispositivos. La primera pregunta es si ese flujo es siquiera esperado en el tenant.

En los registros de inicio de sesión de Microsoft Entra exportados a Log Analytics, la tabla SigninLogs incluye el campo AuthenticationProtocol, con deviceCode documentado por Microsoft como valor posible. También incluye campos como OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId y UniqueTokenIdentifier.

Búsqueda del protocolo de autenticación device code

Una consulta básica de threat hunting puede inventariar el uso exitoso y fallido del device code:

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, ResultType, ResultDescription,
          SessionId, UniqueTokenIdentifier
| order by TimeGenerated desc

Utilice esto como punto de partida de la investigación, no como una detección completa. Revise si la aplicación y el recurso tienen sentido para ese usuario. Un desarrollador que autentica una CLI conocida desde una red conocida es una señal muy distinta a la de un usuario de finanzas que de repente autoriza un flujo de device code desde un país nuevo y genera actividad en Graph o Exchange.

Para un detector más robusto, compare los inicios de sesión recientes mediante device code con el uso histórico:

let lookback = 30d;
let recent = 1d;
let knownUsers = SigninLogs
| where TimeGenerated between (ago(lookback) .. ago(recent))
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| where UserPrincipalName !in (knownUsers)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId, UniqueTokenIdentifier

Priorizar por contexto, no por un único evento

Priorice eventos con estas características:

Primer uso observado del flujo de device code para ese usuario o departamento.
Aplicación o recurso poco habitual para el rol de ese usuario.
Inicio de sesión desde una IP, ASN, país o red no asociados habitualmente al usuario.
Valores de RiskEventTypes_V2 como IP anónima o detecciones relacionadas con threat intelligence.
Flujo de device code exitoso seguido de uso no interactivo del token desde infraestructura inesperada.
Nuevas reglas de bandeja de entrada, acceso sospechoso al correo, actividad inusual en Graph, acceso a archivos de SharePoint o actividad en Teams tras el inicio de sesión.
Actividad de registro o unión de dispositivos en un marco temporal cercano que no forma parte de un onboarding habitual.

Los identificadores vinculables de Microsoft Entra hacen mucho más accionable la fase posterior a la autenticación: comience por el SessionId o el UniqueTokenIdentifier del registro de inicio de sesión y correlaciónelo con los registros de auditoría de Exchange Online, los de actividad de Microsoft Graph, y los de auditoría de SharePoint Online o Teams. Microsoft documenta este modelo para rastrear las actividades de una sesión o token específicos.

Microsoft Defender y Entra ID Protection pueden aportar señales de mayor confianza, como IP anónima, threat intelligence de Microsoft Entra, token anómalo y tráfico de API sospechoso. Trátelas como señales de enriquecimiento y priorización, no como sustituto de comprender si ese flujo de device code debería haberse producido.

Remediación

Bloquear o restringir el flujo de device code

El control más directo es restringir o bloquear el flujo de device code mediante Conditional Access. Microsoft recomienda acercarse lo máximo a un bloqueo unilateral, auditando primero el uso existente y permitiendo el flujo solo para casos bien documentados y asegurados; para organizaciones que no lo utilizan, ofrece un patrón de Conditional Access dirigido a la condición de flujos de autenticación que selecciona el flujo y bloquea el acceso.

Una ruta práctica de hardening es la siguiente:

Inventariar el uso actual del flujo de device code en los registros de inicio de sesión de Entra.
Identificar usuarios, aplicaciones, recursos, ubicaciones y dependencias de registro de dispositivos legítimos.
Crear una política de Conditional Access en modo solo informe dirigida al flujo de device code.
Excluir las cuentas de acceso de emergencia y los casos de uso legítimos documentados.
Revisar el impacto de la política y los registros de inicio de sesión.
Pasar la política de solo informe a habilitada una vez comprendido su impacto.
Monitorizar los intentos bloqueados y las exclusiones inesperadas.

Verificar la compatibilidad antes de aplicar

Existe una advertencia de compatibilidad: si una organización usa el flujo de device code contra el Device Registration Service y tiene una política de flujos de autenticación dirigida a todos los recursos, ese servicio debe quedar exento del alcance para evitar afectaciones. Microsoft documenta su ID de cliente (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9): los registros de inicio de sesión pueden filtrarse por ese ID de recurso y acotarse luego a ese flujo mediante el filtro de protocolo. No bloquee ciegamente todos los recursos sin comprobar antes si los flujos de registro de dispositivos dependen de esta vía.

Los controles de concesión (grant controls) de Conditional Access requieren una interpretación precisa: con el flujo OAuth de device code, los que exigen dispositivo administrado o de estado no son compatibles, porque el dispositivo que se autentica no puede reportar su estado al dispositivo que muestra el código. Por eso una política basada solo en requisitos de dispositivo compatible o unido de forma híbrida puede no comportarse como se espera. Microsoft recomienda usar en su lugar el control de exigir MFA, y controlar el flujo mediante la condición de flujos de autenticación.

También hay que prever el seguimiento de protocolo: una sesión establecida mediante el flujo de device code queda marcada como «con seguimiento de protocolo», estado que se mantiene en las renovaciones posteriores. Por ello, una solicitud posterior en la misma sesión puede ser bloqueada por una política de flujos de autenticación aunque no lo haya usado, y el inicio de sesión reportará el error AADSTS530036. Espere este comportamiento en modo solo informe, y compruebe el método de transferencia original antes de considerarlo una mala configuración.

Reducir el radio de impacto tras la autorización

Los controles complementarios importan porque el device code phishing suele ser una vía de entrada en un incidente de identidad más amplio:

Exigir autenticación resistente al phishing para roles privilegiados donde sea compatible, sin asumir que por sí sola cubre todos los escenarios de device code.
Utilizar Conditional Access basado en riesgo y políticas de Identity Protection para desafiar o bloquear las sesiones de riesgo.
Limitar la exposición de cuentas privilegiadas y evitar cuentas de uso diario con roles amplios sobre el tenant, el mismo riesgo de las revisiones de acceso privilegiado en Azure.
Revisar la configuración de consentimiento y permisos de aplicaciones del tenant, para limitar el alcance del uso indebido de un token.
Monitorizar la actividad en Exchange, Graph, SharePoint y Teams tras inicios de sesión sospechosos.
Utilizar Safe Links, controles antiphishing y flujos de reporte de usuarios para reducir la entrega de señuelos y acelerar el triaje.
Considerar la protección de tokens donde esté disponible y resulte adecuada; su cobertura depende del cliente, la plataforma y la carga de trabajo.

Respuesta a incidentes tras Device Code Phishing

Preservar la evidencia de inicio de sesión y de carga de trabajo

Ante un evento sospechoso de device code phishing, la respuesta debe centrarse en la contención del token y en delimitar el alcance en las cargas de trabajo, no solo en restablecer la contraseña.

Primero, capture la evidencia del inicio de sesión: usuario, aplicación, recurso, IP, ubicación, AuthenticationProtocol, OriginalTransferMethod, resultado de Conditional Access, detalles de riesgo, SessionId y UniqueTokenIdentifier. Preserve el mensaje de phishing original si está disponible, incluidas cabeceras y URL, pero no confíe únicamente en la reputación de la URL: la víctima pudo haber sido dirigida a una página de verificación legítima de Microsoft.

Revocar las sesiones antes de declarar la contención

Segundo, revoque las sesiones activas: revokeSignInSessions de Microsoft Graph invalida los tokens de actualización de las apps y las cookies del navegador, restableciendo la validez de la sesión con un posible retraso de varios minutos, pero no revoca sesiones de usuarios externos, que se autentican desde su tenant de origen. Si la identidad comprometida es un invitado, la revocación debe impulsarse desde allí: invocarla en el tenant de recursos no contiene la sesión. La exposición de cuentas de invitado debe revisarse aparte, sobre todo cuando las identidades externas quedan olvidadas dentro del tenant.

Tercero, restablezca las credenciales únicamente cuando la investigación respalde esa necesidad: el device code phishing puede comprometer tokens sin robar la contraseña directamente. Puede seguir siendo necesario un restablecimiento si hay evidencia de robo de credenciales, reglas de buzón, manipulación de métodos de MFA, registro sospechoso de dispositivos u otras vías de compromiso. El punto clave: restablecer la contraseña por sí solo no basta si los tokens de actualización y las sesiones activas siguen siendo válidos.

Delimitar el alcance de la actividad posterior

Cuarto, delimite el alcance de la actividad posterior. Utilice los identificadores vinculables para rastrear la actividad en Exchange Online, Microsoft Graph, SharePoint Online y Teams asociada a la sesión o al token: creación de reglas de buzón, lecturas y exportaciones de mensajes, descargas de archivos, cambios en aplicaciones OAuth, en la pertenencia a grupos y en los métodos de autenticación, registros de dispositivos y acciones administrativas.

Quinto, cierre la brecha de control: si el flujo de device code era innecesario, bloquéelo; si era necesario para un flujo de trabajo acotado, restrínjalo a usuarios nombrados, aplicaciones conocidas, ubicaciones conocidas y recursos documentados. Cree además alertas para cualquier uso del flujo que quede fuera de ese patrón aprobado.

Validación después del hardening

Validar la prevención

La validación debe demostrar tanto la prevención como la visibilidad.

Para la prevención, confirme que la política de Conditional Access dirigida a los flujos de autenticación está habilitada y se aplica a los usuarios y recursos previstos, y pruebe con una cuenta sin privilegios en un laboratorio controlado antes de un despliegue amplio. Un flujo de device code bloqueado debe aparecer en los registros de inicio de sesión junto con la decisión correspondiente. Mantenga excluidas las cuentas de acceso de emergencia, pero revise esa lista periódicamente.

Para la compatibilidad, verifique el registro legítimo de dispositivos y las herramientas legacy: si el Device Registration Service se usa junto con ese flujo, valide la exclusión documentada y confirme que solo queda excluido el recurso previsto. No cree exclusiones amplias que reproduzcan la exposición original.

Validar la monitorización y la respuesta

Para la detección, confirme que los inicios de sesión mediante device code son visibles en el portal de Entra y en Log Analytics, y que AuthenticationProtocol, OriginalTransferMethod, la aplicación, el recurso, la IP, los detalles del dispositivo, los campos de riesgo, el SessionId y el UniqueTokenIdentifier están disponibles para los analistas, capaces de pivotar desde un inicio de sesión hacia los datos de auditoría de Exchange, Graph, SharePoint y Teams, según su licenciamiento y configuración de registro.

Para la respuesta, realice un ejercicio de simulación: parta de un inicio de sesión sospechoso con deviceCode y exija al analista identificar el usuario, la aplicación, el recurso, el ID de sesión, el identificador del token, la actividad posterior en las cargas de trabajo, la vía de revocación y la evidencia final de contención. Esa es la diferencia entre disponer de un control y ser capaz de operarlo durante un incidente de identidad real.

Cómo EtcSec detecta la exposición relacionada

EtcSec debe tratar el device code phishing como un problema de vía de ataque de identidad y postura de seguridad, no solo de seguridad del correo. Los hallazgos de mayor valor son las condiciones que permiten que un evento de ingeniería social basado en tokens se convierta en un compromiso completo del tenant.

Entre las comprobaciones de exposición relevantes están las políticas de Conditional Access que no restringen el flujo de device code, las políticas de riesgo ausentes o débiles, los usuarios privilegiados sin un aislamiento administrativo sólido, el exceso de roles de administrador permanentes, las cuentas de invitado sin controles de acceso robustos, y los registros de aplicaciones con permisos excesivos. Todas estas áreas están conectadas con el radio de impacto de un evento de device code phishing exitoso.

Para los equipos técnicos, el resultado útil no es una advertencia genérica sobre phishing, sino una lista corta de identidades y políticas que requieren acción: quién puede usar el flujo de device code, qué usuarios están exentos, si los inicios de sesión de riesgo se bloquean o solo se registran, qué cuentas privilegiadas podrían autorizar sesiones en la nube desde contextos poco confiables, y qué aplicaciones o permisos delegados harían más dañina una sesión robada. Ese enfoque pertenece al trabajo más amplio de endurecimiento del tenant de Azure, no solo al ajuste de alertas del SOC.

Controles relacionados

Control	Qué reduce	Evidencia de validación
Política de flujos de autenticación de Conditional Access	Uso amplio del flujo de device code	Revisión de impacto en modo solo informe y bloqueo de inicios de sesión `deviceCode` fuera del alcance aprobado.
Conditional Access basado en riesgo	Abuso de tokens desde ubicaciones de riesgo o señales de threat intelligence	Políticas de riesgo de inicio de sesión y de usuario, y revisión de las detecciones de riesgo.
Aislamiento del acceso privilegiado	Radio de impacto si un usuario privilegiado sufre phishing	Cuentas privilegiadas separadas de las de uso diario y protegidas con controles más estrictos.
Gobernanza de consentimiento y permisos de apps	Impacto del uso indebido de tokens y OAuth	Registros de aplicaciones revisados, permisos delegados y flujos de consentimiento del administrador.
Correlación de auditoría entre cargas de trabajo	Tiempo para delimitar el alcance del uso indebido de un token	Pivotes de `SessionId` y `UniqueTokenIdentifier` hacia los registros de Exchange, Graph, SharePoint y Teams.
Reporte de usuarios y protecciones de correo	Entrega de señuelos y retraso en el triaje	Flujo de reporte de phishing, política de Safe Links y evidencia de investigación de mensajes.

El device code phishing es eficaz porque se sitúa justo en la brecha entre un diseño de autenticación legítimo y la intención real del usuario. La solución duradera no es un eslogan sobre el MFA, sino una postura de seguridad del tenant donde los flujos de autenticación de riesgo están restringidos, los inicios de sesión sospechosos mediante device code son visibles, la actividad de los tokens puede rastrearse, y el acceso privilegiado no depende de que los usuarios tomen decisiones perfectas bajo presión social.

Device Code Phishing: cómo OAuth Device Flow compromete cuentas Entra ID