MCPを活用した自律型ペネトレーションテストツール「PentestMCP」

はじめに

セキュリティ運用の現場において、AIエージェントの研究が急速に進展しています。脆弱性の発見、攻撃の実行、侵入後の活動といったタスクの自動化において、従来のアプローチは、エージェントと利用ツールが密結合した「モノリシック」なアーキテクチャで実装される傾向にありました。

しかし、Anthropic社が提唱した「Model Context Protocol (MCP)」の登場により、その状況は一変しつつあります。

MCPは、AIモデルと外部ツールやデータを接続するための標準規格であり、エージェントからツールを分離し、RPC(Remote Procedure Call)に似た接続モデルを提供します。これにより、エージェントは実行時にツール定義を動的に読み込み、柔軟に機能を拡張することが可能となります。

本稿では、このMCPアーキテクチャを採用し、ペネトレーションテストの自動化を目的として開発されたツール「PentestMCP」に関する論文「PentestMCP: A Toolkit for Agentic Penetration Testing」を紹介します。

ポートランド州立大学のZachary Ezetta氏とWu-chang Feng氏による本研究は、既存のセキュリティツールをMCPサーバとして実装し、AIエージェントによる一連の攻撃シナリオの自動実行を検証したものです。本論文は2025年10月に投稿されたものですが、実験に使用されたモデルは投稿時点の最新版ではありません。主に2024年にリリースされたモデルが使用されています。

LLMの能力は急速に進化しており、現在利用可能な最新バージョンでは、論文で報告された失敗例が改善されている可能性があります。本論文の結果は実験時点でのスナップショットとして理解し、実際の導入検討時には最新モデルでの再評価を推奨します。

PentestMCPの概要とアーキテクチャ

構成

PentestMCPは、ペネトレーションテストで標準的に使用されるツール群を、MCPサーバとしてラップしたツールです。AIエージェントはMCPを通じてこれらのツールを呼び出し、偵察から攻撃、さらには侵入後の活動(Post-Exploitation)までを遂行します。論文内で実装・検証されたMCPサーバと対応ツールは以下の通りです。

動作の仕組み

従来の実装とは異なり、PentestMCPを用いたエージェントには、ツールごとの詳細な使用方法はハードコードされていません。代わりに、MCPサーバ側が各ツールの機能、入力パラメータ、出力形式を定義し、エージェントに対して提示します。

エージェントはこの定義に基づき、目的(例：「サーバのパスワードファイルを取得せよ」)を達成するための計画を立案し、ツールを適切に呼び出します。 ツールの実行結果はエージェントにフィードバックされ、次のアクションを決定する判断材料となります。

この仕組みにより、新しいツールや攻撃手法が登場しても、MCPサーバ側を追加・更新するだけで対応可能となり、エージェント本体のコード修正は不要になります。

実験と検証：自動化されたサイバーキルチェーン

論文では、実際の脆弱性が存在する環境を用意し、PentestMCPを搭載したエージェントが自律的に攻略可能かを検証しています。ここでは、2つのケーススタディを紹介します。

ケース1：Apache Strutsの脆弱性 (CVE-2017-5638)

2017年のEquifax情報漏洩事故の原因としても知られる、Apache Strutsの脆弱性を対象とした実験です。実験環境は、攻撃対象のサーバと、攻撃側のKali Linux VMで構成されました。エージェントには「ターゲットのセキュリティ上の問題を見つけ、悪用してパスワードファイルを抽出せよ」という指示が与えられています。

エージェントの実行プロセスは、まず偵察フェーズから始まります。nmap_scan を実行し、80番ポートでApache Tomcat/Struts2が稼働していることを特定しました。

続いて nuclei_scan を実行し、CVE-2017-5638を含む複数の脆弱性を検出しました。その後、metasploit_search で該当CVEのexploit(攻撃コード)モジュールを検索し、metasploit_info でモジュール詳細を確認し、metasploit_module_payloads で利用可能なペイロードをリストアップしました。

攻撃実行段階では、cmd/unix/reverse_bash ペイロードを選択し、必要なオプション(RHOSTS, LHOST等)を設定して metasploit_exploit を実行しました。リバースシェル(攻撃者側に接続を返すシェル)の獲得に成功しました。

最終的に、metasploit_sessions でセッションIDを確認し、metasploit_session_interact を用いて cat /etc/passwd などのコマンドを実行し、ファイルの奪取に成功しています。このプロセスにおいて、一部のエージェントは、状況に応じてMetasploitを使わず、curl コマンドを直接生成して攻撃を行う柔軟な挙動も見せました。

