Ataques al código de los dispositivos en Azure: De la explotación a la detección.

TL; DR

Qué es: El phishing de código de dispositivo es una técnica de abuso de OAuth en la que los atacantes inician un flujo legítimo de autenticación de código de dispositivo contra Microsoft. Entra IDLuego, engañan al usuario para que ingrese el código resultante en la página real login.microsoft.com/devicelogin, entregándole al atacante un token de acceso válido sin capturar nunca una contraseña. 

Por qué es importante: En menos de un año, ha pasado de ser una técnica de ciberataque propia de estados (STORM-2372, vinculado a Rusia y activo desde agosto de 2024) a un kit de ataque de uso común. El kit de herramientas PhaaS de EvilTokens, revelado por Microsoft en abril de 2026, automatiza todo el proceso de principio a fin, eludiendo la ventana de caducidad de códigos de 15 minutos y ejecutando entre 10 y 15 campañas personalizadas cada 24 horas. 

Por qué es difícil de detectar: No hay página de inicio de sesión falsa, dominio suplantado por errores tipográficos, captura de credenciales ni carga maliciosa que analizar. La única URL involucrada es login.microsoft.com/devicelogin. La autenticación multifactor (MFA) se completa correctamente en el dispositivo real de la víctima, por lo que todas las señales que un sistema de correo electrónico, un dispositivo de respuesta a emergencias (EDR) o un producto de protección de identidad está entrenado para detectar resultan negativas. 

En qué se diferencia de AiTM: Los ataques de intermediario (AIT) utilizan una página de inicio de sesión falsa para robar las cookies de sesión. El phishing mediante código de dispositivo omite por completo el intermediario: la víctima se autentica en la página real de Microsoft, por lo que no existe infraestructura AiTM que pueda detectarse, bloquearse o desactivarse. 

Señal de detección principal: Un inicio de sesión exitoso donde el método de autenticación es el código del dispositivo, el recurso al que se accede es un cliente de Microsoft (por ejemplo, Azure CLI, Microsoft Office) y el inicio de sesión se realiza desde una ubicación anómala o por una entidad que normalmente no se autentica mediante códigos de dispositivo. Casi ningún flujo de trabajo legítimo de un usuario final genera este patrón; para muchas organizaciones, cada caso justifica una investigación. 

Respuesta inmediata en caso de detección: Revocar el acceso del usuario inmediatamente (consultar Documentación de Microsoft), deshabilite al usuario comprometido y elimine sus asignaciones de roles. Tenga en cuenta que revocar los tokens de actualización no invalida los tokens de acceso ya emitidos; estos siguen siendo válidos hasta su vencimiento. Busque actividad maliciosa originada en la sesión sospechosa. La revocación del token por sí sola no es suficiente; el atacante podría haber establecido persistencia.

Medidas políticas clave: Bloquee el flujo de código de dispositivo mediante Acceso Condicional para cualquier grupo de usuarios que no tenga una necesidad empresarial documentada para ello. La propia guía de Microsoft ahora recomienda esta medida. La mayoría de los usuarios empresariales, incluidos la mayoría de los desarrolladores, casi nunca se autentican legítimamente de esta manera. Cuando la autenticación mediante código de dispositivo sea realmente necesaria, restrinja su uso a ubicaciones de confianza mediante geolocalización. 

Lo que los equipos de seguridad deben saber sobre el phishing mediante código de dispositivo.

Un grupo de ciberdelincuentes patrocinado por un Estado (STORM-2372, vinculado a los intereses del Estado ruso) lleva a cabo desde agosto de 2024 una campaña de suplantación de identidad mediante códigos de dispositivos dirigida a agencias gubernamentales, contratistas de defensa, ONG, empresas de telecomunicaciones, energía y organizaciones sanitarias de todo el mundo. 

Esta no es una vulnerabilidad que Microsoft pueda parchear; es una propiedad de diseño del protocolo de código de dispositivo OAuth 2.0, compatible con todos los principales proveedores de identidad. El ataque elude MFA (la víctima lo completa voluntariamente), no deja infraestructura sospechosa para que las herramientas de seguridad la marquen (la única URL es microsoft.com), y los tokens resultantes sobreviven a los restablecimientos de contraseña. Las pasarelas de correo electrónico convencionales, los CASB y los escáneres de URL califican el enlace de ataque como seguro porque is seguro: redirige a la página de inicio de sesión de Microsoft. 

