GoogleのLLMジャッキング警告が露呈させた、盗まれたAIアクセスの闇市場

Googleは、犯罪者がAIアカウント、API認証情報、企業のクラウド容量を盗む動きを強めるなか、LLMジャッキング攻撃が急増していると警告した。

地下市場の販売者は、Google、Anthropic、OpenAIのモデルへの不正アクセスを最大97%引きで宣伝していると報じられている。この数字は確認されたマーケットプレイス上の掲載情報を示すものであり、独自に検証された平均取引価格ではない。

より重要な発見は、見出しの裏にある。AIアクセスは、盗難クレジットカード、クラウドアカウント、住宅用プロキシ接続と同様に、取引可能な犯罪資産になった。

Google Threat Intelligence Groupによると、2026年にAIアカウントの買い手と売り手の増加を観測したという。需要はClaudeとGeminiの認証情報に集中し、Cursor ProやDevinなどのAIコーディング製品も対象となっていた。

これは単なるサブスクリプション詐欺ではない。攻撃者はAPIキーやクラウドIDを盗み、別の企業のアカウント経由でリクエストを送り、その活動の責任を被害者に負わせることができる。

その結果生じるリスクには、想定外の利用量、データ漏えい、サービス障害、信頼されたインフラの犯罪利用が含まれる。また、AI支出を統制されたコンピューティングリソースではなく、ソフトウェア予算として扱い続けるセキュリティプログラムにも課題を突きつける。

従来のリソース乗っ取りキャンペーンは、通常、暗号資産マイニングやプロキシ容量を狙っていた。LLMジャッキングは、同じ経済原理をモデル推論、開発者エージェント、そしてそれらを運用するためのインフラへと向ける。

したがって、この対立は犯罪者対AIプロバイダーという構図にとどまらない。盗まれたアクセスと企業統制の対立であり、追跡されていないキーや過剰な権限を持つワークロードの一つひとつが、市場の供給を広げている。

GoogleのLLMジャッキング警告が実際に示していること

Googleの証拠は、犯罪者が孤立した盗難アカウントを試しているだけでなく、侵害されたAIアクセスを中心とするサプライチェーンを構築していることを示している。

同社の2026年9月のAI脅威トラッカーは、サイバー犯罪コミュニティ全体でAIアカウントの窃取、流出、販売が増加していると説明している。

Googleによると、2026年にはAI関連アカウントを求める地下組織のペルソナが増加した。また、前年と比べて、そうしたアカウントを宣伝する販売者も増えているという。

Googleが追跡した投稿によれば、2026年にはアカウント当たりの平均マーケットプレイス価格が2倍以上になった。この上昇は、一部の掲載情報が極端な割引をうたっていた一方で、需要が伸びたことを示唆する。

この一見矛盾する状況は、不正市場の内部では理にかなっている。正規の推論と高性能コンピューティングには、希少で課金対象となるリソースが必要なため、買い手はアクセスに価値を見いだす。

盗まれたアカウントは、そのコストを被害者に転嫁できる。そのため販売者は、同等のインフラを運用せずとも正規アクセスより安く提供できる。

最大97%に達する割引についての報道は、最も大幅な地下市場の提示価格を指しているとみられる。Googleの公開レポートは、この割合を市場全体の平均として確立していない。

また、被害者総数、損失総額、検証済みの取引量も公表していない。こうした欠落により、市場全体の規模を測定しようとする試みには限界がある。

それでも、基盤となる活動は見出しの割合より確実に記録されている。Googleは、需要の増加、標的型の認証情報窃取、不正なAIワークロードを支えるクラウド侵害を観測した。

同社はインフラ版を「LLMJacking」と呼ぶ。この用語は、AIモデルを実行したり、ホスト型モデルサービスを無許可で利用したりするために、企業クラウドリソースを乗っ取る行為を指す。

Googleは、直接的な窃取以外のアカウント調達手法も特定している。脅威アクターは、自動登録、アカウントプール、プロキシリレー、複数のキーを集約するミドルウェアを利用する。

これらの仕組みは、リクエストを複数のアカウントに分散し、その発信元を隠すことができる。また、購入者のインターフェースを変えずに、無効化された認証情報を置き換えることも可能だ。

