使用 Microsoft Entra 临时访问通行证进行横向移动和本地 NT 哈希转储

临时访问通行证是 Microsoft Entra ID（以前称为 Azure AD）管理员为用户帐户配置临时密码的一种方法，这也将满足多重身份验证控制。它们可以成为设置无密码身份验证方法（例如 FIDO 密钥和 Windows Hello）的有用工具。在本博客中，我们仔细研究了攻击者滥用临时访问通行证进行横向移动的选项，展示了如何将它们用于无密码持久性，甚至在某些混合配置中恢复本地 Active Directory 密码。

默认情况下不启用临时访问通行证。但是，许多主要使用无密码身份验证形式的租户都启用了这些功能，以允许用户首次配置无密码身份验证方法，或者在这些用户需要重置其身份验证方法时进行帐户恢复。对于攻击者来说，临时访问通行证 (TAP) 还提供了有趣的选项，因为这些临时密码位于用户常规密码旁边，这意味着在帐户上配置 TAP 并不是像重置帐户密码那样的破坏性操作。TAP 的滥用本身并不新鲜，已经有一些很棒的博客探讨了这个概念，例如来自 SpecterOps 的 Daniel Heinsen的博客。

不久前阅读 Daniel 的博客后，我开始使用这些 TAP，看看是否也可以将它们与 ROADtools 一起使用来请求令牌，以及这些令牌的限制是什么。由于 TAP 可用于配置无密码身份验证方法，因此我们也可以使用它们在帐户上配置 Windows Hello 企业版密钥也就不足为奇了，该密钥在我去年的 Windows Hello 演讲后已添加到 ROADtools 中。我将在下面描述相关步骤。我在研究过程中发现更有趣的是，TAP 也可用于混合环境中的横向移动，其中在 Entra 中使用 TAP 将允许攻击者在本地 Active Directory 中进行身份验证。它甚至允许攻击者恢复受害者帐户的 NT 哈希值，这可能用于恢复受害者帐户的纯文本密码。混合横向移动部分仅在使用 Cloud Kerberos Trust 时适用，这使 Entra ID 能够为本地身份颁发 Kerberos 票证。

配置 TAP

管理员可以配置临时访问通行证，前提是启用了该功能并且管理员有足够的权限来执行此操作。Microsoft 的TAP 文档中非常清楚地列出了要求和方法。我们还可以通过 Microsoft Graph Rest API 来完成此操作，但这需要我们拥有具有UserAuthenticationMethod.ReadWrite.All委派权限的令牌。对我们来说不幸的是，据我所知，没有任何内置 Microsoft 应用程序具有这种访问权限，因此我们最好的选择是使用 Azure/Entra 门户或从该门户借用令牌并使用它使用 PowerShell 或REST API。在这种情况下，我们将坚持使用 Azure 门户来配置临时访问通行证。

 临时访问通行证充当用户的替代凭证，这意味着我们可以在合法用户不被中断的情况下使用它们，这比密码重置等破坏性操作有很大优势，密码重置将使用户当前会话无效并可能引起一些投诉。由于 TAP 也算作 MFA，因此我们也不必担心他们会收到来自 MFA 提示的通知或短信。现在我们有了 TAP，让我们看看如何将其转换为持久访问。

滥用 TAP 进行横向移动

TAP 本身仅在配置的生命周期内有效。虽然我们可以在创建 TAP 时影响这一点，但较长的有效性也可能会引起怀疑，因为 TAP 在其生命周期内自动成为首选身份验证方法。为了最大限度地减少合法用户被提示输入 TAP 的机会，我们可以使其生命周期尽可能短，或者只允许使用一次。

使用 TAP 配置 Windows Hello 企业版密钥

要配置 Windows Hello 企业版，我们需要一些特殊令牌。此过程与我上一篇博客中的流程非常相似，其中我们使用 Microsoft 身份验证代理的特殊权限来请求可以升级到 PRT 的令牌。此流程也类似于 Windows 在仅使用密码获取主刷新令牌后升级主刷新令牌以包含 MFA 声明的方式。在此流程中，我们不直接在 PRT 请求中使用身份验证方法，而是使用充当中介的特殊刷新令牌。

Windows Hello 配置还要求我们在租户中拥有一个设备。对我们来说幸运的是，几乎所有租户都可以注册或加入设备，因此，如果我们无法访问现有设备，我们可以注册或加入设备作为流程的一部分。从技术上讲，我们可以在这里滥用现有设备，但这会使过程变得复杂，特别是在涉及 TPM 的情况下。

第一步是使用prtenrich来自roadtx 的命令使用 TAP 进行身份验证。如果我们使用该标志，则该命令在没有现有 PRT 的情况下也可以工作--no-prt，这允许我们使用 TAP 进行身份验证。

roadtx prtenrich -u [email protected] --no-prt

这将提示我们输入 TAP（现在是首选身份验证方法），并为我们提供刷新令牌。如果我们还没有设备证书/密钥，我们也可以使用此刷新令牌来注册设备。

roadtx gettokens --refresh-token <token> -c broker -r drs

我们可以使用该模块加入或注册设备device：

roadtx device -n blogtest2 -a register

通过我们新注册的设备，我们可以获得 PRT：

roadtx prt -r <refreshtoken> -c blogtest2.pem -k blogtest2.key

这些命令的输出应该看起来像这样：

对我们来说不幸的是，这个 PRT 的有效期与 TAP 本身一样长。过期时间里没有说，但是TAP过期后就会被拒绝：

