LLMエージェント侵入の初事例、1時間でDB全窃取

攻撃者がスクリプトの代わりにLLMエージェントを使い、侵入から内部DBの窃取までを自律実行した——その実例が、はじめて野良環境で記録されました。

この記事では、Sysdig脅威調査チーム（TRT）が2026年5月10日に捕捉した侵入の全体像と、エージェント駆動と判断した根拠、運用側が取るべき対策を整理します。

この記事でわかること

• 4段階のピボットで1時間以内に完了した攻撃チェーンの流れ
• LLMエージェント駆動と判断した4つの技術的シグネチャ
• 入口となったCVE-2026-39987（Marimo）と優先すべきパッチ対応
• IPベース検知をすり抜けるCloudflare Workersの悪用手法
• 今後の検知・防御設計で意識すべきポイント

何が起きたか

2026年5月10日、Sysdig TRTは侵入のポストエクスプロイト段階をLLMエージェントが担っていた事例を記録しました。Sysdigは、これまで同チームが捕捉した侵入のなかで初めての「AIエージェント駆動」と位置づけています（参考）。

攻撃の流れは次のとおりです。インターネットから到達可能なMarimoノートブックにCVE-2026-39987を悪用して侵入し、侵害ホストからクラウド認証情報を2件取得。取得した認証情報を使い、Cloudflare Workersを出口プールとしてAWS APIを呼び出し、AWS Secrets ManagerからSSH秘密鍵を取得。その鍵でSSHバスチョンに8回の短いセッションを張り、内部PostgreSQLデータベースのスキーマと全内容を2分未満で持ち出しました。Marimo侵害からDBダンプまでの一連の処理は、1時間以内に完了しています。

Sysdig TRTのMichael Clark氏は、この事例について「攻撃者がAIに置き換わっているのではなく、攻撃者がスクリプトをAIに置き換えている」と述べています（参考）。

従来の「AI支援攻撃」と何が違うか

これまでも、LLMがフィッシング文面の生成やコード作成を手伝う事例は報告されていました。Sysdig自身も、2025年11月に「AI支援」と判断したクラウド侵入を公開しています。

今回の5月10日の侵入は性質が異なります。初期侵入（Marimoの悪用）のあと、ポストエクスプロイトの意思決定とコマンド実行をLLMエージェントが担い、事前に書かれたプレイブックではなく、その場の出力を読んで次の手を選んでいました。人間がキーボードを叩いている形跡はなく、4つのピボットが1時間弱でつながった点が、従来の「特定工程だけAI」から一歩進んだ実運用例だと言えます。

4ピボットの攻撃チェーン

Sysdigが整理したタイムライン（すべてUTC）を要約します。

認証情報収集から最初のAWS API呼び出しまで約4分の空白は、収集結果を別ツール環境（エージェント側）へ渡す時間と整合します。Secrets ManagerへのGetSecretValueは22秒間に12回呼び出され、11個の異なるCloudflare WorkersのIPに分散。ソースIP単位の相関に頼る検知を意図的に崩す構造です。

バスチョン上のDB窃取フェーズは113秒の窓に4つのエージェントシグネチャが重なり、並列SSH（6つのWorker IPから10秒間隔で同一鍵セッション）と組み合わさっています。

LLMエージェントと判断した4つの根拠

自動化かどうかは速度と並列性だけでは切り分けられません。Sysdigは「セッション開始前に書かれたスクリプトか、リアルタイムに組み立てられたか」を問題にし、次の4点を根拠に挙げています。

1. 事前情報のない環境への即興ダンプ

バスチョン上にDBの所有者アプリを示す痕跡はなく、ホスト名internal-dbだけが手がかりでした。それでもpg_tablesで列挙した直後、credentialテーブルを単独でSELECTし、最終的にapi_key・credential・userなど6テーブルを1つのHEREDOCでまとめてダンプしています。テーブル一覧はLangflow風のスキーマを想定したものの、Langflowには存在しないcredentialテーブルも含まれており、事前検証済みプレイブックでは説明しにくい挙動です。

2. 計画コメントのコマンドストリームへの混入

