Preámbulo

Los miembros del equipo de Ingeniería de detección e investigación de amenazas (TRADE) de Elastic centraron recientemente su atención en una clase emergente de amenazas dirigidas a los flujos de trabajo de OAuth en Microsoft Entra ID (anteriormente Azure AD). Esta investigación se inspiró en el blog reciente de Volexity, Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows, que atribuye una sofisticada campaña de phishing de OAuth contra ONG al actor de amenazas designado UTA0352.

La investigación de Volexity presenta evidencia forense convincente de cómo los atacantes abusaron de aplicaciones confiables de Microsoft para eludir las defensas tradicionales. Mediante flujos OAuth legítimos y la herramienta de código abierto ROADtools, los actores crearon URL de autenticación de Microsoft personalizadas, recolectaron tokens de seguridad y los emplearon para suplantar a usuarios, elevar privilegios y exfiltrar datos a través de Microsoft Graph, incluida la descarga de emails de Outlook y el acceso a sitios de SharePoint.

Si bien su reporte documenta detalladamente el qué del ataque, nuestro equipo en Elastic se centró en comprender el cómo. Emulamos la cadena de ataque en un entorno controlado para explorar de primera mano la mecánica del abuso de tokens, el registro de dispositivos y el enriquecimiento de tokens. Esta experimentación práctica proporcionó conocimientos más profundos sobre el funcionamiento interno de la implementación de OAuth de Microsoft, el uso práctico de ROADtools, mitigaciones recomendadas y, lo más importante, estrategias de detección efectivas para identificar y responder a actividades similares.

OAuth en Microsoft Entra ID

Microsoft Entra ID implementa OAuth 2.0 para permitir el acceso delegado a servicios de Microsoft 365 como Outlook, SharePoint y Graph API. Si bien la especificación OAuth está estandarizada (RFC6749), Entra ID introduce comportamientos y tipos de tokens únicos que influyen en cómo funciona el acceso delegado y cómo los adversarios los explotan.

En el acceso delegado, una aplicación está autorizada a actuar en nombre de un usuario que inició sesión, limitado por los alcances (licencias) que la aplicación aplicar y que el usuario o administrador consiente. Este modelo es común en entornos empresariales donde las aplicaciones recuperan emails, archivos o datos de directorio de un usuario sin aplicar credenciales cada vez.

Un flujo de autorización delegada típico incluye:

Solicitud de autorización (concesión de código de autorización OAuth 2.0): la aplicación aplicar acceso a un recurso (por ejemplo, Graph) con alcances específicos (por ejemplo, Mail.Read, offline_access). Estos se agregan como parámetros a la URI.

• client_id: el ID de la aplicación (por ejemplo, VSCode)
• Response_type: determina el tipo de concesión del flujo de trabajo OAuth (por ejemplo, código del dispositivo, código de autorización)
• Alcance: Licencias aplicar para el recurso de destino (por ejemplo, Correo.Lectura, acceso sin conexión)
• Redirect_uri: Dónde enviar nuestros códigos de autorización
• Estado: Protección CSRF
• Login_hint: Rellena previamente el nombre de usuario

Autenticación de usuario (OpenID Connect): Entra ID autentica al usuario a través de una política (contraseña, MFA, confianza del dispositivo).

• Autenticación de un solo factor (SFA)
• Autenticación multifactor (MFA)
• Confianza del dispositivo (unión híbrida, cumplimiento de Intune)
• Políticas de acceso condicional (CAP)
• Inicio de sesión único (SSO)

Consentimiento: el consentimiento determina si la aplicación puede recibir un código de autorización y qué alcances están permitidos.

• Ámbitos consentidos por el usuario (por ejemplo, Mail.Read, acceso sin conexión)
• Ámbitos que requieren el consentimiento del administrador (por ejemplo, Directory.ReadWrite) requiere aprobación elevada.

Emisión de token: la aplicación recibe un código de autorización y luego lo canjea por:

• Token de acceso: token de corta duración que se emplea para llamar a API como Graph.
• Refresh Token (RT): token de mayor duración para obtener nuevos tokens de acceso de forma silenciosa.
• Token de identidad: describe al usuario autenticado; presente en los flujos de OpenID.
• (Opcional) Token de actualización principal: si el usuario está en un dispositivo registrado o unido a un dominio, un token de actualización principal (PRT) puede habilitar SSO silencioso y flujos de tokens adicionales sin interacción del usuario.
• Reclamaciones de token: las reclamaciones son pares clave-valor integrados en tokens JWT que describen el usuario, la aplicación, el dispositivo, los alcances y el contexto de la autenticación.

¿Qué define una URL de phishing de MSFT OAuth?

Antes de profundizar en los hallazgos clave del reporte de Volexity que ayudan a dar forma a nuestra estrategia de detección, es importante desglosar exactamente qué define una URL de phishing de Microsoft OAuth.

Como se describió anteriormente, Microsoft Entra ID se basa en estas URL para determinar qué aplicación (cliente) aplicar acceso, en nombre de qué usuario principal, a qué recurso y con qué licencias. Gran parte de este contexto está integrado directamente en los parámetros de consulta de la solicitud de autorización OAuth, lo que los convierte en una fuente fundamental de metadatos tanto para los adversarios como para los defensores.

A continuación se muestra un ejemplo de una URL de phishing alineada con el flujo de concesión del código de autorización, adaptado del blog de Volexity:

https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=https://mae.gov[.]ro/[REMOVED]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=<EMAIL HERE>

Analicemos algunos de los componentes clave:

• login.microsoftonline.com – El punto final de autenticación global de Microsoft Entra ID.
• /oauth2/v2.0/authorize - Punto final de MSFT Entra ID OAuth v2.0 para flujos de trabajo de autorización
• estado: valor opcional empleado para evitar CSRF y mantener el estado de la aplicación. A veces se emplea de forma abusiva para ofuscar redirecciones de phishing.
• client_id – El ID de la aplicación que realiza la solicitud. Esto podría pertenecer a aplicaciones propias de Microsoft (como VSCode, Teams) o aplicaciones maliciosas de terceros registradas por adversarios.
• alcance: define las licencias que aplicar la aplicación (por ejemplo, Mail.Read, offline_access). El ámbito .default se emplea a menudo para que los flujos de credenciales de cliente obtengan licencias previamente consentidas.
• response_type=code – Indica que el flujo está aplicar un código de autorización, que luego puede canjear por un token de acceso y/o actualización.
• redirect_uri – Donde Entra ID enviará la respuesta después de que el usuario se autentique. Si un atacante controla este URI, obtiene el código o se trata de un URI gestionado por MSFT que es válido.
• login_hint – Especifica el usuario de destino (por ejemplo, alice\@tenant.onmicrosoft.com). A menudo se completa previamente para reducir la fricción durante el phishing.

