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

Device code phishing abusa de un OAuth Device Authorization Flow legítimo para hacer que una víctima autorice una sesión controlada por el atacante. En entornos Microsoft Entra ID, el usuario puede introducir un código corto en la página real de inicio de sesión de Microsoft, completar la autenticación normal, satisfacer MFA y aun así permitir que el cliente controlado por el atacante reciba tokens.

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

Los equipos que ya revisan MFA fatigue, password spraying, las limitaciones de MFA por sí solo o una auditoría de seguridad de Microsoft Entra ID deben tratar device code phishing como un tema separado. La interacción inicial del usuario y la sesión resultante no se parecen a una página clásica de phishing de credenciales.

Qué es Device Code Phishing

Device code phishing es una técnica de ingeniería social que abusa del OAuth 2.0 Device Authorization Grant. El atacante inicia un device code flow desde un cliente que controla, recibe un user code y una verification URI, y engaña al usuario para que introduzca ese código en un navegador. Si la víctima completa la autenticación, el cliente del atacante puede recibir tokens para el recurso y los scopes solicitados.

El flujo legítimo existe para dispositivos que no pueden mostrar un navegador completo o aceptar entrada rica de usuario. Microsoft documenta escenarios como una 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 con entrada limitada consulta el token endpoint hasta que la autorización se completa o expira.

Device code phishing invierte ese diseño. El dispositivo que solicita autorización no es una TV de sala o una impresora corporativa delante del usuario. Es una sesión cliente controlada por el atacante. La víctima introduce el código en una página legítima de Microsoft, lo que hace que la experiencia sea más difícil de distinguir de un inicio de sesión normal.

Por eso la expresión “bypass de MFA” debe usarse con precisión. En muchos casos, MFA no se rompe criptográficamente. El usuario puede completar MFA de forma real durante el inicio de sesión de Microsoft. El problema es que está autorizando la sesión device-code del atacante. Una MFA correcta no prueba que la sesión resultante pertenezca a un dispositivo, ubicación o flujo de trabajo de confianza.

Cómo funciona OAuth Device Code Flow

El OAuth Device Authorization Grant está definido en RFC 8628. El cliente solicita autorización de dispositivo al authorization server y recibe valores como device_code, user_code, verification_uri, expiración e intervalo de polling. El usuario visita la verification URI e introduce el user code. Mientras tanto, el cliente consulta el token endpoint con el device_code.

La plataforma de identidad Microsoft implementa este patrón mediante device code flow. Una respuesta de token exitosa puede incluir un access token, un ID token si se solicitó openid, y un refresh token cuando el scope original incluyó offline_access. En un escenario de phishing, ese material de token es el objetivo. El atacante no necesita conocer la contraseña si la víctima completa el flujo de autorización.

RFC 8628 trata explícitamente el remote phishing. Indica que el flujo puede iniciarse en un dispositivo en posesión del atacante y que este puede enviar un mensaje para que la víctima visite la URL de verificación e introduzca el código. El RFC recomienda que el servidor de autorización informe al usuario de que está autorizando un dispositivo y que confirme que ese dispositivo está en su posesión.

Diferencias con ataques similares

Device code phishing está cerca de otros ataques de identidad, pero el mecanismo no es el mismo.

Estas diferencias cambian la remediación. Un tenant puede tener buenos controles de contraseña y seguir expuesto si device code flow está permitido ampliamente. Un tenant puede exigir MFA y aun así ser comprometido si los usuarios autorizan sesiones que no controlan. Bloquear device code flow tampoco reemplaza corregir brechas de Conditional Access o políticas de Identity Protection.

Por qué funciona contra Entra ID

El ataque funciona porque la víctima no envía su contraseña a un dominio sospechoso. Puede ser enviada a una página de verificación alojada por Microsoft y ver prompts familiares de autenticación. La concienciación que solo enseña dominios falsos o formularios de contraseña sospechosos no cubre bien este patrón.

