Skip to content
Tuesday, October 20, 2026AboutContactRSS
Cloud Security

Wiz Reports Attackers Hijack GCP Billing Accounts for Unauthorized LLM Usage

Threat actors use phishing ads to steal credentials and link external projects to victim billing, incurring massive AI API costs.

Illustration: A cloud interface dashboard displays a billing section with a connected external project.
AI-generated illustration: Threat Times

Key points

  • Wiz CIRT identified campaigns where attackers hijack Google Cloud Platform billing accounts to fund unauthorized Large Language Model execution.
  • Initial access occurs via malicious Google Search ads that redirect users to fake login pages to harvest credentials and multi-factor authentication codes.
  • Attackers delete organization-level safety policies to allow external accounts, linking attacker-controlled projects to victim billing while hiding AI usage.

Wiz Customer Incident Response Team researchers have identified a growing attack pattern where threat actors compromise cloud billing accounts to fund unauthorized artificial intelligence usage. According to the firm’s first-hand research, these intrusions result in hundreds of thousands of dollars in unauthorized AI API charges for victim organizations.

The attacks specifically target Google Cloud Platform infrastructure, with threat actors stealing privileged user credentials to link external, attacker-controlled projects directly to the victim’s internal billing accounts. Because the AI workloads run in foreign projects, the prompt contents and model outputs remain hidden from the victim, obscuring the nature of the mass usage.

Attack Lifecycle and Credential Theft

The intrusion chain begins with phishing campaigns delivered through sponsored search ads on Google Search, according to Wiz. Threat actors purchase ads for common administrative terms like “google cloud” and “gcp,” directing users to malicious sites hosted on Google Sites. These pages mimic legitimate Google login forms to capture account credentials and multi-factor authentication codes from users with valid Google Console access.

After harvesting the credentials, the phishing kit automatically executes a malicious login from the source IP address 212.73.134[.]136. The threat actor then reauthenticates from a second IP address, which is used for subsequent activity within the victim’s environment. Wiz notes that Google Ads has since taken action to remove the specific malicious ad campaign following reports of this activity.

Privilege Escalation and Billing Hijacking

Once inside the environment, the threat actor leverages excessive privileges to disable security controls and prepare the billing architecture for exploitation, according to the Wiz report. Rather than building new infrastructure, the attackers target existing, low-usage GCP projects to add service accounts with high-privilege roles such as roles/ml.admin and roles/mcp.toolUser.

To expand their reach without triggering internal domain governance alerts, the threat actor deletes organization-level safety policies, including iam.allowedPolicyMemberDomains. This action removes the restriction that limits Identity and Access Management membership to verified company domains, allowing external personal accounts to gain high-privilege access. The attackers then invite their own external accounts and link them to the victim’s billing account.

Detection Challenges and Industry Context

Google automatically flags these anomalous login attempts as suspicious and sends security alert emails to the affected user’s inbox, according to Wiz. However, the firm warns that organizations should not rely solely on user awareness to catch such intrusions early. Instead, security teams should ingest and monitor Google Workspace User Log Events for suspicious login flags and anomalous re-authentication triggers.

This development follows earlier reporting on the abuse of open-source AI platforms for malicious purposes. As Threat Times reported on October 20, 2026, cyber researchers identified malicious clusters using the Cairn engine to automate persistent access and financial theft against hundreds of global websites.

What should you do?

Organizations should monitor Google Workspace User Log Events for anomalous re-authentication triggers and suspicious login flags rather than relying on user-reported alerts. Security teams should audit organization-level IAM policies, specifically checking for the deletion of iam.allowedPolicyMemberDomains, to ensure external accounts cannot be granted access. Administrators should review linked GCP projects and billing accounts regularly to detect any unauthorized external projects that may be incurring costs.

What to do and how to stay safe: Wiz

  • Monitor Google Workspace User Log Events for suspicious login flags and anomalous re-authentication triggers to detect early intrusion signs.
  • Audit organization-level IAM policies to ensure safety controls like iam.allowedPolicyMemberDomains are active and not deleted by attackers.
  • Regularly review linked GCP projects and billing accounts to identify unauthorized external projects that may be generating unexpected costs.
  • Investigate any high-privilege role assignments, such as roles/ml.admin, added to service accounts in low-usage projects without prior authorization.

Step-by-step guide: Cloud Misconfiguration Response: Containment, Recovery and Prevention Steps

General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

How do threat actors initially gain access to the victim's GCP environment?

They use malicious Google Search ads that redirect users to fake login pages to harvest credentials and multi-factor authentication codes.

Why is it difficult for victims to detect the unauthorized AI usage?

The AI workloads are processed in attacker-controlled foreign projects, so prompt contents and model outputs remain hidden from the victim organization.

What specific policy do attackers delete to allow external account access?

Attackers delete the iam.allowedPolicyMemberDomains policy, which normally restricts IAM membership to verified company domains.

Sources

  1. Wiz
Related articles