Google says stolen cloud access ran AI bills up to $1 million; the post gives no count of victims or days
Google Threat Intelligence Group and Mandiant say criminals who steal cloud access ran AI models at victims' expense, with charges over $100,000 in a day and up to $1 million cumulative at some organisations. The post gives no victim count, no days, and does not say who revoked access.
By Parminder Kumar Sharma · LinkedIn · · 22 min read
The ratio, and what it leaves open
Google's LLMjacking post, dated 2 November 2026, prints two money figures. Fraudulent charges "exceeding $100,000 USD in a single day", and cumulative charges "at some organizations reaching $1 million USD before access was revoked". The second is ten times the first (derived). The post ties neither figure to a named victim, a number of days or a count of incidents. It says only that Mandiant "responded to multiple incidents in 2026". Help Net Security, read on 3 November 2026, says Mandiant responded to "several" incidents; the primary says multiple and gives no number.
What the post does establish is a mechanism. Intruders take cloud access, switch on or reach a model service, and run models at the victim's expense. Google says the dominant way in was stolen cloud identity tokens, and that a second group sells the access on. What it does not establish is how big the problem is: no total loss, no victim count, no share of incidents outside Mandiant's own casework. The headline sums are ceilings seen at some organisations, not averages.
A note on the source, once. The post comes from Google Threat Intelligence Group and Mandiant, which are part of Google. Google sells cloud and AI model services, a security operations product and Mandiant consulting, and the post's advice names several of them: Google's Cloud Armor, Security Posture Management tools, the Google Security Operations rule packs and a Mandiant contact link. That is a normal interest for a vendor threat report. It does not make the findings wrong, and the findings below are checked where they can be against records that are not Google's.
Read on 3 November 2026, between about 11:25 and 11:40 GMT: the whole of Google's post, the two Google documentation pages it links for logging (the Cloud Audit Logs overview and Service Usage audit logging), the National Vulnerability Database and CVE.org records for the one CVE number the post cites, and, as secondaries, Help Net Security and Infosecurity Magazine. The indicator collection the post links is described as being for registered users, so it was not opened. The post's authors and the news writers are not named here.
What the post states, and what it does not
Items from Google's post of 2 November 2026, read in full, with what the post leaves out
| Question | Stated in the post | Not stated |
|---|---|---|
| How many incidents | Mandiant 'responded to multiple incidents in 2026'. | A count. Help Net Security's 'several' is not in the post. |
| Where and who | Victims in North America, South America and Asia Pacific, in financial services, retail, technology and transportation. | Any victim name, country, or number per sector. |
| Which clouds and models | 'A variety of cloud and LLM providers'. Detection advice covers AWS, Azure and Google Cloud. Bedrock and the Gemini API are named as services an actor could enable. | Which provider each victim used, which models were run, and so whether Google's own models were abused. |
| How access was taken | Dominant vector across multiple investigations: 'exposed or stolen cloud identity tokens'. Also exposed endpoints and API keys found in public repositories. | The route in any single incident beyond a handful of examples, or how often each route occurs. |
| The money | Over $100,000 in a single day. Up to $1 million cumulative at some organisations. One actor's cluster 'quickly accumulating over $100,000'. Nearly one million dollars of token costs passed to one victim. | Which incidents each figure belongs to, how many days any bill ran, any total or average. |
| How it ended | Cumulative charges reached up to $1 million 'before access was revoked'. | Who revoked access, what noticed the abuse, and how long that took. |
Two small gaps between the post and its coverage are worth marking, because both soften the same fact. Help Net Security writes that the bills reached up to $1 million "before the attackers lost access". The post says 'before access was revoked', a passive that names no one. Losing access is something that happens to an attacker; revocation is something a defender does, and the post does not say a defender did it. Infosecurity Magazine, for its part, keeps the post's own word multiple.
The chain, as Google draws it
Google's picture is a supply chain with two kinds of crook. One group gets into cloud environments. Another runs what the post calls LLM Mixers, which "function as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers". In one investigation Google says it saw "two distinct operational clusters coordinating to compromise and monetize enterprise LLM infrastructure". The division of labour is stated for that one case and described as a trend GTIG is tracking, not measured.
How the access was stolen
The post separates front doors from back doors. Customer support chatbots can be talked into small tasks such as code generation, but actors doing LLMjacking skip those front ends and go for the model resources behind them. They look for publicly exposed endpoints, or for valid LLM API keys. As an example of an exposed endpoint, Google describes an automated script that checks an exposed Ollama service by trying to register a model of the actor's own. The script is pictured in the post and is not reproduced here.
Most often, though, "the dominant initial access vector has been exposed or stolen cloud identity tokens", listed as IAM credentials, service account keys, GitHub personal access tokens and active session tokens. The post gives several examples, each a different route. Five are tabled here.
Initial access examples as Google's post describes them, 2 November 2026; the last column is this site's reading
| Example | What the post says happened | Control it points at |
|---|---|---|
| A cluster Google tracks as UNC6993, mid 2026 | Compromised a cloud instance through a misconfigured service account key, then used the access to reach an LLM API. Another actor was first seen using a service account key with broad project permissions. | Service account key handling and permissions. |
| The same cluster's fake portal | A page 'masquerading as an application portal to join a group of LLM users' asked visitors to paste a raw JSON payload holding an active access token, which was posted to a back end API, to 'bypass password and multifactor authentication (MFA) controls'. | Token theft after login, not password theft. |
| A stolen access token plus a suspected flaw | A stolen personal access token opened private code repositories. A suspected web application vulnerability in a package in a containerised cloud environment added a foothold. | Secret scanning and patching, together. |
| Corporate IAM credentials and federation | Used 'cloud federation tokens to programmatically generate fresh access keys to circumvent MFA requirements'. | Federation and key creation rights. |
| Keys in public repositories | An actor 'opportunistically harvested exposed corporate LLM API keys from public GitHub repositories' and tested them with one token requests, which let it stay undetected by the victim's EDR and SIEM volume alerts. | Secret scanning, and alerts on tiny requests. |
The friendly name to watch is MFA. In two of the five examples the post says the access went around it, once with a pasted session token and once with keys minted from federation tokens. A session token that has been pasted into a hostile page was issued after the login prompt, so that prompt had already done its work. The post's advice is "Enforce phishing-resistant multi-factor authentication across all cloud identity providers, management consoles, and developer platforms". Whether that would have stopped the fake portal is this site's question, not a finding in the post, which does not test it.
Inside the account, and a CVE number that does not match its record
Once in, the post says actors explore and dig in. They list services and repositories for further credentials, clone code to search for hardcoded secrets, query data warehouse metadata for database passwords, and use token creation rights to mint temporary credentials for powerful service accounts. For persistence it lists "creating unauthorized IAM and service accounts and injecting SSH keys into compute instances", and one actor's "deceptive backdoor service accounts disguised as internal billing optimization utilities". A name that says billing is, in this case, the disguise.
One passage names a CVE. Google says a follow on cluster, holding virtual keys supplied by the first, attacked the victim's LiteLLM gateway: "The actor exploited a user ID rebind vulnerability in the /key/regenerate endpoint (CVE-2026-40217) to elevate standard Virtual Keys into full PROXY_ADMIN master administrative credentials". LiteLLM is an open source gateway that routes requests to many model providers.
That description does not match the public record for the number. NVD and CVE.org, both read on 3 November 2026, describe CVE-2026-40217 as: "LiteLLM through 2026-04-08 allows remote attackers to execute arbitrary code via bytecode rewriting at the /guardrails/test_custom_code URI." Neither record mentions /key/regenerate or an administrative key. CVE.org lists the record as published on 10 April 2026 with a CVSS 3.1 base score of 8.8 (High) assigned by MITRE as the CNA. This site's earlier briefing on LiteLLM's advisories, the Check Point LiteLLM briefing, lists the same number against a sandbox escape in a custom code guardrail, which fits the record and not the post.
Three explanations are possible, and the evidence cannot choose between them: the post may have used the wrong number for a different flaw, the public record may be incomplete, or the same number may cover more than one behaviour. The practical point is narrow. The post's mitigation list tells defenders to patch gateways "such as CVE-2026-40217". A team that patches only for the record's description may not have closed the behaviour the post describes. Check the gateway vendor's own advisory list for the key regeneration issue by its title, not only by the number.
The bill: what proxying, streaming and provisioning mean
The post's one sentence of purpose is "The ultimate objective of LLMJacking is the monetization and resource-hijacking of foundation models, which actors achieve through token proxying, automated model streaming, and GPU hardware provisioning." It does not define the three terms separately. Its examples line up with them, and this site's mapping, labelled as such, is as follows.
The three methods as Google names them, matched to the post's own examples (the matching is this site's)
| Method in the post | Example the post gives | What it costs the victim |
|---|---|---|
| Token proxying | Actors 'deployed publicly accessible reverse proxies' and custom proxy bundles exposing endpoints for several frontier models under a made up persona. Mixers 'pool stolen credentials, meter usage, and obscure the origin of the requests'. | Other people's traffic billed to the victim's keys. |
| Automated model streaming | An actor subscribed victim accounts to pay as you go agreements, chose premium models and started 'high-volume inference streams'. | Premium model tokens at volume. |
| GPU hardware provisioning | Actors 'provisioned compute instances with powerful GPUs, attempted to spin up high-end hardware across multiple regions, and requested quota increases'. | Compute hours, and the quota to buy more. |
Two details show an actor working against a bill and a limit. To get round rate limits, one actor used what Google 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". The attacker was reading the billing page. And UNC6993, after getting LLM API keys, generated more keys and enabled services in the victim's projects, "quickly accumulating over $100,000 USD in billing charges". The post gives no clock time for that figure, so it is not the same statement as 'over $100,000 in a single day'.
The figure is worth a slow look. In it, the largest series is not successful calls but responses coded 429, rate limit or quota, with the successful calls (read off the axis, roughly a fifth of the peak) well below. That is this site's reading of a chart, with no scale beyond the axis labels, and it cannot say which calls were billed. What it does show is the shape Google describes: days of nothing, then a surge that starts and ends within about one day on the chart's own time axis. A bill review at month end would meet it weeks late.
The sums, in Google's words and this site's arithmetic. A single actor feeding the Jet Night service made "more than 500,000 LLM API calls in less than eight hours", and Google says the service "passed nearly one million dollars in token costs to the victim organization". Half a million calls over eight hours is at least 17 calls a second on average (derived: 500,000 divided by 28,800 seconds; fewer hours means a higher rate). The post does not say that all of the near million came from those calls, so no price per call is computed here.
LLM Mixers: how stolen access is sold
The post says Mixers use open source gateways and custom relays to pool stolen credentials, meter use and hide where requests come from. It names two gateway tools that UNC6993 used, new-api and gcli2api, "likely to aggregate stolen keys and balance request loads across accounts", and adds "We believe the threat actor sells access to these tools via underground storefronts." Note the verbs: 'likely' and 'we believe'. The post offers no seller record or sale.
The best developed example is Jet Night. Google says it offers an "unlimited token plan for approximately $60 USD per month with alleged access to frontier models", against "a consumer service level that would typically run between $100 and $250 per month". On Google's figures that is 40 to 76 percent below the comparison (derived: 60 against 100 and against 250). From the gap Google concludes the service "relies on stolen keys to operate profitably". That is an inference from price, and the post presents it as a belief. It adds that the service advertised several outages on a public Telegram channel, "which is likely due to stolen keys being revoked as victims discover their respective compromises". This site did not visit the channel or any seller, by policy, and the outage point rests on Google alone.
A second route is a relay built to look like the victim's own host. A threat actor ran custom relay infrastructure called ai-relay on "deceptive lookalike domains", with a domain made to look like the victim's internal host, to funnel the company's model access into a resale service the post calls newapi[.]pro. In the post's account the relay was used to siphon commercial model access into the resale service, draining the victim's account quotas to serve the actor's customers. Both Jet Night and newapi[.]pro are listed as 'LLM Mixer' indicators in the post and are defanged in the technical details below.
How it ended, and how anyone noticed
The post's answer to how the bills stopped is its passive 'before access was revoked'. It does not say what flagged the abuse. What it does say is a lesson about timing: "In multiple incidents that Mandiant investigated, LLM services were not enabled at the time of compromise." The keys let the actor switch the services on, and then "Once enabled, the threat actor can use the APIs to generate massive bills to the organization in just minutes or hours." The post's instruction follows: treat any unauthorised enablement as a critical security event.
There is a second timing lesson in the small test requests. The post says one actor checked stolen keys with single token calls (max_tokens=1) and so stayed under volume alerts. A volume alert is a friendly name: it watches how many requests there are, and a test of a key is one request.
For Google Cloud, two Google documents allow a reading that the post does not spell out, and it is this site's reading, not Google's finding about these incidents. The Cloud Audit Logs overview says "Admin Activity audit logs are always written; you can't configure, exclude, or disable them." The Service Usage audit logging page lists EnableService as an Admin activity method. So the enablement event should be present by default. Model calls are another matter. The same overview says "Except for BigQuery, Data Access audit logs are disabled by default because they can generate large volumes of data." and the post says the same of the platform's inference operations. Alert on the first, and switch on the second, knowing that Google warns enabling the logs "might result in your Google Cloud project being charged for additional log usage". For AWS and Azure the post's guidance is in the technical details below.
What the report does not establish
Google's post of 2 November 2026: what it supports and what it leaves open
| Topic | What it supports | What it does not establish |
|---|---|---|
| Size of the loss | Two ceilings seen by Mandiant, over $100,000 in a day and up to $1 million cumulative at some organisations. | A total, an average, a typical bill, or how many victims. |
| How common | Multiple Mandiant incidents in 2026 and 'a diverse set of financially motivated threat clusters' tracked by GTIG. | A rate outside Mandiant's casework, or a trend measured over time. The forecast is an expectation. |
| Whose models | Premium and frontier models, unnamed, and Bedrock and the Gemini API as services that were enabled. | Which models were abused in which incident, or whether any were Google's. |
| How keys were stolen | Five example routes and a dominant category. | The route for each incident, or how often each occurs. |
| The Mixer market | That Mixers exist, one service's advertised plan and outage claims, and a belief that it relies on stolen keys. | The size of the market, who the subscribers are, or independent checks of the outage claim. |
| The CVE | That a gateway was attacked to raise virtual keys to administrative ones, as Google describes it. | That the number it cites describes that behaviour. The public record says otherwise. |
The outlook paragraph is a forecast: "GTIG expects that threat actors will increasingly prioritize LLMJacking over traditional resource theft like cryptojacking". It rests on the profit of Mixers. That is a reasoned expectation from a vendor that sees incident data, and it is not a count. If cryptojacking fell, the post does not show it.
What to do, in order
The order below follows the post where it speaks, then labels this site's own suggestions. Nothing here needs a purchase. Where the post names a Google product, the principle usually has an equivalent on other platforms, and the post's detection names cover only AWS, Azure and Google Cloud.
Take this with you
Ranked checklist: Google's detections first, then guards, keys, logs, and the first hour
- 1. Alert on unauthorised enablement of any model service in any project or account, and treat it as critical (Google). On Google Cloud the method is EnableService.
- 1b. Hunt the model API operations the post lists for your cloud: discovery calls, invocation calls, throttling and validation error spikes, and calls that read, change or delete logging settings (Google). Treat disabling logs by anything that is not infrastructure as code as high severity (Google).
- 1c. Look for tiny requests, such as max_tokens set to 1 and zero temperature pings, in model gateway and API logs (Google).
- 2. Set per model API quotas and spending caps on every model service, and give them thresholds (Google). Then find out, by reading the provider's documentation, which ones stop the spend and which only notify (this site's suggestion).
- 2b. Add a daily spend alert on model services that fires well below your bill ceiling (this site's suggestion). The post shows bills reaching six figures within a day.
- 3. Deny access to cloud LLM services to every user and service account that does not need it (Google). Split API keys by model, environment and usage limit (Google), so a key for a cheap model cannot call an expensive one.
- 3b. Keep keys short lived and rotated from a central secrets platform (Google: rotation limits how long a leaked credential works). Prefer short lived tokens to long lived keys for model access wherever the platform allows (this site's suggestion).
- 3c. Scan code repositories for secrets automatically and remove any that are found (Google). Revoke a leaked provider key at the provider, not only in your own copy (this site's suggestion; see the OpenCode briefing).
- 3d. Patch model gateways quickly, and check the advisory for the behaviour by its description, not only by CVE number (Google, with this site's addition).
- 4. Turn on model invocation logs where they are off by default: Data Access audit logs on Google Cloud, Diagnostic Logs on Azure, CloudTrail events for the Bedrock source on AWS (Google). Accept the extra log cost deliberately.
- 5. In the first hour of a surprise bill (this site's suggestion): read the billing console to find the service and project; disable or rotate the credentials that are making the calls; revoke active sessions; list new IAM and service accounts, access keys and SSH keys added in the last day; keep the logs before anything is deleted; and check the model gateway for keys you did not create.
On item 3c, see this site's briefing on OpenCode's provider keys: a notice there makes the point that deleting a saved key from a product is not the same as revoking it at the provider. The Google post does not say this, and the point is offered here as a suggestion.
Technical details
What the post prints: rule names, API operation names, log namespaces, a handful of tool and cluster names and two network indicators. It prints no file hashes, no ready made queries and no configuration files, and the larger indicator collection sits behind a registration wall that was not opened. Each block below is copied from the named source and explained above it. No exploit code and no attack scripts are reproduced, and the script the post pictures for exposed Ollama services is left out.
AWS. The post says to monitor CloudTrail for events from the Bedrock service source and lists the operations by purpose. A defender can build alerts from the names, and the user agent list is a place to look for automated SDKs calling the model service directly. Its user agent examples are claude-cli, aws-sdk-rust and aws-sdk-go-v2, which are strings that appear in logs.
CloudTrail event source named: bedrock.amazonaws.com
Resource exploitation: Converse, InvokeModel, InvokeModelWithResponseStream
Throttling and error spikes: ThrottlingException, ValidationException, ResourceNotFoundException
Target scoping: ListFoundationModels, ListInferenceProfiles, GetFoundationModelAvailability
Unlocking new models: PutUseCaseForModelAccess, CreateFoundationModelAgreement
Security and evasion: GetModelInvocationLoggingConfiguration, PutModelInvocationLoggingConfiguration, DeleteModelInvocationLoggingConfiguration
Automated tooling, user agent strings named: claude-cli, aws-sdk-rust, aws-sdk-go-v2
Azure. Model invocations are on the data plane, so the post says Diagnostic Logs must be enabled to see them. Control plane Activity Logs show new deployments being created.
Namespace: Microsoft.CognitiveServices
Logs: Azure Activity Logs (control plane) and Diagnostic Logs (data plane)
Resource exploitation (data plane, needs Diagnostic Logs): high volumes of POST requests to inference endpoints such as Completions or Chat Completions APIs
Resource exploitation (control plane): Microsoft.CognitiveServices/accounts/deployments/write
Target scoping: Microsoft.CognitiveServices/accounts/read, Microsoft.CognitiveServices/accounts/deployments/read
Security and evasion: Microsoft.Insights/diagnosticSettings/read, Microsoft.Insights/diagnosticSettings/write, Microsoft.Insights/diagnosticSettings/delete
Google Cloud. The post says to alert on enablement and to configure Data Access logging, which is off by default for these inference calls. The next block gives the log filter Google's own documentation prints for the EnableService method. It is a plain filter on the method name, copied from the documentation page and not from the post.
Service named: aiplatform.googleapis.com (the post calls it Gemini Enterprise Agent Platform)
Log type: Data Access audit logs, disabled by default; the post says to configure IAM audit policies manually
Enablement: google.api.serviceusage.v1.ServiceUsage.EnableService
Resource exploitation: google.cloud.aiplatform.v1.PredictionService.Predict
google.cloud.aiplatform.v1.PredictionService.GenerateContent
google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent
Target scoping: google.cloud.aiplatform.v1.ModelService.ListModels
google.cloud.aiplatform.v1.EndpointService.ListEndpoints
google.cloud.aiplatform.v1.PublisherModelService.ListPublisherModels
Security and evasion: google.iam.v1.IAMPolicy.GetIamPolicy
google.logging.v2.ConfigServiceV2.ListSinks
google.logging.v2.ConfigServiceV2.GetSink
Method: google.api.serviceusage.v1.ServiceUsage.EnableService
Audit log type: Admin activity
Filter for this method:
protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.EnableService"
Google Security Operations rules. The post says the activity it describes is detected under these rule names, in three packs. They cover account key and service account creation, firewall and SSH key changes and exfiltration, rather than model calls themselves, so they catch the persistence steps and not the billing.
Rule packs: Cloud Threats, Mandiant Frontline Threats, Mandiant Hunting Rules
Rule names printed in the post:
AWS Account Key Creation
AWS Create New Access Key
AWS Create User Account
AWS Delete User Account
Base64 Encoded Shell Command Execution
Create and Delete Firewall in Default Network
GCE Project SSH Keys
GCP Service Account Key Creation
GCP Create New Service Account
GCP Firewall Rule Created
Linux Archive Exfiltration via Curl or Wget
Persistence: Compute Set Instance or Project Metadata Startup Scripts or URLs
Indicators. Two domains, both labelled as LLM Mixers. They are live criminal infrastructure and are shown defanged. A defender can look for them in DNS, proxy and egress logs. The post's larger collection is for registered users.
Network indicators table, as printed (defanged here):
jet-night[.]com LLM Mixer
newapi[.]pro LLM Mixer
Names in the post's prose. Useful as search terms in an environment, and not indicators on their own: several are legitimate open source projects that the post says were used by criminals.
Cluster tracked by Google: UNC6993
Persona named for rebranded model endpoints: D1337-KAIROS
Custom relay infrastructure named: ai-relay
Gateway and proxy tools named: LiteLLM, new-api, gcli2api
Agent and sandbox tools named in one backdoor: Manus, SearXNG, agent-infra/sandbox
Endpoint named for exposed Ollama services: /api/create
Endpoint, product and role named in the LiteLLM passage: /key/regenerate, Virtual Keys, PROXY_ADMIN
Validation request pattern named: max_tokens=1, zero-temperature pings
The CVE number, side by side. The first paragraph is a paraphrase of the post's wording; the second is the NVD description, which the CVE.org record repeats. Compare them before relying on the number to find the flaw.
What the post says CVE-2026-40217 is:
a user ID rebind vulnerability in the /key/regenerate endpoint that elevates standard Virtual Keys into full PROXY_ADMIN master administrative credentials
What NVD and CVE.org say CVE-2026-40217 is:
LiteLLM through 2026-04-08 allows remote attackers to execute arbitrary code via bytecode rewriting at the /guardrails/test_custom_code URI.
The question to put to your cloud account
Google's post shows that the abuse starts when something nobody asked for is switched on, and ends, in its own words, when access is revoked by someone it does not name. Between those two points sits whatever you have built to notice. If a stolen key switched on a model service in your account tonight, which alert would reach a person, and would it reach them before the bill passed the figure the post gives for a single day?
Key facts
Sources
- PrimaryThe Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources, 2 November 2026. The primary, read in full: incidents, access, persistence, abuse, Mixers, outlook, detection, mitigation, audit log names, indicators, Figures 1 and 3 (used)Google Threat Intelligence Group and Mandiant (Google Cloud Blog)accessed 2026-11-03
- PrimaryCloud Audit Logs overview, linked from the primary: read for Admin Activity logs always written and Data Access logs disabled by defaultGoogle Cloud documentationaccessed 2026-11-03
- PrimaryService Usage audit logging, linked from the primary: read for the EnableService method, its Admin activity log type and its filter lineGoogle Cloud documentationaccessed 2026-11-03
- PrimaryRecord for CVE-2026-40217: read to compare its description with the post's description of the same numberNIST National Vulnerability Databaseaccessed 2026-11-03
- PrimaryRecord for CVE-2026-40217: published 10 April 2026, CVSS 3.1 score 8.8 as assigned by MITRE; same description as NVDCVE Program (CVE.org record service)accessed 2026-11-03
- Reported byStolen AI access leaves companies with cloud bills of up to $1 million, 3 November 2026: secondary report, read in full; compared with the primaryHelp Net Securityaccessed 2026-11-03
- Reported byLLMJacking is Costing Some Businesses Up to $1m, Warns Google, 3 November 2026: secondary report, read; compared with the primaryInfosecurity Magazineaccessed 2026-11-03
