インターネット全体を対象とした偵察活動は、従来のアプリケーションを標的とするものにとどまらず、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互換およびOllamaのAPIエンドポイントも探っていました。
重要なのは、こうしたAI関連の探索トラフィックが、Google Cloudのメタデータサービスを標的としたサーバーサイドリクエストフォージェリ(SSRF)の試みと同時に発生していた点です。これにより、公開されたエージェントツールからサービスアカウントトークンの窃取に至る経路が生まれる可能性があります。
CloudStorage
最も注目すべきリクエストは、JSON-RPC 2.0と2025-03-26プロトコルバージョンを用いて正しく構造化されたMCP initialize呼び出しを含む、POST /mcpによる探索でした。
MCPでは、ツールの検出やインタラクションが始まる前に、クライアントとサーバーがプロトコルの機能をネゴシエートする初期化ライフサイクルが用いられています。
これは単純なパスの存在確認とは本質的に異なるものです。応答が成功すれば、そのホストがMCPサーバーを稼働させていることが判明するだけでなく、攻撃者がAIクライアントで利用可能なツール、リソース、プロンプト、バックエンドサービスを列挙できてしまう可能性があります。
MCPはLLMアプリケーションを外部のツールやデータソースに接続するために設計されているため、インターネットに公開されたサーバーは、データベース、ファイルシステム、内部API、チケット管理プラットフォーム、クラウドサービスへの機械可読な入り口となり得ます。
今回観測された/mcpへの探索は49の異なる送信元IPから発信されており、単発の調査ではなく広範囲にわたる分散型の偵察活動であることがうかがえます。
防御側は、公開を意図したMCPサービスが存在しないにもかかわらず届く未承諾のMCP初期化トラフィックを、信頼度の高い偵察の兆候として扱うべきです。
同一のキャンペーンでは、/.claude/mcp.json、/.cursor/mcp.json、/.cursor/mcp_config.json、/.vscode/mcp.json、/.mcp/config.json、およびClaudeの認証情報パスといったAIアシスタント関連ファイルへのリクエストも行われていました。
これらのリクエストは、攻撃者が開発者側のAI設定情報を、接続情報やAPIキー、認証情報の潜在的な入手元として扱うようになっていることを示しています。
認証情報が記載されたファイル名に対してHEADリクエストが使われている点は特に示唆的です。これにより、スキャナーは機密性の高いオブジェクトの中身を取得せずにその存在有無だけを確認できるため、大量の標的に対して帯域を節約できます。
ISCの研究者によれば、AI固有のパスが従来型のクラウド認証情報ファイル名やKubernetesのシークレット、アプリケーション設定ファイルと並んで出現しており、AI関連のツールがすでに標準的な機密情報探索用ワードリストの一部となっている証拠だとしています。
CloudStorage
組織は、.claude、.cursor、.vscode、.mcp、およびホームディレクトリの設定ファイルパスが、本番環境の成果物にコピーされたり、Web公開ドキュメントルート配下にマッピングされたりしないよう徹底する必要があります。
Webサーバー側では、デプロイ時の運用管理だけに頼るのではなく、隠しディレクトリの設定ファイルや機密性の高いJSONファイルへのアクセスを明示的に拒否すべきです。
攻撃者はまた、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パターンに対する露出を減らすことができます。
CloudStorage
2019年当時のSOC向けに書かれたSLAをそのまま受け入れるのはもうやめませんか——2026年版AI SLA ベンダーチェックリストはこちら – 無料の AI SOC SLA ガイドをダウンロード
翻訳元: https://gbhackers.com/mcp-recon-with-cloud-metadata-ssrf/