Nota: Si bien este ejemplo ilustra una URL de phishing OAuth de Microsoft Entra ID común, existen muchas variaciones. Los adversarios pueden ajustar parámetros como el ID del cliente, los alcances, los tipos de concesión o las URI de redirección según sus objetivos específicos, ya sea para obtener acceso persistente, filtrar emails o escalar privilegios a través de concesiones de consentimiento más amplias.

¿Por qué importa esto?

Como estos parámetros son personalizables, los adversarios pueden cambiar fácilmente los valores para adaptarlos a su operación. Por ejemplo:

• Podrían usar un ID de cliente legítimo de Microsoft para integrar con aplicaciones benignas.
• Pueden emplear un .default alcance para eludir solicitudes de consentimiento específicas.
• Apuntarán el redirect_uri a un sitio bajo su control para recopilar el código de autorización.
• Pueden apuntar a usuarios principales específicos que identificaron durante el reconocimiento.
• Pueden ajustar las licencias para destinar recursos a sus necesidades operativas.

Una vez que un objetivo se autentica, el objetivo es simple: obtener un código de autorización. Luego, este código se intercambia (generalmente mediante herramientas como ROADtools) por un token de actualización o un token de acceso, lo que permite al atacante realizar llamadas a la API Graph o pasar a otros servicios de Microsoft 365 , todo sin mayor interacción del usuario.

Abstracción de los hallazgos clave de Volexity

Para la detección de amenazas, es fundamental comprender los protocolos como OAuth, la implementación del flujo de trabajo en Microsoft Entra ID y los metadatos contextuales sobre los comportamientos y/o pasos tomados por el adversario con respecto a esta operación.

A partir de la investigación y el estudio de Volexity, podemos identificar las diferentes variantes de phishing de OAuth denunciadas. Decidimos desglosarlos para facilitar su comprensión:

Suplantación de identidad (phishing) de OAuth para acceder a Graph API como cliente de VSCode en nombre del usuario principal de destino: estas URL son similares a nuestro ejemplo “Qué define una URL de suplantación de identidad (phishing) de OAuth de MSFT”: el objetivo final es un token de acceso a Graph API con licencias predeterminadas.

• Las URL de phishing de OAuth eran personalizadas y apuntaban al punto final "autorizado".
• Los ID de cliente fueron específicamente VSCode ("aebc6443-996d-45c2-90f0-388ff96faa56")
• El recurso/alcance era MSFT Graph ("https:\/\/graph.microsoft.com\/.default") con .default licencias
• Los flujos de concesión de tokens eran código de autorización (response_type=code)
• Las URI de redireccionamiento eran para dominios legítimos de MSFT (insiders[.]vscode[.]dev o vscode-redirect[.]azurewebsites[.]net)
• Las sugerencias de inicio de sesión eran el principal de usuario específico al que se apuntaba (no los principales de servicio)
• El adversario requería que el objetivo abriera la URL, se autenticara y compartiera el código de autorización (1.AXg….)

Desde aquí, el adversario podría realizar una solicitud al punto final del token OAuth de MSFT (https:\/\/login.microsoftonline.com\/[tenant_id]/oauth2/v2.0/token) e intercambiar el token de actualización por un token de acceso. Esto es suficiente para permitir que el adversario acceda a Graph API y acceda a recursos normalmente disponibles para el usuario. Estos indicadores serán cruciales para determinar nuestras estrategias de detección y caza más adelante en este blog.

Phishing de OAuth para el registro de dispositivos como agente de autenticación MSFT: estas URL son únicas ya que están encadenadas con el uso posterior de ROADtools para registrar un dispositivo virtual, intercambiar un RT por un PRT y requieren enriquecimiento de PRT para lograr acceso al email mediante Graph API y acceso a Sharepoint.

• Las URL de phishing de OAuth eran personalizadas y apuntaban a la autorización (https:\/\/login.microsoftonline.com\/[tenant_id]/oauth2/v2.0/authorize). punto final
• Los ID de cliente eran específicamente MSFT Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e")
• El recurso/alcance fue el Servicio de Registro de Dispositivos (DRS) ("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9")
• Los flujos de concesión de tokens eran código de autorización (response_type=code)
• La URI de redireccionamiento incluye un punto final de unión de dominio basado en la nube (normalmente se emplea durante la configuración de Windows o Autopilot)
• La sugerencia de inicio de sesión contiene la dirección de email principal del usuario (destino)
• La solicitud es, en última instancia, para un token ADRS

Si el usuario es víctima de phishing y abre la URL, la autenticación proporcionará un token ADRS que el adversario necesita para registrar un dispositivo y posteriormente obtener un PRT con la clave privada del dispositivo y el archivo PEM.

El blog de Volexity también incluye información adicional sobre el seguimiento de la actividad de la identidad comprometida a través del ID del dispositivo registrado, así como la actividad posterior al compromiso luego de que se identificó una solicitud 2FA aprobada, lo que permitió al adversario descargar el email del objetivo con una sesión vinculada al dispositivo recién registrado.

Con esta comprensión de cada intento de phishing, nuestro próximo objetivo es replicarlo en nuestro propio inquilino MSFT con la mayor precisión posible para recopilar datos para detecciones plausibles.

Nuestros esfuerzos de emulación

Muy bien, en este punto cubrimos los conceptos básicos de OAuth y cómo Microsoft Entra ID lo implementa. Desglosamos lo que define una URL de phishing de Microsoft OAuth, decodificamos sus parámetros críticos y extrajimos información clave de la excelente investigación de Volexity para identificar indicadores alineados con estos flujos de trabajo de phishing.

