Responder 利用

总结与思考：

1. 利用Responder进行NTLMV2哈希的窃取

2. 使用Responder进行中继，攻击成功后进行代码执行

3. 使用Responder进行凭证/哈希破解

4. 使用Responder进行快速SMB扫描

5. 使用Responder配合MSF反弹shell

6. LLMNR/NBT-NS攻击的防御

概述：

Responder是对渗透测试工作者来说一个很棒的工具，如果客户端/目标无法通过DNS域名解析，则会回退到LLMNR（在Windows Vista中引入）和NBT-NS进行解析。如果我们的Responder在运行着，那么我们将对所有我们能看到的LLMNR和NBT-NS请求响应“yeah, 就是我”，然后所有的传输都将被引导到我们这。在这个简短的概述中，我们将涉及几个常见的用法以及最近由@pythonresponder引入的新功能。

本文<渗透师指南之Responder>属于【脉搏译文系列】文章之一，由安全脉搏编辑w2n1ck 翻译，原文：Pwning with Responder – A Pentester’s Guide 转载请注明来源"安全脉搏”。

针对特定主机：

如果你想针对特定的IP/IP范围，可以通过修改Responder.conf并更改RespondTo参数。当你只是想针对特定的目标时，这是非常有用的，因为你不希望导致整个网络的中断。

此外，还可以通过改变RespondToName参数来指定NBT-NS / LLMNR名称，大家有兴趣可以尝试下。下面的截图中，我们就是针对主机192.168.10.17进行的特定攻击。

在以下屏幕截图中，我们限制只对主机192.168.10.17的攻击。

监听模式：

你可以在监听模式下使用Responder，即分析，但不主动响应任何请求。这可以通过使用-A参数来实现，并且这是一个非常有用的功能，可以查看网络是如何在没有主动定位任何主机的情况下进行的。

主动攻击：

在下面的示例中，攻击者IP地址是192.168.10.206，我们通过SMB针对单个主机192.168.10.17。这是用户输入错误服务器名称的常见情况，由于DNS查找失败，名称解析又回退到NBT-NS和LLMNR。

从上面的Wireshark输出中可以看到192.168.10.17发送一个NBNS查询到广播地址192.168.255.255，而攻击主机192.168.10.206立即回复说它实际上是file-share-123并且返回它自己的IP在回应之内。

在Wireshark捕获中也可以看到，在NBNS请求/响应之后，立即通过LLMNR进行相同的处理，但是使用注册的多播地址224.0.0.252 。敏锐的读者也看到，这个过程也是通过IPv6进行的，使用了FF02 :: 1：3的组播地址（详情也可以从上面的链接中获得）。

这样做的结果是，受害者现在认为我们确实是file-share-123，并试图建立SMB连接（TCP 445）。从这里我们可以继续为受影响的用户（在本例中是一个名为default的本地用户）窃取NTLMv2哈希以进行脱机破解《几种windows本地hash值获取和破解详解》。

这是通过Wireshark查看的SMB通信协商过程

在Responder中还有很多可以尝试的好玩的地方，现在我们将会看下这个项目中增加的一些更新的功能。

Multi-relay攻击：

这是@pythonresponder 在2016年年底推出的新功能之一。使用这个功能，我们可以将我们的NTLMv1/2身份验证中继到特定的目标，然后在攻击成功的时候执行代码。在深入研究这种攻击之前，应该说明下默认攻击目标是特权用户，并且目标不能有SMB签名。一个很好的脚本RunFinger.py已经被封装在Responder的工具目录中，这使得我们可以在主动定位任何主机之前在目标上验证后者。

在准备这个攻击时，我们需要禁用Responder使用的SMB和HTTP服务器，否则我们会在这个和Multi-relay之间产生一些冲突（如下所示）。

对于下面的例子，我们将通过将相关服务更改为“Off”来禁用Responder.conf文件中的这些特定服务来完成任务。

