LLMJacking、盗まれた認証情報で生成AIの請求が1日10万ドル超

認証情報を盗まれた組織に、生成AIの請求が1日10万ドル超

Googleの脅威分析チームGTIG（Google Threat Intelligence Group）とセキュリティ企業のMandiantは2026年11月2日、盗んだ認証情報で企業の生成AIへのアクセスを乗っ取る攻撃「LLMJacking」の分析を公開しました。狙われたのは、クラウドにログインするためのパスワードやAPIキーです。

他人のサーバーで暗号資産を採掘するクリプトジャッキングは、計算資源を少しずつ消費する攻撃でした。クリプトジャッキングと違い、生成AIの不正利用は数時間で請求が跳ね上がり、利用していないサービスでも攻撃者が有効化して請求を発生させます。

累計100万ドルの請求に達した組織も

Mandiantは2026年、LLMJackingのインシデントに複数対応しました。1件の不正利用事案で、1日分の請求が10万ドル（約1,583万円）を超えたこともあります。

被害は北米・南米・アジア太平洋の金融や小売、運輸などの組織に及び、アクセスを取り消すまで請求が積み上がった組織もあります。 その累計は、100万ドル（約1億5,833万円）に達しました。

被害を受けた組織にはテクノロジー企業も含まれ、特定業界に限った攻撃ではありません。

未導入の生成AIサービスも攻撃者が無断で有効にする

Mandiantが調べた事案のいくつかでは、侵入された時点で生成AIのサービスが有効になっていませんでした。攻撃者は、盗んだアクセスキーの権限でAmazon BedrockやGeminiのAPIを有効にしてから、呼び出しを始めています。

生成AIを利用していない企業でも、クラウドの鍵を盗まれればBedrockやGemini APIを勝手に有効化され、請求の対象になります。 有効にされた後は、数分から数時間で多額の請求が出ます。

有効にするのに必要だったのは、盗んだアクセスキーの権限だけでした。

認証情報の入手先は公開リポジトリと偽のポータル

入口の多くは、GitHubに置かれたキーやサービスアカウントの鍵など、露出したクラウドの認証情報でした。 サービスアカウントとは、人ではなくプログラムがクラウドを操作するためのアカウントのことで、その鍵が盗まれると攻撃者はプログラムになりすませます。

GTIGは、IAM（クラウドの権限管理）の認証情報やGitHubの個人用アクセストークン、ログイン中のセッショントークンも侵入口として報告しました。盗み方は、キーを拾い集める、ユーザーをだましてトークンを差し出させる、ソフトウェアの脆弱性を突く、の3通りです。

GitHubで集めたAPIキーが有効か、最小の呼び出しで確認

ある攻撃者は、誰でも見られるGitHubのリポジトリから、企業が置いたままにしていた生成AIのAPIキーを集めていました。集めたキーがまだ使えるかは、自動のスクリプトで1本ずつ確かめています。

攻撃者は1トークンだけを返させる呼び出しでキーが有効かを確かめ、利用量で鳴る検知を避けていました。 呼び出しの設定はmax_tokens=1で、生成AIはほぼ何も返しません。請求額にも呼び出し回数のグラフにもほとんど表れないため、被害組織の監視をすり抜けました。

偽のポータルでトークンを貼らせ、多要素認証をすり抜ける

GTIGがUNC6993と呼ぶ攻撃グループは2026年半ば、設定に不備のあったサービスアカウントの鍵からクラウドのインスタンスへ侵入しました。さらに、生成AIのユーザー仲間に加わるための申し込み画面を装った偽のポータルも用意しています。

偽のポータルは、本物の生成AIサービスを開かせ、そこに出るログイン中のアクセストークンを含むデータを貼り付けさせる仕組みでした。多要素認証は、パスワードに加えてスマートフォンに届くコードなどで本人を確かめる仕組みです。

UNC6993はログイン中のトークンを貼らせることでパスワードも多要素認証も通らずに入り込み、高額な請求を発生させました。 UNC6993は被害者のクラウドで追加のAPIキーを作り、関連するサービスを有効にしようとして、請求額を10万ドル（約1,583万円）超まで膨らませています。

LiteLLMの脆弱性で管理者権限を奪った例も

ある事案では、最初に侵入した攻撃者から仮想キーを受け取った別のグループが、被害組織のLiteLLMを狙いました。LiteLLMは、いくつもの生成AIサービスより手前に置く、ゲートウェイと呼ばれる中継のソフトウェアです。

生成AIへの接続をまとめるLiteLLMでは、CVE-2026-40217を突かれて通常のキーが管理者権限へ引き上げられました。 欠陥があったのは、キーを作り直す機能（/key/regenerate）です。通常の仮想キーがPROXY_ADMINという管理者権限に変わり、攻撃者が環境を長く支配できる状態が生まれています。

ゲートウェイを早く更新することも、GTIGの対策一覧に入っています。LiteLLMでは10月にも、配布された1.107.0に認証情報を盗むマルウェアが混入していました（LiteLLM 1.107.0に混入した認証情報を盗むマルウェアと対処法）。

攻撃者は盗んだキーで中継サービスを運営し、月約60ドルで販売

盗んだキーで生成AIを呼び出すのは、攻撃者自身だけではありません。GTIGによると、攻撃者はnew-apiやgcli2apiといったオープンソースの中継ソフトで盗んだキーをまとめ、利用量を計りながら呼び出しの出どころを隠していました。盗んだキーを束ねて転売する不正な中継の仕組みを、GTIGは「LLM Mixer」と呼んでいます。

