0x00 前言

在一次攻防演练中，通过某RCE漏洞获取到目标系统权限，目标为linux系统 root权限，拿到系统后，就是权限维持、通道搭建，进到内网渗透环节。

​ 在顺利通过wget下载自制linux版CDN的cs马后，并成功上线，一切都是那么顺利，却出现了突发情况，由于linux的cs马暂时还未做socks代理功能，所以又下载了一个frp工具，但奇怪的是frp却始终无法连接到vps，本以为是vps的IP 端口不通，但通过wget测试却是正常连接vps的端口。疑惑之余，测试msf、nc反弹、其他代理工具，发现均无法正常外联，这就很奇怪了，明明wget、cs都能正常出网，难道仅允许http出网，但即使如此，你的TCP连接应该也能出网的，毕竟http基于TCP，不可能拦截TCP的三次握手的，但却无法成功。​

在苦苦无果的时候，查看了一下网络连接，发现连接里居然没有连接 CDN IP的，而马均连向一个内网IP端口，均不是我设置的，看到这其实就明白了，该内网服务器是通过http代理出网的，这就有了后面的分析了。

0x01 代理分析

首先确实下代理设置，确实是做了全局代理，难怪cs马自动走了代理。

那么隧道怎么搭建呢，本来考虑是用http隧道包裹frp出网，但查了frp的手册，frp支持http代理出网呀。

经过本地环境测试，如下配置即可成功经过http代理连接vps。

但在目标系统上测试却还是不行。

简单翻了下frp的源码，发现frp默认会获取系统环境变量http_proxy来自动走代理，所以应该不是设置不设置这个参数的原因导致。

之前也注意到frp执行提示的报错了，提示DialTcpByHttpProxy错误，因为返回的状态码403。也说明frp确实走了代理。

根据报错提示找到判断位置，在第三方代码库中，判断非200则返回错误。

%GOPATH%\pkg\mod\github.com\fatedier\golib@v0.1.1-0.20200901083111-1f870741e185\net\proxy.go

但执行后vps未接收到任何连接，说明是和http代理服务器通信有问题，导致代理服务器直接返回403，而不是vps返回的403。

0x02 数据包分析

接下来怎么分析呢，我在目标系统上使用tcpdump抓包对比分析了下。

tcpdump -i any host 10.1.1.84 -s0 -w /tmp/1.pcap

WGET: 请求到vps成功的包，可以看到代理服务器正常是返回200，根据header也可以确认代理服务器为squid

WGET请求失败，返回403，为啥还有wget失败的，这里是请求的是非80的常用web端口，却失败，上面是请求高端口才成功，怀疑squid是做了策略，比如限制外发的http代理请求端口。

测试下来，80端口可成功，非80常用web端口不成功，而10000以上的端口会成功。

所以我就立即测试了下frp外联vps的80端口，却并没有如想象的连接成功。其实想想也是，之前测试过高端口的wget成功而frp失败，那你80端口也不太可能有啥区别。但渗透嘛，即使知道不行也还是要测测的，就是得不断试错。

CS: 接下来抓了cs的包，因为cs是走的CDN https上线的。也是正常返回200。

FRP: 然后frp的数据包可不能漏，也是返回403

返回错误页面其实如下，访问被拒绝了呗。

其实仔细观察可以发现WGET/CS/FRP的代理请求有些不一样。

如果是HTTP代理，那么客户端发送的请求方法就是常规方法如GET/POST

而如果是HTTPS代理，那么客户端会先发送一个CONNECT请求，让代理与server事先建立好一个连接，代理收到同一客户端的后续请求，只需使用事先建立好的连接即可。

具体区别可参考这篇文章https://www.cnblogs.com/selol/p/5446965.html

所以FRP其实模拟的是HTTPS代理请求，用WGET发送HTTP代理请求测试，结果当然不一样。

在代码里也可以看到FRP伪造代理请求的过程。

既然已经知道了FRP是使用HTTPS代理，那么既然CS能通过HTTPS 443 上线，那么FRP也应该可以通过443代理出网的，经过测试，终于连接成功，可反向代理进目标内网了

经历千辛万苦终于成功了，根据以上测试可推荐squid的策略如下

GET/POST代理请求：使用高端口和默认80端口可请求成功，使用常规非80 http端口均拒绝。

CONNECT代理请求：代表https请求，使用https默认端口（443）可请求成功，使用非https端口则会拒绝。

0x03 总结

搭建通道是内网渗透的一个重要环节，一个通道的隐蔽性、稳定性可提升后渗透阶段的效率。

其实在这次通道搭建过程中使用了很多方法和工具，还包括了端口复用，端口复用因为HTTP代理原因失败。可能有人会说，可以正向HTTP代理呀，因为环境是springboot，没法上传webshell，关于内存马，需要结合实时漏洞做，这个有待下一步研究吧。

在不同场景下会需要不同工具配合，关于http代理场景，之前确实没有注意过，不过在渗透中遇到这些问题也是常事，就是不断试错呗，记录一些试错的过程其实更有意义。

还有其他方案，比如gost+frp。在其他场景中，比如只有ping出网，还能用pingtunnel+frp，代理工具选择有很多，有人也喜欢用ew。我选择frp主要是看重他的稳定性，并且frp的隐蔽性其实蛮好了，可通过ssl tcp 完全加密，又或者使用KCP+SSL。可能有人觉得会有落地配置文件，这个其实很好做，frp本身就支持命令行，稍微改下代码增加一些扩展参数就ok了，这不算啥问题。而文件大小其实还在我的可接受范围内。

总的来说，出网的隧道搭建，越接近正常出网流量越隐蔽，所以能使用http 80、https 443之类的默认端口就尽量用这些，后续还考虑结合CDN做反向代理增加隐蔽性看是否可行。