What does a thief do with your cloud credentials in 2026? According to a report published November 2 by Google Threat Intelligence Group and Mandiant, the answer is increasingly: switch on your company’s AI models and sell the access to strangers for about $60 a month. Google calls it LLMjacking, and in the incidents it worked, the fraudulent charges passed $100,000 in a single day and reached $1 million at some organizations before anyone revoked access.
The term is not new. Sysdig’s threat research team coined it in May 2024, when it estimated that one hijacked AWS account could run up “over $46,000 of LLM consumption costs per day.” What changed in two and a half years is the business model around it, and that change moves where defenders should be looking.
What did Google and Mandiant actually find?
Mandiant responded to multiple LLMjacking incidents in 2026 across North America, South America and Asia Pacific, in financial services, retail, technology and transportation. The report names one cluster, UNC6993, and describes others without names. Its headline line is worth reading verbatim:
“Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours.”
The single most striking case: one actor “executed more than 500,000 LLM API calls in less than eight hours” using stolen third-party API keys, and the service it powered “passed nearly one million dollars in token costs to the victim organization.” BleepingComputer’s write-up adds that once access is resold, request volume can spike past 1,000 requests per second.
Google’s forecast is the part that should land on a CFO’s desk: it “expects that threat actors will increasingly prioritize LLMJacking over traditional resource theft like cryptojacking.” Mining crypto on stolen compute pays slowly. Reselling frontier model access pays at retail prices, immediately.
How does a stolen key become a $60 subscription?
Through what Google calls LLM mixers: “illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers.” The report names two by domain, jet-night.com and newapi[.]pro, and describes how the operators pool stolen credentials behind ordinary open-source gateway software (new-api, gcli2api and LiteLLM all appear) so that usage is metered and the origin of each request is hidden.
The pricing explains the economics. Per Google, Jet Night “offers an unlimited token plan for approximately $60 USD per month with alleged access to frontier models,” against the $100 to $250 a month a legitimate consumer tier would cost. The subscriber pays $60. The victim pays the token bill. The mixer keeps the margin and rotates to a fresh stolen key when one dies; Jet Night even uses a public Telegram channel to announce outages.
That structure matters for victims because a mixer’s traffic does not look like one attacker. It looks like a busy production workload: many different prompts, many models, steady throughput. Volume alerts tuned for a runaway script will fire late, if at all, and by then the hours that matter are gone.
If attackers resell model access, why are model API keys the wrong place to start?
Because in Google’s incidents, most of the time, the model key was not what got stolen. The report is explicit that “the dominant initial access vector has been exposed or stolen cloud identity tokens,” naming IAM credentials, service account keys, GitHub personal access tokens and active session tokens. UNC6993 got in through a misconfigured service account key. Another actor used compromised IAM credentials with federation tokens to mint fresh access keys and sidestep MFA. One group ran a fake LLM user-group portal that asked victims to paste a raw JSON payload containing a live access token.
With a cloud identity in hand, the attacker does not need your AI budget to exist. They create it. Google found that in several incidents the organization had never enabled the model service at all; the actors used the stolen credentials to switch on Bedrock or the Gemini API, accepted model agreements, subscribed the account to pay-as-you-go premium models and created their own API keys. To dodge rate limits, UNC6993 ran what the report calls a “burn and rotate” strategy, “continuously creating and deleting short-lived service accounts while auditing the cloud provider’s billing interface to monitor financial impact.”
So a team that answers this report by rotating its OpenAI and Anthropic keys has fixed the smaller problem. The bigger one is any cloud account where a stolen identity can turn on a model service nobody uses. Google’s own guidance points there first: “treat any unauthorized enablement as a critical security event.” For an organization that has never used Bedrock in a given account, a single CreateFoundationModelAgreement or PutUseCaseForModelAccess event is a better alarm than any spending threshold, because it fires before the first token is billed.
This is the same lesson the LiteLLM compromise taught last month, when a publish key nobody revoked opened the door: the dangerous object is the identity, and the AI service is just the most profitable thing it can reach. It is also why giving agents and service accounts their own scoped, offboardable identities is a cost control and not only a governance nicety.
What does a validation sweep look like, and will your logs even show it?
Before a stolen key goes on sale, someone checks that it works. Google describes UNC6993 running “automated credential validation sweeps using minimal single-token requests (max_tokens=1),” small enough to stay under volume alerts. On AWS, Google also flags spikes of ThrottlingException, ValidationException and ResourceNotFoundException errors, the signature of an automated “spraying” approach that tries models and regions to see what a key can reach, alongside scoping calls such as ListFoundationModels and GetFoundationModelAvailability.
The catch is that the default logging on two of the three big clouds will not show you the inference itself:
- On Google Cloud, Admin Activity logs are always on, but the audit logging documentation states that “Except for BigQuery, Data Access audit logs are disabled by default.” Google’s report notes that model inference calls live in those Data Access logs. The
EnableServiceevent that switches the API on is recorded; the half-million calls that follow may not be. - On AWS, Bedrock’s model invocation logging documentation says plainly: “Model invocation logging is disabled by default.” It also only covers calls through the
bedrock-runtimeendpoint. - On Azure, Google’s report says high-volume completion traffic is visible only if diagnostic logs are turned on for the Cognitive Services resource.
Attackers know this. Sysdig’s 2024 research found them calling GetModelInvocationLoggingConfiguration to check whether logging was on, and Google lists DeleteModelInvocationLoggingConfiguration and Azure diagnosticSettings/delete among the evasion events to watch. Google’s rule is blunt: “Any calls to disable logging by non-IaC (Infrastructure as Code) principals should be treated as high severity.” If a logging change did not come from your Terraform pipeline, a human or a thief made it.
What is the LiteLLM vulnerability in the report, exactly?
Here the sources do not line up, and it is worth being precise. Google says a follow-on cluster bought “pre-validated Virtual Keys” for self-hosted LiteLLM gateways and used CVE-2026-40217 to elevate them to PROXY_ADMIN, describing the bug as “a user ID rebind vulnerability in the /key/regenerate endpoint.” The public CVE record for that number, published April 10, describes something different: LiteLLM “through 2026-04-08 allows remote attackers to execute arbitrary code” via bytecode rewriting at the /guardrails/test_custom_code URI, rated CVSS 8.8. BleepingComputer’s article follows the CVE record’s description. Advisory databases also disagree on the first fixed release, citing 1.83.10, 1.83.11 and 1.83.14-stable.
Either way, the practical reading is the same. Any LiteLLM proxy still running a build from before April is exposed, and Google’s guidance is to “extend vulnerability management programs to include centralized model proxy and routing gateways.” A gateway that holds every provider key your company owns is the highest-value box in your AI stack; it deserves the patch cadence of an identity provider, not of a developer tool. Google also saw scripts probing publicly exposed Ollama endpoints to register the attacker’s own models, which is a reminder for anyone running open models on their own hardware that a local inference port is a server, not a toy.
What should change this week?
Most of Google’s 17 mitigations are standard cloud hygiene. Five of them do the most against this specific attack, in this order:
- Alert on model service enablement in accounts that do not use AI. Bedrock model agreements,
EnableServicefor the Gemini API, new Cognitive Services deployments. Better still, block the service with an organization policy or service control policy where no team has a reason to use it. Google’s phrasing is “Deny all permissions that are not explicitly required, including access to Cloud LLM services.” - Turn on inference logging where you do run models, and alert on any logging change made outside your infrastructure-as-code principals.
- Set per-model quotas and hard spending caps, not just budget emails. An email that arrives eight hours into a 500,000-call burst is a post-mortem input.
- Watch for single-token traffic. Google recommends monitoring gateway and API logs for “anomalous, low-volume requests (such as
max_tokens=1or zero-temperature pings).” Legitimate applications rarely ask for one token. - Hunt for the identities, not just the keys. Service account keys with broad project permissions, long-lived GitHub tokens and new service accounts with innocent names (one actor’s were “disguised as internal billing optimization utilities”) are the entry points in Google’s cases.
None of this needs new tooling. It needs someone to decide that an unexpected model bill is a security incident and not a finance query. Teams already tracing what their own agents do have half the plumbing; the missing half is treating a model call nobody in the company made as the breach signal it is.
The uncomfortable part of Google’s report is the price tag. A stranger paying $60 a month can generate a seven-figure bill for someone else, and the market for that arbitrage is now organized enough to post its outages on Telegram. As long as frontier tokens cost what they cost, stolen cloud identities will be worth more as AI subscriptions than as crypto miners, and the first sign of a breach will keep showing up on the invoice.