Tras comprometer la seguridad, se ha observado que los atacantes registran dispositivos persistentes en un plazo de 10 minutos, mapean las estructuras organizativas mediante Microsoft Graph, filtran los objetivos de alto valor (funciones financieras, ejecutivas y administrativas), crean reglas ocultas en la bandeja de entrada y extraen detalles de transferencias bancarias y correspondencia ejecutiva: la materia prima para el fraude financiero y el fraude por correo electrónico empresarial. 

La acción organizativa inmediata: bloquear el flujo de autenticación del código del dispositivo a través del Acceso Condicional para todos los usuarios que no lo requieran explícitamente, garantizar que su respuesta al incidente El manual incluye la revocación de tokens OAuth (no solo el restablecimiento de contraseñas) y la implementación de la vinculación de tokens para cuentas de alto valor. Consulte las Recomendaciones Estratégicas a continuación para obtener el marco de decisión completo.

¿Qué ocurre si la URL de phishing es microsoft.com?

El phishing mediante código de dispositivo es una técnica de robo de tokens que abusa de la implementación de Microsoft del flujo de código de dispositivo OAuth. A diferencia de la mayoría de las campañas de phishing, los atacantes dirigen a la víctima a una URL real de Microsoft, no a un dominio similar, ni a un proxy inverso, ni a una página de typosquatting. La víctima inicia sesión en la página de inicio de sesión real de Microsoft, completa la autenticación multifactor (MFA) y ve una pantalla de éxito normal. Sin embargo, los tokens de autenticación (un método de autenticación adicional que otorga privilegios a la víctima) se envían silenciosamente al atacante en una máquina completamente diferente. No hay robo de credenciales, ni secuestro de sesión, ni infraestructura del atacante que detectar o desactivar. Simplemente un flujo OAuth legítimo haciendo exactamente lo que fue diseñado para hacer, pero para la parte equivocada. 

Se está explotando a gran escala hoy en día, y aunque el fallo subyacente está en el propio estándar OAuth, Entra IDLa implementación de es lo que hace que sea trivial convertirla en arma. Microsoft atribuyó un Campaña en curso contra STORM-2372, un actor de amenazas evaluado con confianza moderada como alineado con los intereses del Estado ruso. La operación ha tenido como objetivo agencias gubernamentales, contratistas de defensa, ONG, proveedores de telecomunicaciones, compañías energéticas y organizaciones de atención médica en varios continentes desde al menos agosto de 2024. En abril de 2026, Microsoft documentó una escalada significativa: la aparición de EvilTokens, un conjunto de herramientas de phishing como servicio (PhaaS) habilitado por IA que automatiza el abuso de código de dispositivos de extremo a extremo.Generación de códigos en vivo bajo demanda para burlar el plazo de caducidad de 15 minutos, creación de señuelos hiperpersonalizados mediante IA generativa y ejecución de entre 10 y 15 campañas distintas cada 24 horas. Esta técnica ha pasado de ser una táctica propia de estados a un kit de ataque de uso común en menos de un año.  

En esta entrada del blog, desglosaremos exactamente cómo funciona este ataque a nivel de protocolo y realizaremos una simulación práctica con datos reales. Entra ID Captura registros, proporciona consultas de búsqueda KQL que puede ejecutar en su propio entorno hoy mismo y amplía la lógica de detección derivada de los registros generados por el ataque. 

¿Cuál es el flujo del código del dispositivo?

La autorización de dispositivo OAuth 2.0, definida en la RFC 8628 y publicada en agosto de 2019, es un flujo de autenticación diseñado para dispositivos que carecen de navegador o tienen capacidades de entrada limitadas: televisores inteligentes, consolas de videojuegos, sensores IoT, señalización digital, hardware para salas de conferencias y herramientas de línea de comandos como Azure CLI o AWS CloudShell. En lugar de iniciar sesión directamente en el dispositivo, el usuario recibe un código alfanumérico corto y una URL; abre esa URL en otro dispositivo (normalmente un teléfono o un portátil), introduce el código y completa la autenticación allí, incluyendo cualquier solicitud de autenticación multifactor (MFA). Mientras tanto, el dispositivo original consulta al servidor de autorización en segundo plano y recibe un token de acceso una vez que el usuario aprueba. 

