LLMJacking 盗まれた鍵で1日10万ドルの請求

業務アプリや社内ツールに生成AIのAPIを組み込んだ。鍵はサービスアカウントやAPIキーで管理している。その鍵の1本が漏れると、使っていなかったモデルのサービスまで有効にされ、数時間で大きな請求が届くことがあります。

Google Threat Intelligence Group（GTIG）とMandiantは2026年11月2日、こうした被害を「LLMJacking」としてまとめた報告を、Google Cloudの公式ブログで公開しました。報告によると、Mandiantが2026年に対応した複数の事案で、1日に10万ドルを超える不正な請求が発生し、アクセスを止めるまでの累計が100万ドルに達した組織もありました。この記事では、報告に書かれた攻撃の流れと、Google Cloudで先に設定しておく監視と上限を整理します。

暗号資産の採掘と何が違うか

報告は、LLMJacking を「企業の大規模言語モデル（LLM）へのアクセスを乗っ取る手口」と説明しています。事案は北米・南米・アジア太平洋の、金融・小売・テクノロジー・運輸の組織に及び、複数のクラウドとLLMの提供元にまたがっていました。

クラウドの計算資源を盗んで暗号資産を採掘する手口（クリプトジャッキング）は、資源を少しずつ使います。これに対して LLMJacking は、数時間で請求を急増させる点が違う、と報告は書いています。盗んだ利用枠を自分で使うだけでなく、「LLM Mixer」と呼ぶ中継の仕組みで束ねて、地下の利用者へ転売する分業も確認されています。

入口は「公開されたエンドポイント」と「盗まれた鍵」

報告が挙げる入口は2種類です。

1つは、認証なしで公開されたままのLLMのエンドポイントです。報告の図では、攻撃者が公開された Ollama のエンドポイントで /api/create を呼び、自分のモデルを登録しようとしています。

もう1つが、報告が「主な入口」とするクラウドの資格情報の盗用です。IAMの資格情報、サービスアカウントの鍵、GitHubの個人用アクセストークン（PAT）、有効なセッショントークンが挙げられています。事例として、次の手口が書かれています。

• 設定に誤りのあったサービスアカウントの鍵からクラウドのインスタンスに入り、LLMのAPIへの権限を足した（UNC6993）
• LLMの利用者のグループに参加するためのポータルを装ったページで、正規のLLMのサイトへ誘導し、有効なアクセストークンを含むJSONを貼り付けさせて、パスワードと多要素認証を迂回した（UNC6993）
• 盗んだPATで非公開のリポジトリに入り、コンテナ環境で動くパッケージのWebアプリの脆弱性（報告では「疑い」）の悪用と組み合わせた
• フェデレーションのトークンで新しいアクセスキーを作り、多要素認証を迂回した

LLMのAPIキーそのものも狙われています。公開のGitHubリポジトリから企業のAPIキーを集め、max_tokens=1 の最小限のリクエストで有効かどうかを確かめる手口が報告されています。リクエストの量が少ないため、量の異常を見る監視に引っかかりにくい、と報告は指摘しています。

入ったあとに広げ、請求を膨らませる

侵入後は、別の鍵を探して権限を広げます。報告によると、リポジトリを複製してハードコードされた秘密情報を探す、データウェアハウスのメタデータの表からパスワードを探す、トークンを作れる権限で上位のサービスアカウントの一時的な資格情報を作り、シークレットの保管庫から外部APIの鍵を持ち出す、といった動きがありました。

AIアプリ特有の経路として、複数のモデルのAPIをまとめるゲートウェイ LiteLLM の脆弱性も使われています。報告は、/key/regenerate のエンドポイントの脆弱性で、通常の仮想キーを PROXY_ADMIN の管理者の資格情報に引き上げた事例を挙げています。