Pero la teoría y un vistazo al cuaderno de notas de Volexity sólo nos llevan hasta cierto punto.

Para comprender verdaderamente la perspectiva del atacante, la cadena completa de ejecución, las peculiaridades de las herramientas, los obstáculos sutiles y las oportunidades de abuso, decidimos realizar pruebas prácticas de caja blanca. Recreamos el proceso de phishing de OAuth en nuestro propio inquilino, emulando todo, desde la recolección de tokens hasta el acceso a los recursos. ¿El objetivo? Ir más allá de los indicadores estáticos y descubrir las pistas de comportamiento que los defensores pueden detectar con fiabilidad.

Vamos a entrar en materia.

Prerrequisitos

Para empezar, es bueno compartir algunos detalles sobre nuestro entorno de detección e investigación de amenazas en Azure.

• Inquilino de Azure establecido: TENANT.onmicrosoft.com
• Dominio de SharePoint establecido: DOMINIO.sharepoint.com
• IdP nativo Microsoft Entra ID: Habilitación de nuestro IAM
• Licencias de Microsoft 365 (P2) para todos los usuarios
• Registros de actividad de Azure que se transmiten a EventHub
• Registros de inicio de sesión de Microsoft Entra ID que se transmiten a EventHub
• Registros de auditoría de ID de Microsoft Entra que se transmiten a EventHub
• Registros de auditoría de Microsoft Graph que se transmiten a EventHub
• Registros de auditoría de Microsoft 365 que se transmiten a EventHub
• Integración de Elastic Azure y M365 habilitada para la digestión de registros desde EventHub
• Usuario administrador básico habilitado con CAP que requiere MFA
• Aplicación MSFT Authenticator en dispositivos móviles para emulación de 2FA
• Escritorio de Windows 10 con NordVPN (Adversary Box)
• Punto final de macOS (caja víctima)

Tenga en cuenta que, si bien podemos seguir los flujos de trabajo desde un único punto final, a menudo necesitamos datos que reflejen direcciones de origen separadas para que los desarrolladores puedan detectar variaciones de viajes imposibles.

Escenario 1: Suplantación de identidad de OAuth como cliente de VSCode

Emulación

Para emular la técnica de phishing documentada por Volexity, creamos un script en Python para generar una URL de autorización OAuth 2.0 empleando Microsoft Entra ID. La URL inicia un flujo de concesión de código de autorización, hacer pasar por la aplicación de Visual Studio Code de origen para aplicar acceso delegado a la API de Microsoft Graph.

Configuramos la URL con los siguientes parámetros:

{
  "client_id": "aebc6443-996d-45c2-90f0-388ff96faa56",
  "response_type": "code",
  "redirect_uri": "insiders.vscode.dev/redirect",
  "scope": "https://graph.microsoft.com/.default",
  "login_hint": "user @ tenant.onmicrosoft.com",
  "prompt": "select_account",
  "state": "nothingtoseehere"
}

Figura 1: Parámetros para la URL de phishing de OAuth

Esta URL se comparte con el destino (en nuestro caso, un usuario de prueba de MacOS). Cuando se abre, autentica al usuario y completa el flujo de trabajo OAuth. Empleando herramientas para desarrolladores de navegadores, capturamos el código de autorización devuelto en la URI de redirección, exactamente lo que los atacantes pidieron a sus víctimas que enviaran.

Luego de recibir el código, emitimos una solicitud POST a:

{token_url: "https://login.microsoftonline.com/organizations/oauth2/v2.0/token"}

Este intercambio emplea el tipo de concesión authority_code, pasando el código, el ID del cliente y el URI de redireccionamiento. Microsoft devuelve un token de acceso, pero ningún token de actualización. Te preguntarás ¿por qué es esto?

El alcance https:\/\/graph.microsoft.com\/.default indica a Microsoft que emita un token portador para todas las licencias de Graph ya otorgados a la aplicación VSCode en nombre del usuario. Este es un ámbito estático, que se extrae del registro de la aplicación y no incluye ámbitos dinámicos como Mail.Read u offline_access.

La documentación de Microsoft indica:

““Los clientes no pueden combinar el consentimiento estático (.default) y el consentimiento dinámico en una sola solicitud.””

Por lo tanto, intentar incluir offline_access junto con .default da como resultado un error. Si el atacante quiere un token de actualización, debe evitar .default y en su lugar aplicar explícitamente offline_access y los ámbitos delegados requeridos (por ejemplo, Mail.Read), suponiendo que el registro de la aplicación los admita.

Con el token de acceso en la mano, pasamos a un segundo script para interactuar con la API de Microsoft Graph. El objetivo: extraer mensajes de email de la cuenta de la víctima, tal como lo haría el atacante.

Para ello, incluimos el token de acceso como un JWT portador en el encabezado de autorización y realizamos una solicitud GET al siguiente punto final:

{graph_url: "https://graph.microsoft.com/v1.0/me/messages"}

La respuesta devuelve una matriz JSON de objetos de email. Desde aquí, simplemente iteramos a través de los resultados y analizamos metadatos útiles como el remitente, el asunto y la hora de recepción.

Para probar los privilegios más amplios del token, también intentamos enumerar los sitios de SharePoint usando:

{graph_search_url: "https://graph.microsoft.com/v1.0/sites?search=*"}

La solicitud falló con un error de acceso denegado, lo que nos lleva a una pregunta importante: ¿por qué funcionó el acceso al email, pero el acceso a SharePoint no? El motivo es que el cliente de origen (VSCode: aebc6443-996d-45c2-90f0-388ff96faa56) no tiene licencias delegadas predeterminadas con Graph para Sharepoint, como lo define Microsoft. Por lo tanto, sabemos que el adversario tiene un acceso limitado a lo que puede acceder.

Para garantizar que esto fuera preciso, decodificamos el token de acceso para identificar el SCP asociado con VSCode con .default Licencias para Graph – No se verifican sitios.* con licencia de Microsoft.

Esta es una de las variaciones descritas por Volexity, pero nos ayuda a comprender más sobre los procesos detrás de escena para el adversario, así como los recursos, OAuth y más para Microsoft Entra ID.