El flujo cuenta con un amplio respaldo: Microsoft Entra IDGoogle, GitHub, Okta y la mayoría de los principales proveedores de identidad lo implementan, y es el método de inicio de sesión predeterminado para la CLI de Azure (`az login`). Si bien no es el flujo de OAuth más común en las aplicaciones web cotidianas, es el mecanismo estándar para entornos sin interfaz gráfica y con recursos de entrada limitados, y se utiliza activamente en herramientas empresariales, canalizaciones de DevOps y plataformas de transmisión para consumidores. 

Los riesgos de diseño son inherentes al estándar, pero Entra IDLa implementación de Microsoft las amplifica, razón por la cual todos los kits de phishing que circulan actualmente tienen como objetivo a Microsoft. La propia Microsoft ahora recomienda bloquear el flujo mediante Acceso Condicional siempre que no sea explícitamente necesario. 

El fallo crítico de diseño: El código del dispositivo es el único vínculo entre el dispositivo de sondeo y el usuario que se autentica. Microsoft no verifica que el dispositivo de sondeo sea el que el usuario pretendía autorizar. No comprueba la identidad del dispositivo, la ubicación de la red ni el nivel de confianza. Quien tenga el código y lo esté sondeando obtiene los tokens. 

Análisis de ataques

La facilidad con la que se puede utilizar el código del dispositivo es precisamente lo que lo hace vulnerable. Dado que el protocolo nunca vincula directamente el dispositivo de sondeo con el usuario que se autentica, un atacante que obtenga un código de dispositivo válido puede obtener silenciosamente los tokens de acceso y actualización resultantes en el momento en que la víctima inicia sesión. Sin infraestructura de phishing, sin interceptación de credenciales, sin omisión de la autenticación multifactor: simplemente una página de inicio de sesión legítima de Microsoft que funciona exactamente como fue diseñada, pero en nombre de un tercero. 

Cómo los atacantes convierten este flujo en un arma

El punto final del código del dispositivo de Microsoft está diseñado para ser abierto: no requiere secreto de cliente, registro del dispositivo ni prueba de posesión.

Un atacante envía una única solicitud POST no autenticada utilizando un ID de cliente de Microsoft conocido (Azure CLI, Microsoft Office o cualquier otro cliente público de Microsoft; estos ID son públicos, fácilmente enumerables e imposibles de revocar para Microsoft sin comprometer las herramientas legítimas que dependen de ellos) y recibe instantáneamente un código de dispositivo válido. Estos ID de cliente de Microsoft son una ventaja para el atacante: son de confianza por defecto, cuentan con un amplio consentimiento previo y están disponibles de forma permanente. El ID de inquilino se puede obtener fácilmente una vez que el atacante identifica el dominio de la víctima. 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

El atacante envuelve la URL de verificación y el código de usuario en un señuelo convincente (una invitación a una reunión de Teams, una notificación para compartir documentos, una alerta de seguridad informática) y lo envía por correo electrónico, Teams, WhatsApp, Signal u otros medios. Se observó específicamente que STORM-2372 suplantaba notificaciones de reuniones de Teams e invitaciones a grupos de WhatsApp. Mientras la víctima lee el correo electrónico, el script del atacante ya está realizando sondeos. En el momento en que la víctima completa la autenticación, el bucle de sondeo recibe el par de tokens completo. 

¿Por qué fallan los controles de seguridad existentes?

Lo que hace que el phishing mediante código de dispositivo sea particularmente peligroso es la cantidad de defensas convencionales que neutraliza simultáneamente: 

En lo que respecta a la plataforma de identidad de Microsoft, se trató de un inicio de sesión completamente legítimo. 

