GoogleのLLMジャッキング攻撃、AIアクセスを盗品化
Googleによると、プレミアムモデルのコストがアクセスをめぐる地下市場の拡大を招く中、犯罪者はAIアカウントやクラウド認証情報を盗んでいる。
2026年9月のこの警告は、AIセキュリティの焦点を変えるものだ。企業は長年、攻撃者がモデル自体を操作または侵害できるかを議論してきた。Googleが現在指摘する、より差し迫った問題は、攻撃者がそうしたモデルを取り巻くアカウント、APIキー、設定ファイル、クラウドリソースを盗んでいることだ。
その結果生じるGoogleのLLMジャッキング攻撃は、急速に拡大するAIアクセスと、通常のソフトウェアサービス向けに設計されたアイデンティティ制御を対立させる。LLMジャッキングとは、侵害された認証情報を使って、他者が支払ったモデルアクセスやコンピューティング能力を消費する行為を指す。この手法は2024年に初めて公に確認されたが、Googleの証拠は、より広範な犯罪経済へと入り込んだことを示唆している。
GoogleのLLMジャッキング攻撃、盗まれたAPIキーを超えて拡大
Googleの中心的な結論は、AIアクセスが盗まれ、取引され、共有され、再販されるほど価値のあるものになったということだ。
9月の脅威評価は、Google Threat Intelligence Group（GTIG）によるものだ。その根拠は、Mandiantのインシデント対応業務、脅威アクターの追跡、地下フォーラム、Googleのサービス全体で観測された活動に基づいている。
GTIGは、2026年中にAI関連アカウントを求める購入者が増加したと確認した。研究者は、それらを宣伝する販売者の増加も確認している。需要はClaudeとGeminiの認証情報に集中したとされ、自律型コーディング環境向けのアカウントも関心を集めた。
Googleは盗まれたアカウントの総数を公表していない。一方で、アカウント1件当たりの地下市場における平均価格が2026年中に2倍以上になったと報告している。この点が重要なのは、単発的な認証情報窃取ではなく、市場の反応を示しているためだ。
攻撃者がプレミアムAIアクセスを求める理由はいくつかある。有料アカウントは、使い捨ての無料アカウントよりも高い利用上限、強力なモデル、少ない中断を提供する。API認証情報は、消費者向けチャットインターフェースでは維持しにくい自動化ワークロードにも利用できる。
クラウド認証情報には、さらに大きな価値がある。侵害されたアイデンティティは、ホスト型モデル、デプロイ権限、ストレージ、高価なコンピューティングリソースを露出させる可能性がある。攻撃者はその後、被害者に利用料と運用上の影響を負わせたまま、推論ワークロードを実行できる。
Googleはこの行動を、犯罪者が許可なく有料モデルサービスやクラウドインフラを乗っ取るLLMジャッキングと結び付けている。当面の目的は無料アクセスかもしれないが、同じインフラはフィッシング、脆弱性調査、マルウェア開発、再販にも利用できる。
これは、誰かが公開リポジトリで漏えいしたAPIキーを見つけることよりも広範な問題だ。Googleは、盗まれたアカウント、自動登録、アカウントプール、APIアグリゲーション、プロキシサービス、検知回避ツールを含むエコシステムを観測した。
アカウントプーリングでは、複数のアイデンティティやAPIキーを1つのサービスの背後で組み合わせる。この仕組みは利用を分散し、個別の停止措置の影響を減らし、活動の帰属を困難にできる。アグリゲーターは、単一の互換インターフェースを通じて複数のプロバイダーを提供することもできる。
Googleは以前、Gemini、Claude、OpenAIのアカウントを統合するサービスを利用するアクターを記録している。5月の脅威レポートでは、自動登録、認証、ルーティング、クォータ監視、ブラウザーフィンガープリントのマスキングのためのツールを説明している。
こうしたツールの一部には正当な用途がある。開発者は可用性の向上や内部ワークロードの制御のため、モデル間でリクエストをルーティングすることが多い。運用者が盗難アカウントや不正に作成されたアカウントでこうしたシステムを満たす場合に、セキュリティ上の懸念が生じる。
この区別は、よくある分析上の誤りを防ぐ。プロキシソフトウェア自体は犯罪行為の証拠ではない。しかし、盗まれた認証情報、回避的な登録、隠蔽されたトラフィック、無許可の再販が組み合わさると、識別可能な悪用の連鎖が生まれる。
Googleは、攻撃者がAIコーディングアシスタントで使用されるローカル設定ストアも標的にしていることを確認した。2026年5月、ACRSTEALERマルウェアファミリーに関連する管理者らは、Clineのsecrets.jsonおよびContinue AIのconfig.yamlに対するファイル収集ルールを発行した。
これらのファイルには、平文のAPIキーやカスタムのモデルルーティングエンドポイントが含まれる場合がある。盗まれたブラウザーセッションは1人のユーザーアカウントを露出させるかもしれない一方、開発者設定は組織のクォータやインフラへの経路を開く可能性がある。
そのため、AIアカウントの実際の境界を定義することは難しくなっている。それには、アイデンティティ、セッショントークン、APIシークレット、コマンドライン設定、クラウドロール、複数の外部モデルを呼び出す権限が含まれ得る。
セキュリティチームにとって、この拡張された境界は記事の中心的な緊張を生む。組織は日々の業務全体にモデルアクセスを組み込みたいが、利便性の高い統合が増えるたびに、価値ある認証情報が漏えいする場所も増える。
AIアカウント窃取が今、すべてのクラウド顧客に圧力をかける理由
圧力が最も強くかかるのは、モデルアクセスがセキュリティ上の所有責任より速く広がっている、AIを最も急速に導入する組織だ。
従来の盗まれたソフトウェアアカウントは通常、攻撃者にデータやアプリケーション機能へのアクセスを与える。盗まれたAIアカウントは、従量課金型のモデル利用、クラウドコンピューティング、自律型ツール、内部ナレッジへの接続を追加し得る。
この組み合わせは、潜在的な被害を変える。侵害された認証情報は、請求額を発生させ、独自情報を露出させ、別の標的への攻撃インフラを提供する可能性がある。被害者が最初に目にするのは、一般的な侵入の兆候ではなく、異常な利用状況だけかもしれない。
開発者は特に露出しやすい。AIコーディングアシスタントは、ソースリポジトリ、ターミナル、パッケージマネージャー、デプロイメントツールのそばで動作することが多い。その設定ファイルは、単一のチャット履歴よりはるかに広い影響範囲を持つ認証情報を明らかにする可能性がある。
エージェント型AIの利用拡大は、さらにリスクを高める。エージェント型システムでは、モデルが手順を計画し、人間の入力を抑えながらツールを操作できる。その認証情報は、ファイルアクセス、コード実行、ブラウジング、外部サービスとの通信を許可している場合がある。
Googleは、脅威アクターも攻撃的なワークフローのためにマルチエージェントフレームワークを採用していると報告した。こうしたシステムは、スキャンを調整し、エラーを解決し、人間の判断による中断を減らしながら認証情報の収集を管理できる。
2026年第2四半期のある事例は、この変化を印象的な時間軸に凝縮している。GTIGは、攻撃者がクラウドリソースを侵害した後、6時間未満でエージェント対応の大規模認証情報収集キャンペーンを計画、構築、実行したことを観測した。
この発見は、すべての犯罪グループが現在、自律型攻撃システムを運用していることを意味しない。自動化により、初期アクセスから拡張可能な悪用までの期間を短縮できることを示している。
防御側は従来、それらの段階の間にある時間に依存してきた。攻撃者がアクセスを拡大し、永続性を確立し、機密システムへ到達する前に、アラートが調査を引き起こす場合がある。6時間の構築・実行サイクルでは、手作業によるトリアージの余地ははるかに少ない。
盗まれたAI認証情報の価値は、直接的なクォータを超える。設定ファイルはプライベートエンドポイントを露出させる可能性があり、関連するクラウドアイデンティティはログ、データストア、接続済みアプリケーションを明らかにし得る。
したがって組織は、Googleが指摘するAIアカウント窃取を、AIガバナンスだけの問題ではなく、アイデンティティセキュリティの問題として扱うべきだ。制御点は、多くの場合、モデルの安全層ではなく、認証情報とそれを取り巻く権限にある。
長期間有効なシークレットは、最も明白なリスクを生む。従業員がノートPCを閉じたりWebパスワードを変更したりした後も、利用可能な状態が続く場合がある。攻撃者はそれらをひそかに試し、プロキシ経由でトラフィックをルーティングし、利用可能なサービスを確認した後に利用量を増やす可能性がある。
共有の開発者アカウントも別の弱点を生む。複数の人員または自動化システムが1つのアイデンティティを使うと、異常な活動の帰属は難しくなる。アクセスの取り消しが正当な業務を妨げる可能性もあり、封じ込めを遅らせることがある。
クラウド顧客は第2の問題に直面する。インフラレベルでは、消費は正常に見える。有効なキーが有効なモデルリクエストを送っても、マルウェアや禁止されたネットワークトラフィックを検知するために設計された制御は作動しない可能性がある。
代わりにチームには行動シグナルが必要になる。有用な指標には、新しい地理的発信元、予期しないモデルの有効化、急激なクォータ変更、見慣れないAPIゲートウェイ、異常なリクエストタイミング、認証情報の所有者と整合しない利用状況などが含まれる。
モデルプロバイダーにも圧力がかかる。通常の企業アーキテクチャを阻害せずに、正当なアグリゲーションと犯罪的なプーリングを区別しなければならない。また、急速に変化する製品全体で、アカウント、ネットワーク、決済、デバイス、利用状況のシグナルを結び付ける必要もある。
求められる対応は、AIアクセスを中心に据えたアイデンティティの再設計だ。組織には、短期間の認証情報、より限定的な権限、分離されたサービスアイデンティティ、利用上限、迅速な無効化、想定される行動に結び付いた監視が必要になる。
こうした対策が聞き慣れたものであるのは、根本的な失敗も馴染み深いものだからだ。変わったのは、収益化される資産と、盗まれたアクセスが追加の攻撃活動を支援できるまでの速さである。
真のトレードオフはAIの利便性と認証情報管理の間にある
AI導入はユーザーの摩擦を減らすが、その同じ利便性が、ツール、プラグイン、エージェント、ローカルファイルの中に認証情報を隠す可能性がある。
ほとんどの組織は、中央管理された単一のAIシステムを導入しているわけではない。従業員は、ブラウザーアプリケーション、コーディングアシスタント、コマンドラインクライアント、モデルゲートウェイ、クラウドプラットフォーム、拡張機能、カスタム自動化を利用している。
アクセス経路ごとにアイデンティティの扱い方は異なる。あるものはセッションクッキーを使い、別のものはAPIキーを使い、さらに別のものはユーザー環境から継承したクラウドロールを使う場合がある。セキュリティチームは、この3種類すべてのインベントリを把握するのに苦労する可能性がある。
AIコーディングツールは、このトレードオフを特に明確にする。開発者は迅速なセットアップと中断のないモデルアクセスを期待する。設定ファイルにキーを保存するのは便利だが、すでにローカルシステムを探索するマルウェアは、そのファイルを収集対象リストに追加できる。
Googleの調査結果は、インフォスティーラーもそれに応じて適応していることを示している。LUMMAC.V2、STEALC.V2、VIDAR、ACRSTEALERの運用者は、ブラウザープロファイルの窃取を超え、AI開発者設定に関心を示した。
インフォスティーラーは、感染したデバイスから価値ある情報を収集するよう設計されたマルウェアだ。一般に、パスワード、Cookie、ウォレット、アプリケーションデータを標的とする。AI設定ファイルの追加は、既存のビジネスモデルを論理的に拡張するものだ。
この仕組みは、最先端モデルに対する劇的な突破がなくても問題が拡大し得る理由の説明に役立つ。攻撃者は、料金を支払うユーザーになりすませるなら、モデルの中核的なセキュリティアーキテクチャを打ち破る必要はない。
Googleはこの区別を繰り返し示している。2月の調査結果では、攻撃者がLLMサービスを大規模に悪用するにはAPIキーとリソースが必要だったと述べている。この要件は、大きなAI能力を持つ組織を乗っ取る直接的な動機を生む。
エージェントに広範なツール権限が与えられると、対立はいっそう先鋭化する。有用な支援を提供するために、エージェントはリポジトリ、ドキュメント、課題管理ツール、デプロイシステムへのアクセスを必要とする場合がある。コネクタを追加するたびに、有用性と潜在的な露出の両方が増す。
盗まれたAI認証情報を使っても、接続先のすべての権限が自動的に与えられるわけではない。結果は、組織が認証と認可をどのように設計しているかに左右される。ただし、IDが十分に分離されていなければ、盗まれた一つのシークレットが複数の侵入経路になり得る。
シークレットをプロンプト、ソースファイル、ノートブック、あるいは広く読み取り可能な設定ディレクトリに置くべきではない。組織は管理されたシークレット管理システムに保管し、必要とするワークロードにのみ発行すべきだ。
この推奨は言うのは簡単だが、徹底は難しい。開発者は中央プラットフォームの外で一時的な実験を作ることがある。チームは締め切りに間に合わせるため認証情報を共有することがあり、放置されたプロトタイプが何か月も有効なキーを保持している場合もある。
AIゲートウェイは、認証とポリシーを集中管理することで拡散を抑えられる。一方で、高価値の標的にもなり得る。一つのゲートウェイが多くのプロバイダーと広範な利用枠にアクセスできる場合、それが侵害されれば攻撃者に集中的なリソースプールを与えることになる。
答えはゲートウェイを避けることではない。各ゲートウェイIDが呼び出せる対象を制限し、ユーザー単位の帰属を確立し、侵害された一つのコンポーネントが無関係なサービスまで起動できないようにすることだ。
組織はモデルへのアクセスと管理者アクセスも分離する必要がある。推論リクエストを送るサービスに、請求の変更、新しいモデルの有効化、IDの作成、無関係なクラウドシークレットの取得といった権限まで自動的に与えるべきではない。
対話型アカウントでは強力な認証が重要だが、多要素認証ですべての経路を解決できるわけではない。APIキーやサービスIDは対話型チャレンジなしで動作することが多く、盗まれたセッション情報は新規ログインを回避できる場合もある。
短い認証情報の有効期間は、その露出を減らす。静的キーを、実行中アプリケーションの検証済みコンテキストに基づく一時トークンへ置き換えるワークロードIDシステムも有効だ。
利用制御も別の防御層となる。IDごとの予算、レート制限、許可モデルリスト、新しいリージョンからの利用に対するアラートは、攻撃者が使える時間とリソースを減らせる。
ログにも調査に必要な十分なコンテキストを残さなければならない。機密性の高いプロンプト内容を不必要に公開することなく、モデルリクエストをユーザー、サービス、環境、承認済みの目的まで追跡できるようにすべきだ。
ナレッジワーカーにとって、この教訓はより身近なものだ。ブラウザ拡張機能、ダウンロードしたコーディング支援ツール、非公式クライアントは、ユーザーと複数の有料AIサービスの間に入り込むことがある。一つをインストールすることは、認証情報をどのように保存・送信するかについての信頼判断を伴う。
従業員は、未承認のツールに組織のAPIキーを貼り付けるべきではない。予期しないログインアラート、モデル利用通知、急激な利用枠の消費も、通常の請求エラーではなく、セキュリティインシデントの可能性として報告すべきだ。
利便性と統制のトレードオフをなくすことはできない。AIツールは、より多くの情報にアクセスし、より多くの操作を行うことで有用になる。防御可能なアプローチは、各接続を可視化し、制限し、帰属を明確にし、容易に無効化できるようにすることだ。
Googleの警告はLLMジャッキングの全容を測るものではない
証拠は現実に存在し成熟しつつある脅威を示しているが、LLMジャッキングによる損失を被った組織の数を確立するものではない。
Googleのレポートは、「標的化の増加」や「侵入件数の増加」といった方向性を示す表現を用いている。完全な発生率推計ではなく、事例、観測された戦術、マーケットプレイスの動向、インシデント対応事例を提示している。
この限界は重要だ。脅威インテリジェンスは、収集する研究者に見えている環境、顧客、プラットフォーム、地下空間を反映する。その視野の外にある活動は計上されない可能性があり、厳重に監視されている攻撃者はより目立って見える場合がある。
地下市場における平均アカウント価格が倍増したという報告は参考になるが、不完全でもある。Googleは、その市場を時系列で厳密に比較するのに必要な基礎サンプル数、価格分布、方法論を公表していない。
価格上昇は、需要の拡大、供給の制限、アカウント品質の向上、あるいは追跡対象マーケットプレイスの変化を示す可能性がある。それだけでアカウント窃取の成功件数が倍増したことを証明するものではない。
したがって、「急増」という表現は、世界全体のインシデント調査ではなく、観測された活動の増加を示す証拠として読むべきだ。Googleの最も強い主張は、同社チームが直接観測した内容に関するものである。すなわち、買い手と売り手の増加、標的を絞った設定情報の窃取、無許可ワークロードを支えるクラウド侵害だ。
用語上の問題もある。LLMジャッキングは、盗まれた一つのAPIキーの利用から企業クラウド環境の乗っ取りまで、複数の関連行為を指し得る。これらを一つのラベルにまとめると、影響の大きな違いが見えにくくなる。
盗まれたクラウド認証情報に関する初期の公開研究では、LLMジャッキングをホスト型モデルサービスの不正利用として定義していた。その後の報道は、プロキシネットワーク、再販、攻撃的エージェントの開発へと全体像を広げた。
この経緯は有用な比較を提供する。クラウド・クリプトジャッキングも似た経済的論理に従った。攻撃者がコンピューティング能力を盗んだのは、被害者がその請求を支払うためだ。AIワークロードは、侵害されたインフラのもう一つの収益化可能な用途を生み出す。
ただし、LLMジャッキングは消費コストを超えるリスクを生み得る。モデルへのアクセスは、盗まれたコードの分析、地域に合わせた誘導文の生成、調査の自動化、他の犯罪者向けサービスの構築を攻撃者に支援する可能性がある。
Google自身の調査結果にも、もう一つ留保が必要だ。同社は、攻撃者がAIをより高度に利用するようになっていると述べる一方、多くのモデル悪用の試みが安全システムを発動させたか、大幅な能力向上をもたらさなかったとも報告している。
以前の調査では、国家支援を受けたグループがGeminiを調査、コーディング、翻訳、トラブルシューティングに利用していた。Googleは関連資産を無効化し、防御策を更新した。こうした行為者がモデルの中核的な安全対策を突破したとは結論づけていない。
この対比は重要だ。アカウント窃取はアクセスを与えるが、アクセスが無制限の出力や作戦の成功を保証するわけではない。プロバイダーは依然として悪用を検知し、ポリシーを適用し、アカウントを無効化し、モデル保護を更新できる。
犯罪者が盗難アカウントを好むのは、安全対策の執行が依然として機能しているからかもしれない。使い捨てIDのプールは、停止措置を吸収し、リクエストを分散し、より広いパターンを隠すのに役立つ。
この結果として生じる競争は、単に攻撃者とモデルのガードレールの対立ではない。プロバイダーと顧客がアカウントをまたぐ不審な行動を結びつけるより速く、攻撃者がIDをローテーションさせる競争である。
独立した研究も、その根本的な仕組みを裏付けている。Sysdigは2024年にLLMジャッキングを文書化し、その後、より多様な標的と戦術を報告した。ただし、ベンダーの研究は代表性のある世界規模のサンプルではなく、選別されたインシデントに基づくことが多い。
読者は二つの正反対の結論を避けるべきだ。Googleに世界全体の件数がないからといって、この脅威を退けるのは誤りである。同時に、すべてのAIアカウントやクラウド顧客が直ちに侵害に直面していると主張するのも誤りだ。
防御可能な結論はより限定的である。盗まれたAIアクセスには現在、観測可能なマーケットプレイス価値、確立された技術的経路、実証された犯罪利用がある。利用可能な証拠を誇張せずとも、具体的な統制を正当化するには十分だ。
GoogleによるAIアカウント窃取警告の後に注視すべきこと
次の段階を決めるのは、プロバイダーのテレメトリー、インフォスティーラーの標的化、そして攻撃者がアクセスを拡大する前に企業がAI IDを分離できるかどうかだ。
最初のシグナルは、モデルおよびクラウドプロバイダーによる、より詳細な報告だ。Googleは進行方向を示したが、今後のレポートにはインシデント件数、影響を受けた認証情報の種類、悪用期間、より明確なマーケットプレイスの方法論が必要である。
こうした開示は、GoogleのLLMジャッキング攻撃が明確な成長カテゴリーを示すという根拠を強めるだろう。測定可能な拡大が見られなければ、現在の報告は複数の既存の認証情報悪用形態をAI固有のラベルでまとめていることを示唆する。
二つ目のシグナルは、インフォスティーラー運用者の行動だ。GoogleはAIコーディング支援ツールの設定に対する標的型ルールを観測しており、犯罪者が開発者によるモデル認証情報の保管場所を把握していることを示している。
防御側は、より多くのマルウェアファミリーがAIクライアント、エージェントフレームワーク、モデルゲートウェイを収集リストに体系的に追加するかを注視すべきだ。広範な導入は、AIシークレットがブラウザCookieや暗号資産ウォレットと並ぶ標準的な標的になったことを示す。
セキュリティチームは、この変化を内部で探ることができる。ソースコードや従来のパスワードストアに影響が見られない場合でも、AI設定パスに関わるエンドポイント検知はレビューに値する。
三つ目のシグナルは、企業のIDアーキテクチャである。組織は持ち運び可能で長期間有効なシークレットを発行し続けるか、狭い権限とユーザーごとの帰属を持つ一時的なワークロード認証情報へ移行するかの選択を迫られる。
この移行は、盗まれたアクセスが再利用・再販しやすい状態にとどまるかを決める。集中型のインベントリ、迅速なローテーション、デフォルトの利用制限、モデル有効化に対するアラートは、侵害された認証情報の価値を下げられる。
モデルプロバイダーにも役割がある。ネットワーク、デバイス、支払い、リクエストパターンのシグナルを通じて、アカウントプールを特定できる。活動が突然リージョン、モデル、利用プロファイルをまたぐ場合には、より強力な検証を要求できる。
こうした保護策は、正当なエンタープライズルーティングを不当に扱わないようにしなければならない。企業は意図的にワークロードをリージョンやプロバイダーに分散する場合がある。検知システムには、一般的な異常しきい値だけでなく、顧客ポリシーから得るコンテキストが必要だ。
組織は具体的なインベントリから始めるべきである。有料モデルにアクセスできる人物、認証情報を保持するアプリケーション、サービスを有効化できるクラウドロール、モデルリクエストが記録される場所を特定する。
次に、無効化をテストすべきだ。迅速に所在を特定して無効化できない認証情報は、すでにインシデント対応上の負債である。チームは、一つのIDを削除しても無関係なAIワークロードを停止する必要がないことを確認すべきだ。
開発者は、ローカルの静的キーを置き換え、実験用アカウントを本番システムから分離し、チャットやソースリポジトリを通じた認証情報の共有を拒むことでリスクを減らせる。セキュリティチームは、回避策よりも承認済みの経路を使いやすくすべきだ。
経営陣は簡単な問いを投げかけるべきだ。AI認証情報が今夜盗まれた場合、組織は攻撃者、請求額、漏えいデータのどれを最初に気付くだろうか。
Googleの警告がこの問いを急務にしているのは、攻撃者がAIアクセスをもはや目新しいものとは見ていないからだ。彼らはそれを、取得し、プールし、消費し、販売できる資産と見ている。
今後数か月で、プロバイダーがより強力な測定値を公表するか、インフォスティーラーが標的リストを拡大するかが明らかになるはずだ。読者は、地下市場がさらに成熟する前に、この期間を利用してAIアクセスを監査すべきである。