Una vez completada la emulación, ahora pasamos a identificar señales de alta fidelidad que sean viables para la detección SIEM y la búsqueda de amenazas. Nos centramos en los observables de comportamiento en los registros de Microsoft Entra ID y Microsoft Graph.

Detección

Señal 1 : Suplantación de identidad de OAuth de Microsoft Entra ID como cliente de Visual Studio Code

Se completó un flujo exitoso de OAuth 2.0 (autorización) y OpenID Connect (autenticación) empleando la aplicación de origen de Microsoft Visual Studio Code (VSCode). El inicio de sesión se realizó en nombre del usuario principal suplantado, lo que resultó en un acceso delegado a Microsoft Graph con .default licencias.

event.dataset: "azure.signinlogs" and
event.action: "Sign-in activity" and
event.outcome: "success" and
azure.signinlogs.properties.user_type: "Member" and
azure.signinlogs.properties.authentication_processing_details: *Oauth* and
azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
(
  azure.signinlogs.properties.resource_display_name: "Microsoft Graph" or
  azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000"
) and (
  azure.signinlogs.properties.app_id: "aebc6443-996d-45c2-90f0-388ff96faa56" or
  azure.signinlogs.properties.app_display_name: "Visual Studio Code"
)

Señal 2 : reutilización de sesión de Microsoft Entra con acceso sospechoso a gráficos

Si bien los lenguajes de consulta tradicionales como KQL son excelentes para filtrar y visualizar eventos de registros individuales, resultan difíciles cuando la detección depende de la correlación de múltiples registros en conjuntos de datos, tiempo e identificadores. Aquí es donde ES|QL (Elasticsearch Query Language) se vuelve esencial. Estos tipos de correlaciones de múltiples eventos, lógica temporal y normalización de campos son difíciles o totalmente imposibles en lenguajes de consulta basados en filtros estáticos como KQL sin escribir múltiples consultas inconexas y correlacionarlas manualmente luego del hecho.

Esta detección se basa en la correlación de múltiples eventos que ocurren cerca uno del otro pero provenientes de diferentes fuentes de datos, es decir, registros de inicio de sesión y actividad de Microsoft Graph. El objetivo es encontrar una reutilización sospechosa del mismo ID de sesión en múltiples IP, lo que podría indicar un secuestro de sesión o un abuso de token. Por cuestiones de espacio en esta publicación, puede ver la regla de detección real en la sección Reglas de detección. Para ilustrar mejor el flujo de la consulta y el significado, a continuación se muestra un diagrama para ilustrar a un nivel superior.

[ FROM logs-azure.* ]
        |
        |  ← Pulls events from all relevant Microsoft Cloud datasets:
        |     - azure.signinlogs (authentication)
        |     - azure.graphactivitylogs (resource access)
        ↓
[ WHERE session_id IS NOT NULL AND IP NOT MICROSOFT ASN ]
        |
        |  ← Filters out Microsoft-owned infrastructure (e.g., internal proxy,
        |     Graph API relays) using ASN checks.
        |  ← Ensures session ID exists so events can be correlated together.
        ↓
[ EVAL session_id, event_type, time_window, etc. ]
        |
        |  ← Normalizes key fields across datasets:
        |     - session_id (from signin or Graph)
        |     - user ID, app ID, event type ("signin" or "graph")
        |  ← Buckets events into 5-minute windows using DATE_TRUNC()
        ↓
[ KEEP selected fields ]
        |
        |  ← Retains only what's needed:
        |     session_id, timestamp, IP, user, client ID, etc.
        ↓
[ STATS BY session_id + time_window ]
        |
        |  ← Groups by session and time window to compute:
        |     - unique IPs used
        |     - apps involved
        |     - first and last timestamps
        |     - whether both signin and graph occurred
        ↓
[ EVAL time_diff + signin_to_graph_delay ]
        |
        |  ← Calculates:
        |     - time_diff: full session duration
        |     - delay: gap between signin and Graph access
        ↓
[ WHERE types_count > 1 AND unique_ips > 1 AND delay <= 5 ]
        |
        |  ← Flags sessions where:
        |     - multiple event types (signin + graph)
        |     - multiple IPs used
        |     - all occurred within 5 minutes
        ↓
[ Output = Suspicious Session Reuse Detected ]

Señal 3 : inicios de sesión simultáneos de Microsoft Entra ID con propiedades sospechosas

Esta detección identifica inicios de sesión sospechosos en Microsoft Entra ID donde un usuario se autentica empleando el flujo de código del dispositivo sin MFA o inicia sesión empleando el cliente VSCode. Cuando la misma identidad inicia sesión desde dos o más IP distintas en un corto periodo de tiempo empleando cualquiera de los métodos, puede indicar repetición de token, phishing de OAuth o actividad de adversario en el medio (AitM).

[ FROM logs-azure.signinlogs* ]
        |
        |  ← Pulls only Microsoft Entra ID sign-in logs
        ↓
[ WHERE @timestamp > NOW() - 1h AND event.outcome == "success" ]
        |
        |  ← Filters to the last hour and keeps only successful sign-ins
        ↓
[ WHERE source.ip IS NOT NULL AND identity IS NOT NULL ]
        |
        |  ← Ensures the sign-in is tied to a user and IP for correlation
        ↓
[ KEEP fields: identity, app_id, auth_protocol, IP, etc. ]
        |
        |  ← Retains app/client, IP, auth method, and resource info
        ↓
[ EVAL detection flags ]
        |
        |  ← Labels events as:
        |     - device_code: if MFA not required
        |     - visual_studio: if VS Code client used
        |     - other: everything else
        ↓
[ STATS BY identity ]
        |
        |  ← Aggregates all sign-ins per user, calculates:
        |     - IP count
        |     - Device Code or VSCode usage
        |     - App/client/resource details
        ↓
[ WHERE src_ip >= 2 AND (device_code_count > 0 OR vsc > 0) ]
        |
        |  ← Flags users with:
        |     - Sign-ins from multiple IPs
        |     - And either:
        |         - Device Code w/o MFA
        |         - Visual Studio Code app
        ↓
[ Output = Potential OAuth Phishing or Token Misuse ]