盗んだキーは中継サービスにまとめられて格安の定額プランとして売られ、利用料はキーを盗まれた組織に請求されます。 買い手は、地下の掲示板などで申し込んだユーザーです。

また、鍵を盗む役と売る役は別のグループに分かれつつあります。

中継のJet Nightは8時間足らずで50万回超の呼び出し

ある攻撃者は、盗んだ第三者のAPIキーで中継サービス「jet-night.com」を運営していました。8時間足らずのあいだに、生成AIのAPIを50万回を超えて呼び出しています。

盗んだキーで運営された中継サービスは、人の手では出せない量の呼び出しを短時間に重ね、1つの被害組織に請求を集中させました。 Jet Nightを通じて被害組織が負わされたトークンの費用は、100万ドル（約1億5,833万円）近くです。

100万ドル近い費用は誰が負うのか

Jet Nightは、最先端モデルも使えると宣伝した使い放題のプランを月約60ドル（約9,500円）で売っていました。同じ水準の一般向けサービスなら、月100ドル（約1万5,833円）から250ドル（約3万9,583円）かかります。

使い放題の原価は、売り手ではなくキーを盗まれた組織が払っています。 GTIGの見立てでは、この安さで利益が出るのは盗んだキーに頼っているからです。売り手は原価を払っていないので、いくら安く売っても損をしません。

生成AIのAPIキーを持つ開発者と、クラウド管理者の対策

今回の被害は、キーを書いたままコードを公開したことから始まり、担当者がクラウドの権限や請求を確認していなかったことで膨らみました。日本でも、経済産業省とIPA（情報処理推進機構）が中小企業126社を調べた事例集で、APIキーやクラウドの認証情報が外部に流出していた事業者が8社見つかっています。

キーを置く場所と権限を開発者が限定し、管理者が請求と有効化を監視すれば、盗まれても使い込まれる前に遮断できます。 GTIGの推奨とIPAの事例集をもとに、開発者とクラウド管理者のそれぞれが取り組む対策を3つずつ紹介します。

開発者はキーをコードに書かず、権限を限定

キーを公開する場所に置かず、呼び出すモデルと環境だけに限定しておけば、流出しても悪用できる範囲が小さくなります。 生成AIのAPIキーを発行してアプリに組み込む開発者が取り組む対策は、次の3つです。

キーはコードに置かず、秘密情報の保管サービスで管理

攻撃者は公開リポジトリからキーを自動で集めるので、キーは専用の保管サービスに置き、コードからは参照だけにしましょう。保管先の例は、AWS Secrets Managerのような秘密情報を安全に保管するサービスです。リポジトリに紛れ込んだキーを自動で見つけるスキャンを入れておけば、うっかり書いたキーも公開される前に気付けます。

キーは呼び出すモデルと環境に限定して発行

キーごとに使えるモデルと環境、利用上限を設定しておけば、盗まれたキーで高額モデルを使われにくくなります。1本のキーで何でも呼び出せる状態にせず、開発用と本番用、アプリごとにキーを分けて発行しましょう。新しいキーに最低限の権限だけを与えておけば、1本が盗まれても被害はそのキーで呼べる範囲までです。

流出が疑われるキーはすぐ無効化して再発行

削除だけでは盗まれたキーは有効なまま残るので、無効化して新しいキーに切り替え、定期的に変更します。コードからキーの行を消しても、すでに誰かが写し取ったキーは使える状態のままです。一方で、キーの入れ替えを自動にしておけば、気付かないうちに流出したキーも一定の期間で使えなくなります。

クラウド管理者は生成AIの有効化と請求を監視

生成AIを利用しない組織も含め、権限・上限・監視の3つを置けば、攻撃者による有効化と使い込みを早い段階で遮断できます。 クラウドのアカウントと請求を管理する担当者が取り組む対策も、3つです。

利用予定のない生成AIサービスには、アクセス権を付与しない

生成AIを利用しないプロジェクトでは、生成AIサービスへのアクセス権を最初から与えなければ、鍵を盗まれても有効化されません。ユーザーとサービスアカウントには役割に必要な権限だけを持たせ、明示的に必要としない権限は生成AIサービスも含めて拒否しておきます。Mandiantが調べた事案では、生成AIを有効にしていなかった組織でも攻撃者に有効化されました。

モデルごとの呼び出し回数と支出に上限を設定

設定した額を超えた呼び出しはそこで拒否されるので、1日で10万ドル（約1,583万円）を超えるような請求は膨らむ前に頭打ちになります。モデルごとに呼び出し回数の上限を細かく設け、支出の上限で予算を超えないようにしましょう。被害は数時間で膨らむため、月末に届く請求書で気付くのでは間に合いません。

生成AIの有効化や呼び出しログの設定変更を検知したら調査

生成AIサービスが無断で有効にされたり、呼び出し記録の設定が消されたりしていれば、攻撃が始まっている恐れがあります。無断の有効化は、使い込みが始まる直前に出る動きです。記録設定を消したり書き換えたりする呼び出しは、痕跡を隠すために出てきます。

この2つを見逃さないよう、利用ログで不審なAPIの呼び出しが無いかもあわせて確かめましょう。