Las investigaciones de Microsoft de 2025 y 2026 describen el mismo comportamiento central: actores de amenaza abusan de un flujo legítimo de autenticación device code, hacen que la víctima autentique la sesión del atacante y reciben tokens válidos sin robar directamente la contraseña. Microsoft también observó en 2026 automatización y generación dinámica de códigos para mantener vigente el código corto cuando 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 cloud como Exchange Online, Microsoft Graph, SharePoint Online o Teams, según la app, el recurso y los scopes. Eso no significa que todo inicio device code sea malicioso. Significa que los defensores deben saber si este flujo se usa legítimamente en su tenant, por qué aplicaciones, desde qué ubicaciones y bajo qué decisiones de Conditional Access.

Un error frecuente es tratar MFA exitosa como prueba final de legitimidad. En device code phishing, el evento MFA puede ser real. La pregunta es si el usuario pretendía autorizar el cliente que recibió el token. La revisión del sign-in debe incluir protocolo de autenticación, aplicación, recurso, IP, detalles del dispositivo, estado de Conditional Access, detecciones de riesgo, identificadores de sesión y actividad posterior.

Cadena de ataque

Una cadena típica es:

1. El atacante inicia una solicitud device authorization desde infraestructura o tooling que controla.
2. La plataforma de identidad devuelve user code, verification URI, expiración e intervalo de polling.
3. El atacante entrega el código por email, chat, invitación colaborativa, documento señuelo u otro canal social.
4. La víctima visita la página de verificación, introduce el código, inicia sesión y completa los pasos de autenticación.
5. El cliente del atacante consulta el token endpoint y recibe tokens tras la autorización.
6. El atacante usa el acceso para leer correo, consultar Microsoft Graph, enumerar datos del tenant, crear reglas de buzón, acceder a archivos o ejecutar acciones permitidas por el token y los privilegios de la cuenta.
7. El defensor puede ver un device code sign-in exitoso seguido de uso no interactivo de tokens y actividad de workloads.

La cadena no debe reducirse a un solo indicador. deviceCode en el protocolo de autenticación es importante, pero solo indica el flujo usado. No prueba intención maliciosa por sí solo. La investigación se fortalece cuando el evento se correlaciona con ubicación anómala, aplicación inusual, detalles de riesgo, acceso inesperado a recursos, creación de reglas de email, actividad Graph o un usuario que normalmente no usa device code flow.

Detection

Baseline del uso legítimo

La detección empieza con una baseline de uso legítimo. Muchas organizaciones tienen poco o ningún uso real de device code flow. Otras lo utilizan para herramientas legacy, dispositivos de sala, flujos de desarrollador o registro de dispositivos. La primera pregunta es si el flujo era esperado.

En los sign-in logs de Microsoft Entra exportados a Log Analytics, la tabla SigninLogs incluye AuthenticationProtocol. Microsoft documenta deviceCode como valor posible. También hay campos como OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId y UniqueTokenIdentifier.

Buscar autenticación deviceCode

Una consulta básica inventaria usos exitosos y fallidos:

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

Úsala como punto de partida, no como detección completa. Revisa si la aplicación y el recurso tienen sentido para el rol del usuario. Un desarrollador autenticando una CLI conocida desde una red conocida no equivale a un usuario de finanzas autorizando de repente device code flow desde otro país y generando actividad Graph o Exchange.

Para una detección más fuerte, compara actividad reciente con 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

Prioriza eventos con estas señales:

• primer device code flow observado para el usuario o departamento
• aplicación o recurso inusual para el rol
• inicio desde IP, ASN, país o red no asociada al usuario
• RiskEventTypes_V2 relacionados con IP anónima o threat intelligence
• device code flow exitoso seguido de uso no interactivo de tokens desde infraestructura inesperada
• nuevas reglas de buzón, acceso sospechoso al correo, actividad Graph inusual, acceso SharePoint o Teams tras el inicio
• registro o join de dispositivo cercano en el tiempo y no asociado a onboarding normal

Los identificadores correlacionables de Microsoft Entra hacen más útil la fase post-authentication. Empieza con SessionId o UniqueTokenIdentifier y correlaciónalo con logs de Exchange Online, Microsoft Graph, SharePoint Online o Teams. Microsoft documenta este modelo para rastrear actividades realizadas por una sesión o token específico.

