文章总结： 本文解析CVE-2025-33073NTLM反射漏洞，指出即使启用SMB签名，攻击者仍可利用DNS欺骗进行跨协议中继。作者演示了修改NTLMSSP头部实现SMB到LDAPS中继并接管域控的过程。建议立即安装补丁、限制DNS权限并启用通道绑定以缓解风险。 综合评分： 88 文章分类： 渗透测试,内网渗透,漏洞分析

---

利用 NTLM 反射掌控 Active Directory（CVE-2025-33073）

LOGAN DIOMEDI LOGAN DIOMEDI

securitainment

2026年1月29日 23:50 中国香港

| 原文链接 | 作者 | | — | — | | https://www.depthsecurity.com/blog/using-ntlm-reflection-to-own-active-directory/ | LOGAN DIOMEDI |

概述

和许多其他渗透测试人员与进攻性安全从业者一样，我们已经从 CVE-2025-33073 中获得了大量收益。Microsoft 将该漏洞描述为 “Windows SMB 中的不当访问控制允许已授权的攻击者在网络上提升权限。”此外，SYNACKTIV 的原始博客文章对导致该漏洞的核心问题进行了出色的拆解。

虽然看起来在约 7 个月后大家应该都修复了这个问题，但我们发现事实远非如此。无论是企业域控制器、tier-zero 服务器，还是随机的工作站，我们几乎在每一次客户项目中都持续发现仍受该问题影响的主机。这反过来为我们提供了轻而易举的路径来攻陷他们的环境。

这篇博客的目标，是让攻击者和防守者都意识到这个问题比人们原先认为的要严重得多，而且其利用原语并没有最初设想的那样受限。在处理 NTLM 反射漏洞时，可以从 SMB 中继到多种不同协议，并有大量技术与绕过手段可用。其中一些是反射问题所特有的。

原理

我几乎不可能解释得更好，以下是前述博客中的一段摘录：

“NTLM 本地认证是 NTLM 认证的一种特殊情况，在 NTLM_CHALLENGE 消息中，服务器会告知客户端无需在 NTLM_AUTHENTICATE 消息中计算挑战响应。取而代之的是，服务器在挑战消息中设置“Negotiate Local Call”，创建服务器上下文，将其加入全局上下文列表，并把上下文 ID 放入 Reserved 字段。当客户端收到 NTLM_CHALLENGE 消息时，它会理解必须进行本地 NTLM 认证。然后它会把自己的 token 加入通过 Reserved 字段中 ID 传递的服务器上下文。由于客户端和服务器在同一台机器上，所有事情都发生在同一个 lsass.exe 进程内。最终，客户端会发回一个几乎为空的 NTLM_AUTHENTICATE 消息，服务器使用加入其上下文的 token 来执行进一步操作 (在我们的案例中是通过 SMB)。”

“最后一个问题是：我们为什么在这台机器上有特权？嗯，PetitPotam 强制 lsass.exe 向我们的服务器进行认证，而 lsass.exe 以 SYSTEM 身份运行。当客户端 (lsass.exe) 收到 NTLM_CHALLENGE 消息，指示 必须执行本地 NTLM 认证时，它会把自己的 SYSTEM token 复制到服务器上下文中。当服务器收到 NTLM_AUTHENTICATE 消息时，它从上下文对象中取回该 token 并进行冒充，从而通过 SMB (在我们的案例中，使用 Remote Registry 服务导出 SAM hive 并 攻陷机器) 执行进一步动作。”

攻击者所需的先决条件

所以，你可能会想，我们如何强行欺骗服务器，让它相信自己正在处理本地认证请求，而不是远程认证？很简单 – 我们滥用 LsapCheckMarshalledTargetInfo处理认证的方式。需要满足两个条件。

1. 我们可以在 Active Directory 的 DNS 区域中注册一条 DNS 记录 (在 AD 中默认对所有 “Authenticated Users”开放!)，或者如果我们与目标主机处于同一 broadcast domain，我们就能发布一条类似 “localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA”的 DNS 记录，并让该记录指向攻击者控制的主机。
2. 我们可以通过 PetitPotam、DFSCoerce、Printerbug 等多种强制手段引发机器账户认证。在 Active Directory 中，所有已认证用户无论权限如何都可以满足这一要求。

