针对主刷新令牌和 Windows Hello 密钥的网络钓鱼

在 Microsoft Entra ID（以前称为 Azure AD，在本博客中称为“Azure AD”）中，有不同类型的 OAuth 令牌。最强大的令牌是主刷新令牌，它链接到用户的设备，可用于登录任何 Entra ID 连接的应用程序和网站。在网络钓鱼场景中，尤其是滥用合法 OAuth 流（例如设备代码网络钓鱼）的场景中，生成的令牌通常是功能较弱的令牌，其范围或使用方法受到限制。在本博客中，我将介绍直接针对主刷新令牌进行网络钓鱼的新技术，并且在某些情况下还会部署符合最严格的 MFA 策略的无密码凭据。

令牌和限制

简单回顾一下，Azure AD 中有不同的令牌类型，每种类型都有自己的限制：

• 访问令牌，可用于与 API 通信并访问资源，例如通过 Microsoft Graph。它们与特定的客户端（请求它们的应用程序）和特定的资源（您正在访问的 API）相关联。
• 刷新令牌，颁发给应用程序以获取新的访问令牌，因为访问令牌的生命周期相对较短。它们只能由发布到它们的应用程序使用，或者在某些情况下由一组应用程序使用。
• 主刷新令牌，用于在加入、注册或混合加入 Azure AD 的设备上进行单点登录。它们既可用于 Web 应用程序的浏览器登录流程，也可用于登录设备上运行的移动和桌面应用程序。我在许多博客和演讲中广泛介绍了主刷新令牌 (PRT)单点登录、窃取、滥用和横向移动。

访问令牌是唯一可用于访问数据的令牌，（主）刷新令牌可用于请求访问令牌，但不能直接用于与使用 Azure AD 进行身份验证的服务进行通信。这些令牌的安全性还要求您不能使用访问令牌来获取刷新令牌，因为这将允许您将令牌“升级”为比最初更强大的令牌。

获取主刷新令牌的要求是您需要从设备身份开始，然后使用用户凭据请求 PRT。这限制了这些强大代币的发行方式，并使攻击者更难获得它们。

规则的例外 - 特殊刷新令牌

不久前，我正在研究 Windows Hello 企业版 (WHFB)，我花了很多时间重置我的测试系统来分析该过程。在这项研究期间，我观察到了一些有趣的行为。如果设置新的 Windows 安装，通常只需要在设置过程中进行一次身份验证，并且一次身份验证用于完成整个设置流程并设置 WHFB 密钥。这很有趣，因为在我们开始设置时，设备尚未在 Azure AD 中加入或注册。然而，最终，我们有一个用于 SSO 的 PRT，甚至满足提供 WHFB 密钥的要求（这始终需要通过 PRT 使用的设备身份）。

通过分析 Windows 设置过程中使用的令牌流，我发现该过程从登录特定应用程序开始，这为 Windows 提供了访问令牌和刷新令牌。访问令牌可用于将设备加入 Azure AD 并设置设备标识。设备注册后，在没有设备的情况下颁发的刷新令牌将与新设备标识一起使用来请求主刷新令牌。对我来说，这明显违反了令牌安全架构。我们可以使用常规刷新令牌（不与设备绑定但与特定应用程序绑定）首先注册设备，然后请求可在任何登录场景中使用的更强大的令牌。

技术细节

每个刷新令牌都无法从普通刷新令牌“升级”到主刷新令牌。它在登录流程中需要特定的应用程序 ID（客户端 ID）。Windows 使用客户端 ID 29d9ed98-a469-4536-ade2-f981bc1d605e（Microsoft 身份验证代理）和资源https://enrollment.manage.microsoft.com/来执行此请求。我们可以使用 roadtxgettokens命令模拟此流程，该命令支持多种不同的身份验证流程：

如果有需要 MFA 登录的策略，我们可以改用该interactiveauth模块：

生成的刷新令牌（缓存在文件中.roadtools_auth）可用于请求设备注册服务的令牌，我们可以在其中创建设备：

现在我们有了设备标识，我们可以将其与相同的刷新令牌结合起来以获得 PRT（为了便于阅读，两个刷新令牌都被缩短）：

