Attackers Combine MCP Recon With Cloud Metadata SSRF to Steal Service Account Tokens
2026/07/13 gbhackers — インターネット全体を対象とする偵察活動は、従来のアプリケーションに対する範囲を超え、Model Context Protocol (MCP) サービス／AI アシスタントのコンフィグ・ファイル／ローカルで公開された LLM エンドポイントにまで拡大している。小規模かつ低トラフィックの共有ホストから収集した、Apache／ModSecurity の 14 日間のログを分析したところ、通常の WordPress／.env／Git／Spring Boot Actuator に対するプロービングに加え、AI エージェントの偵察に関連する約 200 件のリクエストが確認された。
この活動は偶発的なスキャンではなく、攻撃者は “/mcp” に対して有効な JSON-RPC MCP 初期化リクエストを送信し、Claude／Cursor／VS Code のコンフィグ・ファイルを探索しながら、OpenAI 互換 API／Ollama API エンドポイントをプロービングしていた。
また、この AI に焦点を当てた探索トラフィックには、Google Cloud のメタデータ・サービスを標的とするサーバサイド・リクエスト・フォージェリ (SSRF) 試行も含まれていた。つまり、インターネットに公開されたエージェントツールから、サービス・アカウント・トークンの窃取へ至る、潜在的な経路が生じている。
最も注目すべきリクエストは、JSON-RPC 2.0 とプロトコル・バージョン 2025-03-26 を悪用する POST /mcp リクエストであり、正しく構造化された MCP の initialize 呼び出しを含むものだ。
MCP は、ツールの探索や対話が始まる前に、クライアントとサーバがプロトコル機能をネゴシエートするための初期化ライフサイクルを採用している。レスポンスに成功すると、対象となるホストが MCP サーバを実行していることが判明するという、単純なパスの存在確認とは本質的に異なるものである。
その結果として、AI クライアントが利用できるツール／リソース／プロンプト／バックエンド・サービスの列挙が、攻撃者に許される可能性がある。
LLM アプリケーションを外部のツールやデータソースに接続するために、MCP は設計されている。したがって、インターネットへ公開されたサーバは、データベース／ファイルシステム／内部 API／チケット管理プラットフォーム／クラウドサービスへのマシンリーダブルな入口となり得る。また、観測された /mcp に対する探索は 49 件の異なる送信元 IP から実施されており、孤立した調査ではなく、広範囲に分散した偵察活動であることを示唆している。
MCP サービスを意図的に公開していない環境においては、未承諾の MCP 初期化トラフィックを信頼度の高い探索シグナルとして、防御側は扱うべきである。このキャンペーンでは、AI アシスタント関連のアーティファクトとして、以下の認証情報パスなども要求されていた。
- .claude/mcp.json
- .cursor/mcp.json
- .cursor/mcp_config.json
- .vscode/mcp.json
- .mcp/config.json
これらのリクエストが示すのは、現時点における攻撃者たちが、開発者用 AI コンフィグにおける接続情報や API キーを、潜在的な認証情報の入手元として扱っていることである。認証情報ファイル名に対して、HEAD リクエストを使用している点が特徴的である。これにより、スキャナは機密オブジェクトの内容を取得することなく、それらの存在のみを確認できるため、大規模な標的化における帯域幅の節約が可能になる。
ISC の研究者たちが指摘するのは、従来のクラウド認証情報ファイル名／Kubernetes シークレット／アプリケーション・コンフィグファイルと並ぶかたちで、AI 固有のファイルパスが確認されたことである。標準的なシークレット収集ワードリストの一部として、AI ツールが挙げられていることを示す証拠であると、彼らは述べている。
ユーザー組織に対して推奨されるのは、.claude／.cursor／.vscode／.mcp ホームディレクトリ内のコンフィグ・ファイル・パスが、本番環境のアーティファクトへコピーされないように徹底することである。また、Web アクセス可能なドキュメント・ルート配下へ、マッピングされないようにすることも重要である。
Web サーバの設定においては、デプロイメント管理だけに頼るのではなく、隠しコンフィグ・ディレクトリや機密性の高い JSON ファイルへのアクセスを明示的に拒否すべきである。
MCP 偵察からクラウド・メタデータ SSRF へ
攻撃者たちは、OpenAI 互換モデルの一覧を取得する “/v1/models” や、Ollama のインストール済みモデルの列挙で使用される “/api/tags” に対しても、リクエストを繰り返して送信している。したがって、認証されていないレスポンスから、推論インフラの悪用／モデル探索／後続の攻撃／エクスプロイトにつながる可能性がある。
さらに懸念されるのは、url／uri／path／dest などのパラメータを介して、”metadata.google.internal” を標的とする SSRF ペイロードである。攻撃者たちが探索していたのは、汎用的な “credentials.json” に続く GCP／AWS／Azure 固有のファイル名や、Kubernetes およびアプリケーションに固有の名称である。
Google Compute Engine のワークロードは、メタデータ・サーバから関連付けられるサービス・アカウントの OAuth アクセス・トークンを取得するが、このリクエストには Metadata-Flavor: Google ヘッダーが必要となる。そのため、脅威アクターたちは、メタデータ・サービスに到達するフェッチ／プロキシ／Webhook／画像インポート／エージェント・ツールなどを、認証情報を外部へ流出させる手段として悪用する。
MCP 環境では、URL 取得ツールが一般的に用いられるため、この種のリスクがさらに増大する。制限のない “fetch URL” 機能を備えた公開 MCP サーバは、単一のインターフェイスを通じて、攻撃者に探索機能と SSRF 経路を提供する可能性がある。
防御側にとって必要なことは、アクセスログ内で POST /mcp、/sse、AI コンフィグファイル名、/v1/models、/api/tags、metadata.google.internal、169.254.169.254 を検索することである。それにより、認証されていない公開 MCP アクセスの遮断と、各ツールへの厳格な認可の適用、許可リストによるアウトバウンド通信の制限を実施すべきだ。
URL 取得機能においては、DNS の解決後とリダイレクト時に、リンクローカル／ループバック／プライベート／クラウド・メタデータ・ディスティネーションへのアクセスを拒否すべきである。
また、クラウド・ワークロードでは、最小権限のサービス・アカウントを使用し、盗まれたトークンの価値を最小限に抑えることが推奨される。さらに、AWS では IMDSv2 を強制することでセッション・トークン要件が追加されるため、多くの SSRF パターンの露出を低減できる。
訳者後書：インターネット上において、AI 関連のコンフィグ・ファイルや接続ポイントを狙う偵察活動が増えています。問題の原因は、インターネットに公開されたサーバにおいて、適切なアクセス制限が施されていないことにあります。特に、外部ツールと接続する MCP や LLM のエンドポイントが、認証を必要とせずにアクセスできる状態になっている状況や、開発時の機密ファイルが公開領域に配置されている状況が、不正な探索を許す要因となります。これにより、内部情報を盗み取られる SSRF にも繋がります。よろしければ、MCP での検索結果も、ご参照ください。
IoT OT Security News 
You must be logged in to post a comment.