Wiz CIRTのLLMjacking報告を読む：Google Cloudの請求先アカウントを乗っ取られ、他人のGemini API利用料を払わされるまでの流れと確かめること

どうも！オペ部の西村祐二です！

盗んだクラウドの認証情報で LLM を動かし、利用料を被害者に払わせる攻撃は「LLMjacking」と呼ばれています。よく聞くのは、盗んだ認証情報で被害者のアカウント内のモデルを呼ぶ形です。Wiz のインシデント対応チーム（Wiz CIRT）が2026年10月20日に公開した報告「From Phishing to LLMjacking: Threat Actors Targeting Cloud Billing Accounts for LLM Usage」は、少し違う形を扱っています。攻撃者は被害者の請求先アカウント（Cloud Billing アカウント）を乗っ取り、Gemini API を大量に呼んでいました。報告によると、初回の侵入から24〜48時間で、数万〜数十万ドル規模の想定外の請求が発生しています。

Google Cloud（報告では GCP と表記）を組織で使っていると、請求先アカウントの管理者権限を持つ人が自分のチームにもいるはずです。その立場で読むと、この攻撃は検索広告のクリックひとつからどう進むのか、なぜ被害者のログにプロンプトが残らないのか、自分の環境で何を確かめればよいのかが気になります。この記事では、Wiz の報告から攻撃の流れと成立する理由を整理します。そのうえで、報告にある検知の手がかりと、Google Cloud の公式ドキュメントで確かめた予算と権限の仕様をもとに、確認する点をまとめます。Wiz の製品の使い方、AWS や Azure での同種の攻撃、攻撃者の特定は扱いません。

このレポートを読む前に

• 発行元の Wiz はクラウドセキュリティ製品の会社で、報告のうち検知を扱う節には自社製品のクエリや検知ルールの案内が含まれています。この記事では、製品に依存しない手がかりだけを取り上げます
• 報告は、Wiz CIRT が対応した複数の侵害をまとめたものです。侵害の件数、被害組織の業種や規模、侵害ごとの被害額（示されているのは幅だけです）、攻撃者が誰かは書かれていません
• 対象は Google Cloud だけです。報告の冒頭には同じ傾向の侵害を複数調べたとあり、そのうち Google Cloud を狙ったキャンペーンに絞って書いたとされています
• 攻撃者が Gemini API で何をしていたかは、報告でも分かっていません（理由は次の節で説明します）

他人のプロジェクトの Gemini API の利用料が、自社の請求先アカウントに届く

Google Cloud では、プロジェクトの利用料はそのプロジェクトにつないだ請求先アカウントに請求されます。1つの請求先アカウントには複数のプロジェクトをつなげられるので、この関係が攻撃の前提になります。

報告によると、この侵害の目的は破壊ではなく金銭的な搾取で、大量の LLM 推論の費用を被害者に押し付けることです。

出典: Wiz の報告の冒頭と「Initial Access」「Impact: AI Resource Abuse」の節

このため、攻撃者が自分のプロジェクトを被害者の請求先アカウントにつなぐと、そのプロジェクトの API の利用料は被害者が払うことになります。一方で、API キーやリクエストのログは攻撃者のプロジェクト側にあるので、Gemini API の呼び出し、プロンプト、出力は被害者の監査ログに残りません（報告の「Impact: AI Resource Abuse」の節）。被害者の組織の中で行われた操作、たとえば組織ポリシーの削除や請求先アカウントの IAM の変更は、被害者側のログで追えます。後半で確かめることは、この被害者側に残る操作が中心です。

検索広告のクリックから請求先アカウントの乗っ取りまで

報告は攻撃を、初期侵入、永続化と権限昇格、検知の回避、影響の順に説明しています。流れを表にすると次のとおりです。この記事では、IP アドレスがリンクとして扱われないように 212.73.134[.]136 と表記しています（実際の値は [.] を . に置き換えたものです）。

出典: Wiz の報告の「Initial Access」「Persistence and Privilege Escalation」「Defence Evasion」「Impact: AI Resource Abuse」の各節

この流れを図にすると次のとおりです。図は報告をもとに自作した概念図で、Wiz の報告や Google Cloud の公式の図ではありません。