Microsoft Defender y Entra ID Protection pueden aportar señales de mayor confianza, como IP anónima, Microsoft Entra threat intelligence, anomalous token o suspicious API traffic. Trátalas como enriquecimiento y priorización, no como reemplazo de la pregunta central: ¿debía ocurrir device code flow?

Remediation y hardening

Bloquear o restringir device code flow

El control más directo es restringir o bloquear device code flow con Conditional Access. Microsoft recomienda acercarse lo máximo posible a un bloqueo unilateral, auditar primero el uso existente y permitir el flujo solo para casos documentados y protegidos. Para organizaciones que no lo usan, Microsoft ofrece un patrón de Conditional Access que apunta a la condición authentication flows, selecciona device code flow y bloquea el acceso.

Ruta práctica de hardening:

1. Inventariar el uso actual de device code flow en Entra sign-in logs.
2. Identificar usuarios, apps, recursos, ubicaciones y dependencias legítimas.
3. Crear una política Conditional Access en report-only para device code flow.
4. Excluir cuentas de emergencia y casos de uso documentados.
5. Revisar impacto y logs.
6. Pasar la política a enabled cuando el impacto esté entendido.
7. Monitorizar intentos bloqueados y exclusiones inesperadas.

Verificar compatibilidad antes de aplicar

Hay una advertencia operativa importante. Microsoft indica que si la organización usa device code flow contra Device Registration Service y una política authentication flows apunta a todos los recursos, puede ser necesario excluir Device Registration Service. Microsoft documenta el client ID y cómo filtrar los logs por recurso y flujo. No bloquees todos los recursos sin comprobar dependencias de registro de dispositivos.

Los grant controls de Conditional Access también requieren precisión. Microsoft documenta que cuando se usa el device-code OAuth flow, los grant controls que requieren estado de dispositivo gestionado no se soportan de la misma forma, porque el dispositivo que autentica no puede proporcionar su estado al dispositivo que entrega el código. Un modelo basado solo en compliant device o hybrid-joined device puede no comportarse como se espera. Usa la condición authentication flows para controlar el flujo.

Reducir el blast radius

Controles complementarios:

• exigir autenticación phishing-resistant para roles privilegiados cuando esté soportado, sin asumir que bloquea todos los escenarios device-code
• usar Conditional Access basado en riesgo y Identity Protection para desafiar o bloquear sesiones riesgosas
• limitar exposición privilegiada y reducir roles permanentes, como en acceso privilegiado Azure
• revisar consentimiento de apps y permisos para reducir el impacto de un token abusado
• monitorizar Exchange, Graph, SharePoint y Teams después de inicios sospechosos
• usar Safe Links, antiphishing y reporting de usuarios para reducir entrega de señuelos y acelerar triage
• considerar token protection donde cliente, plataforma y workload lo soporten

Respuesta a incidentes

Preservar evidencia de sign-in y workloads

Ante sospecha, la respuesta debe centrarse en contener tokens y delimitar workloads, no solo en resetear contraseña.

Captura usuario, aplicación, recurso, IP, ubicación, AuthenticationProtocol, OriginalTransferMethod, resultado de Conditional Access, riesgo, SessionId y UniqueTokenIdentifier. Conserva el mensaje original con headers y URLs, pero no dependas solo de reputación URL: la víctima pudo usar una página legítima de Microsoft.

Revocar sesiones antes de cerrar contención

Revoca sesiones activas. Microsoft Graph revokeSignInSessions invalida refresh tokens emitidos a aplicaciones para un usuario y cookies de sesión del navegador al resetear el timestamp de validez de sesión. Microsoft advierte de un retraso de unos minutos y de que usuarios externos inician sesión mediante su home tenant. Si la identidad comprometida es invitada, revisa también el modelo de cuentas invitado Azure.

Resetea credenciales solo si la investigación lo justifica. Device code phishing puede comprometer tokens sin robar directamente la contraseña. Puede requerirse reset si hay robo de credenciales, reglas de buzón, cambios MFA, registro sospechoso de dispositivo u otros caminos. El punto clave: resetear contraseña no basta si refresh tokens y sesiones activas siguen válidos.