認証ファイル探索ブロックの先頭に、中国語のコメント「看还能做什么」（「他に何ができるか見てみる」）が入っていました。続くシェルは英語です。人間が手入力するなら思考をシェルに貼ることは稀で、静的スクリプトに計画コメントはありません。LLMエージェントでは推論と実行が同一トークンストリーム上に載るため、この種の漏れが起き得る、とSysdigは分析しています。

3. 機械消費向けのコマンド形状

echo '---'によるブロック区切り、2>&1 | head -Nによる出力上限、-P pager=offによるページャ無効化、2>/dev/nullによるstderr破棄などが、113秒の即興セッションにまとまって現れています。出力を別プロセス（モデル）が再パースして次手を決めるループ向けの整形です。

4. 直前のツール出力からの値の引き渡し

~/.pgpassを読んだ数秒後に得たパスワードをPGPASSWORDに設定。ListSecretsの応答から20秒後にGetSecretValueのSecretIdを選択。エージェントがコンテキストから値を拾い、次のツール呼び出しに渡す典型的なパターンです。

入口の脆弱性 CVE-2026-39987

https://github.com/marimo-team/marimo/security/advisories/GHSA-2679-6mx9-h9xc

MarimoはリアクティブなPythonノートブック環境です。CVE-2026-39987は、統合ターミナル用WebSocketエンドポイント/terminal/wsが認証検証を省略していたことによる、認証前リモートコード実行（RCE）です。他のWebSocket（/wsなど）はvalidate_auth()を呼ぶ一方、/terminal/wsはモードとプラットフォームのチェックのみで接続を受け付け、Marimoプロセス権限のPTYシェルを与えます。CVSS v4.0は9.3（Critical）です。

修正版は0.23.0以降です。CISAのKnown Exploited Vulnerabilities（KEV）カタログにも掲載され、連邦機関向けの対応期限（2026年5月7日）はすでに過ぎています。Sysdigは「パッチ未適用のインターネット公開Marimoは、エージェントにとって1時間以内に内部DBまで到達しうるピボット装置」と警告しています（参考）。

アップグレード例:

pip install --upgrade "marimo>=0.23.0"

即時アップグレードが難しい場合は、/terminal/wsへのネットワーク到達を制限するか、ターミナル機能自体を無効化してください。

防御側が変えるべき前提

Sysdigが指摘する変化は「能力の飛躍」より「コスト構造の変化」です。ターゲットごとにプレイブックを書く従来型は工数がかかりますが、エージェントはアプリの一般知識（プリオール）からその場でチェーンを組み立てます。存在しないテーブル名を推測して叩くようなミスは起きても、認証失敗や想定外スキーマに対して読み取って次を試す適応性が上がります。

検知面では、コマンド列の既知パターン一致だけでは効きにくくなります。プレイブックは毎回同じUser-Agentやコマンド順序を残しますが、エージェントは標的ごとに異なる指紋を残します。Sysdigが推すのは「認証情報の読み取り」「DBの持ち出し」「権限昇格」など、攻撃者が達成しようとする目的に根ざした検知です。インターネット露出資産だけでなく、内部のランタイム脅威検知とテレメトリの網羅が前提になります。

運用チェックリストとして、Sysdigは次を推奨しています。

• Marimoを0.23.0以降へ更新（または/terminal/wsを遮断）
• 公開されていたMarimo上の環境変数・.env・シークレットを監査し、AWS認証情報・APIキー・DBパスワード・SSH鍵をローテーション
• 横展開の調査ができるテレメトリを有効化
• ネットワーク全体にランタイム脅威検知を展開

読者が持ち帰るべき一点

LLMを「攻撃者の補助ツール」から「ポストエクスプロイトの運転席」へ押し上げた実例が、2026年5月に観測されました。入口は既知CVEのパッチ適用で塞げますが、塞いだあとも、認証情報が1台に載っている限り、エージェントは短時間で内部まで届きます。Marimoのパッチと秘密情報のローテーションを最優先にし、IP相関だけに依存しない検知設計へ移行することが、今回の事例が示す実務的な教訓です。