Si bien esta variante del phishing OAuth carece de la persistencia total que ofrecen los tokens de actualización o PRT, aún proporciona a los adversarios un valioso acceso único a datos confidenciales del usuario (como emails) a través de canales legítimos. Este ejercicio nos ayuda a comprender las limitaciones y capacidades de static .default alcances, la influencia de los registros de aplicaciones y cómo Microsoft Graph juega un papel fundamental en la autenticación posterior. También refuerza una lección más amplia: no todos los ataques de phishing de OAuth son iguales. Algunos buscan la longevidad (como veremos más adelante) a través de tokens de actualización o registro de dispositivos, mientras que otros se centran en el robo de datos inmediato a través de clientes propios. Comprender los matices es esencial para una lógica de detección precisa.

Escenario 2: Suplantación de identidad (phishing) de OAuth para el registro de dispositivos

Como dijimos anteriormente, Volexity también informó sobre un libro de estrategias de phishing separado dirigido a las víctimas, esta vez con el objetivo de registrar un dispositivo virtual y obtener un PRT. Si bien este enfoque requiere más pasos por parte del adversario, la recompensa es un token que otorga mucha más utilidad para completar sus operaciones. Para nuestros esfuerzos de emulación, necesitábamos expandir nuestro conjunto de herramientas y confiar en ROADtools, tal como lo hizo el adversario para seguir siendo precisos; sin embargo, se crearon varios otros scripts de Python para phishing inicial y acciones posteriores al compromiso.

Emulación

Comenzando con el phishing inicial, ajustamos nuestro script de Python para crear una URL OAuth diferente que se enviaría a nuestra víctima. Esta vez, el foco estuvo en nuestro ID de cliente de origen, que es Microsoft Authentication Broker, que aplicar un token de actualización con offline_access y redirecciona al URI del punto final de unión del dispositivo del dominio de nube de Entra ID.

{
  "client_id": "29d9ed98-a469-4536-ade2-f981bc1d605e",
  "response_type": "code",
  "response_mode": "query",
  "redirect_uri": "https://login.microsoftonline.com/WebApp/CloudDomainJoin/8",
  "resource": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
  "state": "nothingtoseehere"
}

Si tiene éxito y nuestra víctima se autentica, el flujo de trabajo OAuth se completará y el usuario será redirigido a la URI especificada con un código de autorización adjunto en los parámetros de consulta. Nuevamente, este código es la pieza crítica, debe compartir con el adversario para poder intercambiarlo por tokens. En nuestro caso, una vez que se abre la URL de phishing y el objetivo se autentica, capturamos el código de autorización integrado en la redirección y lo usamos para aplicar tokens del punto final del token de Microsoft Entra ID.

Ahora es aquí donde la cosa se pone interesante. En respuesta a la solicitud de token, recibimos tres tipos de tokens: un token de acceso, un token de actualización y un token de identificación. Quizás te preguntes: ¿por qué obtenemos más que un simple token de acceso? La respuesta está en los alcances que aplicar inicialmente: openid, offline_access y profile.

• openid nos otorga un token de identificación, que es parte de la capa OpenID Connect y confirma la identidad del usuario: este es su artefacto de autenticación (authN).
• offline_access proporciona un token de actualización, lo que nos permite mantener una sesión y aplicar nuevos tokens de acceso sin necesidad de volver a autenticarnos. Esto admite el acceso persistente pero es fundamental para nuestro uso con ROADtx.
• Y el token de acceso en sí se emplea para autorizar solicitudes a API protegidas como Microsoft Graph, esto representa la autorización (authZ).

Con estos tres tokens, tenemos todo: autenticación, autorización y continuidad de sesión a largo plazo. Eso es suficiente para pasar de una simple operación de phishing de OAuth a un ataque más persistente, como registrar un nuevo dispositivo en Microsoft Entra ID.

Ahora conectemos los puntos. Un PRT requiere el registro de un dispositivo válido, uno que Entra ID reconoce a través de un certificado de dispositivo y una clave privada. Aquí es donde entra en juego ROADtx. Debido a que nuestro phishing OAuth inicial se hizo pasar por un flujo de dispositivo unido, y el cliente empleado fue Microsoft Authentication Broker (un cliente de origen que interactúa con el Servicio de registro de dispositivos), ya tenemos el token de acceso correcto en la mano para interactuar con DRS. Observe que en nuestro objeto devuelto el alcance es adrs_access , que indica acceso a Azure DRS y es importante para detecciones posteriores.

Desde aquí, simplemente colocamos el objeto JSON recibido de nuestro intercambio de tokens en .roadtool_auth archivo. ROADtools consume de forma nativa este archivo y emplea los tokens almacenados para realizar el registro del dispositivo, completando el paso del adversario a la persistencia y preparando el escenario para obtener un PRT válido.

Luego de obtener los tokens, los preparamos para ROADtx reformateando el JSON. ROADtx espera claves en camelCase y también debemos incluir el ID de cliente de Microsoft Authentication Broker como _clientId. Esta configuración nos permite ejecutar el comando refreshtokento , que toma nuestro token de actualización y lo intercambia por un nuevo JWT con alcance en el DRS, específicamente, la entidad de servicio urn:ms-drs:enterpriseregistration.windows.net.

Una vez que esto está en su lugar, usamos el comando del dispositivo para simular un nuevo registro del dispositivo. Esta operación no requiere ninguna máquina virtual real ni host físico porque es un registro de backend que simplemente crea una entrada en Entra ID. En caso de éxito, recibimos un ID de dispositivo válido, un certificado codificado en PEM y una clave privada, todos ellos necesarios para simular un dispositivo híbrido válido en el ecosistema de Microsoft.

Con la identidad de nuestro dispositivo establecida, invocamos el comando prt . Esto emplea el token de actualización, el certificado del dispositivo y la clave privada para generar un nuevo PRT: una credencial altamente privilegiada que vincula de manera efectiva la confianza del usuario y el dispositivo en Microsoft Entra ID.

Y así, ¡vaya! —Tenemos un PRT.

Pero ¿por qué pasar por todo esto? ¿Por qué registrar un dispositivo, generar un certificado y obtener un PRT cuando ya tenemos un token de acceso, un token de identificación y un token de actualización?

