「勝った」と思っていた | AIネイティブ・アクティブディフェンス

6月のある木曜日の午後、私たちがインターネット上に放置していたサーバーに何者かがアクセスし、作業を始めました。人間の入力速度ではあり得ない速さで、わずか65ステップの間にパスワードファイルを読み取り、認証情報ファイルを一通り確認し、コンテナからの脱出コマンドを実行し、自前のSSH鍵を持つバックアップ管理者アカウントを作成しました。作業が終わる頃には、攻撃者から見れば、中堅アナリティクス企業の本番サーバーを掌握したはずでした。

しかし、これらはすべて仕組まれたものでした。このサーバーはハニーポットであり、パスワードファイルも、認証情報も、そして攻撃者が「脱出した」と思い込んだコンテナも、すべて私たちが用意したものです。本物だったのは、その記録だけです。そして、それとは別の3件のセッションでは、盗まれた鍵が後に実際に稼働しているAWSアカウントで使用されており、そのうち1件では2日間で55回も使われ、誰かの請求でモデルが実行されていました。

このマシンは、私たちが用意した24台のうちの1台です。2026年5月から7月にかけて、この24台は私たちが仕掛けたデコイを発見し、そのツールを使用しました。以下は、彼らが実際に行ったことの記録です。

概要

• 私たちは、認証を必要としないModel Context Protocol(MCP)サーバーを公開しました。これは、AIエージェントがコマンドを実行し、ファイルを読み取り、シークレットを取得するためのインターフェースです。約1,000の接続元がこのサーバーにアクセスしました。そのうち596がプロトコルに従って通信し、24がツールの呼び出しまで進みました。
• この24件は628件のシェルコマンド、255件のファイル読み取り、248件のシークレットストア照会を行いました。19件が認証情報を探索し、4件がコンテナからホストへのエスケープを試み、さらに数件はバックドアアカウントの作成やKubernetesの列挙など、より踏み込んだ行動に及びました。
• 活動は増加傾向にあります。ツール呼び出し件数は5月が39件、6月が693件、7月中旬までに877件に達しました。
• 3件のケースで、窃取された情報が私たちの管理下の外に漏れ出しました。デコイから盗まれたトリップワイヤー用の認証情報が、後に実在するAWSアカウントに対して使用され、そのうち2件はモデルの呼び出しに利用されました。

MCPはAIエージェントに「手」を与えます。MCPサーバーはシェル、ファイル読み取り機能、シークレット照会機能といったツールを提示し、エージェントは何か行動を起こす必要があるとき、tools/callリクエストでこれらを呼び出します。これはエージェントを有用たらしめる仕組みであると同時に、認証のないMCPサーバーが単なる「調査対象のサービス」ではなく「奪い取れる能力の集合体」になってしまう理由でもあります。

MCPサーバーの数は急増しています。この約1年でごく少数から数千規模にまで増え、その中で認証を設定していないままインターネットに公開されているものの割合も拡大しています。基本プロトコルではOAuthのステップが任意扱いになっており、多くの実装がこれを省略しているのです。こうしたサーバーは容易に発見できます。スキャナーはJSON-RPCのバナーや/mcp、/messagesといったパスを手がかりに検出し、その後は行儀の良いスキャナーであれば読み取り専用のtools/listを送って「何ができるのか」を尋ねる程度にとどまります。しかし今回観測した24件は、そこで止まりませんでした。返ってきた答えを読み取り、実際に使い始めたのです。

侵入の足跡

先ほどの木曜日のセッションに話を戻しましょう。標準的なハンドシェイクを経て接続してきたこの攻撃者は、ツール一覧を取得すると、その後は一度も手を止めませんでした。以下は、そのセッションの実際の記録を軽く整理したものです。

まず状況を把握し、その後サーバーの掌握に取り掛かりました。

execute_command  id; uname -a; hostname; whoami; pwd
read_file        /etc/passwd
execute_command  sudo -l

続いて、環境設定ファイル、バックアップ、デプロイ鍵、シークレットディレクトリと、認証情報関連のファイルを順序立てて調べていきました。

read_file  /root/.env
read_file  /root/credentials.bak
read_file  /root/deploy-key.pem
list_directory  /root/.secrets

