盗まれたAPIキーでAIを使い放題、企業に最大100万ドルの請求を負わせる「LLMJacking」の脅威

Google傘下のMandiantとGoogle Threat Intelligence Group（GTIG）は2026年11月2日、盗んだクラウド認証情報やAPIキーを悪用して企業の大規模言語モデル（LLM）を不正利用し、その費用を被害組織に負担させる「LLMJacking」に関する調査報告を公開した。Mandiantによると、2026年に対応した個別のインシデントでは、1日当たりの不正請求額が10万ドルを超え、一部の組織ではアクセスを遮断するまでの累計が100万ドルに達した。1日10万ドル超という金額は、セキュリティ企業Sysdigが2024年に最先端AIモデルの不正利用による潜在的なコストとして試算していた水準と一致する。

ただし、Mandiantが示した金額は実際の事案で観測されたものであり、被害組織の平均額ではない。対象となったインシデントの件数や金額の算出方法も公表されていない。今回の報告で重要なのは、2年前には最悪のケースとして想定されていた高額請求が現実に確認されたことに加え、侵害時点では利用できなかったLLMサービスまで攻撃者が有効化し、短時間で大量の推論を実行する手口が明らかになった点だ。

「1日10万ドル超」は個別事案で観測された金額であり、平均値ではない

Mandiantは今回の報告で、個別のインシデントにおいて、リソースの消費に伴う不正請求が1日で10万ドルを超えたことを確認したと説明している。さらに、一部の組織では攻撃者のアクセスを取り消すまでに累計100万ドルの請求が発生したという。いずれも調査で確認された事例の金額であり、すべての被害組織に共通する水準や、典型的な被害額を示したものではない。

金額の詳細については、重要な情報が明らかになっていない。何件のインシデントを調査し、そのうち何件で1日10万ドルを超えたのか、対象となった日付や計測期間、請求額が確定した実額なのか推計値なのかは公表されていない。被害組織は北米、南米、アジア太平洋地域にまたがり、金融サービス、小売、テクノロジー、運輸などの業種に属しているという。ただし、アジア太平洋地域の具体的な国名は示されておらず、日本企業が被害を受けた事例が含まれるかどうかも確認できない。

海外メディアでも高額な不正請求が注目された。SiliconANGLEはGoogleが1日10万ドルの不正クラウド請求につながる攻撃を確認したと報じ、The Registerも企業に1日10万ドル超のLLM利用料金を負担させる攻撃を取り上げた。しかし、これらの金額は被害組織が毎日継続的に支払っていることを意味するものではない。Mandiantの一次報告が示しているのは、個別のインシデントで観測された1日当たりの請求額だ。

報告には、別の事例として10万ドル超の請求額も登場する。Mandiantが「UNC6993」と呼ぶ攻撃グループは、盗んだ認証情報を使って追加のAPIキーを作成し、関連するLLMサービスの有効化を試みた。その結果、短期間で10万ドルを超える請求額が積み上がったという。ただし、この事例については正確な期間が明記されておらず、前述の「1日10万ドル超」と同じインシデントであるとも説明されていないため、両者は区別する必要がある。

これほど短期間で請求額が膨らむ理由は、LLMの従量課金方式にある。従来のクリプトジャッキングは、盗んだ計算資源を使って仮想通貨を採掘するため、リソース消費が比較的緩やかに進む。一方、LLMJackingでは攻撃者が高額なAIモデルを選び、大量のAPIリクエストを継続的に送信することで、推論処理に応じた料金を急速に積み上げられる。Mandiantは、こうした不正利用によって数時間でクラウドの請求額が急増する可能性があると警告している。

2024年のSysdigによる試算が、2026年には実際の被害に

「LLMjacking」という名称は、Sysdigの脅威調査チームが2024年5月6日に公開した調査報告で使い始めたものだ。当時Sysdigは、脆弱なLaravel（CVE-2021-3129）を悪用して盗んだクラウド認証情報を使い、10種類のクラウドLLMサービスを標的とする攻撃を確認していた。攻撃者は不正に取得した認証情報を使ってLLMへのアクセス権を調べ、その利用権を第三者に販売しようとしていた。