Porque el PRT es la clave para la emulación completa de la identidad del usuario y del dispositivo. Piense en ello como un token de concesión de tiquetes similar a Kerberos en el mundo de Entra ID, pero en lugar de eso, un token de concesión de tokens. Con un PRT válido:

• Un adversario puede aplicar nuevos tokens de acceso e identificación para aplicaciones propias como Outlook, SharePoint o Teams sin necesidad de interacción del usuario.
• El PRT permite un inicio de sesión único (SSO) (SSO) sin inconvenientes en múltiples servicios, omitiendo MFA y otras políticas de acceso condicional (CAP) que normalmente volverían a aplicar al usuario. Esto es crucial para la persistencia, ya que el CAP y el MFA suelen ser enormes barreras para los adversarios.
• Admite persistencia de larga duración, ya que el PRT puede renovar y aprovechar de forma silenciosa en diferentes sesiones siempre que la identidad del dispositivo siga siendo confiable.

Y quizás lo más peligroso es que el PRT permite a los adversarios hacer pasar por una combinación de dispositivo y usuario totalmente compatible y unido al dominio, evadiendo eficazmente la mayoría de los controles de detección y respuesta convencionales, lo que hace que la línea entre lo benigno y lo sospechoso sea extremadamente delgada para los cazadores y analistas.

Esto convierte al PRT en un recurso increíblemente valioso que permite el movimiento lateral encubierto, la escalada de privilegios y el acceso profundo a los servicios de Microsoft 365 . Ya no se trata solo de entrar, sino de pasar desapercibido.

No olvidemos la actividad posterior al compromiso…

ROADtx ofrece algunos comandos poderosos empleados frecuentemente por los adversarios: prtenrich y browserprtauth. Por ejemplo, podemos acceder a la mayoría de los servicios de interfaz de usuario basados en navegador en la suite de Microsoft suministrando nuestro PRT que incluye los metadatos necesarios para la autenticación y la autorización, que originalmente pertenecían a nuestra víctima de phishing (yo), pero que en realidad es Microsoft Authentication Broker que actúa en su nombre.

Volexity también informó que luego del registro del dispositivo y la adquisición de PRT, se envió una solicitud 2FA a la víctima inicial, la cual fue aprobada y luego empleada para acceder a emails a través de SharePoint. Si bien no especifican exactamente cómo se realizaron las solicitudes, es razonable suponer que el adversario empleó el PRT para autenticar a través de un cliente propio de Microsoft y que el acceso real a los datos se realizó a través de Microsoft Graph. Graph sigue siendo un objetivo popular luego de una vulneración porque funciona como un centro de API central para la mayoría de los recursos de Microsoft 365 .

Para comenzar, aprovechemos ROADtx para autenticarnos con nuestro PRT, donde Microsoft Teams es nuestro cliente y Microsoft Graph es nuestro recurso. Al usar el comando prtauth con nuestro PRT, podemos obtener un nuevo token de acceso y un token de actualización, lo que demuestra claramente la utilidad del PRT como un token que otorga tokens dentro de la estructura de identidad de Microsoft.

Una vez que obtenemos nuestro token de acceso, lo conectamos a un script de Python personalizado para comenzar a enumerar nuestros sitios, unidades y elementos de SharePoint, lo que nos permite identificar archivos de interés y descargar su contenido.

Con esta emulación, mostramos cómo los adversarios pueden encadenar el phishing de OAuth con Microsoft Authentication Broker y obtener el material de credenciales necesario para aprovechar ROADtx para adquirir un PRT. Este PRT se convierte entonces en una utilidad importante luego del compromiso para acceder a archivos confidenciales, enumerar recursos de los inquilinos y mucho más.

Ahora, cambiemos el enfoque: ¿cuáles son las señales plausibles y precisas para detectar esta actividad?

Detección

Señal 1 : Suplantación de identidad (phishing) de Microsoft Entra ID OAuth como agente de autenticación de Microsoft

Identifica instancias en las que un usuario principal inicia un flujo de código de autorización OAuth empleando Microsoft Authentication Broker (MAB) como cliente y el Servicio de registro de dispositivos (DRS) como recurso de destino. Esta detección se centra en casos en los que se reutiliza un único ID de sesión en dos o más direcciones IP distintas dentro de un breve periodo de tiempo y al menos una solicitud se origina en un navegador, un comportamiento comúnmente asociado con el phishing.

[ FROM logs-azure.signinlogs-* ]
        |
        |  ← Pulls all Microsoft Entra ID sign-in logs
        ↓
[ WHERE app_id == MAB AND resource_id == DRS ]
        |
        |  ← Filters to OAuth auth code requests targeting
        |     Microsoft Authentication Broker + Device Reg Service
        ↓
[ EVAL session_id + is_browser ]
        |
        |  ← Extracts session ID and flags browser-based activity
        ↓
[ STATS BY 30-minute window, user, session_id ]
        |
        |  ← Groups logins within same session and time window,
        |     then aggregates:
        |       - user/session/token identifiers
        |       - distinct IPs and geo info
        |       - user agent, browser presence
        |       - app/resource/client info
        ↓
[ WHERE ip_count ≥ 2 AND session_id_count == 1 ]
        |
        |  ← Identifies reuse of a single session ID
        |     across ≥ 2 different IP addresses
        ↓
[ AND has_browser ≥ 1 AND auth_count ≥ 2 ]
        |
        |  ← Requires at least one browser-based request
        |     and at least two total sign-in events
        ↓
[ Output = Suspicious OAuth Flow with Auth Broker for DRS ]

Señal 2 : Solicitud sospechosa de token ADRS por parte del agente de autenticación de Microsoft

Identifica eventos de inicio de sesión de Microsoft Entra ID donde un usuario principal se autentica empleando un token de actualización emitido al cliente de Microsoft Authentication Broker (MAB), dirigido al Servicio de registro de dispositivos (DRS) con el ámbito OAuth adrs_access . Este patrón puede indicar acceso basado en token a DRS luego de un flujo de phishing de código de autorización inicial o de registro de dispositivo.

