ある小規模なウェブホストの2週間分のApacheおよびModSecurityログを分析したところ、ハッカーがインターネット上で公開されたModel Context Protocol(MCP)サーバー、AIアシスタントの設定ファイル、そして認証を経ずにアクセス可能なローカルの大規模言語モデル(LLM)エンドポイントを積極的にスキャンしていることが明らかになりました。
このホストには、WordPressサイト、独自のアプリケーションバックエンド、静的サイトなど、トラフィック量の少ない複数の仮想サーバーが含まれていました。
MCPサービスやAIコーディングアシスタントのインフラ、自己ホスト型LLMは運用されていませんでした。それにもかかわらず、攻撃者はこれら3つすべてを繰り返し探索しており、AI関連サービスがインターネット上の日常的な偵察活動の対象に組み込まれていることを示しています。
従来型のプローブも依然として多く見られ、WordPressのXML-RPCリクエスト、公開状態の.envファイル、Gitリポジトリファイル、Spring Boot Actuatorエンドポイントなどが確認されました。しかし、約200200200件のリクエストがAIエージェントのインフラを標的としていました。
MCPサーバーは、AIエージェントがデータベース、ファイルシステム、チケット管理プラットフォーム、内部API、クラウドサービスといった外部のツールやデータにアクセスできるようにする仕組みです。
MCPサーバーが認証なしで公開されている場合、攻撃者は利用可能なツールを列挙したり、接続先のデータソースを特定したり、サーバーの機能を悪用したりする可能性があります。
攻撃者は/sseへのリクエストも行っていました。これは、旧来のMCPトランスポート実装に関連するServer-Sent Eventsエンドポイントです。
プロトコルを意識したPOST /mcpリクエストと/sseへのプローブが組み合わさっていることから、スキャナーは現行および旧来双方のMCP実装を探索しているとみられます。
認証情報を狙った複数のプローブでは、GETではなくHTTPのHEADメソッドが使用されていました。これにより攻撃者は、ファイルの内容をダウンロードすることなく、その存在の有無を確認できます。大規模なスキャン作業における帯域幅の消費を抑える狙いがあります。
これらのファイルには、MCPサーバーのURL、ローカル設定の詳細、アクセストークン、APIキー、その他の機密情報が含まれている場合があります。
開発者が誤って隠しAIアシスタント用ディレクトリを公開済みのウェブルート内に含めてしまった場合、攻撃者はそこから内部ツールやクラウドサービスへのアクセスを可能にする認証情報を取得できる可能性があります。
いずれかのエンドポイントから認証なしで応答が返ってくると、そのホストがローカルモデルサーバーを稼働させていることが明らかになってしまいます。攻撃者はこれを無料の推論リソースとして悪用したり、利用可能なモデルを列挙したり、さらなる攻撃の足がかりとしてこのサービスを利用したりする可能性があります。
これらのプローブに伴って、Google Cloudのメタデータサービスを狙ったSSRF(サーバーサイドリクエストフォージェリ)の試みも確認されました。
リクエストにはurl、uri、path、destといったパラメータが使用されており、アプリケーションがmetadata.google.internalを含む攻撃者制御下のURLを取得してしまうかどうかを試すものでした。これが成功すると、クラウドサービスアカウントのトークンが漏えいする恐れがあります。
組織はMCPサービスに対して強固な認証を要求し、LLMサーバーをパブリックインターネットに公開しないようにし、フェッチ型エンドポイントからクラウドメタデータアドレスへのアクセスをブロックし、.claudeや.cursorといった類似のディレクトリがウェブからアクセス可能なパス内に絶対に配置されないよう徹底すべきです。
注: IPアドレスおよびドメインは、誤った名前解決やハイパーリンク化を防ぐため、意図的に無害化表記(例: [.])としています。再度有効な形式に戻す作業は、MISP、VirusTotal、SIEMなど管理された脅威インテリジェンスプラットフォーム内でのみ行ってください。
翻訳元: https://cyberpress.org/hackers-scan-exposed-ai/