如果我们想要真正的持久性，我们需要在帐户上提供一些额外的凭据。在这种情况下，我们可以为该帐户设置一个 Windows Hello 密钥，然后在 TAP 过期后可以使用该密钥。执行此操作的过程与我上一篇博客中的过程非常相似。我们prtenrich再次使用该命令来获取 Windows Hello 配置的访问令牌，然后注册实际的 hello 密钥。

roadtx prtenrich --ngcmfa-drs-authroadtx winhello -k hybriduser.key

prtenrich如果我们在过去 10 分钟内进行了 TAP 身份验证，该命令应该会自动继续。如果没有，我们可以再次使用 TAP 来满足 MFA 要求（前提是 TAP 可以多次使用）。该winhello命令为我们的用户提供密钥。如果需要，我们可以用它来获取新的 PRT，该 PRT 的有效期更长，并且也算作 MFA：

roadtx prt -hk hybriduser.key -c blogtest2.pem -k blogtest2.key -u [email protected]

我们可以像平常一样使用此 PRT prtauth，browserprtauth以获取令牌或作为受害者浏览网页。

通过TAP获取受害者的NT哈希值

到目前为止，我们没有看到任何意外的情况。毕竟，TAP 是配置无密码凭据的合法方式，例如 Windows Hello 密钥或 FIDO 密钥（我们甚至不需要使用自定义工具来注册 FIDO 密钥，浏览器就足够了）。但如果我们退后一步，查看使用 TAP 后收到的 PRT，我们会看到一些意想不到的情况：

我们的 PRT 附带了一个 Kerberos TGT，用于受害者所在的本地 Active Directory。这是通过 Cloud Kerberos Trust 功能实现的，因此仅当已在 Entra 租户和本地 AD 中配置该功能时，它才有效。但是，它的目的是通过 Windows Hello 实现业务密钥和 FIDO 密钥的本地身份验证，而不一定使用 TAP。这里的问题是，虽然 TAP 根据定义是临时的，但我们在这里收到的 TGT 有效期为 10 小时，这很可能超过了 TAP 本身的有效期。此外，由于 Cloud Kerberos 信任能够恢复旧凭据（即 NT 哈希值），因此只要我们能够看到本地 AD 域控制器，我们就可以获得受害者的 NT 哈希值。即使 TAP 过期或我们在云中的访问权限被撤销后，NT 哈希也可用于请求 TGT。如果用户的原始密码比较弱，我们或许还可以通过hashcat等工具暴力破解NT哈希来恢复明文密码。

回顾一下，假设我们有以下内容：

• 租户中启用的 TAP

• 为我们的受害者提供充分的 TAP 访问权限

• 启用云 Kerberos 信任

• 到本地 AD 的视线

我们可以为任何可以为其配置 TAP 的人获取 NT 哈希值，而无需在他们的帐户上配置持久性，并且所有人员都可以使用单一设备身份来留下尽可能少的痕迹。虽然这个要求列表相当长，但如果您满足所有要求，它可以用作有点嘈杂的哈希转储方法，完全由 Entra 控制。我们可以以此为目标的帐户存在限制，因此像域管理员这样的用户（首先不应该同步到 Entra）不会受到影响。我的Cloud Kerberos Trust 博客中介绍了其具体工作原理的限制和详细信息。

让我们执行攻击的最后一步。我们重复使用第一步获得的 PRT，即在注册 Windows Hello 密钥之前请求使用 TAP 的 PRT。该 PRT 包含部分 TGT，我们可以使用ROADtools Hybrid的partialtofulltgt.py脚本将其交换为完整的 TGT。

python partialtofulltgt.py -f roadtx.prt hybrid.iminyour.cloud/hybrid

如果我们想为更多用户执行此操作，我们只需为他们提供一个 TAP，使用 TAP 请求 TGT，然后恢复 NT 哈希。您可以编写一个脚本来循环执行此操作并恢复尽可能多的哈希值，而无需对帐户进行永久更改或对帐户的真实用户造成影响。

披露、预防和检测

虽然其中的许多部分都遵循设计原则，但通过临时访问通行证获取长期密钥（NT 哈希）的能力对我来说似乎是该协议的一个易受攻击的功能。当我向 MSRC 报告时，微软确实认为这是一个有效的发现，但由于权限要求很高，所以并不是立即关注的问题，而且事实上，处于该位置的管理员还可以通过类似的方式破坏本地帐户密码写回（如果在租户中启用）。

我同意他们的观点，即所需的特权很高，这不是默认配置，并且还有其他选项可以滥用这些角色拥有的特权。但是，我仍然认为临时密码不应立即授予对长期密钥的访问权限。从渗透测试人员的角度来看，我还发现它是一种有趣的攻击，因为它不会对实际用户造成干扰，这在红队或渗透测试参与期间是一个很大的优势。由于此功能不会在不久的将来得到解决，因此攻击者可能会在攻击的横向移动/后利用阶段滥用该功能。

如果您的设置具有这些功能，我的建议如下：

• 避免将 Active Directory 中拥有特权的帐户同步到 Entra ID。

• 确保将临时访问通行证身份验证方法的范围仅限于普通用户，而不是可能从本地同步的管理员帐户（尽管我只是告诉您不要这样做）。

• 监控敏感帐户的临时访问通行证分配情况，尤其是大量情况下。

• 监视大量用户“从”同一设备登录，这是发出 PRT 时生成的事件。

• 要求使用合规或混合连接的设备进行登录，以防止攻击者使用注册的虚假设备来访问应用程序。

与往常一样，ROADtools 可通过GitHub或 PyPI 通过pip install roadtx. ROADtools Hybrid在 GitHub 上作为独立脚本的集合提供。

作者：Dirk-jan Mollema原文翻译自：https://dirkjanm.io/lateral-movement-and-hash-dumping-with-temporary-access-passes-microsoft-entra/