Google: LLMjacking runs victims' cloud AI bills past $1 million
GTIG and Mandiant detail an LLMjacking economy where stolen API keys run up to $1M in fraudulent cloud-AI charges, resold through routing services like Jet Night for $60/month.
Google's Threat Intelligence Group and Mandiant have published a report on LLMjacking — stealing access to cloud-hosted LLMs and billing the fraudulent inference to the victim. The primary source is GTIG's Monetizing compromised cloud models writeup; BleepingComputer and The Hacker News both covered it. The headline for anyone who owns a cloud bill: Google says cumulative fraudulent charges at some organizations reached $1,000,000, with single-day charges topping $100,000.
How the economy works
GTIG describes a supply chain, not a one-off abuse. Attackers gain initial access through exposed or compromised cloud credentials, service-account keys, GitHub tokens, active session tokens, and raw LLM API keys — then sell that access to intermediaries GTIG calls "LLM mixers" who resell it.
Two routing services are named. Jet Night (jet-night.com) made more than 500,000 LLM API calls in under eight hours on stolen third-party keys, and in one case "passed nearly one million dollars in token costs to the victim organization." It advertises "unlimited access plans" for $60 per month. A second relay, newapi[.]pro, works the same way. After access is resold, request volumes can spike past 1,000 requests per second against the victim's account.
Google tracks a cluster it labels UNC6993 using gateway tooling to aggregate stolen keys and distribute requests, likely selling through underground forums, and a persona called D1337-KAIROS that rebrands frontier models and exposes them through reverse proxies and Node.js proxy bundles planted on victims' cloud infrastructure. Attribution here is GTIG's clustering — treat UNC labels as activity groups, not named operators.
One CVE to watch
Among the initial-access paths, GTIG flags CVE-2026-40217, an arbitrary-code-execution flaw in LiteLLM's custom-code guardrail testing endpoint (/guardrails/test_custom_code). Public analysis describes a sandbox escape via bytecode rewriting that defeats regex source filtering; code runs as the LiteLLM process user, which is root in the default Docker image. If you run a LiteLLM proxy, patch it and keep the management port (default 4000) off the public internet.
What to do today
- Centralize and rotate secrets. Move cloud credentials, service-account and API keys into a managed secrets platform and rotate anything that has been exposed in logs, repos, or notebooks.
- Deny LLM access by default. Google's own guidance: "Deny all permissions that are not explicitly required, including access to Cloud LLM services." Grant inference permissions only to the identities that need them.
- Cap spend and set alerts. Put hard API usage and billing limits on cloud-AI services so a stolen key hits a ceiling, not a $100,000 day.
- Turn on inference and audit logging and alert on unauthorized service activation, suspicious credential checks, abnormal request rates, and attempts to disable logging.
- Enforce phishing-resistant MFA and hunt for shadow-AI endpoints and unauthorized proxy services running on your own infrastructure.
Context
Stolen model access is now a priced, resold commodity rather than opportunistic theft — the same shift this desk flagged when infostealer operators began ranking victims by the LLM credentials in their logs. The defensive problem is mostly old: exposed keys, over-broad IAM, unmonitored billing. What is new is the speed at which a leaked key converts to a six-figure invoice, and a resale market that makes any exposed credential worth harvesting.