• La autenticación multifactor (MFA) se utiliza de forma no eludida. La víctima completa la MFA normalmente. El token resultante lleva el valor mfaAuthenticated=true.
• No hay infraestructura del atacante que detectar. La única URL en la cadena de ataque es microsoft.com, que tiene una reputación impecable en todos los canales de inteligencia sobre amenazas y un certificado EV válido. Su puerta de enlace de correo electrónico, CASB, entorno aislado de URL y reescritura de enlaces seguros del proxy la inspeccionan y confirman que es segura.
• Los tokens de actualización sobreviven a los restablecimientos de contraseña. A diferencia de las cookies de sesión (que roban los ataques AiTM), los tokens de actualización de OAuth están diseñados para el acceso a largo plazo entre dispositivos. Se pueden intercambiar silenciosamente por nuevos tokens de acceso sin interacción del usuario ni solicitudes de autenticación multifactor (MFA). Restablecer la contraseña de la víctima no los revoca; el atacante conserva el acceso a menos que los tokens se revoquen explícitamente.
• El rastro forense es mínimo. Los registros de inicio de sesión muestran un inicio de sesión exitoso con Nivel de Riesgo = Ninguno y MFA = Correcto. No hay múltiples intentos de inicio de sesión fallidos, cambios de credenciales ni creación de objetos sospechosos. La única señal potencial es una actualización de token no interactiva desde una IP inesperada, y solo si se está monitorizando específicamente para ello. 

Importante: Esto no es un ataque de intermediario (AiTM). Las herramientas AiTM, como EvilProxy, interceptan las sesiones mediante un proxy inverso y capturan las cookies tras la autenticación multifactor (MFA). Esto requiere infraestructura controlada por el atacante (dominios, certificados, servidores activos), todo lo cual deja un rastro forense. El phishing mediante código de dispositivo solo requiere una solicitud HTTP POST y un correo electrónico convincente. Los tokens que genera tienen una vida útil más larga y un alcance más amplio que las cookies de sesión, y no hay infraestructura del atacante que investigar o eliminar.

Perspectiva del atacante: Flujo paso a paso

Para demostrar la cadena de ataque completa, la reproducimos en un entorno de laboratorio controlado utilizando un inquilino de investigación dedicado (glich.net). La simulación modela a un adversario que opera como helpdesk@glich.net y que ataca al usuario roni@glich.net con un señuelo de phishing de código de dispositivo disfrazado como un solicitud de verificación de credenciales. 

Fase 1: Generación del código del dispositivo

El atacante envía una solicitud POST a Entra IDEl dispositivo utiliza el punto final de autorización mediante el ID de cliente público de la CLI de Azure, recibe un código de dispositivo y un código de usuario, y comienza a consultar el punto final de token inmediatamente. 

Fase 2: Elaboración y entrega del señuelo de phishing

El atacante encapsula el código del dispositivo y la URL login.microsoft.com/devicelogin en un correo electrónico con un tono urgente, disfrazado de invitación a una reunión de Teams, solicitud de verificación de credenciales o alerta de seguridad informática. 

Fase 3: Aprobación del usuario

El usuario recibe el correo electrónico y otorga acceso al atacante. 

Cuando la víctima proporciona el código y las credenciales en su navegador, el bucle de sondeo recoge los tokens. 

Fase 4: Post-explotación

Con un token de acceso válido y un token de actualización de larga duración en mano, el atacante ha autenticado el acceso al entorno de Microsoft 365 de la víctima, y ​​el tiempo corre en su contra. Análisis de abril de 2026 Un estudio sobre una campaña de phishing de código de dispositivo con IA (una evolución directa de la actividad STORM-2372 reportada por primera vez en febrero de 2025) documentó el manual de procedimientos posteriores a la intrusión que los ciberdelincuentes están utilizando en la práctica. La progresión sigue un patrón consistente: 

Registro de dispositivos para persistencia 

En algunos casos, a los 10 minutos de la brecha inicial, los ciberdelincuentes registraron nuevos dispositivos bajo la cuenta comprometida para generar un token de actualización principal (PRT). Un PRT proporciona acceso a largo plazo con capacidad de inicio de sesión único (SSO) que sobrevive a la revocación de tokens individuales, lo que le otorga al atacante una base de operaciones persistente mucho más difícil de detectar y remediar que un token de actualización robado por sí solo. 

