type
status
date
slug
summary
tags
category
icon
password
URL
0x01 背景假设
获取Webshell后，但是机器不出网（DNS、TCP、UDP）等常规端口都进行了尝试。
不出网的解释：内部的Webshell服务器无法连接互联网。
尝试过的方案有：
那么，一般我们会尝试：
- …
这种类型的工具往往都有一个特性：通过脚本帮助我们把HTTP协议转换成Socks，由于HTTP协议无状态，因此需要发送大量数据包。
但是这个场景以上方案都使用起来都不能给出一个很好的效果，因为网络延迟、系统卡顿等等问题，想要传递工具到服务器上变得困难。
0x02 尝试理解目标网络架构
这里我画了一个简单的架构图：
类似这种场景在企业种非常的常见，网络管理员应业务部门的要求，利用NAT端口映射的技术可以直接将DMZ区域的某台机器上的某个端口对外网开放。
这里我使用Docker搭建了一个简单的靶场：
对应的NAT 端口转发情况：
如果攻击者访问172.17.0.2的8080端口，流量将会被转发到192.168.1.128上，那么设想一下，NAT规则在生产的场景中会不会产生规则滥用的情况？
我猜想有以下几种情况：
- 业务下线了，NAT规则没有来得及删除
- 某个规则指向的端口服务暂时停止了
- 网络管理员觉得流程麻烦，遂开放了一段端口，如：8080-8090
0x03 利用NAT规则实现内网漫游
理清楚网络结构后，可以开始寻找有用的NAT规则了，我总结了两个办法：
- 结束正在占用NAT端口的程序
- 寻找未被使用的NAT端口
如何判断目标正在使用这个NAT端口，我的办法是使用Nmap进行扫描。一些NAT规则大多数会采用相同端口映射的关系，比如：8080:8080。
通过信息收集，了解到内网IP端口是192.168.1.128。
映射关系：
这个时候扫描172.17.0.2查看开放状态：
我为了模拟真实环境，还映射了其他端口：8081。
真实场景下，如果是非映射端口，将会是filtered，这种的情况是数据包到达防火墙后就被DROP掉了。
倘若在8081 closed情况下，我们可以直接nc监听起来进行测试：
这个时候，内网的服务器监听了8081端口，成功的利用NAT规则使得我们可以直接正向连接到NC。
如何利用？
我们可以将nc这个程序换成别的，比如：socks5的服务端程序，监听8081端口，如此一来就能够直接连接
socks5:172.17.0.2:8081作为内网的入口。0x04 总结
本文主要在防火墙规则上做了一些思考，并且进行了环境的模拟搭建，与实战环境相同，因此得出以下结论：
- 通过分析NAT规则，能够构建一个稳定代理。
- 测试NAT只能使用端口监听工具，然后在外网进行连接测试。
- Filtered是DROP，ACCEPT是Open，未被使用Closed也是能够ACCEPT。
- 通过这种方案可以提升效率。
- 在非不得已的情况下，最好不要结束占用了NAT端口的进程。