LLMjacking: stolen cloud keys, a $60 "unlimited" AI plan, and a victim left with a $1 million bill

Background

Cloud AI platforms — Amazon Bedrock, Google's Gemini API and Vertex AI, Azure OpenAI and others — bill by usage. Whoever holds a valid key or cloud identity with access to them can run up charges, and the bill goes to the account owner. That makes stolen AI access directly monetizable in a way stolen compute for cryptomining never quite was.

This case study is built on Google Threat Intelligence Group (GTIG) and Mandiant's November 2, 2026 report on incidents Mandiant responded to during 2026, affecting financial services, retail, technology and transportation organizations in North America, South America and Asia Pacific. The victims are not named; the attack lifecycle is documented in detail.

From a leaked key to a resold AI subscription

What actually happened

Across the incidents Mandiant handled, the dominant entry point was stolen cloud identity material: IAM credentials, service account keys, GitHub personal access tokens and active session tokens. One cluster GTIG tracks as UNC6993 compromised a cloud instance through a misconfigured service account key in mid-2026; it also ran a fake "application portal" for an LLM user group that tricked people into pasting a raw JSON payload containing a live access token, bypassing passwords and MFA. Other actors used cloud federation tokens to mint fresh access keys around MFA, scraped LLM API keys from public GitHub repositories and quietly tested each with a one-token request (max_tokens=1) to stay under volume alerts, or probed publicly exposed model endpoints.

Once inside, attackers mapped services and identity policies across regions, cloned code repositories to hunt for hard-coded secrets, and queried data-warehouse metadata for database credentials. They escalated by minting tokens for higher-privilege service accounts, attaching administrative policies, creating full-admin IAM accounts and backdoor service accounts disguised as "billing optimization utilities," and injecting SSH keys into VM and project metadata. A follow-on cluster exploited a LiteLLM gateway flaw (CVE-2026-40217) to turn ordinary virtual keys into proxy-admin master credentials.

Then they monetized. Attackers enabled managed AI services that were not switched on at the time of compromise, created additional API keys, signed victim accounts up to pay-as-you-go agreements, requested quota increases, and ran high-volume inference against premium models. UNC6993 quickly ran up more than $100,000 in charges this way. Much of the access ended up in "LLM mixers" — gateways that pool stolen keys, meter usage and resell it. One actor made more than 500,000 LLM API calls in under eight hours with stolen third-party keys to power a token-routing service called Jet Night, which advertised unlimited frontier-model access for about $60 a month and passed nearly $1 million in token costs to the victim. Jet Night's own channel advertised outages that GTIG believes coincided with victims discovering the theft and revoking keys.

Root cause

Timeline

Detection

What to monitor for in your own environment

Containment, eradication & recovery

Security control analysis

Controls that would have prevented or limited this

Blast radius

What stolen AI access costs the victim vs. what it sells for

What they got right

GTIG and Mandiant published the full lifecycle with concrete log events to alert on for GCP, AWS and Azure, and named indicators (jet-night.com, newapi.pro) — guidance defenders can implement directly.

Victims that revoked keys disrupted the resale services immediately, showing that fast revocation directly cuts off the attacker's revenue.

The report separated the two businesses — initial-access actors and LLM mixers — which helps defenders and providers target both.

Why this keeps happening

Cloud keys and AI API keys are created freely by developers, embedded in code and notebooks, and rarely given budgets or scopes.

Many organizations have AI services available in every project by default, even where no one uses them.

Inference logging is often off by default, so the first signal is the invoice.

An underground resale market now exists to turn any stolen key into cash within hours.

Lessons for your own environment

1. An AI key is a credit card — give it a limit

   Budgets and per-key quotas are the single control that caps the loss regardless of how the key was stolen.

2. Switching on an AI service is a security event

   Attackers enabled services victims never used. Alert on enablement the way you'd alert on a new admin.

3. Service account keys are the weak point

   They were the most common way in. Move to workload identity and delete keys you don't need.

4. Turn on inference logging before you need it

   Data-access logs for AI calls are off by default on some platforms. Without them you see the bill, not the abuse.

5. Patch your AI gateways like any other internet-facing service

   A LiteLLM flaw turned ordinary keys into master credentials. Proxies and gateways belong in your patch program.

6. Scan for secrets everywhere code lives

   Keys scraped from public GitHub repos were validated with a one-token request and resold.

CISO & board lessons

• Require a budget, quota and named owner for every AI API key and every project with AI services enabled. No owner, no key.
• Make AI service enablement, new key creation and logging-configuration changes critical alerts routed to the SOC, not just billing notifications.
• Set a target date to eliminate long-lived service account keys and classic tokens in favor of workload identity and short-lived credentials.
• Include AI gateways and model proxies (LiteLLM and similar) in vulnerability management and attack-surface inventories.
• Agree in advance with your cloud and AI providers how fraudulent-usage disputes are handled. Refund practice has been discretionary.

Action plan

Could this happen in your organization?

• Does every AI API key and AI-enabled project in your cloud have a spending cap and quota?
• Would you get an alert — not just a bill — if someone enabled Bedrock, Vertex AI or Azure OpenAI in a project that never used it?
• Is inference data-access logging switched on for your AI services?
• How many long-lived service account keys exist across your cloud accounts?
• Do you scan every repository and CI log for exposed AI and cloud keys?
• Are your AI gateways and model proxies patched and inventoried like other internet-facing services?

If this happened to you: what to ask, and what to say

Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.