身份验证产生的令牌将包含与注册期间使用的相同的身份验证方法声明，因此任何 MFA 使用都将转移到 PRT。我们获得的 PRT 可用于任何身份验证流程，因此我们可以将有限的刷新令牌的范围扩展到任何可能的应用程序。

我们还可以使用它来登录浏览器流：

配置 Windows Hello 企业版密钥

如果您设置 Windows 并且为您的设备启用了 WHFB，它将使用相同的会话为新设置的设备预配 WHFB 密钥。为此，我们需要带有ngcmfa声明的访问令牌。只要我们在最后 10 分钟内进行了 MFA 身份验证，我们就需要上一步的 PRT。我们可以要求 Azure AD 为包含此声明的设备注册服务提供令牌，而无需进一步的用户交互。为此，我们使用prtenrichroadtx 中的命令，该命令将请求此令牌。

有了这个新的访问令牌，我们可以配置新的 WHFB 密钥。该密钥还可用于将来请求新的 PRT，而无需访问用户密码。

主要刷新令牌的网络钓鱼

现在我们知道了这个过程是如何工作的，我们可以改变方法以使其可用于网络钓鱼。直接钓鱼 PRT 是不可能的，因为这需要在流程中使用现有的设备身份。我们无法欺骗用户或其端点向我们发送直接请求 PRT 所需的信息。但是，我们可以使用多种方法向正确的客户端和资源请求定期刷新令牌，然后使用它来注册设备并请求 PRT。

设备代码网络钓鱼

在上面的身份验证步骤中，我们使用用户名和密码进行身份验证。但是，我们也可以使用设备代码流来实现此目的。虽然 Windows 不使用此流程进行注册/加入过程，但它是一个有效的 OAuth 流程，将为我们提供相同的刷新令牌。

如您所见，设备代码流程要求用户在自己的设备上输入代码并完成身份验证，这将在启动的设备上提供令牌。此流程也适用于网络钓鱼，因为如果我们能够说服受害者使用设备代码执行身份验证，我们将代表他们获取令牌。这不是一项新技术，但过去已有几个人描述过。还有几个工具包可以使整个过程变得更容易。如果您想了解这项技术，这里有一些参考资料：

• https://aadinternals.com/post/phishing/
• https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html
• https://github.com/secureworks/squarephish
• https://www.blackhillsinfosec.com/dynamic-device-code-phishing/

因此，让我们假设我们说服用户进行身份验证，并且我们收到刷新令牌。我们现在可以使用此刷新令牌来：

• 如果我们尚无权访问租户中的设备，请将设备注册或加入到 Azure AD。
• 使用刷新令牌请求 PRT。
• 如果用户在使用设备代码流进行身份验证时执行“全新”MFA，我们还可以在其帐户上注册 WHFB 凭据以实现持久性。

对此有一些注意事项，如果您执行此攻击，则必须考虑这些注意事项：

• 设备代码仅在您启动设备代码流后 15 分钟内有效，如果您想将其用于网络钓鱼，这会增加额外的限制。一些工具通过仅在用户与电子邮件交互（例如通过 QR 码）时创建设备代码来解决此问题。
• 在租户中注册或加入设备可以仅限于特定用户。一般来说，加入设备比注册设备更容易受到限制。除非有特定的策略要求特定的设备状态，否则令牌的可用性不会有实际差异。
• 仅当用户在使用设备代码时主动执行 MFA 时，才可以注册 WHFB 凭据。如果他们使用其托管设备的现有会话中的设备代码，MFA 声明将传递到刷新令牌，并且很可能不够新，无法配置 WHFB 密钥。在我的测试中，仅当用户在非托管设备上具有现有会话时才会使用缓存的登录状态，并且在使用 SSO 登录的浏览器上不会自动使用缓存的登录信息。

下面的视频显示了该攻击作为概念证明。在实际场景中，您可以使用您喜欢的设备代码网络钓鱼框架或方法来完成网络钓鱼部分。