再一次用默认选项运行Responder，可以看到这两个服务现在被禁用了。

我们现在要为受害者192.168.10.17（如前面的例子）作出毒害响应，但是我们现在也要将我们的会话认证转接到第二主机192.168.11.17。

此工具的语法如下所示，其中IP是要中继身份验证的地址，并希望获得shell访问权限：

python MultiRelay.py -t 192.168.11.17 -u ALL

在下面的示例中，主机是Windows 10的默认安装，当前被认证为192.168.10.17的受害用户是名为default的本地管理员用户。

在下面的输出中，可以看到这个用户被列入白名单（我们将-u ALL指定为参数），同时拒绝访问中继主机192.168.11.17。 Multi-relay在这里帮了我们一个忙，同时不会继续尝试向可能被锁定帐户的主机进行认证。 192.168.10.17和192.168.11.17都配置相同的帐户/凭证。

在Wireshark中查看它显示了以下内容

因此，我们有一个管理员用户（在主机上实际上拥有有效凭据），但它不是RID为500的默认管理员帐户。我们再次运行该攻击，但是这次我们将使用 RID 500的本地管理员帐户。

成功！所以我们已经成功地转发了来自受害者192.168.10.17的默认RID 500的身份验证，并获得了192.168.11.17上的shell访问权限，因为两个主机都使用相同的本地管理员帐户凭证。还应该提到，这两个都是域成员，而不是独立的基于工作组的系统。

下面的Wireshark输出只显示了初始中继通信中涉及的smb流量，我们可以清楚地看到中继路由 192.168.10.17（毒害受害者）> 192.168.10.206（攻击者）> 192.168.11.17（中继目标）

Multi-relay功能：

这就是Multi-relay功能中自己特色的地方。今年3月底，@pythonresponder和@gentilkiwi一起添加了Mimikatz集成（其他一些有趣的工具），使得获得凭证/哈希变得轻而易举。

我们来试验下这些; 我们目前在192.168.11.17上有一个Multi-relay shell，我们可以通过使用mimi命令轻松地调用标准的Mimikatz函数（如果我们的目标是一个32位的主机，我们可以使用mimi32）。

其他有用的功能包括超快速SMB扫描，可用于查找网络中的其他潜在目标。下面的屏幕截图显示了一个例子，它提供了一个/ 16范围（我们的示例网络是一个192.168.0.0/16）。

让我们玩Multi-relay的最后一个功能，并使用此工具来产生每个读者最喜欢的shell——Meterpreter。首先我们需要在msf中配置一个合适的监听器，在这个例子中，我们将使用exploit/multi/script/web_delivery。这个实验没有关于这个漏洞的具体细节，我们的攻击系统为192.168.10.206 ，已经设置了一些基本的选项，PowerShell已经配置了攻击目标。

回到Multi-relay shell，我们现在可以运行我们最喜欢的IEX命令，并希望反弹更多的shell。请注意，我们并不期待任何输出，因此在这种特定情况下通常可以忽略“something went wrong…”输出。

回到msf的web_delivery漏洞，我们看到一些动作，一旦shell已经登陆，我们可以根据需要在msf框架内部使用内置的Meterpreter 模块和功能。

预防和修复：

为了加强Windows系统的安全性，可以进行以下调整。

通过组策略禁用LLMNR

打开gpedit.msc 到计算机配置>管理>网络> DNS客户端>关闭多播域名解析并设置为已启用

禁用NBT-NS

这可以到网卡>属性> IPv4>高级> WINS，然后在“NetBIOS设置”下选择禁用TCP/IP上的NetBIOS

或者，这个任务可以通过到下面的键修改注册表，并将值更改为2 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\{$ InterfaceID}\NetbiosOptions

通过组策略启用SMB签名

SMB签名的更多细节以及可以定义的各种值可以在以下链接中找到。

http://techgenix.com/secure-smb-connections/

https://technet.microsoft.com/en-us/library/jj852239(v=ws.11).aspx