0x01 背景假设

获取Webshell后,但是机器不出网(DNS、TCP、UDP)等常规端口都进行了尝试。

不出网的解释:内部的Webshell服务器无法连接互联网。

尝试过的方案有:

那么,一般我们会尝试:

这种类型的工具往往都有一个特性:通过脚本帮助我们把HTTP协议转换成Socks,由于HTTP协议无状态,因此需要发送大量数据包。

但是这个场景以上方案都使用起来都不能给出一个很好的效果,因为网络延迟、系统卡顿等等问题,想要传递工具到服务器上变得困难。

0x02 尝试理解目标网络架构

这里我画了一个简单的架构图:

类似这种场景在企业种非常的常见,网络管理员应业务部门的要求,利用NAT端口映射的技术可以直接将DMZ区域的某台机器上的某个端口对外网开放。

这里我使用Docker搭建了一个简单的靶场:

对应的NAT 端口转发情况:

iptables -t nat -A PREROUTING -p tcp -d 172.17.0.2 --dport 8080 -j DNAT --to-destination 192.168.1.128:8080
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.128 --dport 8080 -j SNAT --to-source 192.168.1.129
iptables -t nat -A PREROUTING -p tcp -d 172.17.0.2 --dport 8080 -j DNAT --to-destination 192.168.1.125:8080
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.125 --dport 8080 -j SNAT --to-source 192.168.1.129
iptables -t nat -A PREROUTING -p tcp -d 172.17.0.2 --dport 8081 -j DNAT --to-destination 192.168.1.128:8081
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.128 --dport 8081 -j SNAT --to-source 192.168.1.129
iptables-save

如果攻击者访问172.17.0.2的8080端口,流量将会被转发到192.168.1.128上,那么设想一下,NAT规则在生产的场景中会不会产生规则滥用的情况?

我猜想有以下几种情况:

  1. 业务下线了,NAT规则没有来得及删除
  2. 某个规则指向的端口服务暂时停止了
  3. 网络管理员觉得流程麻烦,遂开放了一段端口,如:8080-8090

0x03 利用NAT规则实现内网漫游

理清楚网络结构后,可以开始寻找有用的NAT规则了,我总结了两个办法:

  1. 结束正在占用NAT端口的程序
  2. 寻找未被使用的NAT端口

如何判断目标正在使用这个NAT端口,我的办法是使用Nmap进行扫描。一些NAT规则大多数会采用相同端口映射的关系,比如:8080:8080。

2020-11-01-22-31-26

2020-11-01-22-32-56

通过信息收集,了解到内网IP端口是192.168.1.128。

映射关系:

这个时候扫描172.17.0.2查看开放状态:

2020-11-01-22-36-44

我为了模拟真实环境,还映射了其他端口:8081。

2020-11-01-22-38-21

真实场景下,如果是非映射端口,将会是filtered,这种的情况是数据包到达防火墙后就被DROP掉了。

2020-11-01-22-42-16

iptables -t nat -A PREROUTING -p tcp -d 172.17.0.2 --dport 8080 -j DNAT --to-destination 192.168.1.128:8080
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.128 --dport 8080 -j SNAT --to-source 192.168.1.129

iptables -t nat -A PREROUTING -p tcp -d 172.17.0.2 --dport 8080 -j DNAT --to-destination 192.168.1.125:8080
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.125 --dport 8080 -j SNAT --to-source 192.168.1.129

iptables -t nat -A PREROUTING -p tcp -d 172.17.0.2 --dport 8081 -j DNAT --to-destination 192.168.1.128:8081
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.128 --dport 8081 -j SNAT --to-source 192.168.1.129
iptables -P INPUT DROP
iptables-save

2020-11-01-23-10-02

倘若在8081 closed情况下,我们可以直接nc监听起来进行测试:

2020-11-01-23-12-54

这个时候,内网的服务器监听了8081端口,成功的利用NAT规则使得我们可以直接正向连接到NC。

2020-11-01-23-14-06

如何利用?

我们可以将nc这个程序换成别的,比如:socks5的服务端程序,监听8081端口,如此一来就能够直接连接 socks5:172.17.0.2:8081作为内网的入口。

0x04 总结

本文主要在防火墙规则上做了一些思考,并且进行了环境的模拟搭建,与实战环境相同,因此得出以下结论:

  1. 通过分析NAT规则,能够构建一个稳定代理。
  2. 测试NAT只能使用端口监听工具,然后在外网进行连接测试。
  3. Filtered是DROP,ACCEPT是Open,未被使用Closed也是能够ACCEPT。
  4. 通过这种方案可以提升效率。
  5. 在非不得已的情况下,最好不要结束占用了NAT端口的进程。