この構造は、侵害されたアクセスをサービスへと変える。買い手は、どの組織が実際の請求を負担しているかを理解する必要がない。

この市場には、消費者向けAIアカウント、コーディング支援ツール、モデルAPIの認証情報が含まれると報じられている。これらの資産がさらす対象は大きく異なる。

盗まれたチャットアカウントは、会話履歴やアップロード済みの文書を明らかにする可能性がある。API認証情報は、クォータ、モデル、または接続されたクラウドプロジェクトへのプログラム可能なアクセスを提供し得る。

侵害されたクラウドIDは最も広範なリスクをもたらす。侵入者がインフラをプロビジョニングし、保存済み認証情報を探索し、隣接する企業サービスへ到達できる可能性がある。

Googleの警告は、これらの層を一つの経済圏として結び付けている。盗まれたアカウントは即時アクセスを提供し、侵害されたインフラは持続的なコンピューティング能力を供給する。

この組み合わせが、単一プロバイダーを超えて脅威が重要である理由を説明する。Google、Anthropic、OpenAIは正規顧客をめぐって競争しているが、犯罪者は3社すべてへのアクセスを代替可能な在庫として取引できる。

AIアクセスが価値ある犯罪在庫となった理由

LLMジャッキングの台頭は、基本的な経済的変化を反映している。モデルへのアクセスは現在、犯罪者が自ら資金を投じたくない、有用で拡張可能なコンピューティング能力を提供する。

犯罪グループは、盗んだリソースで収益を得られる場合、長年にわたりインフラを盗用してきた。暗号資産マイニングでは、計算能力が直接デジタル資産に変わるため、侵害されたプロセッサに価値が生じた。

プロキシジャッキングは、被害者のシステムを経由してトラフィックを流すことで別の市場を生み出した。攻撃者は帯域幅や、信頼性が高く見える住宅用または企業用アドレスを販売できた。

LLMジャッキングは、このモデルを推論へと拡張する。盗まれるリソースは、プロンプトを送信し、出力を生成し、エージェントを運用し、あるいは乗っ取られたハードウェア上でモデルを実行する能力である。

MITREは、このより広い行動をリソース乗っ取りとして分類している。そのフレームワークには、コンピューティング、帯域幅、メッセージング、クラウドサービスの悪用が含まれる。

AIはこの機会をより柔軟にする。一つの認証情報で、コード生成、偵察、コンテンツ制作、翻訳、フィッシング準備、または自動化された攻撃ワークフローを支援できる。

同じ認証情報は、匿名の無料アカウントでは利用できない高い利用上限や機能へのアクセスを提供することもある。継続的な自動化に依存する活動では、この違いが重要になる。

Googleによると、プレミアムアクセスと高性能コンピューティングは、攻撃者にとって依然として重要な障壁である。これらのリソースを盗むことで、犯罪者はAIプラットフォームを構築せずに障壁を下げられる。

この市場は複数のタイプの買い手に対応し得る。安価な汎用モデルアクセスを求める者もいれば、大量利用やポリシー違反の利用に耐えるアカウントを求める者もいる。

より高度なグループは、盗まれたアクセスをオーケストレーションシステムに接続できる。こうしたシステムは、アカウントを自動的に選択し、エンドポイントをローテーションし、失敗したリクエストを再試行し、作業を分散する。

Googleの2026年5月の脅威調査は、商用モデルへのアクセスを産業化するために使われたプロキシリレーと自動登録パイプラインを記録している。

このレポートは、請求制約やプラットフォームの取り締まりを回避するために設計されたアンチディテクトブラウザ、アカウントプール、カスタムミドルウェアについて説明している。これらの仕組みは、単一の認証情報への依存を減らす。

また、帰属の特定も複雑にする。プロバイダーに到達するトラフィックは、別の場所で悪意ある結果を生む前に、リレーや侵害されたプロジェクトを経由する可能性がある。

企業の被害者にとって、最初に明らかな兆候は異常なモデル利用量かもしれない。しかし攻撃者は、数日前に開発者デバイスから侵入していた可能性がある。

インフォスティーラーは、認証情報やセッションデータを収集するよう設計されたマルウェアであり、AI設定情報を探すためにローカルファイルを検索できる。その後、役立つ情報をすべてその運用者に送信できる。