ケース2：EternalBlue (CVE-2017-0144)

WannaCryランサムウェアで使用されたWindows SMBの脆弱性(EternalBlue)を対象とした実験です。エージェントは最初に nmap で445番ポート(SMB)のオープンを確認し、スクリプトスキャンで脆弱性を特定しました。

その後、Metasploitで ms17_010_eternalblue モジュールを選択しましたが、エージェントは当初、必須パラメータ(module_options)を含めずに攻撃を実行しエラーとなりました。しかし、ここでエージェントの自律的なリカバリ能力が発揮されます。

エージェントはエラーメッセージを受け取った後、再度 metasploit_info を参照してパラメータ要件を確認し、正しいパラメータで再実行することで、Meterpreterシェル(Metasploitに内蔵されている高機能なシェル)の獲得に成功しました。その後、システム情報の取得やパスワードハッシュのダンプ(hashdump)を実行し、侵入テストを完遂しています。

LLMモデル間の性能比較

論文では、複数のLLMモデルを用いて同一タスクを実行した際の結果も比較検討されています。

CVE-2017-5638(Apache Struts)のケースでは、GPT-4o (gpt-4o-2024-08-06)は脆弱性を特定したものの、攻撃の準備段階でx64のVMに対して誤ったアーキテクチャ(aarch64)のペイロードを選択してしまい、失敗に終わりました。Grok 4(grok-4-0709)は脆弱性を特定しましたが、適切なexploitモジュールの発見に至りませんでした。

一方、OpenAIのo3(o3-2025-04-16)、Gemini 2.5 Flash(gemini-2.5-flash-preview-05-20)は脆弱性特定から攻撃まで成功しました。CVE-2017-0144(EternalBlue)のケースでは、GPT-4o(gpt-4o-2024-08-06)は脆弱性の特定に失敗しました。Grok 4(grok-4-0709)は脆弱性を特定しましたが、適切なexploitモジュールの発見に至りませんでした。

ここでも、OpenAIのo3(o3-2025-04-16)、Gemini 2.5 Flash(gemini-2.5-flash-preview-05-20)は脆弱性特定から攻撃まで成功しました。この結果は、エージェントの能力が基盤となるモデルの推論能力やツール利用能力に深く依存することを示唆しています。

また、モデルによってツールの選択傾向や、エラー時のリカバリ挙動が異なることも明らかになりました。複雑なパラメータ設定やコンテキスト判断が必要な場面では、モデルによる差が顕著に現れる傾向があります。

まとめ

本稿で紹介したPentestMCPは、自身が管理している、または攻撃を許可された環境でのみ使用することを前提としています。無許可での攻撃行為は違法行為であり、日本国内では、不正アクセス禁止法により処罰されます。

PentestMCPは、MCPという標準プロトコルを用いることで、各ペネトレーションテストツールをAIエージェントから「疎結合」に利用可能にするアプローチの有効性を検証しました。モジュール化により新しいツールへの対応が容易になり、自律的なエラーリカバリ能力により人間の介入を最小限に抑えることが可能になりました。

ただし、成功率は使用するLLMの性能に左右され、複雑なパラメータ設定やコンテキスト判断が必要な場面では、モデルによる差が顕著に現れることも明らかになりました。

本研究は、定型的な脆弱性診断タスクの自動化におけるAIエージェントの有用性を示す一方で、実運用においては適切なモデルの選定と、エージェントが誤った操作を行わないための制御・監視が重要であることを示唆しています。AIエージェントによる自動化は効率性を高める一方で、意図しない破壊的操作の実行、過度な負荷によるシステム障害、誤検知による不適切な対応といったリスクも伴います。

実運用においては、必ず人間による監視と制御を設け、段階的な権限付与と承認プロセスを組み込むことが重要です。また、エージェントの動作ログを詳細に記録し、事後検証可能な体制を整えることも不可欠です。特に本番環境や顧客環境でのテストを行う場合は、事前の十分な検証と、緊急時の停止手順の確立が必須となります。

AIエージェントの普及により、ペネトレーションテスト/脆弱性診断の実務に大きな変化が訪れることが予想されます。まず、ペンテスターの役割が変化していくでしょう。

定型的な脆弱性診断作業から解放され、より高度な攻撃シナリオの設計やAIエージェントの監督、結果の検証が主要業務になっていく可能性があります。ユーザー企業内部のセキュリティチームにおいても、継続的な自動診断による脆弱性の早期発見が可能になり、脆弱性診断の頻度の向上とコストの削減が期待できます。