Skip to content

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.

Published 3 min read

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

  1. 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.
  2. 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.
  3. 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.
  4. Turn on inference and audit logging and alert on unauthorized service activation, suspicious credential checks, abnormal request rates, and attempts to disable logging.
  5. 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.

Related stories