その後、認証情報の探索を切り上げ、ホストの掌握に移りました。ホストのルートを使い捨ての特権コンテナ内にマウントして踏み込むコンテナエスケープのコマンドを実行し、そのまま永続化の作業に入りました。

execute_command  sudo docker run --rm --privileged --pid=host -v /:/host alpine chroot /host …
execute_command  sudo useradd -m -s /bin/bash -p $(openssl passwd -6 ******) admin
execute_command  sudo mkdir -p /home/admin/.ssh && echo ssh-rsa AAAAB3N… >> …/authorized_keys
execute_command  sudo usermod -aG sudo admin

バックドア用の管理者アカウント、独自のSSH鍵、root権限相当のsudo権限。いずれのコマンドもそれらしい「成功」の応答を返しましたが、それはこのデコイがそう返すよう設計されていたからにほかなりません。攻撃者の視点からすれば、コンテナからの脱出に成功し、再侵入の足がかりを確保したように見えたはずです。しかし実際には何も脱出していません。攻撃者はずっとBeelzebubと対話していただけであり、乗っ取ったはずのホストはそもそも存在しないのです。そこに残されたのは、本物らしく見えるだけのシステムに対する乗っ取りの試みを、コマンド一つひとつまで順に記録した完全なログでした。

シグナルは「接続」ではなく「呼び出し」

1,000件のうち、注目すべき24件を残りと分けたのはハンドシェイクの有無ではありませんでした。ハンドシェイクだけならスキャナーでも完了させられます。実際、596の接続元がMCPで通信したものの、そこから先には進みませんでした。両者を分けたのは次の一手、すなわち本来触れる理由のないデータに対してツールを呼び出すという行為です。接続自体はどの公開ポートでも発生する背景ノイズにすぎませんが、呼び出しには明確な意図が表れます。

今回の24件の中で、その意図は大きく3つのパターンに分かれました。

手当たり次第型。ある接続元は330回のツール呼び出しを行い、うち304回は単一セッション内に集中していましたが、状況に応じた調整は一切見られませんでした。思いつく限りのあらゆる表記のキー名、OPENAI_API_KEY、openai_api_key、ANTHROPIC_API_KEY、AWS_SECRET_ACCESS_KEY、VAULT_TOKENなど、大文字小文字も含めて、決まった順序でシークレットストアを機械的に叩き続けました。結果を読み返すこともありませんでした。まるでネットワーク接続を持ったワードリストのような動きです。

状況を読み取る型。より静かなセッションでは、まずシークレットストアの一覧を取得し、実際に存在するキー、クラウドの認証情報、vaultのアドレス、署名鍵だけを狙って取得し、それ以外はスキップしました。これは単なるスクリプトではなくエージェントであることを示す最も明確な特徴です。結果を読み取り、その内容に基づいて次の呼び出しを選んでいるのです。速度だけでは示唆にとどまり、実際24件中8件は機械並みの速度で動いていましたが、真の決め手となるシグナルは「適応」の有無でした。

環境全体を狙う型。別の接続元は/etc/shadowを読み取り、setuidビットの立ったバイナリをファイルシステム全体から検索し、同様のコンテナエスケープを実行した後、オーケストレーション層にまで手を伸ばしました。kubectl get pods --all-namespacesやkubectl auth can-i --listを実行し、盗んだアイデンティティでクラスター内のどこまで到達できるかを洗い出していたのです。

この3パターンを、ハンドシェイクより先に進まなかったスキャナー群と比較すると、その違いは非常に明快です。

ハンドシェイクだけでは何もわかりません。意味を持つのは、あくまでツール呼び出しの内容です。

唯一本物だったもの

ここまで述べたことはすべてデコイの中で起きた出来事であり、攻撃者が持ち去った認証情報も偽物でした。ただし、一つだけ意図的な例外があります。シークレットストアの中には、ハニートークンが仕込まれていました。これは、一見本物のように見えるものの実際には何の機能も持たず、誰かが使用した瞬間にアラートを発する鍵です。

3件の攻撃者がこのハニートークンに引っかかりました。デコイから盗まれた鍵が、数日後に実際に稼働しているAWSアカウントに対して使用されているのが確認されたのです。トークンごとに割り当てられた固有の値によって、出どころが特定できました。