在绝大多数环境中，这些先决条件并不难满足。许多组织尚未采取措施确保所有“Authenticated Users”无法在其 AD DNS 区域中添加任意 DNS 记录。在这种情况已被修复的环境里，你也可以走 poisoning/MiTM 向量。这在网络非常扁平、广播域很大的环境中特别有效 (例如 /16 – 是的，我们经常见到)。已有现成的 GitHub 仓库 可以直接为攻击者完成这些操作。

CVE-2025-33073 的经典利用

当目标主机未启用 SMB signing 且同样存在 CVE-2025-33073 漏洞时，成功利用的表现会类似 ntlmrelayx.py 中的如下输出：

图 1: 使用 CVE-2025-33073 的 SMB->SMB 成功中继

这使得攻击者能够通过多种技术在受影响的主机上立即实现代码执行。我们中的大多数已经知道，你可以在特权会话上下文中通过 SMB 执行代码，这并不令人意外。事实上，SYNACKTIV 的博客也有类似说法：

图 2: SYNACKTIV 博客结论

到这一步，你可能会笑着说：

“哈！想象一下环境里居然没有全面启用 SMB signing！这是什么，2013 年吗？”

好吧，没毛病。确实有越来越多的客户在其环境中全面启用了 SMB signing。对我们来说，见到整个组织完全没有启用 SMB signing 的情况正变得越来越少。更常见的场景是，某些落单主机没有启用，或者未加入域的主机没有收到 GPO 来强制该策略。这些主机对攻击者和渗透测试人员来说通常意义不大，因为它们上面几乎没有任何特权凭据 (甚至没有域凭据)。

那么事情就这么简单了，对吧？只要在所有地方启用 SMB signing，就可以忽略与 NTLM 反射相关的安全补丁。

错。

2026 年 NTLM 反射漏洞的残酷现实

当 CVE-2025-33073 首次被公开时，我立即对在客户环境中发现该问题产生了兴趣，因为它看起来很可能会在较长时间内持续存在，毕竟企业环境中的补丁节奏通常很慢。事实也的确如此。但我在不少场景里遇到 SMB signing 已启用的情况，而除了把它标记为未安装安全补丁之外，似乎也没什么可做的。

直到 2025 年 9 月，Alex Neff (@al3x_n3ff) 发布了一条 X/Twitter 帖子，其中提到以下内容：

图 3: Alex Neff 的 X 帖子

该讨论还补充了更多信息：

图 4: Alex Neff 的 X 帖子 (续)

这在很多方面都是一个游戏规则改变者。得知我们可以跨协议中继到 ADCS 证书注册服务、MSSQL 数据库以及 WinRMS 非常令人兴奋。一些敏锐的读者可能会做出如下 (通常正确) 的假设：

“这些环境一定还允许发生 Net-NTLMv1 认证！Net-NTLMv1 无法包含 MIC (Message Integrity Code)，这总是允许跨协议中继到其他强制 channel binding 与 signing 的服务！”

有点像，但不完全是。在下面这个 GitHub issue 讨论 中，多位黑客做了大量排查并证明，确实可以从 SMB 向某些其他协议做跨协议中继，有些协议强制 channel binding，有些则不强制，但几乎没有人真正理解为何会成功。它就是能行，原因不明。

图 5: GitHub issue 讨论摘录

这甚至还没有考虑 Kerberos 反射攻击，这又是另一场完全不同的游戏，并且超出了本文范围。许多配置都容易受到 Kerberos 反射攻击，尽管 signing 与 channel binding 仍然至关重要，以确保你有机会防住它。

好吧，到这时你可能又会想：

“那就对所有协议都启用 channel binding ANDsigning，这样我就彻底安全了。”

并不完全 (如果你没有安装安全更新)。

将 NTLM 反射攻击扩展到 LDAP/LDAPS 与 (可能的) RPC 服务

在开发一个新工具时 (我计划在单独的博客中发布，和中继相关，很快就会发出来) – 我读到了意大利安全研究员 Andrea Pierini – “Decoder” (@decoder-it) 的一篇非常精彩的博客。

