LLMjacking Cloud Bills: Stolen Keys, $1 Million AI Charges

Google Threat Intelligence Group and Mandiant say LLMjacking cloud bills have topped $100,000 in a single day, with some victims reaching $1 million before the stolen credentials were revoked. For Cyprus and EU firms that hand service account keys and GitHub tokens to AI projects, the invoice is often the first sign of a compromised identity.

Why are LLMjacking cloud bills reaching $1 million?

On Monday, Google Threat Intelligence Group (GTIG) and Mandiant warned that criminals are hijacking enterprise access to large language models and leaving victims to pay for the compute. Sysdig researchers coined the term LLMjacking earlier for the same abuse. The mechanics are simple: an attacker obtains an API key or equivalent credential for an organization’s LLM accounts, runs workloads through it, and the owner gets the bill.

Google observed incidents where fraudulent consumption exceeded $100,000 in one day. At some organizations, cumulative charges reached $1 million before access was cut. Victims sit in North America, South America and Asia-Pacific, across financial services, retail, technology and transportation. The report does not name them.

“Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours,” the researchers wrote. A stolen key pointed at a frontier model turns into sellable inference immediately, which is why Google expects attackers to favor LLMjacking over cryptojacking.

How do stolen LLM API keys and cloud identities leak?

The most common foothold is exposed or stolen cloud identity material, not a leaked chatbot password: IAM credentials, service account keys, GitHub Personal Access Tokens (PATs) and active session tokens. They escape through phishing, source-code leaks, misconfigured environments, client-side code that ships secrets to the browser, and keys committed to public repositories.

Access to Amazon Bedrock, Google Vertex AI or Azure OpenAI is usually governed by the same cloud IAM that controls everything else in the account. A service account that can read a storage bucket and also invoke a model is one leak away from a six-figure bill. Direct OpenAI or Anthropic keys copied from an environment file are simpler still. Google also observed:

• Corporate IAM credentials used to programmatically generate fresh access keys, which sidesteps MFA because access keys never prompt for a second factor.
• A hijacked service account key with broad project permissions.
• LLM API keys harvested from public GitHub repositories, and publicly exposed LLM endpoints.

One unidentified attacker used a stolen PAT to open private repositories, then exploited what Google calls a suspected vulnerability in a package running in a containerized cloud environment. The exact flaw has not been confirmed.

How did UNC6993 turn one key into a six-figure bill?

UNC6993 got in through a misconfigured service account key on a cloud instance, pivoted to LLM API access, and minted additional API keys to scale its use inside victim projects. Charges exceeded $100,000. UNC is Mandiant’s prefix for an uncategorized cluster; Google gives no nation-state or other attribution.

Its second path was a page posing as an application portal for an LLM user community. It sent visitors to the legitimate LLM service, then asked them to paste back a raw JSON payload containing an active access token, which went to an attacker backend. The victim had already passed password and MFA checks on the real site, so the stolen session arrived fully authenticated. Nothing sensitive was typed on the fake page.

The extra API keys are the persistence. Revoking the original service account key does not stop a key minted from it an hour later, so containment has to enumerate every key created in the project during the incident window.

What does the attacker do after the first key works?

Once inside, the actors follow a consistent routine, and each step leaves traces in logs:

• Multi-region reconnaissance of cloud services, repositories, data stores and identity policies.
• Cloning sensitive codebases for hard-coded secrets and developer credentials.
• Scanning access logs and querying databases for credentials to secondary environments.
• Abusing token-creation rights to mint temporary credentials for high-privilege accounts.
• 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.

Backdoor service accounts were disguised as internal billing-optimization utilities. Some actors also use “burn and rotate”, continuously creating and deleting short-lived service accounts to get around rate limits. The goal is monetization through token proxying, automated model streaming and GPU provisioning, plus proxy endpoints and agentic workloads hosted on victim accounts.

LiteLLM CVE-2026-40217: patch the gateway

Google cites CVE-2026-40217 in LiteLLM as a vulnerability actors exploited to escalate privileges. LiteLLM is an open-source proxy many companies run as a shared LLM gateway, so one instance can hold upstream keys for every model provider. The report gives no CVSS score, affected versions or fixed release, so check the project’s own advisory. This is a different issue from the poisoned LiteLLM 1.107.0 release we covered earlier. Gateways like this belong in scope for LLM application penetration testing, not just the chat front end.

What are LLM mixers, and what did the Codex and Claude Code relay do?

LLM mixers are illicit gateways that proxy, aggregate and resell stolen model access through underground storefronts. Google names Jet Night, which sold an “unlimited” token plan with alleged frontier-model access for about $60 a month. That price only works because someone else pays the inference bill.

Symantec and Carbon Black, in a report published the week before, described a grey-market relay service active since at least early 2026. It appears to target markets where OpenAI and Anthropic do not operate. Users install the genuine OpenAI Codex or Anthropic Claude Code CLI through npm, then are likely told to run a one-line command that pulls a fileless PowerShell or bash script from a lookalike domain. The script checks the Windows locale, then rewrites ~/.codex/config.toml or ~/.claude/settings.json:

• It disables the CLI execution sandbox (for Codex, by setting it to danger-full-access).
• It enables network access for the write sandbox.
• It replaces the user’s real API credentials with relay-issued tokens.
• It disables telemetry and error reporting.

About a dozen organizations were affected, mainly in mainland China, plus subsidiaries of multinationals in South Korea, Taiwan and Malaysia, in shipping, semiconductors, pharmaceuticals, petrochemicals, electronics, industrial automation and data center services. Symantec found no evidence of prompt harvesting or altered responses. The risk remains: an unsandboxed agent with full network access routes every request through a third party, on a machine holding source code and cloud credentials. Cyprus shipping groups with Asian subsidiaries or ship-management partners should ask them directly whether developers use relayed coding agents.

What should Cyprus and EU firms check this week?

Start with billing and identity, because the invoice is often the only alarm and fraud refunds are not automatic.

1. Set budgets, quotas and anomaly alerts on every project with model access: Bedrock, Vertex AI, Azure OpenAI and direct vendor accounts.
2. Inventory every identity that can invoke a model, including PATs that reach repos holding keys. Replace long-lived keys with workload identity federation or short-lived tokens.
3. Review who can create keys or mint tokens: in GCP, the Service Account Token Creator role and key-admin permissions; in AWS, access-key creation and role-assumption paths.
4. List recently created service accounts, especially names mentioning billing, cost or optimization.
5. Search admin audit logs for service account create and delete pairs from the same caller, minutes apart. That is burn and rotate.
6. Scan repositories and client-side bundles for model keys. Treat any key ever pushed publicly as compromised: rotate it, then pull its usage history.
7. Patch LiteLLM and similar gateways, and keep their admin interfaces off the internet.
8. Check developer Codex and Claude Code config files for disabled sandboxes, non-vendor endpoints or tokens your organization did not issue.
9. Tell staff plainly that no legitimate portal will ask them to paste a raw access token.

Indicators named in the reports

• jet-night[.]com: storefront of the Jet Night LLM mixer (GTIG).
• vibe.aiok[.]me: lookalike domain serving the relay setup script (Symantec).
• CVE-2026-40217: LiteLLM privilege escalation exploited in these intrusions.

Block both domains at DNS and web proxy, then search proxy logs and developer shell history for earlier hits.

Preserve evidence before you revoke

The first evidence is the billing and usage console, not EDR. Before deleting anything, export per-key token consumption and per-service-account API call logs for the past 30 days, and snapshot IAM bindings. It takes minutes and preserves the attribution trail that hurried cleanup erases.

The path we find most often in AWS penetration testing and GCP penetration testing is not exotic: a CI secret or a developer’s old access key that grants far more than model invocation, often including the secret manager.

Is an LLMjacking bill a NIS2 or DORA incident?

Often, yes, because the bill is evidence of a credential compromise. DORA, which has applied since 17 January 2025, requires EU financial entities, including CySEC-supervised investment firms and EMIs licensed by the Central Bank of Cyprus, to classify and report major ICT-related incidents. Whether this one counts as major depends on the criteria, but a seven-figure loss plus access to secret managers would weigh heavily.

NIS2 sets a 24-hour early warning and 72-hour notification for significant incidents at in-scope entities, which include many cloud and managed-service providers. In Cyprus, the Digital Security Authority supervises NIS2, and notifications go through CSIRT-CY. The real question is what else the attacker touched. If credential-hunting database queries reached personal data, a GDPR breach assessment applies too.

Google expects the pressure to grow: “As enterprises integrate higher-tier models and agentic workflows into production environments, cybercriminals will likely refine automated reconnaissance to target exposed API tokens and exploit vulnerabilities in model routing middleware.” Firms putting agents into production this year should read that as a description of their own gateway.

FAQ

What is LLMjacking and who pays the bill?

LLMjacking is the use of a stolen API key or cloud credential to run large language model workloads on someone else's account. The owner pays, because providers bill the credential's project and fraud refunds are not automatic.

How is LLMjacking different from cryptojacking?

Cryptojacking consumes resources gradually and earns slowly. Google says LLMjacking produces large charge spikes within hours, above $100,000 in a single day, and monetizes immediately through resale.

What did Mandiant cluster UNC6993 do?

It used a misconfigured service account key to reach LLM APIs, minted extra keys and ran up more than $100,000. It also ran a fake community portal that collected pasted access tokens, bypassing password and MFA checks.

Is LLMjacking a reportable NIS2 or DORA incident?

It can be. The usage proves a credential compromise and these attackers also reached secret managers and repositories, so DORA classification and NIS2 assessment should start immediately; in Cyprus, notifications go to CSIRT-CY.

If you are not sure which leaked key would reach your model spend or your secret manager, our cloud and container security testing traces those paths before an attacker or an invoice does.