青い枠は被害者の組織の中にあり、そこで行われた3〜5段目と7段目の操作は被害者側の監査ログで追えます。赤い枠は攻撃者側で、6段目で紐付けられた攻撃者のプロジェクトの利用料だけが、被害者の請求先アカウントに届きます。

二度目のログイン画面と、Google が送った警告メール（1〜2段目）

フィッシングの画面は、認証情報を盗んだあと利用者を本物の Google のログイン画面へ戻していました。利用者はもう一度ログインすることになりました。報告は、利用者が最初のログインの失敗をちょっとした不具合だと思っただろうと書いています。その間に、フィッシングキットは盗んだ認証情報で最初のログインを済ませていました。なお、報告によると、この活動が報告されたあと、Google 広告は該当の広告キャンペーンを削除しました。

Google はこのログインを不審なものと判定し、利用者に警告メールを送っていましたが、侵害は防げませんでした。この経緯から報告は、利用者の注意だけに頼らないよう勧めています。具体的には、Google Workspace のユーザーログイベントを取り込み、不審なログインの判定や不自然な再認証を監視する方法が挙げられています。

新しい環境を作らず、使われていないプロジェクトを使う（3段目）

攻撃者は新しいインフラをゼロから作らず、利用の少ない既存のプロジェクトで Gemini API を有効にし、API キーを発行していました。報告は理由を書いていませんが、普段から使っているプロジェクトよりも、持ち主が日常的に見ていないプロジェクトの方が変化に気付かれにくい、と自分は読みました。後半の確認項目に、利用の少ないプロジェクトでの API の有効化と鍵の作成を入れているのはこのためです。

組織ポリシーを消してから、外部の Gmail アカウントを招き入れる（4〜5段目）

iam.allowedPolicyMemberDomains は、IAM ロールを付けられる相手を許可したドメインに限る組織ポリシーです。Google Cloud のドキュメントによると、2024年5月3日以降に作られた組織では、このポリシーが既定で有効になっていて、自社のドメインだけが許可されています。攻撃者はこの制限を外してから、Gmail アカウントを請求先アカウントに追加しています。被害組織の作成時期は報告に書かれていないため、このポリシーが既定で有効だったかどうかは分かりません。

付与された roles/billing.admin について、報告は、請求先アカウントを完全に操作できるロールだと説明しています。権限の管理、外部プロジェクトの紐付け、支払い設定の変更まで含まれます。Cloud Billing のアクセス制御のドキュメントでも、Billing Account Administrator は請求先アカウントの所有者に当たるロールで、プロジェクトの紐付けと解除、ほかのユーザーのロールの管理ができると書かれています。

本社がある国の IP から操作し、元の管理者を閲覧専用にする（7段目）

初回ログインのあと、攻撃者はどの侵害でも、乗っ取った利用者の実際の場所に関係なく、被害組織の本社がある国の IP アドレスから操作していました。報告は、場所に基づくアラートを避けるための手口だとしています。日本に本社がある組織なら、日本の IP からの操作に見えることになるので、送信元の国だけを見る検知では気付けない、と自分は解釈しています。

さらに攻撃者は、既存の請求先アカウント管理者を閲覧専用の billing viewer に格下げしていました。報告によると、この格下げで正規の管理者はコンソールから権限を取り消すことも、不正なプロジェクトを切り離すこともできなくなっています。

自分の Google Cloud 環境で確かめること

報告は、Google Workspace、Google Cloud の管理アクティビティ、Cloud Billing の監査ログを横断して調べるよう勧めています。その検知の手がかりをまとめると次のとおりです。

出典: Wiz の報告の「Detection and Threat Hunting Indicators」の節

フィッシングのドメイン17件の一覧は、報告の「Indicators of Compromise」の節にあります。

以下は Google Cloud のドキュメントで確かめた内容です。

請求先アカウントのロールを持つ人を棚卸しする

プロジェクトの請求先を変更する手順のドキュメントによると、プロジェクトを請求先アカウントにつなぐには、つなぐ先の請求先アカウントで billing.resourceAssociations.create 権限が必要です。この権限は Billing Account User と Billing Account Administrator のロールに含まれています。Billing Account User について、アクセス制御のドキュメントは、権限がとても限られているので広く付与できると書いています。一方で、Project Creator と組み合わせると、その請求先アカウントにつながった新しいプロジェクトを作れます。Project Billing Manager と組み合わせると、プロジェクトの紐付けと解除もできると書かれています。