Reflecting Your Authentication: When Windows Ends Up Talking to Itself

Decoder 进一步解释了 Kerberos 反射问题也可以通过注册一条带有特殊序列化、类似 base64 结构的 Credential Target Information 的 DNS 记录来滥用 CredMarshalTargetInfo 技巧。他们还解释了，如我们已知的那样，针对 SMB 服务的 NTLM 与 Kerberos 反射攻击，会在易受影响的主机上获得 SYSTEM 权限。

图 6: Decoder 的 Kerberos/NTLM 反射示例

他们还提到了一些关于 Windows“NTLM 本地认证”的特殊特性与怪癖：

图 7: NTLM 本地认证的特殊属性

图 8: NTLM 本地认证的特殊属性 (续)

这些信息很有意思。但在阅读过程中，还有一件更有意思的事情引起了我的注意。见下图：

图 9: 解释针对域控制器的 NTLM 反射

哇。这种情况我从未见过。事实上，如果把我此前看到的所有博客、技术文章和 X 线程当作“圣经”，我的默认假设就是“这不可能、不可行”。Decoder 继续写道：

图 10: 通过 CVE-2025-33073 进行 SMB->LDAPS 反射

此时，我把这当作一个挑战，打算在我的自定义 Impacket 分支里实现它。毕竟，这是一条巨大的攻击路径，会让许多环境中的域攻陷变得轻而易举。最初在 01/06/2026 研究这个问题时，Decoder 的“partial MIC removal”代码尚未公开，于是我自己动手实现。

为 NTLM 反射实现“SIGN + SEAL”的 NTLMSSP 头部剥离

尽管 Decoder 的 Impacket 分支当时尚未公开，但他们给了足够的提示。我们知道需要剥离与 SIGN 和 SEAL 属性相关的 NTLMSSP 标志，但必须保留 MIC。是时候抓包了。

首先，我运行 tcpdump 命令来捕获利用 CVE-2025-33073 产生的认证数据包。只要在 TCP 的 445 端口做一个基础过滤就够用了。结果生成了如下数据包：

图 11: NTLM 反射包的 NTLMSSP 属性

啊哈！如高亮所示，有三条标志：

Negotiate Always Sign: Set

Negotiate Seal: Set

Negotiate Sign: Set

这 一定就是 Decoder 所说的内容。因此，我修改了 Impacket 的 ntlmrelayx.py 中的“ldaprelayclient.py”，来剥离这些标志。我先只移除“sign”标志来观察行为，在自己的分支里实现了“–remove-mic-partial”标志，并推送到我的测试设备上。我恰好有一个完美的环境：域控制器对 CVE-2025-33073 脆弱，同时强制了 channel binding+signing，用来测试这个问题。

我的补丁：

图 12: “ldaprelayclient.py”的“partial MIC removal”补丁

在未对 ntlmrelayx.py 打补丁时，行为如下：

图 13: 反射无法对 LDAPS 认证

除非你幸运地收到来自易受影响主机的 Net-NTLMv1 认证，否则这就是预期结果。不过，加上 partial MIC removal 标志之后……

图 14: 成功的 SMB->LDAPS 反射

哇！就这么简单？到这里，我已经拿到了一个低权限计算机账户，于是把该账户加入内置“Administrators”组，随后做了 DCSync，拿下了胜利！非常酷。

这让我开始思考：有没有办法对其他协议也做同样的事？

尝试 SMB -> RPC 中继执行高权限命令 (以及带 signing 的 SMB->SMB!)

为节省读者 (你) 阅读一段又一段技术信息、排错与失败的时间，这是精简版。

我发现实际上可以在 NTLM 反射场景下，通过在强制认证后的 NTLMSSP 响应中剥离类似的认证头，实现 SMB->RPC 的“中继” (这里的“中继”只是宽泛说法)。我的目标是以“NT AUTHORITYSYSTEM”账户通过 RPC 使用 TSCH 创建一个服务，让它执行任意命令 (例如添加一个本地用户并提升为管理员)，然后优雅退出。