ただし、報告がこの脆弱性に付けた CVE-2026-40217 という番号は、公的な記録と合いません。NVDとLiteLLMのアドバイザリ（GHSA-wxxx-gvqv-xp7p）では、この番号は /guardrails/test_custom_code のサンドボックスを抜けてコードを実行できる別の問題です。2026年11月6日の時点で、/key/regenerate での権限の引き上げを説明したアドバイザリは見つかりませんでした。CVEの番号だけで影響の有無を判断せず、LiteLLMのアドバイザリの一覧と使っている版を照らし合わせてください。

換金の段階では、次の動きが報告されています。

• 被害者のプロジェクトでAPIキーを追加で作り、関連するサービスを有効にしようとする。UNC6993 はこの動きで、短時間に10万ドルを超える請求を積み上げた
• 従量課金の契約に申し込み、上位のモデルで大量の推論を流す。レート制限を避けるため、短命のサービスアカウントを作っては消す
• 盗んだ鍵でトークンの中継サービスを動かす。ある攻撃者は8時間未満で50万回を超えるAPI呼び出しを行い、100万ドル近いトークンの費用が被害組織に回った

報告は、Mandiantが調べた複数の事案で、侵害の時点ではLLMのサービスが有効になっていなかったと書いています。使っていないから安全、ではなく、使っていないサービスが急に有効になること自体を重大な兆候として扱う必要があります。

Google Cloudで見るべきログ

報告は、AWS・Azure・Google Cloudのそれぞれで監視する操作を挙げています。Google Cloudでは、Gemini Enterprise Agent Platform（旧 Vertex AI、aiplatform.googleapis.com）への呼び出しを Cloud Audit Logs で見ます。注意点は、推論の操作が「データアクセス」の監査ログに含まれ、このログは量と取り込みの費用のため既定で無効になっていることです。IAMの監査ポリシーで手動で有効にする必要があります。Cloud Audit Logs のドキュメントでも、BigQueryを除くデータアクセスの監査ログは既定で無効です。

右の列は、2026年11月6日に各サービスの監査ログのドキュメントで確かめた内容です。報告が「データアクセスのログが必要」と明記するのはモデルの実行だけですが、モデルの一覧やログの設定を読む操作も同じ種類のログで、既定では残りません。

報告の操作名は、ドキュメントの表記と一致しないものがあります。Agent Platform の一覧に載っているのは endpoints.predict、endpoints.rawPredict、models.list、endpoints.list などの形で、GenerateContent、StreamGenerateContent、ListPublisherModels は見当たりませんでした。ログを有効にしたら試験用の呼び出しを1回行い、実際に記録される methodName を確かめてから通知の条件を作ってください。

Google AI Studio などから使う Gemini API（generativelanguage.googleapis.com）は別のサービスです。Cloud Audit Logs の対応サービスの一覧には見当たらなかったため、このAPIを使うプロジェクトでは、どの記録が残るかを別に確かめてください。

AWSでは Bedrock の InvokeModel などの実行、ListFoundationModels などの調査、CreateFoundationModelAgreement などのモデルの解放、呼び出しのログの設定の変更や削除を見るよう書かれています。IaC以外の主体がログの記録を止める操作は、重大度を高く扱うよう求めています。Azureでは Microsoft.CognitiveServices の展開の作成や、診断設定の変更を見るよう書かれています。

先に設定しておく予防策

報告の推奨のうち、AIのAPIを組み込んだシステムで設定や運用に落としやすいものを挙げます。

• 秘密情報の一元管理と交換: 鍵の保管と交換を自動化し、漏れた鍵が使える期間を短くする
• 最小権限: 役割に要らない権限は拒否する。LLMのサービスへのアクセスも含める
• コードの秘密情報のスキャン: GitHub・GitLabなどで、コードに入ったAPIキーを自動で見つけて取り除く
• 予算と上限: モデルごとにAPIの割り当てを細かく決め、支出の上限で使いすぎを防ぐ
• フィッシングに強い多要素認証: クラウドの管理画面と開発基盤に適用する
• APIキーの範囲の分割: モデル・環境（開発／本番）・利用量で鍵を分け、安いモデル向けの鍵で上位のモデルを呼べないようにする
• 確認の呼び出しの監視: max_tokens=1 などの少量で不自然なリクエストを、ゲートウェイとAPIのログで見る
• ゲートウェイの更新: LiteLLM などの中継のソフトウェアも、脆弱性の管理の対象に入れる

