Attackers Linked Their Own Google Cloud Projects to Victims' Billing and Ran Gemini on Their Money. The Prompts Never Reach Your Logs. Here Is the Hunt and 18 IOCs.

If your company runs on Google Cloud, check one thing today: which projects are linked to your billing account, and whether you own all of them. Wiz's incident response team has investigated several intrusions where attackers phished a cloud administrator, attached their own projects to the victim's billing account and ran Google's Gemini models on the victim's money. Charges reached tens to hundreds of thousands of dollars within 24 to 48 hours. The prompts were not in the victim's logs, because the usage was not in the victim's projects.

How it works
Wiz published the write-up on October 20, by Shira Ayal and Andre Maccarone. The chain is short and every step uses a normal administrative feature.
- The lure. The attacker bought Google search ads on the words an administrator types, such as "google cloud" and "gcp". The ad went through a Google Sites redirect to a fake Google login page. It captured the password and the MFA code, then passed the user on to the real login, so nothing looked wrong. Google removed the ad campaign once it was reported.
- The first login. The kit used the stolen session at once from 212.73.134.136. Later activity came from addresses in the victim's own headquarters country, so a location alert would not fire.
- Keys in quiet places. The attacker turned on the Gemini API in old, little-used projects, created service accounts and API keys there, and gave them powerful roles.
- The guardrail. Many organizations restrict IAM membership to their own domains with the org policy iam.allowedPolicyMemberDomains. The attacker deleted it.
- The billing account. With the restriction gone, the attacker added outside Gmail accounts as billing administrators and demoted the real billing administrators to read-only, so they could not unlink anything.
- The theft. The attacker linked their own Google Cloud projects to the victim's billing account. Every Gemini call those projects made was charged to the victim.
Wiz did not attribute the activity or say how many organizations were hit.
Why the usual signal is missing
We call this kind of attack token theft: stealing metered AI capacity rather than data. Whether you notice it depends on where the usage lands. Here it lands in projects you cannot see, so your own Gemini usage logs, prompt logging and data-loss tools have nothing to inspect. What you do have is the control plane: the record of who changed policies, keys, members and billing links. The bill is the first symptom most victims see, and it arrives after the money is spent.
The hunt
All of this comes from Wiz's guidance and works with Google's own audit logs, no product required.
- List the projects linked to each billing account and confirm you own every one. A project you do not recognize is the finding.
- Search audit logs for SetOrgPolicy changes, especially any deletion of iam.allowedPolicyMemberDomains.
- Search for EnableService turning on the Gemini API, and for CreateServiceAccount, CreateServiceAccountKey and CreateKey, in projects that have been quiet for months.
- Review IAM on billing accounts and the organization for members outside your domains, such as gmail.com addresses, and for recent role changes on billing administrators.
- Search for activity from 212.73.134.136 in Workspace and Cloud logs, and for the phishing domains below in DNS and proxy logs.
- Set a budget alert with a hard action on every billing account, and treat a sudden AI-cost surge as a security event, not an accounting one.
- Watch Workspace login alerts. Google flagged the suspicious logins in these cases; the alerts were there to be read.
The indicators
Wiz published one IP address and 17 domains. We checked each against our corpus first. None was there; the only nearby record is a different address in the same /24, 212.73.134.204, which served as a Tor exit in February and March, and that says nothing about this campaign. This is Wiz's research, not something we saw first.
We added all 18 to the DugganUSA feed at confidence 80, attributed to Wiz, under source manual-batch-wiz-llmjacking-gcp-2026-10, and read every one back. The IP appears in the ips.csv blocklist and the domains in domains.csv.
- IP: 212.73.134.136
- Domains (Wiz lists them as wildcards, so block subdomains too): gboogl.com, groosl.com, gprokl.com, gxoosl.com, gsoolg.com, gwoogl.com, gzoozl.com, groonl.com, gsool.space, gbrokl.space, gbrokl.xyz, gsoosl.xyz, gsool.xyz, gpoosl.com, groolg.com, gcslom.com, gcoalg.com
Credit to Wiz CIRT for the investigation and for publishing indicators and detection steps anyone can use.
If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Get your free key → analytics.dugganusa.com/stix/register
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=attackers-linked-their-own-google-cloud-projects-to-victims-billing-and-ran-gemini-on-their-money