Sysdigはこの調査で、AnthropicのClaude 2.xを複数のリージョンでクォータの上限まで利用された場合、被害組織が負担する料金は1日4万6000ドルを超える可能性があると試算した。これは実際に発生した請求額ではなく、当時のモデル利用料金とクォータを使った最悪ケースの計算だった。攻撃者が利用可能な上限まで推論処理を実行すれば、短期間で高額な費用を発生させられることを示したものだ。

同年9月18日に公開した続報では、攻撃手法の変化も報告された。攻撃者は、すでに利用可能な状態にあるLLMを悪用するだけでなく、盗んだクラウド認証情報を使ってモデルそのものを有効化しようとしていたという。さらに、Claude 3 Opusのような当時の最先端モデルが悪用された場合、被害組織の潜在的なコストは1日10万ドルを超える可能性があると指摘した。Sysdigは2024年7月11日にも、わずか3時間でAWS Bedrock APIへのリクエスト約6万1000件を観測しており、攻撃者が極めて短時間に大量の推論処理を実行できることを確認していた。

GTIGも2026年9月8日の「AI Threat Tracker」で、企業のクラウド環境やAIアカウントを狙った不正利用を取り上げている。今回の11月2日の報告は、こうした攻撃の実態をMandiantのインシデント対応事例からさらに詳しく分析したものだ。金額に関する主な報告を時系列で整理すると、次のようになる。

公表日	発表元	1日当たりの金額	数字の性質
2024年5月6日	Sysdig	4万6000ドル超	Claude 2.xの不正利用を想定した最悪ケースの試算
2024年9月18日	Sysdig	10万ドル超	Claude 3 Opusなど最先端モデルの潜在コストを試算
2026年11月2日	Mandiant、GTIG	10万ドル超	個別インシデントで観測された不正請求

2024年のSysdigによる試算と、2026年のMandiantによる観測には重要な違いがある。前者は想定される利用量と料金体系に基づいて算出した潜在的なコストであり、後者は実際のインシデント対応で確認された不正請求額だ。両者は同じ条件で計測されたものではないため、被害額が何倍に増えたといった比較はできない。また、Mandiantは事案数や金額の算出方法を明らかにしていないため、被害の平均額や増加率を求めることも不可能だ。

攻撃手法についても、2024年からの変化と共通点が見られる。盗んだ認証情報によるモデルの有効化は、Sysdigが2024年9月の時点ですでに確認していた。2026年のMandiantの報告で新たに明らかになったのは、こうした攻撃が実際に巨額の請求を発生させていることに加え、初期侵入を担う攻撃者と、不正に取得したLLMへのアクセスを転売する攻撃者の分業が進んでいる点だ。

無効だったLLMサービスを攻撃者が有効化する手口

LLMJackingの多くは、クラウド環境の認証情報を盗むことから始まる。Mandiantによると、複数の調査で主要な初期侵入経路となったのは、外部に露出したり盗まれたりしたクラウドのIDトークンだった。具体的には、IAM（Identity and Access Management）の認証情報、サービスアカウントキー、GitHubの個人アクセストークン（PAT）、有効なセッショントークンなどが含まれる。また、外部からアクセスできる状態で放置されたOllamaのエンドポイントに対し、/api/createを呼び出して攻撃者自身のモデルを登録しようとする事例も報告されている。

UNC6993は2026年半ば、設定に不備のあるサービスアカウントキーを悪用してクラウドインスタンスに侵入し、そこを足がかりにLLM APIへのアクセス権を拡大した。さらに、LLM利用者向けグループへの参加ポータルを装ったページを用意し、正規のLLMサービスで有効なアクセストークンを含むJSONデータを利用者自身に貼り付けさせた。こうして取得したトークンを使えば、パスワードや多要素認証（MFA）を改めて入力することなく、認証済みのセッションを悪用できる。MFAを導入していても、認証後のトークンが盗まれれば不正アクセスを許す可能性があることを示す事例だ。

