Cloud billing admin is a privileged role, and a security team that leaves it outside its privileged-access program has left open the door that let attackers run up charges in the tens to hundreds of thousands of dollars on someone else’s AI workloads.
What Wiz found
The Wiz Customer Incident Response Team described a pattern it has investigated across several intrusions, with its write-up focused on Google Cloud campaigns. The attackers bought search ads for terms such as “google cloud” and “gcp”. A click led through a Google Sites redirect to a fake login page, which collected the password and the multi-factor code, then sent the user back to the real sign-in prompt so the second attempt looked like a glitch.
With a privileged account in hand, Wiz says the attackers enabled the Gemini API in old, low-usage projects, created service accounts with API keys, and gave them roles such as roles/ml.admin. They deleted the organization policy iam.allowedPolicyMemberDomains, which removes the rule restricting access to verified company domains, then added their own Gmail accounts to the billing account and granted roles/billing.admin. They linked attacker-controlled projects to the victim’s billing account, and demoted the existing billing administrators to read-only viewers.
The result, in Wiz’s account, was tens to hundreds of thousands of dollars in Gemini API charges within 24 to 48 hours. Because the AI workloads ran in foreign projects, the victim paid and could not see a single prompt or output.
Billing sits outside most privileged-access programs
A privileged-access program usually lists owners, org admins and security admins. Billing administrator is easy to leave off, because it sounds like a finance function. I think that omission is a mistake. This campaign shows what the role can do. It can attach outside projects to your payment method, and it can remove other administrators, which is how the attackers locked out the people who could have detached the rogue projects. That is a control-plane role, and it should carry the same requirements as the roles around it.
The same applies to the organization policy that the attackers deleted. A domain restriction is a guardrail with exactly one job, and the intruders went for it second. Changes to it should page someone, because deleting that one policy is what let outside accounts receive roles in the first place. A team that reads its audit log only after an invoice arrives has chosen the slowest detector it owns, and the cost of that choice scales with how fast the attacker can spend. Wiz’s cases ran up the charges within two days.
The strongest objection
The best counter-argument is proportion. Nothing was encrypted and no customer records left the building, so a billing incident is a budget problem for finance to dispute with the provider, and security attention belongs on breaches. I take the point on data. I do not take it on consequence. Wiz notes that the intruders also removed existing administrators and rewrote IAM to admit external accounts, and a team that cannot see what ran in its own billing account cannot tell whether the prompts held stolen data, malware instructions or something else. Paying for an unknown workload is a security outcome even if the invoice goes to accounts payable.
What I would change this quarter
Put billing admin and organization-policy admin in the privileged tier, and issue those roles to as few people as possible. Require a sign-in method that a fake page cannot replay for them; a six-digit code typed into a look-alike site is the weakness in this story, and my judgment is that a credential bound to the real domain removes it. Wiz also says organizations should not rely on user awareness alone, and recommends ingesting Google Workspace login events for suspicious-login flags and re-authentication anomalies.
Then add the alerts Wiz lists. Review IAM for members on outside domains, especially personal email providers. Watch audit logs for changes to allowedPolicyMemberDomains and to billing administrator bindings, and for unexpected Gemini API enablement or service account key creation in projects nobody has touched in months. Set spend caps and anomaly alerts, since a cost surge is the signal Wiz describes, and the victim’s own logs gave no view of the workloads. The same logic runs through giving every AI agent its own identity and no permissions, and it is why I made the case in Enterprises Locked the Humans. Machines Walk Right In. that machine credentials deserve human-grade scrutiny. Service accounts with API keys were step two of this intrusion.
Source: Wiz, From Phishing to LLMjacking: Threat Actors Targeting Cloud Billing Accounts for LLM Usage
