From Phishing to LLMjacking: Threat Actors Targeting Cloud Billing Accounts for LLM Usage

The Wiz Customer Incident Response Team (CIRT) has investigated a rising threat pattern in cloud environments: threat actors hijacking cloud billing accounts to fund unauthorized AI usage. Threat actors are not only using AI as a tool to conduct attacks, they are also compromising victim environments solely to abuse their finances for mass Large Language Model (LLM) execution, incurring hundreds of thousands of dollars in AI API charges.

Wiz CIRT has investigated multiple intrusions demonstrating this pattern, with this blogpost focusing specifically on campaigns targeting Google Cloud Platform (GCP) infrastructure. In these attacks, threat actors compromised privileged GCP user credentials and linked external, attacker-controlled GCP projects directly to the victim's internal billing accounts. Because the AI workloads were processed in foreign projects, prompt contents and model outputs remained completely hidden from the victim organization, leaving the nature of the mass AI usage unknown.

This blogpost details the full attack lifecycle observed across these intrusions, from the initial phishing and policy manipulation to cross-tenant project linking, and provides actionable threat hunting guidance to help organizations detect LLMjacking in their environments.

Initial Access: Phishing via Sponsored Search Ads The attack began with a classic yet efficient phishing tactic. The threat actor purchased Google Search ads for common administrative search terms such as “google cloud” and “gcp”. When a user clicked the malicious ad, they were led through a Google Sites redirect to a fake Google login web page. Victim users with valid access to Google Console proceeded to input their account credentials and multi-factor-authentication (MFA) codes into the phishing page. The malicious site captured the user supplied credentials before seamlessly redirecting the user back to the legitimate Google authentication prompt. Forced to authenticate a second time, the user likely assumed the initial attempt was a minor glitch. In reality, the automated phishing kit immediately leveraged the harvested credentials to execute the first malicious login into the victim’s GCP environment from 212.73.134[.]136, the source IP address of the phishing kit. The threat actor then reauthenticated a few minutes later from a second IP address, which was later used for the rest of the GCP activity. Following reports of this activity, Google Ads has taken action to remove the malicious ad campaign.

Google automatically flagged the anomalous login attempt as suspicious and dispatched security alert emails to the user's inbox. However, to catch such intrusions early, organizations should not rely on user awareness alone, but ingest and monitor Google Workspace User Log Events for suspicious login flags and anomalous re-authentication triggers.

Once inside the environment, the threat actor leveraged the compromised account’s excessive privileges to solidify their access, bypass organizational security controls, and prepare the billing architecture for external exploitation.

Rather than creating new infrastructure from scratch, the attacker targeted existing, low-usage GCP projects to:

• Enable the Gemini API product
• Create service accounts with Gemini API keys
• Add the newly created service accounts to high privileged roles such as roles/ml.admin androles/mcp.toolUser

To expand their reach without raising immediate alarms within internal domain governance, the threat actor deleted safety policies at the organization level, such as iam.allowedPolicyMemberDomains. This action removed the guardrail that restricts Identity and Access Management (IAM) membership to verified company domains, enabling external, personal accounts to be granted access as well as high-privilege permissions.

With domain restrictions lifted, the compromised user account was leveraged to add external actor-controlled Gmail accounts directly into the organization's billing account.

The threat actor also assigned administrative roles to the compromised users or the external accounts, such as:

The role roles/billing.admin granted full control over the billing account, including the ability to manage permissions, attach external projects, and alter payment settings.

The threat actor linked external GCP projects directly to the victim’s internal billing account. This move established a cross-tenant access, allowing all API requests executed in the threat actors external projects to be automatically charged to the victim's billing account while keeping prompt payloads invisible to internal log monitoring.

Once initial access was secured, threat actors employed defense evasion techniques designed to avoid triggering location-based security alerts and prevent security teams from regaining control.

In each of the intrusions investigated, Wiz CIRT observed that after the initial login, subsequent threat actor activity shifted to originate from IP addresses geolocated within each victim organization's headquartered country, even when this did not match the compromised user’s actual physical location.

Additionally, after securing administrative control, the threat actors demoted pre-existing internal billing administrators from their administrative roles down to read-only billing viewers. This modification stripped legitimate administrators of their ability to revoke permissions or detach rogue projects directly from the console.

The primary objective of these intrusions was non-destructive financial exploitation - leveraging hijacked cloud infrastructure to offload the costs of high-volume LLM inference. Across the observed cases, the impact manifested as rapid billing surges driven by automated, large-scale Gemini API utilization.

Within 24 to 48 hours of initial access, victim organizations experienced unexpected charges reaching tens to hundreds of thousands of dollars in unauthorized Gemini API usage. This activity represented a sharp surge from the organizations' established baseline compute spend.

Because the threat actors linked external, attacker-controlled GCP projects directly to the victim’s billing accounts, all API key generation, prompt requests, and model outputs occurred entirely within foreign tenants. Consequently, while the victim organization carried financial responsibility for the API consumption, internal security and audit logs provided no visibility into the nature, content, or context of the AI workloads being executed.

To detect potential LLMjacking and unauthorized billing account manipulation in your Google Cloud environment, security teams should hunt for indicators across Google Workspace, GCP Admin Activity, and Cloud Billing audit logs. Wiz customers can review the Threat Intel Center advisory that includes the following indicators:

• Review Google Workspace and GCP audit logs for activity from the indicators of compromise section below. Wiz customers can use this Cloud Events query .
• Review GCP IAM for any users with external domains, especially non-corporate email providers such as @gmail.com. Wiz customers can use this Cloud Events query , and replace the domain.com with their own organization domain.
• Review GCP audit logs for changes to organization policy controls, especially allowedPolicyMemberDomains , and IAM policy changes related to billing account administrators. Wiz customers can usethis Cloud Events query .
• Review GCP audit logs for unexpected Gemini API enablement, service account creation and service account API key creation in old projects Wiz customers can use this Cloud Events query .
• Monitor abnormal cost surge in API usage, and potentially enforce spend cap budgets. Wiz Cloud Cost customers can detect abnormal AI usage per model and cloud provider by monitoring Cost Monitor Findings for Resource Anomalies.

Wiz Defend customers ingesting cloud logs such as Google Workspace will get Wiz Threats on the initial logins. Customers ingesting GCP audit logs will get Threats for the described activity.

If you experience a breach or any cloud security incident, contact Wiz CIRT for incident response support.