攻撃者は、盗んだAPIキーが現在も有効かどうかを確認する際にも、検知を避ける工夫をしていた。ある攻撃グループは、公開されたGitHubリポジトリから企業のLLM APIキーを収集し、出力を1トークンに制限するmax_tokens=1を指定したリクエストを自動送信していたという。わずか1トークンの出力を要求するだけでも、APIが正常に応答するかどうかは確認できる。一方、1回当たりのリソース消費量は非常に小さいため、大量の処理や急激な通信量の増加を検知する仕組みでは見逃されやすい。

Mandiantによれば、この手法は被害組織のEDR（エンドポイントでの脅威検知・対応）やSIEM（セキュリティ情報・イベント管理）の利用量に基づく異常検知アラートに捕捉されなかった。攻撃者は大量の推論を実行する前に、低負荷のリクエストを使って利用可能な認証情報を選別していたことになる。従来のように異常なアクセス量だけを監視する方法では、こうした準備段階を捉えられない可能性がある。

さらに深刻なのは、侵入時点でLLMサービスが有効化されていなくても、攻撃を防げるとは限らないことだ。Mandiantが調査した複数の事案では、攻撃者が侵入した時点ではLLMサービスは無効だった。しかし、盗んだ認証情報に十分な権限があれば、AWS BedrockやGemini APIなどのサービス設定を変更し、新たに有効化できる。Mandiantは、一度サービスが有効化されると、攻撃者が数分から数時間で巨額の請求を発生させる可能性があると説明している。

実際、UNC6993は侵害したクラウドプロジェクト内で追加のAPIキーを生成し、関連サービスを有効化しようとして、短期間で10万ドルを超える請求を発生させた。別の攻撃者は被害アカウントを従量課金契約に登録し、高額な基盤モデルを選択して大量の推論を実行した。レート制限を回避するため、短期間だけ使うサービスアカウントを繰り返し作成・削除する「burn and rotate」という手法も確認されている。この攻撃者はクラウド事業者の請求画面を調べ、不正利用による費用の発生状況まで監視していたという。

攻撃者はLLMの推論サービスだけでなく、クラウドの計算資源も悪用していた。別の事案では、Manusのエージェントフレームワークを利用するコンテナ型バックドアを侵害環境に配置し、外部のLLMを使って指示を解釈しながらコマンドを実行する仕組みを構築していた。さらに、高性能GPUを搭載したインスタンスを複数のリージョンで起動しようとし、必要なクォータの引き上げも要求していた。こうした事例は、LLMJackingが単なるAPIの不正利用にとどまらず、クラウド環境全体のリソース窃取へ発展していることを示している。

盗んだLLMの利用権を転売する「LLM Mixer」

MandiantとGTIGは、LLMJackingを巡る犯罪活動で分業が進んでいることも明らかにした。初期侵入を担当する攻撃者が企業の認証情報やAPIキーを盗み、別の攻撃者が不正に取得したLLMへのアクセスを集約して転売するという構造だ。GTIGは、こうした不正利用の中継基盤を「LLM Mixer」と呼んでいる。ある調査では、2つの異なる攻撃グループが連携し、企業のLLM基盤への侵入から収益化までを分担していたという。

LLM Mixerは、盗んだAPIキーやクラウド認証情報を複数集約し、利用者からのリクエストを中継するゲートウェイとして機能する。攻撃者はオープンソースのAPIゲートウェイや独自の中継基盤を使い、利用量を計測しながら複数のアカウントにリクエストを振り分ける。これにより、サービスを購入した第三者は通常のLLM APIと同じようにモデルを利用できる一方、その処理料金は認証情報を盗まれた企業に請求される。利用者から見えるAPIの提供元と、実際に費用を負担する組織が切り離される仕組みだ。

