3つのVMはすべてVirtualBox上で動作し、NATネットワークで192.168.0.0/24に接続されている。

Suricataが攻撃者ボックス上で動作する理由

Suricata は攻撃者とターゲット間のトラフィックを可視化する必要がある。プロミスキャス/ミラーポートを持つ専用のセンサーVM を用意するか、トラフィックパス上にある2台のホストのいずれかにセンサーを配置するかの2つの選択肢がある。Wazuh マネージャー（Amazon Linux 2023）は EPEL をサポートしておらず、Suricata のインストールが現実的ではなかった。また、ターゲットはエージェントを全く実行できないため、Suricata は Kali ボックス上で直接実行される。これにより、プロミスキャスモードやスパンポートを必要とせず、自身のインターフェイスで攻撃トラフィックの100%を確認でき、すでに Kali に登録されている Wazuh エージェントを介してイベントをマネージャーに送信する。

検知

1. 偵察 — Nmap スキャン検知

攻撃:

検知: Suricata の Emerging Threats ルールセットは、スキャンが各オープンポートに触れるたびに、Metasploitable の露出した UnrealIRCd サービス（ET CHAT IRC USER command）へのトラフィックを含む、複数のスキャン関連およびプロトコル異常シグネチャをリアルタイムでフラグ付けした。

結果: スキャン完了から数秒以内に、Wazuh の脅威ハンティングビューで ids, suricata ルールグループの下に 132 以上の IDS イベントが生成され、適切に分類された。

2. エクスプロイト — vsftpd 2.3.4 バックドア (CVE-2011-2523)

攻撃:

Metasploitable の vsftpd 2.3.4 には、不正な FTP ログイン文字列によってトリガーされるバックドアが含まれており、TCP ポート 6200 で root シェルを起動する。エクスプロイトは正常に実行され、root として Meterpreter セッションが返された。

検知: Suricata の GPL ATTACK_RESPONSE id check returned root シグネチャ（SID 2100498）が、シェルが起動してから11秒後に発火した。これは、シェルのコマンド出力内の平文 uid=0(root) 文字列がポート6200を介してネットワーク上を通過する際に一致したもの。

なぜこれが重要なのか: これは、ホストベースのログがまったくない資産に対するルート権限奪取の成功をネットワーク層で確認したものであり、このアーキテクチャが処理するために設計されたまさにそのシナリオである。

3. 認証攻撃 — FTP ブルートフォース (MITRE ATT&CK T1110)

攻撃:

Hydra は複数の FTP ログインを迅速に試行し、数回の失敗後、有効な認証情報ペア msfadmin:msfadmin を正しく特定した。

検知状況: Suricata の FTP プロトコルパーサーは、個々の USER/PASS コマンドとサーバー応答コードをすべて eve.json（event_type: ftp）にキャプチャし、マネージャーの生イベントアーカイブに存在することが確認された:

Suricata のデフォルトルールセットには FTP ブルートフォース専用のシグネチャはない。これは既知の悪意のある文字列ではなくプロトコルパターンであるためだ。このギャップを埋めるために、カスタムの Wazuh 相関ルールが設計された:

状況: 進行中 — 基盤となるイベントデータがマネージャーに到達していること、ルール構文が wazuh-logtest で検証されていることは確認済みだが、相関ルール（100101）はまだエンドツーエンドで確実に発火していない。次のデバッグ手順は、実際のサンプルに対して wazuh-logtest を使用して、パース時にネストされた Suricata FTP フィールドに割り当てられるデコーダフィールドパスを確認すること。以下、将来の作業として追跡中。

学んだ教訓

• レガシーターゲットはコマンドだけでなく、アーキテクチャそのものを変える。 Metasploitable 2 の古いツールチェーンでは、最新の Wazuh エージェントや基本的な syslog 転送（rsyslog なし、インターネットアクセスなし）さえ不可能だった。ホストベースのアプローチを強制するのではなく、プロジェクトはネットワークベースの検知に方向転換した。これは、現実世界のレガシー/IoT 資産にとって、おそらくより現実的なパターンである。
• パッケージエコシステムは交換可能ではない。 Wazuh マネージャーのベースである Amazon Linux 2023 は従来の EPEL をサポートしておらず、そこに Suricata を直接インストールすることが妨げられた。すでにトラフィックパス上にある Debian ベースの Kali ボックスにセンサーを移動することで、問題を完全に回避できた。
• デフォルトの IDS ルールセットはシグネチャベースであり、行動ベースではない。 Suricata は、既知のシグネチャが存在したため vsftpd のエクスプロイトを即座に検知したが、FTP ブルートフォースに対しては何も検知しなかった。これはパターンであり、静的な文字列ではないからだ。これこそが、標準の IDS コンテンツだけに頼るのではなく、SIEM でカスタム相関ルールを作成する正当な理由である。
• archives.log/archives.json はデフォルトでは有効になっていない（logall/logall_json は初期設定で no）。そして、これらは SIEM が実際に何を受信し、何をアラートとして選択したかをデバッグするために不可欠である。

将来の作業

• FTP ブルートフォース相関ルール（100100/100101）のエンドツーエンドデバッグを完了する
• Suricata がすでにターゲット上の IRC トラフィックをフラグ付けしているため、4つ目の検知として UnrealIRCd バックドアエクスプロイト（CVE-2010-2075）を追加する
• 5つ目の手法として Samba usermap_script RCE（CVE-2007-2447）を追加する
• 高重要度アラートを TheHive または Shuffle に配線し、自動ケース作成を実現する
• アクティブレスポンスを追加し、ブルートフォース検知が繰り返された場合に攻撃者 IP を自動的にブロックする

使用ツール

• Wazuh 4.14.6 — SIEM（マネージャー、インデクサー、ダッシュボード）
• Suricata 8.0.5 — ネットワーク IDS
• Metasploit Framework / Hydra / Nmap — 攻撃シミュレーション
• VirtualBox — ラボ仮想化

MITRE ATT&CK マッピング