Google: attackers ran up AI bills of up to $1 million on victims' accounts

An AI key is spending authority

A company's AI account works like a metered utility. Whoever holds the key spends the money. The account owner gets the bill.

Google's latest threat report shows what happens when the wrong person holds that key. This is the argument here: treat AI keys as spending authority, not as configuration files.

What Google found

Google Threat Intelligence Group and Mandiant call the tactic LLMjacking. The attacker obtains an API key. That is a password that lets software use an AI service. The attacker then runs work on the victim's AI accounts, and the victim pays.

Google says the targets were not clustered in one place. Affected organizations were spread across the Americas and the Asia Pacific region. Their sectors included financial services, retail, technology and transportation.

Across individual incidents, the researchers saw charges above $100,000 in a single day. At some organizations, total charges reached $1 million before access was revoked.

Google contrasts this with cryptojacking, the older theft of computing power to mine coins. That drain is gradual. LLMjacking can spike the bill within hours.

How the attackers got in

The most common entry point was an exposed or stolen cloud identity token. A token is a digital pass that proves who you are. Google groups these passes into four types: cloud login credentials, keys issued to software accounts, GitHub access tokens, and tokens from sessions already logged in.

Other cases began with AI keys found in public GitHub repositories. Google also names phishing, source code leaks and exposed client-side code as ways keys get out.

Google tracks one group as UNC6993. It entered a cloud environment through a poorly configured Service Account key. A Service Account key is a pass issued to software, not to a person. From there the group reached an AI service.

The group also ran a fake sign-up page for an AI user group. The page asked people to paste a block of login data, including a live access token, into a form. It then sent the token to the attacker. Google says that route bypassed password and multi-factor checks.

The mechanism is straightforward. A session token proves a login already happened. A thief who holds it can skip the second-factor prompt.

From one key to the wider cloud

Once inside, Google says, the actors escalate their privileges quickly. They look for more credentials. They copy code to search for secrets that developers left in it.

They also created backdoor service accounts. The names were chosen to look like internal tools for trimming cloud bills.

Some actors used CVE-2026-40217 in LiteLLM to gain higher privileges. LiteLLM is software that routes requests between applications and AI models.

Others used a method Google calls "burn and rotate". They kept creating and deleting short-lived service accounts to get around rate limits.

Google says UNC6993 created extra API keys to scale up, racking up over $100,000 in billing charges.

A resale market for unauthorized access

Google also describes a new kind of actor, the LLM Mixer. These gateways pool unauthorized AI access and resell it to other criminals through underground shops.

Google names one seller, Jet Night. It advertises a plan of about $60 a month with no token cap. It claims to offer a top-tier model, and Google calls that access alleged.

This splits the crime into two jobs. One group breaks in. Another sells what was taken. The victim keeps paying until the misuse is found.

A related case: an employee trying a coding assistant

Symantec and Carbon Black described a different service last week. It is a grey-market reseller of Western AI coding tools.

The reseller does not ship its own software. Symantec says the official OpenAI Codex and Anthropic Claude Code tools are installed in the normal way. Users are then likely told to run a one-line command that fetches a setup script.

The script rewrites each tool's settings. It switches off the protective sandbox and swaps the user's real credentials for tokens issued by the reseller. Every request then travels through the reseller's servers instead of the vendors' own.

Symantec assesses the service as active since at least early 2026. It mainly affected about a dozen organizations in Mainland China. Subsidiaries in South Korea, Taiwan and Malaysia were also affected.

Symantec's assessment is that the reseller aims at countries where those two vendors offer no service. An install appears to begin when an employee wants to try a Western coding assistant and finds the unofficial reseller. Symantec suspects the operators are circumventing regional restrictions and reselling capacity below market rates.

Symantec found no evidence that the service reads prompts or alters answers. That is a limit of the finding, not proof the service is safe.

The next point is this article's argument, not Symantec's. If staff have no sanctioned way to use these tools, an unapproved one is easy to find.

Questions to put to your team

Ask where every AI key lives. Check code repositories and client-side code, since Google names both as sources of exposed keys.

Ask who is alerted when AI spending jumps. A monthly invoice is too slow for charges that can build in hours.

Ask whether a stolen session token alone could reach your AI accounts.

Ask who patches AI routing software such as LiteLLM. Ask whether CVE-2026-40217 has been checked.

Ask whether staff have a sanctioned way to use AI coding tools. Without one, unapproved routes become easier to find.

An AI key is not a setting. It is a signature on a blank cheque.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Hacker News.