サービスアカウントの鍵を配らずに済む構成は鍵レスのWorkload Identity連携の記事、ゲートウェイを置く判断は社内AIのゲートウェイの記事で扱いました。LiteLLM の改ざん版の確認はLiteLLM 1.107.0の記事を参照してください。

編集部の提案：最初に確かめる3つ

報告の監視と予防の項目は多いため、Google Cloudを使う組織が最初に手を付ける順番を、編集部の提案として示します。

1. 生成AIを使っていないプロジェクトで、サービスの有効化を通知する。報告は EnableService を通知の対象に挙げ、「侵害の時点では有効でなかった」事案を示しています。Service Usage のドキュメントによると、この操作は管理アクティビティの監査ログに記録され、このログは常に書き込まれます。データアクセスのログを有効にしなくても記録は残ります。複数のサービスをまとめて有効にする BatchEnableServices も同じ種類のログなので、あわせて対象にします（通知の設定そのものは編集部では試していません）
2. 生成AIを使うプロジェクトでは、データアクセスの監査ログの対象と費用を決める。既定で無効のため、有効にしない限り推論の呼び出しは残りません。Cloud Logging の取り込みは1GiBあたり0.50ドルで、プロジェクトごとに毎月50GiBまでは無料です（2026年11月6日の料金ページ）。データアクセスのログは既定で _Default のバケットに入り、保存の期間の既定は30日です。呼び出しの量から費用を見積もり、保存の期間をあわせて決めます
3. 鍵の棚卸しをする。サービスアカウントの鍵、LLMのAPIキー、GitHubのPATについて、誰が作り、どこに置かれ、どのモデルと環境に使えるかを一覧にし、不要なものを消します

予算のアラートと支出の上限は、被害が起きたあとの金額を抑える手段です。検知の代わりにはならないため、1と組み合わせて設定します。

Google Cloud の通常の予算は通知だけで、利用は止まりません。利用を止めるには、Cloud Billing の支出の上限つきの予算（spend cap budget）を使います。対象は Gemini API、Gemini Enterprise Agent Platform、Cloud Run、Cloud Run functions で、1つのプロジェクトの1つのサービスごとに、月単位で設定します。上限を超えると、手動で解除しない限り、そのサービスの新しい利用が月末まで止まります。適用は即時ではなく、超えた分は請求される、とドキュメントは書いています。本番のサービスが止まる影響もあるため、上限の額はあらかじめ業務の担当者と決めておきます。止まる範囲と導入の順番は支出の上限の記事で扱いました。

確認した範囲

2026年11月3日と6日に、Google Cloud公式ブログのGTIG・Mandiantの報告「The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources」（配信データの公開日は2026年11月2日、ページの表示は11月3日）を直接取得し、本文の数値・手口・監視する操作・推奨を原文と照合しました（資料調査）。被害額や件数は報告に書かれた事案の値で、業界全体の統計ではありません。11月6日に、監査ログ・料金・支出の上限のドキュメント、CVE-2026-40217 のNVDの記録とLiteLLMのアドバイザリも確かめました。/key/regenerate の脆弱性の影響版と修正版、報告の番号が公的な記録と違う理由は確かめられていません。監視の設定と支出の上限の検証はしていません。

AIのAPIを組み込んだシステムの権限・監視の見直しは、開発・AI・自動化のご相談からお問い合わせください。

参考資料

• The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources（Google Cloud Blog、2026-11-02）
• Cloud Audit Logs overview（Google Cloud）
• Agent Platform audit logging information（Google Cloud）
• Service Usage audit logging（Google Cloud）
• Manage spend cap budgets（Google Cloud）
• Google Cloud Observability pricing
• CVE-2026-40217（NVD）
• GHSA-wxxx-gvqv-xp7p（GitHub Advisory Database）