LLM の盗用は「1 トークンの確認呼び出し」で始まる：LiteLLM のキー昇格と GTIG の推奨
Google GTIG/Mandiant の LLMJacking 調査では、盗んだ API キーを出力 1 トークンだけの要求で有効か確かめ、利用量の異常検知をすり抜けていた。LLM 中継の LiteLLM では仮想キーを管理者へ付け替える不備も悪用された。
手口のポイント
- 初期侵入は、露出・窃取された IAM 認証情報、サービスアカウント鍵、GitHub の PAT が中心。
- UNC6993 は「LLM 利用者グループへの参加窓口」を装う偽ページで、正規 LLM サービスから取ったアクセストークン入り JSON を貼り付けさせ、パスワードと MFA を回避した。
- LiteLLM では
/key/regenerateの不備で仮想キーの利用者 ID を管理者 ID に付け替え、PROXY_ADMIN権限を得た（PR #27793 で修正）。報告は CVE-2026-40217 としているが、同番号の CVE レコードは/guardrails/test_custom_codeの任意コード実行という別の不備なので、番号だけで判断しない。 - 侵害時に無効だった LLM サービスを攻撃者が有効化した例が複数。中継サービスで 8 時間足らずに 50 万回超呼び出し、100 万ドル近い費用を転嫁した例も。
対策
- LiteLLM を使っているなら修正を含む版へ更新する。 管理 API（キー発行・再生成）は外部から届かない場所に置き、仮想キーの権限変更を監査する。
max_tokens=1のような極小の要求を監視対象にする。 量ではなく「見慣れない送信元からの小さな確認呼び出し」がシグナルになる。- 使っていない LLM サービス（Vertex AI、Bedrock など）の有効化イベントをアラートにする。
- GCP では推論の記録を含む Data Access ログが既定で無効。必要なプロジェクトで有効にしておかないと後から追えない。
- 支出上限・予算アラートを小さめに設定する（クラウドの請求先を乗っ取られて AI 利用料を払わされない（GCP の LLMjacking 事例） も参照）。
- 「トークン入り JSON を貼ってください」と求めるページは、正規サービスの名前があっても入力しない。