LLMjacking is the theft of a company’s cloud access to large language models, used to run the thief’s own workloads or resold to other buyers. Google Threat Intelligence and Mandiant describe the technique in a report published 2 November 2026, built from incidents its teams investigated directly.
The pattern looks like cryptojacking at first glance: an outsider gets into a cloud account and runs up someone else’s bill. Mandiant says the resemblance stops there. It found fraudulent charges from LLM abuse exceeding $100,000 USD in a single day at some organizations, with cumulative totals reaching $1 million USD before access was revoked.
How LLMjacking Differs From Ordinary Credential Theft
Ordinary credential theft gets an attacker into one account. LLMjacking goes a step further and turns that access into a product with its own price list.
Mandiant’s clearest example makes the point. One threat actor ran more than 500,000 LLM API calls in under eight hours, using stolen third-party API keys to power a token-reselling service. That activity alone passed nearly one million dollars in token costs to the victim organization.
How Attackers Get Into the Account
Mandiant lists several ways in. Some attackers find leaked IAM credentials, service account keys or GitHub personal access tokens sitting in public code or old session tokens still left active. Others build pages that mimic a real application login, built only to steal the raw access token a victim’s browser is holding.
Other attackers go after the application layer directly. Mandiant describes stolen GitHub personal access tokens combined with a web application flaw, and federated cloud identity tokens used to step around multi-factor authentication. A related technique scans public GitHub repositories for exposed LLM API keys, then validates each one with a single near-zero-cost request so the check stays quiet.
Security teams that confirm a key or token like this have a next step. Brandefense’s guide on how to respond to leaked credentials covers revoking, rotating and checking what the credential touched.
- Leaked IAM key or tokenInternetgives access to the cloud account
- Victim’s cloud accountCloud Accountenables the LLM service
- LLM API callsLLM Servicerun up the victim’s bill
- Mixer or proxy serviceUnderground Marketresells the access
- Paying subscriberUnderground Market
Turning Access Into a Reseller’s Product
Once inside, attackers do not just use the access themselves. Mandiant calls the resale layer an LLM Mixer: an illicit gateway that proxies, aggregates and resells unauthorized LLM access to underground subscribers. One such service, Jet Night, advertised an unlimited token plan for about $60 USD a month, undercutting the $100 to $250 a legitimate heavy user typically pays.
Mandiant names two actors behind this activity. UNC6993 compromised a cloud instance through a misconfigured service account key, then built fake login pages to harvest more tokens. D1337-KAIROS deployed a containerized backdoor using the Manus agent framework, supported by SearXNG search and an agent-infra sandbox for executing commands.
Mandiant describes a separate case with a different evasion habit. That threat actor subscribed a victim’s account to a pay-as-you-go plan, then ran a burn-and-rotate pattern of creating and deleting short-lived service accounts. The actor also watched the cloud provider’s billing interface, to track the financial damage in real time.
Service accounts and API keys are a form of non-human identity: machine credentials that often get far less scrutiny than a human login. That gap is exactly what LLMjacking exploits.
A Gateway Flaw That Turned One Key Into Full Admin
Stolen credentials are not the only route in. Mandiant also describes attackers exploiting the LLM routing software itself. In one case, a follow-on actor used pre-validated virtual keys to attack a victim’s LiteLLM gateway directly.
The attacker exploited a user ID rebind flaw in the gateway’s key-regeneration endpoint to turn a standard virtual key into a full administrative credential. From there, Mandiant reports, the actor held deep and persistent control over the environment.
What Changes for Defenders
Mandiant’s recommendations center on two things most security teams do not watch closely: cloud spend and machine credentials. It advises treating any unexpected enablement of an LLM service as a critical alert, not a billing curiosity.
On key hygiene, Mandiant recommends a centralized secrets platform to manage and rotate sensitive keys. It also recommends automated secret scanning across code repositories, so a key never sits in public code for long. A third step is least-privilege access: deny any permission, including LLM service access, that a role does not explicitly need.
On monitoring, the specifics differ by cloud. Mandiant tells AWS users to watch CloudTrail for Bedrock model-invocation calls, and Azure users to watch Cognitive Services operations. GCP users should enable Data Access audit logging on the Gemini Enterprise Agent Platform, since those logs are off by default.
Mandiant also flags one quiet tell: automated validation sweeps that check a stolen key with a single near-zero-cost request before using it at scale. A model gateway’s access logs showing a burst of these minimal requests is itself worth a look, long before any large bill arrives.
None of this is new ground for a team that already treats cloud security as access control, not only a network perimeter. The harder shift is treating machine credentials, keys, tokens and service accounts, with the same suspicion as a human login. Brandefense’s page on AI agent identity and access covers that shift for teams building or buying agentic tools.
The stakes are not only financial. Mandiant notes that LLM services were not enabled at the time of compromise in some incidents, which means the enablement event itself is the first real signal a defender gets. A budget alert that fires only after the invoice arrives is already too late.