• 6月16日に取得された1件の鍵は、6月30日まで使用され続けました。GetUser、ListBuckets、ポリシーの確認、そしてBedrockのInvokeModel呼び出しが確認されています。
• 6月25日に取得された1件は、同日中にcaller-identityの確認とS3のリスト取得に使われた後、使用されなくなりました。
• 7月12日に取得された1件は、2日間で55件のアラートを発生させました。アイデンティティの確認、IAMの列挙、Secrets ManagerおよびS3のリスト取得、AssumeRole、GetSessionToken、そしてAmazon Bedrockに対するInvokeModelとConverseの呼び出しが繰り返し行われています。

最後の一連の動きは、いわゆるLLMjackingです。盗んだ鍵が有効かどうかを確認し、どこまでアクセスできるかを洗い出した上で、被害者の請求でモデルを実行し尽くすという手口です。私たちはハニーポット内での情報窃取と、トークンを通じて実際のアカウントでの使用の両方を記録しました。このうち2件は実際の推論実行にまで至っています。今回の記事の中で、推測ではなく事実として断言できるのはこの点だけです。帯域外のアラームが、それぞれの実行を記録していたからです。

2025年後半、GreyNoiseは何も応答しないMCPエンドポイントを公開しましたが、その結果集まったのはスキャナーのみで、実際の攻撃活動は確認されませんでした。一方で私たちのデコイには24件の攻撃者が訪れ、一連の攻撃チェーン全体が観測されました。この違いを生んだのはプロトコルそのものではなく、「餌」の質です。何も応答しない空のエンドポイントはスキャンを招くだけですが、MCPに正しく応答し、企業の内部プラットフォームのように振る舞うサーバーは、攻撃者をそこに留まらせる誘因になるのです。

この再現度の高さこそが、今回の仕組みの核心です。このハニーポットは本物のMCPサーバーとして動作するため、接続してきたクライアントから見れば、ハンドシェイク、ツール一覧の取得、呼び出しのフレーミングは本番環境と見分けがつきません。欺瞞が仕込まれているのは、ツールが返す「結果」の部分だけです。プロトコル層で見抜けるようなトリックは存在せず、攻撃者たちは筋の通った応答を返す世界に引っかかり、私たちが見守る中で何百回ものツール呼び出しをその世界に対して費やしていったのです。

攻撃指標

以下は、デコイに対してツールを呼び出した接続元の一覧です。IPアドレスは無害化して記載しています。これは観測された挙動に関するインテリジェンスであり、特定の攻撃者集団を名指しするものではありません。使用されているインフラはレンタル型で、頻繁に切り替わっています。

このほかにも5件の接続元がわずかなツール呼び出しを行っていますが、認証情報へのアクセスには至っていないため、ここでは割愛しています。

検知と防御

以下の内容には一つ留意点があります。今回のサーバーはデコイであるため、私たちは実際に「エスケープ」や「認証情報の流出」を検知したわけではありません。あくまで、それらの試みをツール呼び出しとして受け取り、記録したにすぎません。読者にとって価値があるのは、これらの試みが実際のMCPサーバーで何を計測すべきかを示している点です。

まず認証から見直してください。もしサーバーが外部から到達可能かつ認証なしの状態であれば、真っ先に対処すべきはそこです。プロトコルにOAuthのステップが用意されているのはそのためです。その上で、ツールハンドラーこそが制御を効かせるべき要所であり、最も強力な対策はアラートを出すことではなく、そもそも「拒否する」ことです。すべてのtools/callをスキーマとアローリストに照らして検証し、引数の書き方がどうであれ、シェルツールやファイルツールが/etc/shadow、クラウドの認証情報ファイル、.envを解決できないようにし、ホストのルートをバインドマウントする操作(-v /:、--privileged、--pid=host)は拒否してください。これらはいずれも、自社のエージェントが本来触れる理由のない領域です。また、攻撃者が真っ先に狙う場所にハニートークンを仕込んでおけば、窃取された時点で悪用される前にアラームを鳴らせます。

ほとんどのMCPサーバーは何もログを残していません。これ自体が一つの問題です。もしツール呼び出しをログに記録しているのであれば、今回のデータが示す検知ポイントは、認証情報のパスを読み取るtools/callです。MCPのツールテレメトリには標準のログソースが存在しないため、フィールド名は各自の監査スキーマに合わせてマッピングしてください。

