LLMjacking Attacks: Google Sees $100K Bills in a Single Day

Google Threat Intelligence Group and Mandiant say LLMjacking attacks, in which intruders hijack a company's access to large language models, have produced fraudulent cloud charges above $100,000 in one day and up to $1 million before access was cut. The attackers rarely go through the model itself. They use the same leaked keys and tokens cloud teams have been losing for years.

What are LLMjacking attacks?

LLMjacking is the hijacking of an organization’s access to large language models: the attacker consumes paid model compute and the victim pays the bill. Google Threat Intelligence Group (GTIG) and Mandiant issued the warning on Monday, November 2, 2026, in a report shared with The Hacker News.

Sysdig researchers coined the term in 2024 after finding stolen cloud credentials used to call hosted model APIs. Google adds scale, a named actor and a picture of the market that buys this access. It separates two tiers of abuse:

• Low tier: manipulating a customer-support chatbot into tasks it was never meant to do, such as writing code.
• High tier: attacking backend model resources directly, through publicly exposed LLM endpoints or valid stolen LLM API keys. This is LLMjacking proper, and it is where the money goes.

The second tier is not prompt injection. It is a cloud intrusion that pays out in model tokens instead of Monero.

How much can an LLMjacking incident cost?

In incidents Google observed, fraudulent charges passed $100,000 in a single day, and cumulative charges at some organizations reached $1 million before access was revoked. “Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours,” the report says.

Managed model services such as Amazon Bedrock, Azure OpenAI and Google Vertex AI sit behind the same IAM and billing constructs as any other cloud resource. A stolen key with model-invocation rights produces charges that look like legitimate spend. No malware lands and no host CPU graph climbs. The first signal is often a cost anomaly alert, if anyone configured one.

Victims are in North America, South America and Asia Pacific, in financial services, retail, technology and transportation. Google gave no victim count, no names and no detail on how the incidents were detected.

Cryptojacking, the dominant cloud resource-theft pattern since around 2017, burned compute slowly for modest returns. Google expects LLMjacking to displace it, “driven by the immediate, high-margin monetization enabled by emerging underground LLM Mixers.” Higher-tier models cost more per token, so every model upgrade an enterprise makes raises the resale value of a key that can call it.

How do attackers steal LLM API keys and cloud tokens?

The most common way in is exposed or stolen cloud identity material: IAM credentials, service account keys, GitHub personal access tokens (PATs) and active session tokens. The report describes these routes:

• Phishing, source-code leaks, misconfigured environments and exposed client-side code.
• LLM API keys left in public GitHub repositories.
• Compromised IAM credentials of corporate users, used to programmatically mint fresh access keys and sidestep MFA.
• A hacked cloud service account key carrying broad project permissions.
• A stolen GitHub PAT that opened private repositories, followed by exploitation of a suspected web application vulnerability in a package running inside a containerized cloud environment. Google did not name this actor.

Client-side exposure gets underrated: if a front end calls a model API directly, the provider key ships in the JavaScript bundle, and anyone with developer tools can copy it.

The MFA point needs precision. Service account keys, IAM access keys and PATs are bearer credentials, so possession is authentication. MFA protects the interactive login, not the long-lived key a developer created six months ago. “Bypassing MFA” here is how programmatic credentials work, not a defect in any MFA product.

Mapping which endpoints, bundles and identities expose model credentials is the first phase of LLM application penetration testing, before anyone writes a prompt.

Who is UNC6993 and what did it do?

UNC6993 is the one threat cluster Google named. It breached a cloud instance through a misconfigured service account key, reached an LLM API, then created additional API keys inside the victim’s cloud project to scale its usage. That generated more than $100,000 in billing charges.

In Google’s words, “UNC6993 also hosted a session hijacking page masquerading as an application portal to join a group of LLM users.” The page sent visitors to the legitimate LLM service website, then had them paste back a raw JSON payload containing an active access token, which was posted to a backend API. The victim had already passed the password and MFA checks. The attacker took the session.

The lure resembles paste-your-token tricks previously seen against OAuth device-flow logins. Google did not say how many users fell for it or which provider issued the tokens. The UNC prefix means Mandiant has not tied the cluster to a known group.

Both halves of the playbook are identity events. As we argued in AI agent incident response starts with the identity record, the first question is which credential acted, who issued it and what else it can reach.

What happens after the key is stolen?

After initial access, Google describes a standard cloud intrusion with a billing objective: privilege escalation, persistence and internal reconnaissance for more secrets. Observed steps included:

• Cross-region reconnaissance to map services and identity policies.
• Cloning sensitive codebases to find hard-coded secrets and developer credentials.
• Scanning access logs and querying databases for stored credentials, including those for secondary cloud environments.
• Abusing token-creation privileges on service accounts to mint temporary high-privilege credentials, then pulling infrastructure credentials, database passwords and third-party API keys from cloud secret managers.
• Creating unauthorized IAM and service accounts and injecting SSH keys into compute instances.
• Adding backdoor service accounts disguised as internal billing-optimization utilities.

