Az - Pass the PRT
O que é um PRT
Az - Primary Refresh Token (PRT)Verifique se você tem um PRT
Na seção SSO State, você deve ver o AzureAdPrt
definido como YES.
No mesmo output, você também pode ver se o dispositivo está associado ao Azure (no campo AzureAdJoined
):
PRT Cookie
O PRT cookie é na verdade chamado de x-ms-RefreshTokenCredential
e é um JSON Web Token (JWT). Um JWT contém 3 partes, o header, payload e signature, divididos por um .
e todos codificados em base64 seguro para URL. Um PRT cookie típico contém o seguinte header e body:
O Primary Refresh Token (PRT) real está encapsulado dentro do refresh_token
, que é criptografado por uma chave sob o controle do Azure AD, tornando seu conteúdo opaco e indecifrável para nós. O campo is_primary
indica a encapsulação do primary refresh token dentro deste token. Para garantir que o cookie permaneça vinculado à sessão de login específica para a qual foi destinado, o request_nonce
é transmitido da página logon.microsoftonline.com
.
Fluxo de Cookie PRT usando TPM
O processo LSASS enviará para o TPM o contexto KDF, e o TPM usará a chave de sessão (obtida quando o dispositivo foi registrado no AzureAD e armazenada no TPM) e o contexto anterior para derivar uma chave, e essa chave derivada é usada para assinar o cookie PRT (JWT).
O contexto KDF é um nonce do AzureAD e o PRT criando um JWT misturado com um contexto (bytes aleatórios).
Portanto, mesmo que o PRT não possa ser extraído porque está localizado dentro do TPM, é possível abusar do LSASS para solicitar chaves derivadas de novos contextos e usar as chaves geradas para assinar Cookies.
Cenários de Abuso do PRT
Como um usuário regular é possível solicitar o uso do PRT pedindo dados de SSO ao LSASS. Isso pode ser feito como aplicativos nativos que solicitam tokens do Web Account Manager (token broker). O WAM passa a solicitação para o LSASS, que solicita tokens usando a afirmação PRT assinada. Ou pode ser feito com fluxos baseados em navegador (web) onde um cookie PRT é usado como cabeçalho para autenticar solicitações nas páginas de login do Azure AS.
Como SYSTEM você poderia roubar o PRT se não estiver protegido pelo TPM ou interagir com as chaves PRT no LSASS usando APIs de criptografia.
Exemplos de Ataques Pass-the-PRT
Ataque - ROADtoken
Para mais informações sobre este método verifique este post. O 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 refresh token persistente.
Para gerar um cookie PRT válido, a primeira coisa que você precisa é um nonce. Você pode obter isso com:
Ou usando roadrecon:
Então você pode usar roadtoken para obter um novo PRT (execute a ferramenta a partir de um processo do usuário a ser atacado):
Como oneliner:
Então você pode usar o cookie gerado para gerar tokens para login usando Azure AD Graph ou Microsoft Graph:
Attack - Using roadrecon
Attack - Using AADInternals and a leaked PRT
Get-AADIntUserPRTToken
obtém o token PRT do usuário do computador associado ao Azure AD ou associado de forma híbrida. Usa BrowserCore.exe
para obter o token PRT.
Vá para https://login.microsoftonline.com, limpe todos os cookies para login.microsoftonline.com e insira um novo cookie.
Then go to https://portal.azure.com
O restante deve ser o padrão. Certifique-se de que você pode atualizar a página e o cookie não desaparece; se desaparecer, você pode ter cometido um erro e terá que passar pelo processo novamente. Se não desaparecer, você deve estar bem.
Ataque - Mimikatz
Passos
O PRT (Primary Refresh Token) é extraído do LSASS (Local Security Authority Subsystem Service) e armazenado para uso subsequente.
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 nestes recursos: HackTricks e para entender sua aplicação, consulte Pass-the-cookie attack.
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 é usada para assinar o JWT (JSON Web Token) que constitui o cookie. Uma explicação abrangente deste processo foi fornecida por Dirk-jan, acessível aqui.
Note que se o PRT estiver dentro do TPM e não dentro do lsass
mimikatz não será capaz de extraí-lo.
No entanto, será possível obter uma chave de uma chave derivada de um contexto do TPM e usá-la para assinar um cookie (verifique a opção 3).
Você pode encontrar uma explicação detalhada do processo realizado para extrair esses detalhes aqui: https://dirkjanm.io/digging-further-into-the-primary-refresh-token/
Isso não funcionará exatamente após as correções de agosto de 2021 para obter tokens PRT de outros usuários, pois apenas o usuário pode obter seu PRT (um administrador local não pode acessar os PRTs de outros usuários), mas pode acessar o seu.
Você pode usar mimikatz para extrair o PRT:
(Imagens de https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
Copie a parte rotulada como Prt e salve-a.
Extraia também a chave de sessão (o KeyValue
do campo ProofOfPossesionKey
) que você pode ver destacado abaixo. Isso está criptografado e precisaremos usar nossas chaves mestres DPAPI para descriptografá-lo.
Se você não vir nenhum dado PRT, pode ser que você não tenha nenhum PRT porque seu dispositivo não está associado ao Azure AD ou pode ser que você esteja executando uma versão antiga do Windows 10.
Para descriptografar a chave de sessão, você precisa elevar seus privilégios para SYSTEM para executar no contexto do computador e poder usar a chave mestra DPAPI para descriptografá-la. Você pode usar os seguintes comandos para fazer isso:
Opção 1 - Mimikatz Completo
Agora você quer copiar ambos os valores de Context:
E o valor da chave derivada:
Finalmente, você pode usar todas essas informações para gerar cookies PRT:
Vá para https://login.microsoftonline.com, limpe todos os cookies para login.microsoftonline.com e insira um novo cookie.
Então vá para https://portal.azure.com
O resto deve ser o padrão. Certifique-se de que você pode atualizar a página e o cookie não desapareça; se desaparecer, você pode ter cometido um erro e terá que passar pelo processo novamente. Se não desaparecer, você deve estar bem.
Opção 2 - roadrecon usando PRT
Renove o PRT primeiro, o que o salvará em
roadtx.prt
:
Agora podemos solicitar tokens usando o navegador interativo com
roadtx browserprtauth
. Se usarmos o comandoroadtx describe
, veremos que o token de acesso inclui uma reivindicação MFA porque o PRT que usei neste caso também tinha uma reivindicação MFA.
Opção 3 - roadrecon usando chaves derivadas
Tendo o contexto e a chave derivada extraída pelo mimikatz, é possível usar o roadrecon para gerar um novo cookie assinado com:
Referências
Last updated