攻撃者が自分で作ったプロジェクトなら、プロジェクト側の権限は最初から持っているので、被害者の請求先アカウントで Billing Account User を得るだけで紐付けが成立すると考えられます。棚卸しでは、Administrator と User の両方について、社外のアカウントが混じっていないかを確かめます。アクセス制御のドキュメントによると、請求先アカウントは親の組織から IAM の権限を継承します。棚卸しでは、請求先アカウント自体の IAM に加えて、組織レベルで付与された請求のロールも確かめます。

あわせて、請求先アカウントにつながっているプロジェクトの一覧に、自社の組織に属さないプロジェクトがないかも確かめておくと、攻撃の6段目の痕跡に気付けます。一覧は、Google Cloud コンソールで Cloud Billing の「アカウント管理」（Account management）ページを開くと見られると、プロジェクトの請求先を変更する手順のドキュメントで説明されています。アクセス制御のドキュメントには、請求先アカウントは別の組織に属するプロジェクトの費用も払えると書かれているので、自社の組織の外のプロジェクトも一覧に出てきます。

格下げされたあとでもこの一覧を見られるかについては、2つのドキュメントの記述が分かれています。アクセス制御のドキュメントでは、一覧を見る billing.resourceAssociations.list を Billing Account Viewer も持っています。一方、請求先の変更のドキュメントでは、紐付けの表示に必要な権限としてプロジェクト側の resourcemanager.projects.get も挙げられています。どちらが必要になるかは、今回は自分の環境で試していません。

上限付きの予算は、攻撃者のプロジェクトにはかからない

Cloud Billing の予算には、通知だけの予算と、上限付きの予算（spend cap budget）の2種類があります。

出典: Google Cloud の「Create, edit, or delete budgets and budget alerts」「Manage spend cap budgets」

上限付きの予算の対象サービスには、Gemini API（generativelanguage.googleapis.com）が含まれています。ただし、上限付きの予算は1つのプロジェクトに対して設定するもので、フォルダ、組織、複数のプロジェクトを範囲にした予算には設定できません。攻撃者が後からつないだ攻撃者側のプロジェクトには、被害者が設定した上限付きの予算はかかりません。この予算で守れるのは、攻撃の3段目のように自社の既存プロジェクトで Gemini API を使われる場合までです。なお、spend cap のドキュメントによると、上限に達した時点で処理中のリクエストは最後まで処理され、その分は課金されます。

攻撃者のプロジェクトでの利用を知るには、請求先アカウント全体を対象にした通知だけの予算で、普段の利用額に近い予算額を設定し、早めの閾値を置いておく方法があります。予算のドキュメントによると、組織やフォルダを範囲にした予算はその中のプロジェクトにだけかかるので、攻撃者の外部プロジェクトは拾えません。範囲は請求先アカウント全体にしておく必要があります。

ただし、予算は後から気付くための安全網と考えたほうがよさそうです。同じドキュメントは、利用状況の報告には遅れがあるので、予算額を使える資金より低めに設定するよう勧めています。spend cap のドキュメントでも、実際の費用が請求のレポートに出るのは通常1日以内で、24時間を超えることもあると説明されています。報告では24〜48時間で被害が出ているので、通知だけの予算のアラートが届いた時点で、被害がかなり進んでいる可能性があります。早く気付くには、後述の組織ポリシーや IAM の変更の監視と組み合わせる必要があります。

予算アラートの宛先と、予算そのものの変更

予算のドキュメントによると、予算のアラートメールは既定で、請求先アカウントの Billing Account Administrator と Billing Account User に送られます。Cloud Monitoring のメール通知チャネルを予算につなぐと、任意のアドレスにもアラートを送れると説明されています。

予算アラートは、請求先アカウントのロールに依存しない宛先にも送るようにしておくのがよさそうです。あわせて、組織の管理者（組織の IAM ポリシーを変更でき、請求先アカウント管理者の権限を戻せる人）への連絡経路を事前に決めておくと、格下げされたあとでも切り離しを頼めます。

また、アクセス制御のドキュメントの権限一覧では、Billing Account Administrator は予算の作成、変更、削除と上限の設定の権限（billing.budgets.*）を持っています。攻撃者がこのロールを得れば、予算そのものを変えられます。予算の変更をどう検知するかは今回確かめていないので、予算のアラートだけを頼りにしないほうがよさそうです。

