Google Ads phishing and LLMjacking: how attackers hijack a Google Cloud account

1. A Google ad that leads to a fake sign-in page

It starts with an ordinary search. The user types “google cloud” into Google to open their console. At the top of the results sits a sponsored ad, accepted by Google Ads, that leads to a fake Google Cloud sign-in page: same interface, same look, nothing suspicious at first sight. The user enters their credentials, completes two-factor authentication and thinks they are signing in as usual. They are on a phishing page.

Wiz describes this technique precisely. The attacker buys Google ads on common administrative searches such as “google cloud” and “gcp”. The click goes through a redirect hosted on Google Sites before reaching the fake page, which captures the username, the password and the two-factor code, then sends the user back to Google’s real sign-in page. Forced to authenticate a second time, the user assumes it was a minor glitch.

• A sponsored ad at the top of the results for an administrative search (“google cloud”, “gcp”).
• A redirect, then a fake Google sign-in page identical to the real one.
• The username, password and two-factor code are typed in and captured along the way.
• A return to Google’s real page, which asks for a new sign-in and hides the trick.

2. A two-factor code replayed at once

Two-factor authentication does not help here, because the code is used within seconds of being typed. According to Wiz, the phishing kit is automated: it uses the stolen credentials as soon as they are captured to open a first session in the victim’s Google Cloud environment, from its own IP address.

The attacker then signs in again a few minutes later from a second IP address used for the rest of the attack. In every intrusion Wiz investigated, later sign-ins came from addresses located in the country of the victim’s headquarters, even when that was not where the user was, so as not to trigger location-based alerts.

3. What Wiz documented

Wiz, the cloud security specialist whose acquisition by Google was completed on 11 March 2026, published on 20 October 2026 its analysis of several intrusions following this pattern, focusing on those targeting Google Cloud. The article describes the whole attack chain: a fake Google Ads ad, theft of the credentials and the two-factor code, then fraudulent use of the Gemini API at the victim’s expense.

Wiz also publishes indicators of compromise, including the phishing kit’s IP address and a list of domains that imitate Google’s name, along with the log searches to run. The article is cited in the sources at the bottom of this page: it is the reference to use when checking your own environment.

4. LLMjacking: hijacking cloud billing to pay for AI

Wiz uses the term LLMjacking for attackers who hijack their victims’ cloud billing accounts to fund large-scale use of large language models (LLMs). The goal is neither to encrypt data nor to break the environment: it is financial exploitation, where the victim pays for the attacker’s AI consumption.

Once signed in, the attacker in the campaign described by Wiz uses the stolen account’s broad permissions to settle in. One key point: the external projects linked to the billing account run their AI requests on the attacker’s side. The victim pays for the usage, but its own logs show neither the requests nor the model outputs.

• Enable the Gemini API in existing, little-used projects, then create service accounts and Gemini API keys there.
• Grant these service accounts high-privilege roles such as roles/ml.admin.
• Delete, at organisation level, the iam.allowedPolicyMemberDomains policy that restricts access to the company’s domains.
• Add external Gmail accounts to the billing account with the roles/billing.admin role.
• Link attacker-controlled Google Cloud projects to the victim’s billing account.
• Demote the legitimate billing administrators to read-only viewers, so they cannot detach those projects from the console.

5. An AI bill that runs away within hours

For the intrusions it analysed, Wiz reports that within 24 to 48 hours of initial access, victims saw charges reaching tens to hundreds of thousands of dollars in unauthorised Gemini API usage, far above their usual consumption. It is often the bill, not a security alert, that reveals the attack.

On Google Cloud, the Gemini models are also offered through Vertex AI, the AI platform Google renamed Gemini Enterprise Agent Platform in April 2026. Abnormal usage can therefore show up under either name in billing: the sudden surge is what should raise the alarm, whatever service is displayed.

6. Why everything looks legitimate

What stands out in this attack is that the user never has an objective reason to be suspicious. The ad was accepted by Google Ads, the fraudulent link is featured on Google, the page faithfully reproduces the sign-in interface, and the attacker’s sign-in is accepted with a valid password and code. To the user, everything looks legitimate; yet it is a trap from start to finish.

Wiz adds two points. In the cases it describes, Google flagged the sign-in as suspicious and sent security alert emails to the user, and Google Ads removed the campaign after it was reported. Wiz concludes that organisations should not rely on user awareness alone but monitor sign-in events themselves. The technique, a sponsored ad leading to a fake sign-in page, is not specific to Google Cloud either: it can target any sensitive service, a bank, AWS, Azure or Microsoft 365.

7. Two habits that stop the attack

The first habit costs nothing. A phishing page only works if you land on it: by opening consoles from a saved bookmark rather than from a search engine, the user never sees the fraudulent ad.

The second concerns two-factor authentication. In this attack, the code is typed into the fake page and replayed at once by the attacker: a code received by text message or generated by an app does not protect against this relay. Passkeys and FIDO2 security keys resist phishing; Google presents security keys as the most secure form of 2-step verification, one that protects against phishing. Failing that, phone approval with number matching is better than a plain text message: the US cybersecurity agency CISA recommends it as an interim measure against repeated approval requests, while noting that it remains weaker than a phishing-resistant method.

• Save your admin consoles (Google Cloud, AWS, Azure, Microsoft 365, your bank) as bookmarks and always go through them.
• Turn on passkeys or FIDO2 keys for privileged accounts, starting with administrators and billing owners.
• Failing that, prefer phone approval with number matching to text-message codes.

8. On the Google Cloud side: check and limit the damage

If you administer a Google Cloud environment, Wiz’s detection guidance makes a good checklist, even without any sign of an attack. It covers the Google Workspace logs, the Google Cloud Admin Activity logs and the billing logs.

On prevention, the organisation policy that restricts access to the company’s domains must stay in place and be monitored, since deleting it is one of the attacker’s first moves. On costs, Google points out that a standard budget only sends alerts and does not cap spending; spend cap budgets, on the other hand, pause usage of eligible services in a project once the amount is reached. Wiz recommends monitoring abnormal surges in API usage and considering such caps.

• Search the Google Workspace and Google Cloud logs for the indicators of compromise published by Wiz (the phishing kit’s IP address and phishing domains).
• List IAM users from external domains, especially @gmail.com addresses.
• Review changes to organisation policies, especially allowedPolicyMemberDomains, and changes to billing account administrators.
• Look for unexpected Gemini API enablement, service account creation and API key creation, especially in old projects.
• Check the projects linked to the billing account and set up spend alerts and caps.

9. Key takeaways

There is a lot of talk about firewalls, antivirus software and sophisticated security tools. This attack is a reminder that clicking the top Google result can be enough to compromise a whole cloud environment, two-factor authentication included, and that the first visible sign is often the bill.

The defences are simple and cheap: bookmarks to reach consoles, phishing-resistant authentication for privileged accounts, billing permissions kept to the bare minimum, alerts on sign-ins and on costs. That is what we set up for our hosting and managed services clients.

Sources and documentation

• Wiz CIRT: From Phishing to LLMjacking, threat actors targeting cloud billing accounts for LLM usage (20 October 2026)
• Cleary Gottlieb: Google completes its acquisition of Wiz (11 March 2026)
• Google Cloud: Vertex AI renamed Gemini Enterprise Agent Platform (release notes, 22 April 2026)
• Google Workspace: 2-Step Verification, security keys and passkeys
• CISA: Implementing phishing-resistant MFA
• CISA: Implementing number matching in MFA applications
• Google Cloud: restricting identities by domain (organisation policy)
• Google Cloud: budgets and budget alerts
• Google Cloud: spend cap budgets