Reconocimiento de Microsoft Graph 

Utilizando los tokens robados, los atacantes consultaron la API de Microsoft Graph para mapear programáticamente las estructuras organizativas internas, los roles de usuario y las asignaciones de permisos. Este reconocimiento automatizado les permitió identificar rápidamente qué cuentas comprometidas tenían acceso a recursos confidenciales y dónde escalada de privilegios era posible. 

Filtrado de objetivos de alto valor 

En lugar de explotar indiscriminadamente todas las cuentas comprometidas, los ciberdelincuentes filtraron a las víctimas para identificar perfiles de alto valor, específicamente personas con cargos financieros, ejecutivos o administrativos. Este enfoque selectivo concentró la actividad más invasiva posterior al ataque en las cuentas con mayor potencial de ganancias. 

Reglas maliciosas de la bandeja de entrada para la persistencia 

Para objetivos específicos, los ciberdelincuentes crearon reglas de bandeja de entrada utilizando la aplicación Microsoft Office para redirigir, ocultar o eliminar los correos electrónicos entrantes. Estas reglas tenían un doble propósito: mantener el acceso constante a las comunicaciones por correo electrónico sin necesidad de iniciar sesión repetidamente y ocultar a la víctima las pruebas de la intrusión (por ejemplo, eliminando automáticamente las alertas de seguridad o las notificaciones de restablecimiento de contraseña). 

Exfiltración de correo electrónico dirigida 

La actividad más invasiva estaba reservada para usuarios con autoridad financiera. Los ciberdelincuentes realizaban búsquedas exhaustivas en las comunicaciones por correo electrónico, centrándose específicamente en los detalles de las transferencias bancarias, las facturas pendientes y la correspondencia ejecutiva: la materia prima para el fraude por correo electrónico empresarial (BEC) y el fraude financiero. 

Ejecución retardada para evadir la detección 

No todos los ciberdelincuentes actuaron de inmediato. En varios casos observados, los atacantes esperaron horas después de la intrusión inicial antes de tomar cualquier medida posterior a la explotación: una técnica de evasión deliberada diseñada para separar el evento de autenticación sospechoso de la actividad maliciosa en los registros, lo que dificulta la correlación temporal para los defensores. Para cuando comienza la actividad maliciosa, el evento de autenticación que la habilitó ya ha quedado fuera de las colas de triaje a corto plazo y las ventanas de alerta en tiempo real. Los defensores que revisan un inicio de sesión sospechoso en T+0 pueden no encontrar actividad posterior y cerrarlo como inofensivo, solo para que el atacante comience la exfiltración horas después, cuando la alerta original ya no está en la pantalla de nadie. Esta brecha deliberada entre el acceso y la acción es lo que hace que el phishing de código de dispositivo sea particularmente resistente a la detección basada en el tiempo: la brecha y el impacto nunca aparecen en la misma ventana de investigación a menos que los defensores correlacionen explícitamente en marcos de tiempo extendidos. 

Perspectiva del defensor: Qué debemos buscar en los registros

Para cazadores de amenazas y analistas de SOC, realmente Entra ID Capturas de registro que muestran exactamente qué buscar. 

Nosotros capturamos Entra ID Entradas de registro de inicio de sesión generadas por este flujo. Las solicitudes de sondeo del atacante (las respuestas repetidas authorization_pending) no se registran en absoluto. Solo la emisión exitosa del token genera entradas, divididas en dos pestañas: 

Entrada 1: Interactiva (Navegador/Lado de la víctima)

La víctima visitó microsoft.com/devicelogin y aprobó el código. La autenticación multifactor se satisfizo mediante una declaración de sesión previa; la víctima no experimentó ningún problema más allá de hacer clic en "aprobar". 

Entrada 2: No interactiva (cliente de sondeo/lado del atacante)

Comparación lado a lado