Googleは、ACRSTEALERの運用者がClineおよびContinue AIに関連する設定ストアを標的にしていることを観測した。これらのファイルには、平文のAPIキーやカスタムルーティングエンドポイントが含まれる場合がある。

この詳細は、AI開発者環境が特に重要であることを示している。コーディング支援ツールは、ソースリポジトリ、パッケージレジストリ、ターミナル、クラウドツールの近くに置かれることが多い。

その環境から盗まれた認証情報は、モデルアクセス以上のものをもたらし得る。攻撃者が開発スタックを把握したり、本番システムへの経路を見つけたりする助けになる可能性がある。

したがって、拡大する市場は、セキュリティ責任者、エンジニアリングマネージャー、クラウド財務チームに同時に圧力をかける。各グループは、インシデントの異なる断片を見る。

セキュリティ部門は侵害されたIDを見る。エンジニアリング部門は失敗したリクエストや枯渇したクォータを見る。財務部門は、アクセスがすでに収益化された後に説明のつかない利用量を見る。

共有された監視がなければ、これらの断片は一つのインシデントとして認識されない可能性がある。闇市場は、その組織的な遅れから利益を得る。

GoogleのLLMジャッキング警告がID統制に圧力をかける

中心的な問題は、モデルが突然ハッキングしやすくなったことではない。攻撃者は、それらを取り巻くIDとインフラを盗んでいる。

Googleの調査は、AI資産に対する攻撃と、最先端モデル自体への侵害成功を区別している。観測された活動は、主に認証情報、コネクター、開発者設定、クラウドプロジェクト、オーケストレーション層に焦点を当てている。

この区別は重要である。なぜなら、モデルの安全対策では漏えいした企業キーを無効化できないからだ。また、クラウド環境全体で不要なアクセスを許可するIDロールを修正することもできない。

ベアラー認証情報は、その保有者に認証情報へ割り当てられた権限で行動させる。システムは、そのリクエストが所有者から来たのか、盗人から来たのかを認識できない場合がある。

長期有効のAPIキーは、この弱点を管理しにくくする。そうしたキーは、従業員の異動、放棄されたプロトタイプ、AIプロバイダー間の移行を経ても残り続けることが多い。

開発者は利便性のため、ローカル設定ファイルにそれらをコピーすることがある。自動ツールが、確立されたセキュリティインベントリに登録しないままキーを生成する場合もある。

その結果、認証情報のスプロールが生じる。組織は承認したAIツールを把握していても、どのID、キー、拡張機能、ローカルエージェントがそれらにアクセスできるかを必ずしも把握していない。

LLMジャッキングは、このガバナンス上の隙間を犯罪者の在庫へと変える。再利用可能な認証情報はすべて、潜在的な商品となる。

組織がモデルを社内データに接続すると、セキュリティ上の課題は拡大する。AIアシスタントは、ソースコード、技術文書、サポート記録、プロジェクト上の議論にアクセスできる場合がある。

侵入者がアシスタントのセッションを盗んだ場合、そのインシデントは保存された会話や接続済みリソースを露出させる可能性がある。攻撃者が盗んだのがAPIキーだけなら、直接的なデータ露出はその権限に依存する。

これらのシナリオを一つの主張にまとめるべきではない。侵害されたキーが、すべてのプロンプトや社内システムへのアクセスを自動的に付与するわけではない。

ただし、チームは不正利用が請求上の問題だけを生むと考えるべきでもない。ログ、モデル出力、接続ツール、アプリケーションコンテキストには、いずれも機密情報が含まれ得る。

エージェントではリスクがより明確になる。エージェントは、ツールを呼び出し、文書を取得し、承認済みのアクションを実行し、ワークフロー全体で運用コンテキストを保持できる。

こうした機能が有用なのは、手作業を減らせるからだ。一方で、基盤となるIDに限定的な権限と信頼できる監査証跡が欠けている場合は危険である。

Googleは、攻撃者が人手による遅延を減らしたエージェント型の運用へ移行していると報告した。第2四半期のある事例では、侵害されたクラウドリソースが6時間未満で大規模な認証情報窃取キャンペーンを支えた。

この例は、盗まれたすべてのAIアカウントが自律的な攻撃に使われることを示すものではない。しかし、遅い手動の承認プロセスだけを防御手段として残すことはできない理由を示している。