event.dataset: "azure.signinlogs" and azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and azure.signinlogs.properties.authentication_processing_details.`Oauth Scope Info`: *adrs_access* and azure.signinlogs.properties.incoming_token_type: "refreshToken" and azure.signinlogs.properties.user_type: "Member"

Señal 3 - Registro de dispositivo inusual en Entra ID

Detecta una secuencia de eventos del registro de auditoría de Entra ID que indican una posible actividad de registro de dispositivo malicioso mediante un token de actualización, algo que se observa comúnmente luego de un ataque de phishing de OAuth. Este patrón imita el comportamiento de herramientas como ROADtx, donde el Servicio de registro de dispositivos agrega un dispositivo Windows recién registrado (con una versión de sistema operativo codificada 10.0.19041.928), seguido de las asignaciones de usuario y propietario. Todos los eventos deben compartir el mismo ID de correlación y ocurrir dentro de una ventana de un minuto, lo que sugiere fuertemente una automatización o un registro impulsado por scripts en lugar de un comportamiento legítimo del usuario.

sequence by azure.correlation_id with maxspan=1m
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.identity == "Device Registration Service" and azure.auditlogs.operation_name == "Add device" and azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and (
  azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.display_name == "CloudAccountEnabled" and 
azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.new_value: "[true]") and azure.auditlogs.properties.target_resources.`0`.modified_properties.`3`.new_value like "*10.0.19041.928*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered users to device" and azure.auditlogs.properties.target_resources.`0`.modified_properties.`2`.new_value like "*urn:ms-drs:enterpriseregistration.windows.net*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered owner to device"]

Señal 3 : Transición de RT a PRT de Entra ID desde el mismo usuario y dispositivo

Esta detección identifica cuándo un usuario de Microsoft Entra ID se autentica por primera vez empleando un token de actualización emitido al Microsoft Authentication Broker (MAB), seguido poco después por el uso de un token de actualización principal (PRT) del mismo dispositivo. Esta secuencia es poco común en el comportamiento normal del usuario y puede indicar que un adversario registró con éxito un dispositivo y escaló al acceso persistente empleando herramientas como ROADtx. Al filtrar la actividad vinculada al Servicio de registro de dispositivos (DRS) en el segundo paso, la regla se centra en el uso del PRT posterior al registro para acceder a otros servicios de Microsoft 365 .

Este comportamiento sugiere fuertemente un compromiso basado en tokens y una emulación de sesión a largo plazo, particularmente cuando la confianza del dispositivo se establece de forma silenciosa. Captar esta transición del token de actualización al PRT es fundamental para detectar señales de alta fidelidad de phishing de OAuth y persistencia posterior al compromiso.

sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1d
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
    azure.signinlogs.properties.device_detail.device_id != null and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]

Señal 4 - Uso inusual de PRT y dispositivo registrado para el usuario principal

Esta detección surge cuando un usuario de Microsoft Entra ID registra un nuevo dispositivo que no vio antes en los últimos 7 días: un comportamiento que suele estar asociado con campañas de phishing de OAuth que se encadenan con el registro de dispositivos basado en ROADtx. En estos ataques, los adversarios engañan a los usuarios para que autoricen el acceso al Microsoft Authentication Broker (MAB) que apunta al DRS, obtienen un RT y luego usan ROADtx para registrar silenciosamente un dispositivo Windows falso y crear un PRT. Esta regla alerta cuando un usuario principal se autentica desde un ID de dispositivo recientemente observado, en individuo si la sesión no está vinculada, lo que es característico de la reproducción de tokens o la suplantación de dispositivos. Debido a que los PRT requieren un dispositivo registrado y confiable, esta señal juega un papel fundamental a la hora de identificar cuándo un adversario pasó del abuso básico de tokens al acceso persistente y sigiloso alineado con un compromiso a largo plazo.

event.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
    not azure.signinlogs.properties.device_detail.device_id: "" and
    azure.signinlogs.properties.user_principal_name: *

Nuevos valores de los términos :

• azure.signinlogs.properties.nombre_principal_del_usuario
• azure.signinlogs.properties.detail_del_dispositivo.id_del_dispositivo

Esta emulación nos ayudó a validar el flujo de trabajo completo del atacante, desde la suplantación de identidad (phishing) para obtener consentimiento hasta el establecimiento de la confianza del dispositivo y la creación de un PRT para la persistencia a largo plazo. Al encadenar el abuso de OAuth con el registro de dispositivos, los adversarios pueden satisfacer los CAP, suplantar puntos finales compatibles y mover lateralmente a través de entornos de nube, a menudo sin activar los controles de seguridad tradicionales.

Estos matices importan. Si se observan de forma aislada, eventos individuales como la emisión de tokens o el registro de dispositivos pueden parecer benignos. Pero cuando se correlacionan los registros de inicio de sesión, los datos de auditoría y los metadatos del token, exponen un rastro claro de violación de la identidad.

Detalles clave de telemetría para detección y abuso

A lo largo de nuestros esfuerzos de emulación y detección, los artefactos de telemetría específicos demostraron consistentemente ser esenciales para separar la actividad benigna de OAuth del abuso malicioso. Comprender cómo aparecen estos campos en los registros de identificación de Microsoft Entra (y cómo los manipulan los atacantes) es fundamental para una ingeniería de búsqueda y detección eficaz. Desde las identificaciones de clientes y los tipos de concesiones hasta la conformidad del dispositivo, los tipos de tokens y los resultados de acceso condicional, estas señales cuentan la historia de los ataques basados en identidad. A continuación seleccionamos una lista de los más importantes y cómo pueden ayudarnos.