To get past rate limits, some actors run a “burn and rotate” strategy, continuously creating and deleting short-lived service accounts. The payoff, in Google’s words, comes “through token proxying, automated model streaming, and GPU hardware provisioning.” Actors also used victim access to host their own proxy endpoints and agentic workloads.

What are LLM mixers, and what is the CLI relay?

LLM mixers are illicit routing gateways that proxy, aggregate and resell unauthorized model access to other criminals through underground storefronts. Initial-access actors steal keys and downstream operators sell the compute, the way stolen RDP logins became subscription products.

Google’s named example is Jet Night, a storefront advertising an unlimited token plan with alleged frontier-model access for about $60 a month. The domain is not reproduced here. That price only works because a victim pays the real invoice.

A separate report from Broadcom-owned Symantec and Carbon Black, published the previous week, describes a grey-market relay that does not steal keys at all. Per Symantec, it installs the genuine OpenAI Codex and Anthropic Claude Code CLIs, then rewrites their configuration “to switch sandboxing off, in Codex’s case by setting it to ‘danger-full-access,'” and routes every request through its own servers.

After a legitimate npm install, the user is likely told to run a one-line command that fetches a fileless PowerShell or bash script from a lookalike domain. The script edits ~/.codex/config.toml or ~/.claude/settings.json and leaves the binaries untouched. It disables the execution sandbox, enables network access for the write sandbox, swaps the user’s API credentials for relay-issued tokens, and turns off telemetry and error reporting. It also checks the Windows locale to confirm the machine is in the region the service serves.

Symantec assesses the service has been active since at least early 2026, hitting a dozen organizations mostly in mainland China, plus multinational subsidiaries in South Korea, Taiwan and Malaysia, in sectors from semiconductors and pharmaceuticals to shipping and data center services. The apparent customers are employees in markets where OpenAI and Anthropic do not operate. Symantec found no evidence of prompt harvesting or altered responses, and nothing published links the relay to UNC6993 or Jet Night.

The risk sits in the setup: a coding agent with shell and filesystem reach runs unsandboxed, and every file it reads passes through a third party’s servers. An AI supply chain security audit should treat agent CLI configuration as part of the developer toolchain.

What should security teams check now?

Start with the controls that would have shortened every incident in the report:

• Page on spend, don’t just report it. Set per-project and per-key thresholds on model invocation in Bedrock, Vertex AI and Azure OpenAI, and route alerts to on-call. A monthly cost review finds a $1 million problem a month late.
• Inventory long-lived keys. List every service account JSON key, IAM access key, GitHub PAT and provider API key with its age, scope and last use. Delete unused ones, rotate the rest, and move workloads to workload identity federation or OIDC where the platform supports it.
• Restrict who can mint tokens. Token-creator and key-creation rights on service accounts are the escalation path Google describes, so very few identities should hold them.
• Hunt for burn and rotate. Look for bursts of short-lived service accounts with model-invocation roles, especially ones created by a human identity or from an unfamiliar region.
• Scan front ends and repos. Search shipped JavaScript bundles and git history for provider keys, and turn on push protection.
• Check developer endpoints. Compare Codex and Claude Code config files against a managed baseline: sandbox mode, API base URL, credential source and telemetry flags.
• Patch LiteLLM. Google cites CVE-2026-40217 as a privilege-escalation flaw in LiteLLM and expects attackers to keep targeting model-routing middleware. Public reporting gives no CVSS score, affected versions or fixed version, so read the project’s advisory before you triage, and keep the router off the internet.

A router holds keys for several providers; compromise it and you get every key behind it.

From our cloud engagements: the path to a model API is rarely a model bug. It is a service account key in a CI variable, a PAT with org-wide repo scope, or a role that can impersonate a more privileged one. A cloud configuration review that traces token-minting and model-invocation rights should prove those paths are closed.

FAQ

What is LLMjacking?

LLMjacking is the hijacking of an organization's access to large language models so an attacker consumes paid model compute at the victim's expense. It usually starts with stolen cloud credentials or LLM API keys rather than an attack on the model itself.

How much money can LLMjacking cost a company?

In incidents Google observed, one day of abuse cost more than $100,000, and some organizations accumulated $1 million in charges before access was revoked.

Who is UNC6993?

UNC6993 is a threat cluster Mandiant tracks but has not tied to a known group. It abused a misconfigured service account key and ran a fake LLM user-group portal that collected pasted access tokens.

What are LLM mixers?

LLM mixers are illicit gateways that proxy, aggregate and resell stolen model access to other criminals. Google names Jet Night, which advertises an unlimited token plan for about $60 a month.

agent::offense tests the full path from a leaked key to a model invocation on your bill, across cloud identity, routing middleware and the agents your developers run. See our AI and LLM security testing to scope an assessment.