企業は、どのIDがモデルを利用できるのか、どのアプリケーションがそれらを所有しているのか、そして通常の利用状況がどのようなものかを把握しなければならない。また、アクセスを迅速に停止する手段も必要だ。

このためには、セキュリティオペレーションセンターを越えた連携が求められる。プラットフォームチームは認証情報を可観測にし、調達チームは請求書を特定の所有者とワークロードに結び付けなければならない。

開発者には、利便性を損なわない承認済みの保管・ローテーション手段も必要だ。安全なプロセスに過度な摩擦があれば、管理されないローカルな代替手段が広がり続ける。

この対立で勝つのは、最も長い利用許諾ポリシーを持つ企業ではない。AIアクセスを迅速に特定し、制限し、取り消せる企業だ。

攻撃チェーンは最初の不審なプロンプトより前に始まる

LLM-jackingは通常、既知の認証情報窃取やクラウド悪用によって成功し、その後AI利用を収益化の層として活用する。

典型的な経路は、開発者のワークステーションから始まる。フィッシング、悪意あるソフトウェア、侵害されたパッケージ、または偽装されたブラウザ拡張機能がインフォスティーラーを送り込む可能性がある。

マルウェアはブラウザ、設定ディレクトリ、コマンド履歴、環境ファイル、アプリケーションストアを探る。多くのAI開発ツールはモデル認証情報を必要とするため、追加の標的を生み出している。

キーが盗まれると、自動的に試験される可能性がある。犯罪運営者は、その提供元、利用可能なクォータ、制限、そして認証情報が現在も有効かどうかを特定できる。

有用な認証情報は直接販売されるか、リレーに投入される。リレーは顧客からのリクエストを受け取り、1つまたは複数の侵害済みアカウントを経由して転送する。

顧客には安定したサービスエンドポイントが見える。その裏側では、運営者が失効した認証情報を置き換え、利用量を分散し、特定のワークロードを異なるモデルへ振り分けられる。

この分離により、購入者は個々の盗難アカウントの不安定さから保護される。また、販売者は1組の認証情報を多くの顧客にまたがって収益化できる。

クラウド侵害は別の経路を生み出す。攻撃者は、モデルサービスの有効化やセルフホスト型インフラのデプロイを許可するIDを入手できる。

その後、被害者のプロジェクトを通じてホスト型推論を利用する可能性がある。あるいは、盗んだコンピューティング能力でモデルを直接実行することもできる。

セキュリティ企業Sysdigは2024年、盗まれたクラウド認証情報を使って有料モデルサービスを利用する行為をLLMjackingと命名した。その後のLLMjacking researchでは、攻撃的なエージェント型ワークロードへの進展が説明されている。

セルフホスト型モデルも関連する露出を生む。認証なしでインターネットからアクセス可能な推論サーバーは、それを発見した誰にでも無料の能力を提供しかねない。

この経路では盗まれたAPIキーは不要だ。脆弱性は、公開されたサービスと不十分なネットワーク制御にある。

それでも、外部者が組織のAIインフラを利用するため、結果はLLM-jackingに似たものになり得る。ただし、対処はアカウント窃取の調査とは異なる。

チームは少なくとも3種類のインシデントを区別する必要がある。侵害されたユーザーセッション、盗まれたモデル認証情報、そして乗っ取られたクラウドまたはセルフホスト型インフラだ。

セッション窃取には、アカウントの無効化、端末調査、露出したコンテンツの確認が求められる。APIキーの窃取には、キーのローテーション、ログ分析、関連する権限の検証が必要となる。

インフラ侵害には、より広範なインシデント対応が必要だ。調査担当者は、攻撃者がどのように侵入したか、どのリソースが作成されたか、持続的アクセスが残っているかを明らかにしなければならない。

利用量の異常は3種類すべてを明らかにし得るが、それだけでは十分ではない。正当な製品ローンチでも、モデルトラフィックが急増する可能性がある。

有用な検知は、量、ID、地理的位置、時間、モデル選択、アプリケーションの挙動を組み合わせる。複数の側面が同時に変化するワークロードは、迅速な確認に値する。

チームは、安全制御によって拒否されたリクエストも監視すべきだ。こうしたイベントは悪用を示す場合があるが、高度な攻撃者は無害なタスクや独自モデルを使う可能性もある。