ID de aplicación del cliente (client_id): identifica la aplicación que inicia la solicitud OAuth. Clientes de origen (por ejemplo, Se puede hacer un uso indebido de VSCode, Auth Broker para integrar. Los clientes de terceros pueden ser maliciosos o no revisados, lo que a menudo representa ataques de concesión de consentimiento. Se emplea principalmente para identificar usos riesgosos o inesperados de la aplicación.

Recurso de destino (resource_id / resource_display_name): define a qué servicio MSFT se está accediendo (por ejemplo, Gráfico MSFT o Equipos). Los objetivos de alto valor incluyen: Graph API, SharePoint, Outlook, Teams y servicios de directorio. La selección de recursos suele estar delimitada por los objetivos del atacante.

Tipo de principal (user_type): indica si el inicio de sesión fue realizado por un miembro (usuario) o un principal de servicio. Las campañas de phishing casi siempre se dirigen a las cuentas de los miembros. Esto permite un filtrado sencillo en la lógica de detección, pero ayuda a emparejar solicitudes de clientes de primera parte inusuales en nombre de los usuarios principales.

Tipo de concesión de OAuth (authentication_processing_details): clave para comprender cómo se obtuvo el token (códigos de autorización, tokens de actualización, códigos de dispositivo, credenciales de cliente, etc.). Mientras que los tokens de actualización y la reutilización del código del dispositivo son señales de alta fidelidad de post-compromiso.

Geolocalización: Nos permite identificar inicios de sesión atípicos (por ejemplo, país raro visto) o viaje imposible (el mismo usuario desde lugares distantes en poco tiempo). Combinados con el identificador de sesión y los identificadores de correlación, estos pueden revelar secuestro de tokens, compromiso de identidad posterior o movimiento lateral.

Metadatos del dispositivo (detalle del dispositivo, tipo de confianza, estado de cumplimiento): incluye ID de dispositivo, sistema operativo, tipos de confianza, cumplimiento, estado gestionado y más. El registro del dispositivo y la emisión de PRT están vinculados a estos metadatos. A menudo, un objetivo de los adversarios es satisfacer el CAP y obtener un acceso confiable y persistente.

Protocolos y tipos de autenticación (authentication_protocol / incoming_token_type): revela si la sesión se basó en OAuth o si se empleó MFA. Las fuentes de token entrantes son aquellas empleadas para esta solicitud que proporcionan authN o authZ. Útil para detectar reutilización de tokens e inicios de sesión no interactivos.

Material de autenticación y contexto de sesión: los tokens empleados se pueden inferir a través del tipo de token entrante, el estado de protección del token y la ID de la sesión. La reutilización de sesiones, una duración de sesión prolongada o múltiples IP vinculadas a una sola sesión suelen indicar abuso.

Estado de la política de acceso condicional: se evalúa durante la emisión del token; sin embargo, influye en gran medida si se concede el acceso. Esto ayuda a identificar la evasión de la PAC, resultados políticos inesperados o puede ser un factor de riesgo.

Ámbitos y comportamiento del consentimiento: los ámbitos aplicar aparecen en los parámetros SCP u OAuth capturados en los registros de inicio de sesión. Los indicadores de abuso incluyen offline_access, .default, o ámbitos amplios como Mail.ReadWrite. La telemetría de consentimiento puede ayudar a determinar o correlacionar si el usuario aprobó una aplicación sospechosa.

Conclusión

La implementación de OAuth de Microsoft Entra ID presenta un arma de doble filo: permite experiencias de autenticación poderosas y fluidas, pero también expone nuevas oportunidades para que los adversarios exploten las rutas de ataque de confianza, persistencia de sesión y registro de dispositivos.

Al replicar las técnicas de phishing de OAuth observadas por Volexity, nuestro equipo pudo validar cómo los atacantes abusan de aplicaciones legítimas de Microsoft, flujos de tokens y herramientas de código abierto para obtener acceso sigiloso a datos confidenciales. Extendimos este trabajo a través de una emulación práctica, profundizando en la mecánica del phishing y los flujos de trabajo de OAuth, los metadatos y la adquisición de tokens de seguridad, lo que ayudó a descubrir indicadores de comportamiento que los defensores pueden detectar.

Nuestros hallazgos refuerzan un punto clave: el abuso de OAuth no depende de malware o de la ejecución de código. Convierte la identidad, el consentimiento y la reutilización de tokens en armas, lo que convierte a los controles de seguridad tradicionales en un desafío, y explica por qué la detección basada en registros, la correlación y el análisis del comportamiento son tan críticos.

Esperamos que los artefactos de emulación, las reglas de detección y las lecciones compartidas aquí ayuden a los defensores de toda la comunidad a comprender mejor (y detectar/cazar) esta clase en evolución de amenazas a la identidad basadas en la nube.

Si usa Elastic, publicamos en código abierto todas las reglas de detección analizadas en este blog para que pueda comenzar. Y si estás cazando en otro SIEM, te recomendamos adaptar la lógica y ajustarla a tu entorno en consecuencia.

La identidad es el nuevo perímetro y es hora de que la tratemos de esa manera. ¡Mantener seguro y feliz caza!

Reglas de detección

• Reutilización de sesión de Microsoft Entra ID con acceso sospechoso a gráficos
• Suplantación de identidad (phishing) de Microsoft Entra ID OAuth a través del cliente de Visual Studio Code
• Flujo sospechoso de Microsoft OAuth a través del agente de autenticación hacia DRS
• Solicitud sospechosa de token ADRS por parte de Microsoft Auth Broker
• Registro de dispositivo inusual en Entra ID
• Transición de Entra ID RT a PRT desde el mismo usuario y dispositivo
• Dispositivo registrado inusual para el usuario principal

Referencias:

• https:\/\/www.volexity.com\/blog\/2025\/04\/22\/phishing-para-códigos-de-amenaza-rusos-se-dirige-a-los-flujos-de-trabajo-oauth-de-microsoft-365\/
• https:\/\/dirkjanm.io\/abuso-de-azure-ad-sso-con-el-token-de-actualización-principal\/
• https:\/\/posts.specterops.io\/solicitud-de-tokens-de-solicitud-de-azure-ad-en-máquinas-unidas-a-azure-ad-para-navegador-SSO-2b0409caad30
• https:\/\/learn.microsoft.com\/es-es\/entra\/identity\/devices\/concept-primary-refresh-token
• https:\/\/learn.microsoft.com\/es-es\/entra\/identity-platform\/refresh-tokens
• https:\/\/learn.microsoft.com\/es-es\/entra\/identity-platform\/v2-oauth2-auth-code-flow
• https:\/\/learn.microsoft.com\/es-es\/entra\/identity-platform\/scopes-oidc#the-default-scope