El método de detección es claro: ambas entradas comparten un ID de correlación, pero el agente de usuario y, posiblemente, la dirección IP son diferentes. El registro del navegador muestra Chrome en Mac; el registro de sondeo muestra curl. En un ataque real, este par de registros con estas diferencias —especialmente una división geográfica que indica una posible imposibilidad de desplazamiento o una fuente sospechosa— constituye la señal principal para configurar las alertas. 

Enriquecer la IP del lado de sondeo con fuentes de inteligencia sobre amenazas, listas de reputación de IP, valores de agente de usuario sospechosos (como el ejemplo "curl" en los registros) y metadatos de ASN refuerza aún más la detección: la infraestructura del atacante suele provenir de proveedores de alojamiento, VPN comerciales o ASN sin presencia legítima en su base de usuarios. Una IP de sondeo que se resuelve en un ASN malicioso conocido o que aparece en una lista negra es un indicador de alta confianza incluso sin una discrepancia de IP entre las ramas.

Detección de suplantación de identidad mediante código de dispositivo en su entorno.

Para los cazadores de amenazas: copien y peguen las consultas KQL para Azure Monitor, Microsoft Sentinel o cualquier SIEM compatible con KQL. 

Las siguientes consultas KQL se pueden utilizar para buscar actividad de phishing de código de dispositivo en su Entra ID Registros de inicio de sesión. Están diseñados para poder copiarse y pegarse fácilmente en Azure Monitor, Microsoft Sentinel o cualquier SIEM compatible con KQL. 

El objetivo es detectar el abuso del código del dispositivo lo más cerca posible del tiempo T+0. Cada consulta a continuación apunta a una señal diferente: patrones de uso anormales del código del dispositivo, discrepancias de IP o agente de usuario entre las ramas interactivas y de sondeo, y generación de código de alto volumen que puede indicar una campaña activa. 

1. Mostrar todos los eventos de flujo de código del dispositivo para el análisis de correlación.

Esta consulta recupera ambas ramas (interactiva y no interactiva) del flujo de código de cada dispositivo. Ordene o combine por CorrelationId para compararlas una al lado de la otra y busque discrepancias de IP o agente de usuario: la señal de detección principal. 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. Detectar flujos de código de dispositivo con discrepancia de dirección IP entre ramas

Esta consulta combina las entradas interactivas y no interactivas de cada flujo de código de dispositivo mediante CorrelationId y marca los flujos donde las direcciones IP difieren, lo que indica claramente que el cliente de sondeo no es el mismo dispositivo ni se encuentra en la misma ubicación que el navegador que se autentica. Para obtener alertas más precisas, enriquezca la IP de sondeo con búsquedas de ASN y fuentes de inteligencia sobre amenazas; marque los flujos donde la IP de sondeo pertenece a un proveedor de alojamiento, una VPN comercial o un rango en la lista negra, incluso si las IP se encuentran en el mismo país. 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. Monitorear la generación de código de dispositivo de alto volumen desde una sola aplicación.

Un atacante que ejecuta una campaña de phishing mediante códigos de dispositivo genera muchos códigos en un breve lapso de tiempo. Esta consulta revela aplicaciones con un número inusualmente alto de flujos de códigos de dispositivo entre usuarios distintos en las últimas 24 horas. 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

Ajuste los umbrales y los intervalos de tiempo para que coincidan con la configuración base de su entorno. Las organizaciones que utilizan legítimamente flujos de código de dispositivos (por ejemplo, para la CLI de Azure o la incorporación de dispositivos IoT) deben establecer una lista de identificadores de cliente válidos y excluirlos. 

Se ha encontrado un par de registros sospechosos, ¿y ahora qué?

No todos los flujos de código de dispositivo exitosos con una discrepancia de agente de usuario son maliciosos; existen escenarios legítimos (por ejemplo, un desarrollador que ejecuta `az login` en un servidor remoto y se autentica desde su computadora portátil). Investigue antes de escalar el problema. Sin embargo, si el par de registros muestra indicios de abuso (una IP de sondeo desconocida, un ASN de proveedor de alojamiento, un usuario que no inició un flujo de código de dispositivo), considérelo como un robo de token confirmado y ejecute los siguientes pasos de inmediato: 

1. Revocar inmediatamente todos los tokens de actualización. 