組織ポリシーの変更の通知は、プロジェクトのログを前提にすると届かない

報告の4段目で削除された iam.allowedPolicyMemberDomains は、ドメイン制限のドキュメントでは「legacy managed constraint」と書かれています。同じドキュメントでは、ドメインを制限する方法として3つが案内されていて、新しい形式のマネージド制約 iam.managed.allowedPolicyMembers が最初に挙げられています。ほかの2つは、カスタム組織ポリシーを使う方法と、従来の iam.allowedPolicyMemberDomains です。いずれの方法を使っていても、変更が起きた時点で通知が届く形にしておく必要があります。

組織ポリシーの監査ログのドキュメントによると、google.cloud.orgpolicy.v2.OrgPolicy.CreatePolicy、UpdatePolicy、DeletePolicy は管理アクティビティの監査ログに記録されます。ポリシーを新しく作って緩める変更もあるので、削除と更新だけでなく作成も対象にします。同じページでは、v1 API（Resource Manager）経由の変更の監査ログは別のページに分けられているので、v2 のメソッド名だけで絞ると v1 経由の変更を拾えない可能性があります（v1 のメソッド名は今回確かめていません）。

Cloud Logging には、特定のログが現れたときに通知するログベースのアラートポリシーがあります。ただし、Cloud Logging の監視のドキュメントによると、ログベースのアラートポリシーは、フォルダ、請求先アカウント、組織から出たログには使えません。組織レベルのポリシーの変更や、請求先アカウントの IAM の変更は、この方法では拾えないことになります。同じページには、リンクした BigQuery データセットにクエリをかける SQL ベースのアラートポリシー（プレビュー段階の機能）も載っていて、こちらにはプロジェクトから出たログに限るという制限は書かれていません。組織のログをプロジェクトのログバケットに集めて SQL ベースのアラートで通知する構成が候補になりそうですが、今回は試していません。

まとめ

Wiz CIRT の報告によると、請求先アカウントを乗っ取って攻撃者のプロジェクトの利用料を払わせる手口は、増えている傾向にあります。攻撃者のプロジェクトを外からつながれると、プロンプトや出力は被害者のログに残らず、プロジェクト単位の上限付きの予算もかかりません。被害者側で追えるのは、組織の中で行われた操作と、請求先アカウントの変化です。

自分の Google Cloud 環境で、同じ経路の攻撃に気付く手がかりになる点は次のとおりです。

• Google Workspace の不審なログインの判定と再認証を監視し、報告の侵害の指標とも照合しているか
• 請求先アカウントのロール（Billing Account Administrator と Billing Account User）を持つ主体に、社外のアカウントが混じっていないか
• 請求先アカウントにつながったプロジェクトに、自社の組織に属さないものがないか
• 組織ポリシーの変更と、請求先アカウント管理者の IAM の変更を通知する仕組みがあるか（プロジェクトのログを前提にしたログベースのアラートでは拾えない）
• 利用の少ないプロジェクトでの Gemini API の有効化と API キーの作成を監視しているか
• 請求先アカウント全体の予算で、普段の利用額に近い閾値のアラートを置いているか（プロジェクト単位の上限付きの予算は、攻撃者のプロジェクトにはかからない）
• 予算アラートの宛先と組織の管理者への連絡経路が、請求先アカウントのロールに依存していないか

誰かの参考になれば幸いです。

参考リンク:

• From Phishing to LLMjacking: Threat Actors Targeting Cloud Billing Accounts for LLM Usage | Wiz Blog
• Create, edit, or delete budgets and budget alerts | Cloud Billing | Google Cloud
• Manage spend cap budgets | Cloud Billing | Google Cloud
• Cloud Billing access control and permissions | Google Cloud
• Enable, disable, or change billing for a project | Cloud Billing | Google Cloud
• Restrict identities with domain-restricted sharing | Organization Policy | Google Cloud
• Organization Policy audit logging | Google Cloud
• Configure log-based alerting policies | Cloud Logging | Google Cloud
• Monitor your logs | Cloud Logging | Google Cloud
• Gemini API | Google AI for Developers
• User log events | Google Workspace Admin Help