UNC6993は、複数のモデルへのアクセスをまとめるオープンソースのゲートウェイ「new-api」や、コマンドラインツールを一般的なLLM API形式に変換する「gcli2api」を利用していた。GTIGは、盗んだ認証情報を集約し、複数アカウント間でリクエストを分散させるために、これらのツールが使われた可能性が高いと分析している。また、UNC6993は地下の販売サイトを通じて、こうした中継基盤へのアクセスを販売しているとみられる。

攻撃者間の分業は、LiteLLMを悪用した事例でも確認された。LiteLLMは複数のLLMへのリクエストを一元的に中継するソフトウェアで、利用者ごとにVirtual Keyと呼ばれるAPIキーを発行できる。Mandiantによると、ある攻撃グループが侵入先から取得した有効なVirtual Keyを別のグループに渡し、後続の攻撃者が被害組織のLiteLLMゲートウェイを攻撃した。攻撃者は権限昇格の脆弱性を悪用し、通常のVirtual Keyから管理者権限を持つPROXY_ADMINの資格情報を取得したという。

ただし、この事例には脆弱性識別番号の不一致がある。Mandiantは/key/regenerateエンドポイントにおけるユーザーIDの再バインドに関する脆弱性を「CVE-2026-40217」としているが、GitHub Advisory Databaseに登録された同番号の脆弱性は、/guardrails/test_custom_codeにおけるサンドボックス脱出と任意コード実行の問題を指している。一方、CVE-2026-47101は、LiteLLMがAPIキー生成時にallowed_routesの権限を適切に検証しないため、一般ユーザーが管理者専用の操作にアクセスできる脆弱性として登録されている。

CVE-2026-47101の説明は管理者権限への昇格という点ではMandiantの報告と共通するものの、問題となるエンドポイントや攻撃の仕組みは一致しない。2026年11月3日時点の公開情報では、Mandiantが報告した攻撃に実際に対応するCVE番号を特定できない。このため、報告に記載されたCVE-2026-40217を、そのまま/key/regenerateの権限昇格の識別番号として扱うことは避ける必要がある。

LLM Mixerによる収益化の実態を示す事例が、トークン中継サービス「Jet Night（jet-night.com）」だ。Mandiantによれば、ある攻撃者は8時間未満で50万回を超えるLLM APIリクエストを実行し、盗んだ第三者のAPIキーを使ってJet Nightのサービスを動かしていた。この不正利用によって、被害組織には100万ドル近いトークン利用料金が発生したという。利用者が支払う料金と、実際の処理費用を負担する組織が異なることで、攻撃者は高額なAIサービスを低価格で転売できる。

Jet Nightは、最先端モデルへのアクセスをうたい、トークンを使い放題とするプランを月額約60ドルで販売していた。GTIGによれば、同等の一般消費者向けサービスの料金は通常月額100〜250ドルであり、Jet Nightの価格はこれを大きく下回っていた。約60ドルという料金を基準に計算すると、月額100ドルのサービスより約40%、250ドルのサービスより約76%安いことになる。ただし、これはGTIGが示した概算価格帯から求めた差であり、比較対象の具体的なサービス名は公表されていない。

GTIGは、この大幅な価格差から、Jet Nightが盗んだAPIキーを利用することで利益を確保していると分析している。また、同サービスがTelegram上で繰り返し告知していた障害についても、被害組織が不正利用に気付き、盗まれたAPIキーを無効化したことが原因である可能性が高いとみている。攻撃者にとって、盗んだキーの継続的な確保はサービスの運営を左右する要素となっている。

数時間で膨らむ不正請求への対策、重要なのはサービス有効化の検知

Mandiantは防御策として、LLMのアカウントやサービス設定の変更を監視し、許可されていないサービスの有効化を重大なセキュリティイベントとして扱うよう推奨している。侵害時点でLLMサービスが無効だった組織でも被害が発生しているため、現在使っていないサービスだからといって安全とは限らない。攻撃者がサービスを有効化してから大量の推論を実行するまでの時間が短いことを考えると、異常な請求額が確認されてから対応するだけでは不十分だ。