最善の制御は、確率と影響の両方を低減する。短命な認証情報は攻撃の機会を狭め、ワークロード固有のIDは盗まれた認証情報が到達できる範囲を制限する。

ネットワーク制限は、想定外の環境からの利用を阻止できる。クォータと利用上限は、対応者が調査する間の悪用を遅らせられる。

これらの制御はいずれも確実性を提供しない。しかし組み合わせれば、盗まれたアクセスの信頼性を下げ、闇市場の販売者にとっての価値を低下させられる。

97%割引という主張が証明しないこと

劇的な割引は有用な警告シグナルではあるが、市場の実際の規模、信頼性、または金銭的影響を測るものではない。

闇市場の広告は、成立した販売を意味しない。販売者はアクセス品質、アカウント種別、残存クォータ、失効までの期間を誇張する可能性がある。

宣伝される商品は、正規のアクセスと異なる場合もある。購入者は、譲渡可能なサブスクリプションではなく、共有プロキシ、ブラウザセッション、または短命なアカウントを受け取るかもしれない。

この違いは割引率の計算を変える。不安定な犯罪者のリレーと、信頼できてサポート付きのアクセスを比較すれば、誤解を招く割合になり得る。

この数字は、基盤となる利用を誰が負担したかも明らかにしない。一部のアクセスは盗まれた認証情報に由来する一方、他の提供はトライアルや自動アカウント作成を悪用している可能性がある。

Googleは、これらすべての調達経路を文書化している。公開されている証拠は、市場の何パーセントが各経路によるものかを示していない。

また、この報告書は、攻撃者がGoogle、Anthropic、またはOpenAIの中核モデルインフラを侵害したことを立証していない。観測された市場の大部分は、侵害された顧客やアカウントのエコシステムに依存している。

このニュアンスは対応方針に反映されるべきだ。脆弱性の多くは顧客管理のIDやデバイス内に存在するため、企業はプロバイダーがすべての事例を解決するのを待てない。

プロバイダーにも依然として大きな責任がある。各プラットフォームで、アカウントのプール利用、不審なリレー、不可能な利用パターン、組織的な登録悪用を検出できる。

Googleは、脅威インテリジェンスを活用して保護策を強化し、悪意あるプロジェクトやアカウントを無効化していると述べている。こうした執行は、闇市場サービスを維持するコストを高める可能性がある。

ただし、プロバイダーの対応は別の不確実性ももたらす。積極的な自動ブロックは、正当な共有インフラや世界に分散した開発チームを妨げる可能性がある。

したがって、セキュリティシステムには単一のトラフィック急増を超える証拠が必要だ。製品ローンチ、設定ミスのアプリケーション、盗まれた認証情報を迅速に見分けなければならない。

集計された損失データがないことも、ランサムウェア、クリプトジャッキング、その他のクラウド脅威との比較を制限する。LLM-jackingは広く存在していても、被害者1件あたりの損失は小さいかもしれない。

逆のパターンもあり得る。少数のクラウド侵害でも、盗まれたIDが価値あるデータやインフラに到達するため、深刻な露出を生む可能性がある。

Googleのテレメトリーも別の境界を示す。自社エコシステムとインシデント対応の取り組みには強い可視性を提供するが、すべてのプロバイダーや闇市場取引を対象とするものではない。

独立した研究は攻撃パターンの確認に役立つ。それでも、断片的な観測を完全な世界市場推計へ変換することはできない。

擁護可能な結論は、より限定的で有用だ。犯罪需要は存在し、販売者はそれに応じており、盗まれたAIアクセスには再現可能な収益化経路が生まれている。

この結論は、ダークウェブ上のすべての掲載情報を額面どおりに受け入れる必要はない。AI認証情報を、攻撃者が積極的に狙う資産として扱うことが求められる。

したがって、懐疑的な読み方は運用上の教訓を強める。チームは、違法販売者の宣伝上の数字1つを基にポリシーを構築するのではなく、検証済みの攻撃メカニズムに対応すべきだ。

LLM-Jackingが成長を続けるかを示す3つのシグナル

次の段階は、認証情報窃取マルウェアの標的化、プロバイダーによる執行、企業の利用量異常を通じて明らかになる。