上面的视频使用deviceCode2WinHello脚本来自动执行所有这些步骤，由 SpectreOps 的Kai编写（请参阅博客末尾的结论）。它还使用该roadtx keepassauth模块进行身份验证，实际上您必须说服受害者进行身份验证，但这对于演示来说更容易。

凭证网络钓鱼

还可以使用凭证网络钓鱼方法来执行网络钓鱼攻击，例如使用 evilginx 作为框架。如果我们使用 Microsoft 365 phishlet 登录，例如Jan Bakker 的这个，我们将获取受害者的会话 cookie。这些会话 cookie 可以与 roadtx 一起使用来请求正确的令牌，并且从那里开始的攻击是相同的：

预防与检测

防止这些攻击的方法并不多。设备代码网络钓鱼是需要一定 MFA 强度而无法阻止的少数方法之一，因为用户针对合法的 Microsoft 域执行此身份验证。此外，不幸的是，无法阻止某些 OAuth 流，例如设备代码流。上述凭证网络钓鱼方法更容易预防，因为这种情况会发生在虚假网站上，从而阻止某些 MFA 方法发挥作用。

阻止这种攻击的唯一真正有效的方法是要求通过 MDM 或 MAM 管理设备，方法是制定需要合规或混合连接设备的条件访问策略。为了遵守此策略，新注册的设备也需要在 Intune 中注册。如果 Intune 被充分锁定以阻止人们注册非公司或虚假设备，我们新注册的设备将无法合规并满足这些策略的要求。请注意，设备注册流本身不会被需要合规设备的策略阻止，因为根据定义，该流已被排除在这些策略之外（在设备注册期间您不能已经拥有合规设备）。因此，如果制定了要求合规或混合连接设备的政策，仍然可以获得 PRT。然而，PRT 不能用于验证或注册 WHFB 密钥，因为这需要设备兼容或混合连接。

幸运的是，这种技术的检测更容易。Windows 不会使用设备代码流将自身注册或加入 Azure AD，但会以交互方式提示用户进行身份验证。由于身份验证流程显示在登录日志中，因此根据应用程序 ID 和身份验证流程编写检测查询非常容易。KQL 查询示例如下所示：

在我与 Microsoft 讨论此主题时，我获悉在某些情况下，代理应用程序会合法使用设备代码流，因此此查询可能会产生一些误报。如果您发现此查询存在一些合法匹配项，请随时与我们联系，以便我们看看是否可以对其进行微调以排除合法情况。

披露流程

几个月前，我向 Microsoft 报告了此问题，因为升级令牌的功能违反了刷新令牌应实施的限制。虽然微软承认了这个问题，但他们认为不值得立即解决这个问题，因为需要网络钓鱼用户进行身份验证。这意味着红队可以在未来的活动中使用这种技术，直到该技术出现新的缓解措施，并且防御者应该意识到这些身份验证流程的滥用潜力。

微软确实表示他们正在开发新功能来缓解这个问题。他们正在考虑的缓解措施如下：

• 如果设备代码流屏幕用于对代理客户端进行身份验证，则会向设备代码流屏幕添加其他警告，警告用户这将允许应用程序代表他们执行单点登录。
• 向条件访问添加附加功能，以便对何时允许设备代码流提供更多控制，从而提供限制或阻止某些应用程序或位置的设备代码流的可能性，类似于其他条件访问功能。

结论和工具

由于能够将一些刷新令牌升级为主刷新令牌，攻击者有更多方法来钓鱼用户和危害帐户。这使用了工具中已有的正常令牌流，例如 ROADtools Token eXchange 工具包 (roadtx)（可通过GitHub获取）。

在写这个博客时，我与Kai聊天，他是几周前参加我的 Azure AD 培训的人员之一。他还独立地找出了相同的升级技术，并编写了一个通过单个命令执行这些步骤的脚本。

deviceCode2WinHello脚本来自动执行所有这些步骤，由 SpectreOps 的Kai

• https://github.com/kiwids0220/deviceCode2WinHello

ROADtools Token eXchange 工具包 (roadtx)：

• https://github.com/dirkjanm/ROADtools

单个命令执行这些步骤的脚本

• https://github.com/kiwids0220/deviceCode2WinHello

原文地址或（点击阅读原文）：

https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/