Google Cloudを利用する企業にとっては、監査ログの設定も重要になる。Mandiantによると、Gemini Enterprise Agent Platform（aiplatform.googleapis.com）の推論操作はData Access監査ログに記録されるが、このログは大量のデータ生成と取り込みコストを考慮して既定では無効になっている。そのため、推論操作を監視するには、IAMの監査ポリシーを手動で設定する必要がある。Mandiantは、同プラットフォームのサービスを有効化するgoogle.api.serviceusage.v1.ServiceUsage.EnableServiceの実行を検知し、アラートを発することも推奨している。

同様の監視はAWSやAzureでも必要だ。MandiantはAWSについて、CloudTrailを使ってAmazon BedrockのConverseやInvokeModelなどのAPI操作を監視するよう勧めている。Azureについても、モデルの推論エンドポイントへの大量アクセスに加え、新しいデプロイメントの作成や診断ログの設定変更などを監視対象に挙げた。重要なのは、LLMへのアクセス量だけでなく、利用可能なサービスや認証情報が変更された段階から不正利用を検知することだ。

認証情報の保護については、APIキーやシークレットの一元管理、定期的なローテーション、ソースコードに含まれる認証情報の自動スキャンなどが推奨されている。また、利用者やサービスアカウントには必要最小限の権限だけを与え、使う予定のないLLMサービスへのアクセス権を付与しないことも重要だ。認証情報が流出した場合でも、攻撃者が新しいサービスを有効化したり、高額なモデルを呼び出したりできる範囲を制限することが被害の抑制につながる。

検知の対象には、大量の推論リクエストだけでなく、max_tokens=1を指定した少量のAPI呼び出しも含める必要がある。こうしたリクエストは認証情報の有効性を調べるために使われるため、通常の利用量に基づくアラートだけでは発見が難しい。また、APIキーごとにアクセスできるモデルや利用環境を限定し、モデル別のクォータや支出上限を設定することで、不正利用時の費用を抑えられる可能性がある。ただし、予算アラートが必ずしも利用の自動停止を意味するわけではないため、実際にどの条件でリクエストが遮断されるかをクラウド事業者ごとに確認する必要がある。

LLMの中継基盤に対する脆弱性管理も欠かせない。LiteLLMのようなAPIゲートウェイは、複数モデルへのアクセス権や認証情報を集中的に扱うため、侵害されると被害が広がりやすい。Mandiantは、こうしたゲートウェイも通常のアプリケーションと同様に脆弱性管理の対象とし、権限昇格や認証回避につながる問題へのパッチ適用を徹底するよう求めている。認証情報の保護、権限の制限、サービス設定の監視、API利用量の制御を組み合わせることが、被害を早期に抑えるための基本となる。

GTIGは今後、攻撃者が従来のクリプトジャッキングよりもLLMJackingを優先するようになると予測している。その背景にあるのは、不正取得したLLMへのアクセスを短期間で収益化できることと、LLM Mixerによる転売市場が形成されつつあることだ。GTIGのチーフアナリストであるJohn HultquistもThe Registerに対し、こうしたリソースへのアクセスを厳格に管理することは、企業を巨額の請求から守るだけでなく、安価な自律型攻撃が広範囲に拡大することを防ぐうえでも重要だと指摘している。

今回のMandiantの報告は、1日10万ドル超という金額が個別事案で観測された水準にすぎず、一般的な被害額を表していないという点で慎重に読む必要がある。しかし、侵害時点では無効だったLLMサービスが攻撃者によって有効化され、数分から数時間で巨額の請求を発生させ得ることは、企業のクラウド管理にとって重大なリスクだ。LLMサービスの有効化を検知する仕組みと、APIの利用権限や支出を制限する設定を、不正利用が始まる前から整えておく必要がある。