第一のシグナルは、インフォスティーラーがAI設定ファイルへの標的化を拡大するかどうかだ。Googleはすでに、特定のコーディングアシスタントのシークレットを探すマルウェアコントローラーを観測している。

追加のエージェント、モデルルーター、ローカル開発ツールを対象とする新たなルールは、攻撃者がそこに価値ある認証情報を見出し続けていることを示すだろう。

そのためセキュリティチームは、設定ディレクトリ全体にわたる見慣れない検索について、エンドポイント検知を確認すべきだ。また、モデル認証情報をローカルに保存するアプリケーションを棚卸しする必要がある。

第二のシグナルはプロバイダーの執行だ。無効化されたアカウントプール、解体されたリレーネットワーク、より厳格な登録確認、より限定的な認証オプションについての開示に注目すべきである。

執行の強化は、プロバイダーが意味のある規模の組織的悪用を認識していることを裏付ける。それは同時に、犯罪者をセルフホスト型モデルや直接的なクラウド侵害へ向かわせる可能性もある。

この移行は重要だ。盗まれた消費者アカウントをブロックしても、低コストのコンピューティング能力への需要は消えない。

第三のシグナルは企業テレメトリーだ。説明できない推論リクエストの増加、新しいモデルの利用、見慣れない地域、デプロイウィンドウ外での利用は、侵害されたアクセスを明らかにし得る。

MITREのクラウドサービス・ハイジャッキングモデルは、急激なリソース変化と不正なサービス利用を確認するよう推奨している。AIチームはこの考え方をトークン、リクエスト、エンドポイント、モデルファミリーに適用できる。

GoogleのAPI key guidanceは、制限、利用状況の監視、キーの分離、定期的なローテーション、利用可能な場合のより強力な認証を推奨している。

チームはこれらの原則を所有権ルールに落とし込むべきだ。すべてのモデル認証情報には、名前付きのアプリケーション、責任を負うチーム、承認済み環境、文書化された失効手順が必要である。

1つのキーを人やワークロード間で共有することは避けるべきだ。認証情報を分離すれば、監査証跡が改善され、単一の侵害が及ぼす範囲を減らせる。

本番環境のシークレットをリポジトリ、ノートブック、ブラウザからアクセス可能なコード、または緩く管理されたローカルファイルに保存してはならない。管理されたシークレットストアを使用し、認証情報の配布を自動化する。

プロバイダーがサポートする場合は、短命なID認証情報を優先する。一時的な認証情報では、攻撃者がアクセスを試験、パッケージ化、再販できる時間が短くなる。

利用アラートは、クラウドアカウント全体だけでなくワークロードレベルで設定する。集計された請求情報は、通常の企業成長に紛れた悪用を隠してしまう可能性がある。

拒否されたリクエストと、モデル選択の急激な変化を監視する。侵害されたアプリケーションが突然別のモデルを呼び出す場合、攻撃者による試行を示している可能性がある。

各IDが利用できるサービス、アプリケーション、ネットワーク、手法を制限する。最小権限により、盗まれたキーをマスター認証情報から限定的な資産へ変えられる。

AI接続ツールは、ソースリポジトリやクラウドコンソールと同じ規律で確認する。エージェントは、チームが見落としがちなコネクターを介して機密性の高い権限を継承する可能性がある。

AI認証情報向けのインシデントプレイブックを維持するべきだ。そこには、失効、ログ保全、エンドポイント調査、プロバイダーへの通知、隣接するクラウドアクセスの確認を含める必要がある。

検索可能なengineering knowledge baseは、チームが所有権記録と対応手順を維持する助けとなる。ただし、そこに有効なシークレットを含めてはならない。

GoogleのLLMジャッキングに関する警告は、企業が問うべき内容を変える。犯罪者がAIへのアクセスに価値を見いだしているかどうかは、もはや問題ではない。闇市場が、その答えを示している。

実務上の論点は、自組織がモデルに到達するすべての認証情報を把握し、異常な利用を検知し、それが取引対象となる前にアクセスを取り消せるかどうかだ。

今すぐ認証情報を監査する。残存するすべてのキーに担当者を割り当て、放置されたアクセス権を削除し、現実的な条件下で失効プロセスをテストする。