title: MCP Tool Call Reading A Credential File
id: cbe4124b-f0c5-45d1-beaf-c10dcdc8807d
status: experimental
logsource:
    product: mcp_server
    service: tool_audit          # CUSTOM/NON-STANDARD — map to your audit schema
detection:
    selection_tool:
        tool_name:
            - 'execute_command'
            - 'read_file'
    selection_target:
        tool_arguments|contains:
            - '/etc/shadow'
            - '/etc/passwd'
            - '.aws/credentials'
            - '.env'
    condition: selection_tool and selection_target
falsepositives:
    - A first-party agent that legitimately reads these paths. If yours does, it
      belongs in an allowlist, not an alert.
level: high
tags: [attack.credential-access, attack.t1552.001]

もう一つ注目すべきシグナルはテンポです。単一セッションから短時間に何十回ものシークレットストア照会が行われるという点です。これは単発のイベントではなく発生率の問題であるため、同一ログ上での相関分析が必要になります。今回観測した攻撃者たちを分ける目安は「5分間に20回」でしたが、これは自組織のベースラインに合わせて調整してください。さらに、シェルツールが実際のホストにアクセスできる権限を持っている場合、エスケープやアカウント作成の試みは通常のホストセキュリティの問題として扱えます。/etc/shadowやauthorized_keysに対するauditdの監視、そして--privilegedや/のバインドマウント付きで作成されたコンテナに対するDockerデーモンの監査が有効です。

MITRE ATT&CK

現行のマトリックスに照らして検証済みです。簡潔にするためDiscovery系の手法は割愛し、今回の一連の攻撃チェーンにおいて重要なものだけを挙げます。

本レポートの限界

これはハニーポットのデータであり、示しているのはあくまで「意図」であって「侵害の成立」ではありません。実際のシステムには一切到達しておらず、対象となったホストはデコイであり、そこで提供された認証情報はすべて偽物かトリップワイヤーです。エスケープ、バックドアアカウント、/etc/shadowの読み取りといった一連の行動は、すべて作り物の応答に対する試みにすぎません。24件という数字はあくまで下限値であり、私たちのセンサーのカバー範囲と、約10週間という観測期間に制約されています。速度に基づく機械的挙動の判定はあくまで評価であって、身元が確認されたものではなく、私たちはいずれのセッションについても特定の個人や集団に帰属させてはいません。

新たな戦線が開かれた

これは、公開されたMCPサーバーを狙う攻撃者たちの活動について、これまでで最も鮮明に捉えられた事例です。そして、これが最後の事例になるとは考えていません。AIエージェントのツールボックスは今や攻撃対象領域の一部となっており、攻撃者たちは偵察を省略し、いきなり鍵そのものを狙ってきています。

これらの動きは、外部からはほぼ一切見えません。スキャナーからはサーバーがハンドシェイクに応答したことしか見えないのです。認証情報の総当たり、エスケープ、バックドア、そして後になって誰かのBedrockの請求書に姿を現す盗まれた鍵、これらはすべてサーバー自身にしか見えません。それがこの脅威の実態であり、デケプション(欺瞞技術)が有効である理由でもあります。公開されたMCPサーバーが実際に悪用されている様子を見ることができるのは、そのサーバー自身という視点だけなのです。こうしたサーバーは今後も増え続けます。MCPサーバーを運用するすべての人にとって、もはや問題は「攻撃者に見つかるかどうか」ではありません。「見つかったときに、あなたがそれを見張っているかどうか」なのです。

本レポートで使用されたハニーポットは、AIネイティブなインフラ向けのオープンソース・デセプションフレームワークであるBeelzebub(github.com/beelzebub-labs/beelzebub)を用いて構築されています。このフレームワークは本物さながらにプロトコルに応答するため、スキャナーには到達し得ない領域にデコイを配置できます。攻撃者がそこで行うあらゆるツール呼び出しを記録できるのです。

MCPサーバー、AIゲートウェイ、エージェントインフラを運用しており、自社の環境がどのような攻撃を引き寄せているのかを確認したい方は、デモを予約してください。

Beelzebubチームは、インターネットをより良く、より安全な場所にすることに尽力しています。❤️