Revocar el acceso del usuario inmediatamente (consultar Documentación de MicrosoftDeshabilita al usuario comprometido y elimina sus asignaciones de roles. Esto invalida todos los tokens de actualización activos e impide que el atacante obtenga nuevos tokens de acceso sin ser detectado. Realiza este procedimiento antes de restablecer la contraseña; un simple restablecimiento de contraseña no revoca los tokens de actualización de OAuth. 

2. Finalizar las sesiones activas 

Revocar los tokens de actualización no invalida los tokens de acceso ya emitidos; estos permanecen válidos hasta que caduquen. Si su inquilino utiliza la Evaluación de Acceso Continuo (CAE), fuerce una reevaluación de todas las sesiones activas del usuario para vaciar los tokens almacenados en caché. Para cargas de trabajo que no utilizan CAE, revoque las sesiones del usuario en Entra ID (Usuarios → Revocar sesiones) para invalidar cualquier token almacenado en caché en los servicios de Microsoft 365. 

3. Comprobar los mecanismos de persistencia 

Busque dispositivos recién registrados, reglas de bandeja de entrada, consentimientos de aplicaciones OAuth y cualquier otra acción realizada en la misma sesión. Preste especial atención a los registros de dispositivos (que generan tokens de actualización primarios), las reglas de bandeja de entrada que reenvían, redirigen o eliminan correos electrónicos y los cambios en los métodos de autenticación (por ejemplo, un nuevo número de teléfono añadido para la autenticación multifactor). La revocación del token por sí sola no es suficiente: el atacante podría haber establecido persistencia; elimine todo lo que el usuario no reconozca. 

4. Contiene movimiento lateral 

Si el usuario comprometido tiene privilegios (Administrador global, Administrador de Exchange, etc.) o acceso a recursos confidenciales, restrinja la cuenta mediante Acceso condicional mientras se lleva a cabo la investigación. Compruebe si el atacante utilizó los tokens robados para acceder a recursos de SharePoint, Teams o Azure; los registros de auditoría unificada y de actividad de Microsoft Graph mostrarán el alcance del acceso. 

5. Conservar las pruebas y alertar al SOC 

Exporta las entradas relevantes del registro de inicio de sesión (tanto interactivas como no interactivas, vinculadas por el ID de correlación), la actividad reciente del registro de auditoría del usuario y cualquier regla de bandeja de entrada o registro de dispositivo que hayas eliminado. Estos datos son fundamentales para determinar el alcance del impacto y para cumplir con los requisitos posteriores de informes de incidentes.

Recomendaciones y mejores prácticas

Recomendaciones estratégicas

Para ejecutivos y líderes de seguridad: las decisiones políticas que más importan. 

• Bloquea el flujo de autenticación mediante código de dispositivo para todos los usuarios que no lo requieran explícitamente. Este cambio en la política de acceso condicional elimina por completo la superficie de ataque para la mayor parte de tu plantilla.
• Actualiza tu plan de respuesta a incidentes para incluir la revocación de tokens OAuth como un paso obligatorio junto con el restablecimiento de contraseñas. Un simple restablecimiento de contraseña no revoca los tokens de actualización; el atacante conserva el acceso indefinidamente a menos que los tokens se revoquen explícitamente.
• Priorice la vinculación de tokens (protección de tokens) para las cuentas de alto valor: ejecutivos, finanzas y administradores. Esta función está disponible generalmente en Windows (versión preliminar en iOS/macOS) y constituye la medida de seguridad más eficaz contra la repetición de tokens a partir de flujos de código de dispositivos robados.
• Audite qué aplicaciones de su inquilino tienen habilitado el flujo de código de dispositivo. Muchas organizaciones tienen aplicaciones OAuth con permisos de código de dispositivo que nunca se configuraron intencionalmente. Reducir la superficie de vulnerabilidad es una solución rápida.
• Asegúrese de que su equipo de operaciones de seguridad supervise los registros de inicio de sesión no interactivos, no solo los interactivos. La actividad de actualización de tokens del atacante aparece únicamente en los registros no interactivos, que muchos centros de operaciones de seguridad no revisan habitualmente.

Recomendaciones tácticas

Para ingenieros y administradores de seguridad: orientación a nivel de implementación: 

Restringir o bloquear el flujo de código del dispositivo mediante acceso condicional.

Si su organización no depende de la autenticación mediante código de dispositivo para casos de uso legítimos (herramientas CLI, dispositivos IoT, hardware de salas de conferencias), bloquee el flujo por completo mediante políticas de acceso condicional. Entra ID, cree una política que se dirija a Todos los usuarios → Recursos de destino → Todos los recursos (anteriormente aplicaciones en la nube) → Condiciones → Flujos de autenticación → Flujo de código de dispositivo = Bloquear. Si algunos equipos lo necesitan, limite el alcance de la política de permiso a usuarios o grupos específicos y plataformas de dispositivos conocidas solamente, mientras se mantiene el principio de menor privilegio. 

Dicte las medidas pertinentes para mitigar el robo de tokens.

Los restablecimientos de contraseña por sí solos no revocan los tokens de actualización de OAuth. Los pasos de respuesta para una cuenta comprometida deben incluir: (1) revocar el acceso del usuario y deshabilitar la cuenta, (2) reevaluar todas las sesiones activas de Evaluación de Acceso Continuo (CAE) y (3) revisar los consentimientos de la aplicación OAuth del usuario y eliminar cualquier entidad de servicio desconocida. Sin estos pasos, el atacante conserva el acceso a través del token de actualización hasta que caduque, hasta 90 días para una contraseña predeterminada. Entra ID configuración. 

Supervise los registros de inicio de sesión no interactivos para detectar anomalías geográficas.

La pestaña de inicio de sesión no interactiva en Entra ID Aquí es donde aparecen los eventos de actualización de tokens. Un atacante que utilice un token de actualización robado generará inicios de sesión no interactivos desde una dirección IP y un agente de usuario que probablemente difieran de la configuración base del usuario. Configure alertas para los inicios de sesión no interactivos donde la IP de origen se encuentre en un país o ASN diferente al del último inicio de sesión interactivo del usuario. Vaya más allá comparando la IP de origen con las fuentes de inteligencia de amenazas y las bases de datos de reputación de IP: la actividad de sondeo o actualización desde IP incluidas en listas negras, proveedores de alojamiento web seguros o redes proxy residenciales es un indicador de alta confianza, independientemente de la ubicación geográfica. Esta combinación de información geográfica Detección de anomalías y el filtrado basado en la reputación es la señal más temprana y fiable para el robo de tokens de código de dispositivo. 

Cómo protegerse contra el phishing de códigos de dispositivos

El phishing mediante código de dispositivo representa un cambio fundamental en el panorama de las amenazas de identidad: el atacante no necesita infraestructura, la autenticación multifactor (MFA) se aprovecha en lugar de eludirse, y el acceso persiste incluso después de restablecer la contraseña. El ataque funciona precisamente porque es legítimo: una página de inicio de sesión real de Microsoft, una solicitud de MFA real, una pantalla de éxito real. Simplemente, los tokens se envían al equipo equivocado. 

La respuesta estratégica es sencilla: bloquear el flujo de código del dispositivo donde no sea necesario, garantizar que sus manuales de respuesta a incidentes incluyan la revocación de tokens y supervisar los registros de inicio de sesión no interactivos que la mayoría de las organizaciones pasan por alto. El análisis técnico exhaustivo de esta publicación —desde el análisis de protocolos hasta la captura de registros y las consultas KQL— proporciona a su equipo de seguridad todo lo necesario para detectar esta actividad hoy mismo. 

A medida que los ataques de identidad basados ​​en OAuth continúan evolucionando, la brecha entre lo que las herramientas perimetrales tradicionales pueden ver y lo que sucede en la capa de identidad solo se ampliará. Las organizaciones que invierten en protocolos a nivel detección y respuesta—y no solo la monitorización de los puntos finales y de la red— serán las que detecten la próxima evolución de esta técnica antes de que alcance la fase posterior a la explotación. 

SilverfortEl equipo de investigación de sigue haciendo un seguimiento de la evolución de las técnicas de ataque basadas en OAuth.