当我第一次成功让认证工作起来 (而不是抛出“Not implemented!”) 时，我非常激动：

图 15: 成功的 SMB->RPC 反射认证

然而，之后就没那么有趣了。无论我怎么做，协商了哪种认证级别，剥离、修改或篡改了多少 NTLMSSP 标志，给 ntlmrelayx.py 传入了多少不同参数，我得到的都只有：

图 16: DCERPC – rpc_s_access_denied

这真的很沮丧。我非常想让它成功，但最终发现，无论如何都无法绕过一个现实：RPC 要求你用 NTLM session key 对后续会话数据包进行加密。这与 SMB signing 的工作方式类似 (实际上完全一样)。事实上，即使启用了 SMB signing，我也能在 SMB 上看到相同的行为：

图 17: “成功的”(并非) SMB->SMB 带 signing 中继

但是，任何通过 SOCKS 中继尝试执行操作都会得到 STATUS_ACCESS_DENIED，因为我们没有用协商凭据来满足会话签名要求。对于了解 SMB signing 工作原理的人来说，这很明显，但我还是想看看 NTLM 反射是否会对其产生影响。

我花了很多时间尝试是否能强制设置 “Negotiate LAN Manager Key”、“Request Non-NT Session Key”、“Negotiate 56”等多个标志，以启用基于 DES 的 session key，从而可能使用彩虹表或暴力破解，然后以 SYSTEM 账户对这些服务进行认证。我也对 NTLMSSP 握手中的目标主机名属性做了各种篡改 (localhost、计算机真实主机名、FQDN、null)，同样毫无效果，以及各种组合尝试。

在我的测试中，这并没有带来任何有价值的结果。我确实认为在 Net-NTLMv1 认证场景下或许有可能，但那是另一套研究了。

结论与注意事项

首先，我想感谢之前所有研究人员，他们完成了绝大部分的基础工作。有趣的是，当我快要完成这篇博客时，我去看了 @decoder-it 的 GitHub 页面，看到这个：

图 18: Decoder 现已公开的“partial-remove-mic”Impacket 分支

我当场就“捂脸”，然后笑了出来，因为我花了几个小时抓包、修改 ntlmrelayx.py 并进行测试，结果发现我需要的代码马上就要被发布了。为了有趣起见，来看看 Decoder 的实现：

图 19: Decoder 的 partial MIC removal 源码

这是我的实现，再次作为参考 (未移除 NTLMSSP_NEGOTIATE_SEAL 版本)：

图 20: 自研的“partial MIC removal”补丁

我们的实现最终几乎一模一样，且都能工作。这个提交 是成功对 LDAPS 实现 partial MIC removal 行为的最小改动代码。

总体而言，我很高兴经历了这次过程，更深入地理解了 NTLMSSP 的工作方式。它并没有特别复杂，我认为还存在进一步的缺陷与反射原语。事实上，我知道有，因为 decoder-it 再次暗示：

图 21: 即将出现的更多 NTLM 反射问题

真正的要点是什么？为系统打补丁，在所有协议上启用 channel binding 与 signing，务必把它列为重要优先事项。NTLM 反射漏洞可以启用跨协议的漏洞利用，有时甚至绕过 signing 与 channel binding 之类的控制。CVE-2025-33073 不是仅在未启用 SMB signing 的主机上才成立的 SYSTEM 代码执行漏洞 – 它是一个高影响、易于利用、在某些情况下 没有任何缓解措施的漏洞。

建议

建议？如果你想防住这种特定的中继滥用，请安装 2025 年 6 月的 Windows 安全更新。当然，还要在所有协议上启用 signing 与 channel binding。快速修补那些会导致 NTLM 反射问题的漏洞利用。重新配置你的 AD DNS domain ACLs，防止所有低权限 AD 用户创建新的 DNS 记录。这条建议一直都适用，但对于这类 NTLM 反射漏洞尤为重要。

---

Using NTLM Reflection to Own Active Directory (CVE-2025-33073)

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment LOGAN DIOMEDI LOGAN DIOMEDI《利用 NTLM 反射掌控 Active Directory（CVE-2025-33073）》