Delimitar actividad posterior

Usa identificadores correlacionables para rastrear Exchange Online, Microsoft Graph, SharePoint Online y Teams asociados a la sesión o token. Busca reglas de buzón, lecturas/exportaciones de mensajes, descargas de archivos, cambios OAuth, cambios de grupos, métodos de autenticación modificados, registros de dispositivos y acciones administrativas.

Cierra la brecha de control. Si device code flow no era necesario, bloquéalo. Si era necesario para un workflow estrecho, limítalo a usuarios, apps, ubicaciones y recursos documentados. Después alerta por uso fuera de ese patrón.

Validación después del hardening

Validar prevención

Confirma que la política Conditional Access para authentication flows está habilitada y aplica a usuarios y recursos previstos. Prueba con una cuenta no privilegiada en un escenario controlado. Un device code flow bloqueado debe aparecer en sign-in logs con la decisión Conditional Access correspondiente. Las cuentas break-glass deben estar excluidas, pero la lista se revisa periódicamente.

Para compatibilidad, revisa registro de dispositivos y herramientas legacy legítimas. Si Device Registration Service usa device code flow, valida la exclusión documentada y confirma que solo el recurso previsto está excluido. Evita excepciones amplias.

Validar monitorización y respuesta

Para detección, confirma que los device code sign-ins son visibles en portal Entra y Log Analytics. Verifica que AuthenticationProtocol, OriginalTransferMethod, app, recurso, IP, device details, riesgo, SessionId y UniqueTokenIdentifier están disponibles para analistas. Confirma pivotes hacia Exchange, Graph, SharePoint y Teams cuando licencia y logging lo permitan.

Para respuesta, ejecuta un tabletop. Parte de un sign-in deviceCode sospechoso y exige identificar usuario, app, recurso, session ID, token identifier, actividad posterior, ruta de revocación y evidencia final de contención. Esa es la diferencia entre tener un control y operarlo durante un incidente.

Cómo EtcSec detecta exposición relacionada

EtcSec debe tratar device code phishing como una ruta de ataque de identidad y un problema de postura, no solo como email security. Los hallazgos útiles son las condiciones que convierten un evento de social engineering centrado en tokens en compromiso del tenant.

Exposiciones relevantes: políticas Conditional Access que no restringen device code flow, políticas de riesgo ausentes o débiles, usuarios privilegiados fuera de aislamiento administrativo fuerte, exceso de roles admin permanentes, cuentas invitado sin controles fuertes y app registrations sobreprivilegiadas. Para equipos técnicos, la salida útil es concreta: quién puede usar device code flow, qué usuarios están exentos, si los sign-ins riesgosos se bloquean o solo se registran, qué cuentas privilegiadas podrían autorizar sesiones desde contextos de baja confianza, y qué apps o permisos delegados harían más dañina una sesión robada.

Controles relacionados

Device code phishing es efectivo porque vive en la brecha entre un diseño de autenticación legítimo y la intención del usuario. La solución duradera no es un eslogan sobre MFA. Es una postura de tenant donde los flujos de autenticación riesgosos están restringidos, los device-code sign-ins sospechosos son visibles, la actividad de tokens puede rastrearse y el acceso privilegiado no depende de que los usuarios decidan perfectamente bajo presión social.

Referencias principales

• RFC 8628: OAuth 2.0 Device Authorization Grant
• Microsoft identity platform and OAuth 2.0 device authorization grant flow
• Authentication flows as a condition in Conditional Access
• Block authentication flows with Conditional Access policy
• How to configure grant controls in Microsoft Entra
• Protecting tokens in Microsoft Entra ID
• Azure Monitor Logs reference: SigninLogs
• Track and investigate identity activities with linkable identifiers
• Microsoft Graph: revokeSignInSessions
• Microsoft Security Blog: Storm-2372 conducts device code phishing campaign
• Microsoft Security Blog: Inside an AI-enabled device code phishing campaign
• MITRE ATT&CK T1566.002 Spearphishing Link
• MITRE ATT&CK T1550.001 Application Access Token