DISC InfoSec blog

The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources

Nov 3, 2026 · @disc

The $100,000 Afternoon

Cryptojacking took months to show up on a cloud bill. LLMJacking takes an afternoon. In incidents Mandiant worked through 2026, attackers ran up more than $100,000 in fraudulent model charges in a single day, and some victims hit roughly $1 million before anyone revoked the stolen access.

That is the headline from the Google Threat Intelligence Group and Mandiant report published November 2, 2026. The attackers did not need a zero-day or a jailbreak. They needed one leaked service account key, one GitHub token, or one LLM API key committed to a public repo.

Here is the uncomfortable part for anyone selling or buying AI-enabled software. Every organization that has wired a frontier model into production now holds a credential that converts directly into cash. Criminals have noticed. They have built a supply chain to steal those credentials, validate them quietly, and resell the model access to paying subscribers at a discount, while the victim pays the invoice.

For B2B SaaS and financial services teams, this is not only a cloud security story. It is a denial-of-wallet risk, a data exposure risk, and an AI governance evidence problem. Your ISO/IEC 42001 auditor, your SOC 2 auditor, and your enterprise customers’ vendor risk teams will start asking how you govern model access. This post lays out how LLMJacking works, who profits, and the specific controls and evidence that close the gap.

What Mandiant and GTIG Actually Found

LLMJacking is now an organized, multi-region criminal business with a division of labor, not a hobbyist’s trick. The November 2026 report draws on multiple Mandiant incident responses across North America, South America, and Asia Pacific, hitting financial services, retail, technology, and transportation organizations.

Five findings matter most for defenders:

• Speed beats cryptojacking. Cryptominers drain resources slowly. LLMJacking produces billing spikes within hours, with single-day fraud above $100,000 and cumulative losses near $1 million at some victims.
• Identity is the front door. Exposed endpoints such as unauthenticated Ollama servers get probed, but the dominant entry point was stolen cloud identity: IAM credentials, service account keys, GitHub personal access tokens, and live session tokens.
• Attackers turn LLM services on. In several cases the victim had never enabled a managed LLM service. The attacker enabled Bedrock, Gemini, or similar APIs with stolen keys, then started billing.
• The model gateway is a target. A follow-on actor exploited CVE-2026-40217, a user ID rebind flaw in the LiteLLM /key/regenerate endpoint, to turn ordinary virtual keys into PROXY_ADMIN master credentials.
• Specialists now split the work. One cluster breaks in and validates access. A second cluster runs “LLM Mixers” that pool, meter, and resell the stolen model access to underground subscribers.

The tradecraft is quiet before it is loud. One group validated keys harvested from public GitHub with single-token requests (max_tokens=1), cheap enough to slip under volume-based SIEM and EDR thresholds. Another bypassed MFA by tricking users into pasting a raw JSON access token into a fake portal for joining an LLM user group, a tactic GTIG attributes to UNC6993.

The LLMJacking Kill Chain

Every stage of an LLMJacking intrusion uses ordinary cloud attack techniques; only the payoff is new. That is good news. Most of the controls you need already exist in your cloud security program. They just are not pointed at model services yet.

Stage	What attackers did in the Mandiant cases	MITRE ATT&CK / ATLAS	Earliest place to catch it
1. Credential theft	Harvested LLM API keys and service account keys from public GitHub; stole PATs; phished raw session tokens	T1552.001 Credentials in Files; T1528 Steal Application Access Token; ATLAS AML.T0055 Unsecured Credentials	Secret scanning with push protection; token binding; phishing-resistant MFA
2. Quiet validation	Single-token max_tokens=1 calls to confirm keys work	T1078.004 Valid Accounts: Cloud; ATLAS AML.T0040 AI Model Inference API Access	Gateway logs for tiny, zero-temperature requests from new IPs or user agents
3. Discovery	Enumerated regions, models, identity policies, repos, data warehouse metadata	T1580 Cloud Infrastructure Discovery; T1213.003 Code Repositories	ListFoundationModels, ListModels, deployments/read calls by unusual principals
4. Privilege escalation	Minted tokens for high-privilege service accounts; attached admin policies; exploited LiteLLM CVE-2026-40217	T1098.001 Additional Cloud Credentials; T1068 Exploitation for Privilege Escalation	IAM policy change alerts; gateway admin key creation alerts
5. Persistence	Created IAM users and backdoor service accounts named like billing tools; injected SSH keys into instance metadata	T1136.003 Create Cloud Account; T1098.004 SSH Authorized Keys	New-identity alerts; project-wide SSH key changes
6. Defense evasion	Checked or disabled model invocation logging; “burn and rotate” short-lived service accounts	T1562.008 Disable or Modify Cloud Logs	Any logging change by a non-IaC principal = high severity
7. Abuse and monetization	Enabled LLM services, accepted model agreements, ran high-volume inference, provisioned GPUs, requested quota increases, resold access	T1496.004 Cloud Service Hijacking; ATLAS AML.T0034 Cost Harvesting	EnableService, PutUseCaseForModelAccess, quota requests; budget anomaly alerts

The table shows where defenders have leverage. Stages 1 and 2 are cheap to stop and nearly invisible to traditional volume-based alerting. By stage 7 you are watching an invoice grow in real time.

The LLM Mixer Economy: Your Quota, Their Storefront

Stolen model access is now a resold commodity, and your invoice funds someone else’s discount subscription. GTIG calls the resale layer “LLM Mixers”: gateways that proxy, pool, and meter unauthorized access, then sell it to underground customers.

The tooling is mostly open source, which makes the economics brutal:

• Pooling and load balancing. UNC6993 used new-api, a centralized model hub, and gcli2api, which turns CLI tools into standard model endpoints, to aggregate stolen keys and spread requests across victim accounts.
• Retail storefronts. The service Jet Night, run on stolen third-party keys, executed more than 500,000 API calls in under eight hours and passed close to $1 million in token costs to one victim. Its unlimited plan sold for about $60 a month, against $100 to $250 for a comparable legitimate tier. Its public Telegram channel announced outages, which GTIG reads as keys being revoked by victims.
• Lookalike relays. One actor ran custom ai-relay infrastructure on a domain built to mimic the victim’s own internal host, siphoning quota into the newapi.pro resale ecosystem.
• Hijacked agents and GPUs. Another actor deployed public reverse proxies branded D1337-KAIROS, a containerized Manus-based agent backdoor that reasoned through tasks and ran commands locally, self-hosted LiteLLM gateways, and GPU instances across regions with quota-increase requests.

The lesson for governance teams: stolen model access has a market price, a resale channel, and customer demand. That turns every unscoped API key into a monetizable asset, the same way stolen card numbers became one twenty years ago. Expect LLMJacking to keep displacing cryptojacking, because the margins are better and the payout is immediate.

Network indicators GTIG published: jet-night.com and newapi.pro, both classified as LLM Mixers. Block them at egress and hunt for historical connections.

Why This Is an AI Governance Problem, Not Just a Cloud Ticket

LLMJacking succeeds where AI governance stops at the policy document. The attackers did not beat a model; they walked through gaps in inventory, ownership, spend limits, and logging that an AI management system is supposed to close.

Five governance failures show up across the Mandiant cases:

1. No inventory of model access. If you cannot list which identities can call which models, you cannot notice a new one. GTIG explicitly recommends shadow LLM discovery, which is the AI system inventory ISO/IEC 42001 already expects.
2. Model services that were never approved got switched on. Several victims had no LLM service enabled until the attacker enabled it. That is a change-management and approval failure, not just an IAM gap.
3. Denial-of-wallet was never a named risk. OWASP lists Unbounded Consumption (LLM10:2025) in its Top 10 for LLM applications. Most risk registers still treat AI cost as a FinOps topic, with no owner, no threshold, and no incident trigger.
4. The model gateway is treated as plumbing. LiteLLM-style routers hold master keys for every model you pay for. That makes the gateway a crown-jewel asset that needs patch SLAs, admin-key monitoring, and its own threat model.
5. Agents inherit ambient credentials. The D1337-KAIROS backdoor shows attackers running their own agent inside your cloud on your bill. Any agentic workload with broad service account rights, model access, and open egress closes the “lethal trifecta” of private data, untrusted input, and an outbound channel.

There is also a data protection angle that gets lost in the billing headlines. The same footholds were used to clone repositories, query data warehouse metadata for passwords, and pull secrets from cloud secret managers. Prompts and completions routed through a hijacked gateway can expose customer data. For financial services firms, that can become a reportable incident, not just an unexpected invoice.

This connects to a theme from earlier DISC InfoSec posts, The Controls Are Still Being Written and The Harness Is the Contract: AI capability is shipping faster than the controls and evidence around it. LLMJacking is what that gap looks like once criminals put a price on it.

Threat Model: Risk, Mapping, Control, Evidence

Each LLMJacking risk needs a named control and a piece of evidence an auditor or customer can check. A control without evidence is a statement, not assurance, which is the same point we made in the When Structure Pays case study with Frontier Founder.

Risk	OWASP mapping	Control	Evidence an auditor can verify
Long-lived cloud or LLM keys leak to code, CI, or chat	LLM02 Sensitive Information Disclosure; ASI03 Identity & Privilege Abuse	Workload identity federation instead of static keys; secret scanning with push protection; 90-day max key age	Scanner reports; key-age report from IAM credential report; zero static keys for prod model access
Session token theft bypasses MFA	ASI03 Identity & Privilege Abuse; ASI09 Human-Agent Trust Exploitation	Phishing-resistant MFA; token binding; short session lifetimes; user training on token-paste lures	IdP policy export; conditional access config; training records
Unapproved model services enabled	LLM10 Unbounded Consumption	Org policy denying LLM service enablement outside approved projects; change approval for new models	SCP / Org Policy / Azure Policy export; AI system register entries with approvals
Runaway inference spend	LLM10 Unbounded Consumption	Per-model quotas, hard spending caps, per-key budgets at the gateway, budget alerts to the SOC	Quota config; budget alert routing; test that a cap actually stops calls
Model gateway compromise (e.g., CVE-2026-40217)	LLM03 Supply Chain; ASI04 Agentic Supply Chain	Gateway in asset inventory; 72-hour critical patch SLA; admin keys in a vault; alerts on admin key creation	SBOM; patch tickets with dates; gateway audit log
Logging disabled to hide abuse	No direct OWASP item; ATT&CK T1562.008	Model invocation and data access logs on by default; alerts on any logging change by non-IaC principals	Log config snapshots; alert rule definitions; test alert firing
Hijacked agent runs attacker tasks	ASI02 Tool Misuse & Exploitation; ASI05 Unexpected Code Execution	Sandboxed execution; egress allowlists; no broad service account on agent runtimes	Network policy; runtime identity bindings; sandbox config
Compromised model or dependency pulled into pipelines	LLM03 Supply Chain; ASI04 Agentic Supply Chain	Approved internal model registry; SCA on ML dependencies	Registry allowlist; SCA results in CI

Detection and Hunting Playbook

Treat any unauthorized enablement of an LLM service, or any change to model invocation logging, as a critical security event. Those two signals arrive before the bill does. Volume alerts alone will miss the max_tokens=1 validation sweeps that come first.

AWS (Bedrock, via CloudTrail)

• Abuse: InvokeModel, InvokeModelWithResponseStream, Converse from principals or regions with no history.
• Spraying: spikes in ThrottlingException, ValidationException, ResourceNotFoundException.
• Scoping: ListFoundationModels, ListInferenceProfiles, GetFoundationModelAvailability; unlock attempts via PutUseCaseForModelAccess and CreateFoundationModelAgreement.
• Evasion: GetModelInvocationLoggingConfiguration, PutModelInvocationLoggingConfiguration, DeleteModelInvocationLoggingConfiguration by non-IaC principals.
• Tooling: user agents such as aws-sdk-rust, aws-sdk-go-v2, or CLI tools that your workloads never use.

Azure (Microsoft.CognitiveServices)

• Abuse: high volumes of POST requests to Completions or Chat Completions endpoints. This needs Diagnostic Logs enabled on the data plane.
• New capacity: Microsoft.CognitiveServices/accounts/deployments/write.
• Scoping: accounts/read and accounts/deployments/read by unusual identities.
• Evasion: Microsoft.Insights/diagnosticSettings/read, write, or delete.

Google Cloud (aiplatform.googleapis.com)

• Enablement: alert on ServiceUsage.EnableService for the agent platform.
• Abuse: PredictionService.Predict, GenerateContent, StreamGenerateContent. These live in Data Access audit logs, which are off by default, so turn them on for model projects.
• Scoping: ModelService.ListModels, EndpointService.ListEndpoints, PublisherModelService.ListPublisherModels.
• Evasion: IAMPolicy.GetIamPolicy and log sink reads (ListSinks, GetSink) from unexpected principals.

At the model gateway (LiteLLM, Portkey, Kong AI, custom)

• Requests with max_tokens of 1 to 5 or zero temperature from new source IPs or keys.
• New virtual keys, key regeneration, or admin role changes, especially via /key/regenerate.
• Per-key token rate that jumps more than 10x over its 7-day baseline.
• Egress to known mixer infrastructure such as jet-night.com and newapi.pro, or to lookalike domains of your own hosts.

Cross-cutting identity hunts

• New IAM users or service accounts with names that sound like billing or optimization tools.
• Project-wide SSH keys added to instance metadata; startup script changes.
• Service account key creation, or token creation for high-privilege service accounts.
• Quota increase requests for GPU families you do not run.

If you run Google Security Operations, GTIG maps this activity to existing rules such as GCP Service Account Key Creation, GCE Project SSH Keys, AWS Create New Access Key, and Persistence via instance metadata startup scripts. Other SIEMs can implement the same logic as Sigma or KQL rules.

Hardening: Twelve Controls, Ranked by Payoff

If you do only three things this month, kill static model keys, cap spend per key, and block unapproved LLM service enablement. Those three break the attacker’s business model even when a credential leaks. The rest of the list hardens around them.

Tier 1: stop the bleeding (this week)

1. Hard spend caps and per-model quotas. Set budgets per project and per gateway key, with alerts routed to security, not only finance. A cap turns a $1 million incident into a $5,000 one.
2. Deny-by-default for LLM services. Use AWS SCPs, GCP Organization Policies, or Azure Policy to block enabling Bedrock, the agent platform, or Azure OpenAI outside approved projects. Block model access agreements the same way.
3. Rotate and scope every model key. Inventory LLM API keys, revoke unused ones, and scope the rest by model, environment, and rate. A key for a cheap utility model should never reach a frontier model.

Tier 2: close the doors (this month)

• Replace static cloud keys with workload identity. Service account keys and long-lived access keys were the dominant entry point. Federation removes the thing to steal.
• Secret scanning with push protection across GitHub, GitLab, CI logs, container images, and frontend bundles. Rotate first, then rewrite history.
• Phishing-resistant MFA and short-lived sessions for consoles, IdPs, and developer platforms, plus training on token-paste lures.
• Turn on model invocation and data access logging in every model project, and alert on any change to it.

Tier 3: harden the AI layer (this quarter)

• Treat the model gateway as a crown jewel. Put LiteLLM or equivalent in the asset register, patch CVE-2026-40217 now, store master keys in a vault, and alert on admin key creation.
• Egress allowlisting for model workloads and agent runtimes, plus blocks on known mixer domains.
• Sandbox agents. Run code-executing agents in isolated, process-level sandboxes with no ambient admin identity.
• Approved model and dependency registry. Pull models only from vetted internal sources; run SCA on ML libraries.
• Continuous exposure testing. Scan for open Ollama, vLLM, or gateway endpoints and simulate a validation sweep against your own keys to prove alerts fire.

Governance Crosswalk: Where LLMJacking Controls Live in Your Frameworks

You do not need a new framework for LLMJacking; you need existing controls scoped to model access. The crosswalk below shows where each control family already sits, so one piece of evidence can serve several audits.

Control family	ISO/IEC 42001	ISO/IEC 27001:2022 Annex A	NIST AI RMF 1.0	NIST CSF 2.0	SOC 2 (TSC 2017)
Inventory of models, keys, gateways	A.4.2 resource documentation; A.4.5 system and computing resources	5.9 inventory of assets	GOVERN 1.6	ID.AM	CC6.1
Identity, keys, and MFA	A.4.5; Clause 6.1 risk treatment	5.15, 5.17, 8.2, 8.5	MANAGE 2.4	PR.AA	CC6.1, CC6.2
Approval to enable new models or services	A.6.2.2 to A.6.2.5 lifecycle requirements and deployment	8.9 configuration; 8.32 change management	MAP 1.1; GOVERN 1.4	PR.PS-01	CC8.1
Spend caps and quotas (denial-of-wallet)	A.6.2.6 operation and monitoring	8.6 capacity management	MEASURE 2.7; MANAGE 2.3	PR.IR-04	A1.1
Invocation logging and alerting	A.6.2.8 event logs	8.15 logging; 8.16 monitoring	MEASURE 2.7; MANAGE 4.1	DE.CM	CC7.2
Gateway and ML supply chain patching	A.10 third-party and customer relationships	5.19 to 5.23 supplier and cloud services; 8.8 vulnerabilities	MAP 4.1; GOVERN 6.1	GV.SC; ID.RA	CC7.1, CC9.2
AI incident response	Clause 10 improvement; A.8 information for interested parties	5.24 to 5.28 incident management	MANAGE 4.3	RS.MA	CC7.3 to CC7.5

Two regulatory notes. First, under the EU AI Act, Article 15 requires high-risk AI systems to be resilient against attempts by unauthorized third parties to exploit vulnerabilities, which squarely covers credential and gateway abuse. Second, for U.S. financial institutions, an LLMJacking intrusion that touches customer data can trigger GLBA Safeguards Rule and state notification duties, so loop counsel in early.

Verify control numbers against the current version of each standard before citing them in an audit response; numbering shifts between editions.

Incident Response: The First 60 Minutes and the First 24 Hours

In an LLMJacking incident, every hour of hesitation is billed. Containment comes first, forensics second, because the attacker’s meter is running on your account.

First 60 minutes: stop the spend

1. Apply a hard budget cap or quota of zero on the affected model services and gateway keys.
2. Revoke the suspect LLM API keys and gateway virtual keys. Rotate first where production depends on them.
3. Disable, do not delete, suspect IAM users, service accounts, and keys. Keep them for evidence.
4. Block egress to known mixer domains and to any lookalike domains you find in gateway logs.
5. Snapshot current IAM policy, logging configuration, and gateway config before anyone changes more.
6. Open a case with your cloud provider’s support and abuse teams about the fraudulent charges.

First 24 hours: evict and scope

1. Hunt for persistence: new identities, admin policy attachments, project-wide SSH keys, startup scripts, and GPU instances in unused regions.
2. Find the entry point: leaked keys in Git history, CI logs, container images, or phished session tokens.
3. Scope data exposure: cloned repositories, secret manager reads, data warehouse queries, and prompts or outputs routed through the gateway.
4. Re-enable logging that was altered, and confirm data access logs cover every model project.
5. Brief legal and compliance on notification duties, customer contracts, and cyber insurance terms.
6. Record everything in your AI incident log; ISO/IEC 42001 and SOC 2 auditors will ask for it.

Afterward, run a short post-incident review that ends in specific control changes, owners, and dates, not just a lessons-learned paragraph.

My Perspective

LLMJacking is the clearest proof yet that AI risk is measured in dollars before it is measured in headlines. The industry has spent two years debating jailbreaks and hallucinations. Meanwhile, criminals found the simplest exploit of all: use someone else’s credentials, run someone else’s models, and send someone else the bill.

When I led ShareVault through ISO/IEC 42001 Stage 2 certification, and later wrote its MCP Governance Standard, the controls that held up under audit were never the clever ones. They were inventory, ownership, least privilege, logging, and evidence that those things worked. LLMJacking attacks exactly those basics. Financial data rooms are the hard mode of compliance for a reason: when the asset is money or customer data, the attacker shows up with a business plan.

Three things I would tell any CISO or founder this week:

• Put AI spend on the risk register with a security owner. Denial-of-wallet is a security outcome, and a hard spending cap is the cheapest control you will ever deploy.
• Count your model gateway as a crown jewel. If it holds master keys to every model you pay for, it deserves the same patching and monitoring as your identity provider.
• Ask for evidence, not policy. Can you show an auditor the list of identities that can invoke a frontier model, and an alert that fired in testing? If not, you have a statement, not a control.

The good news is that nothing in the Mandiant report requires exotic tooling. It requires governance that reaches the model layer, which is exactly what ISO/IEC 42001 and the NIST AI RMF were built to do.

Work With DISC InfoSec

If you cannot answer “who can invoke our models, and what stops a $100,000 day?” in under a minute, let’s fix that. DISC InfoSec helps B2B SaaS and financial services teams put AI governance where attackers are actually operating.

• Free AI Governance Readiness Assessment: a 30-minute review of your model inventory, key hygiene, spend controls, and logging.
• AI Governance Quick-Start (7 to 10 days): an LLMJacking-focused control baseline mapped to ISO/IEC 42001, ISO/IEC 27001, and the NIST AI RMF, with evidence your auditors and customers will accept.
• vCISO / vCAIO retainers: ongoing ownership of AI risk, model gateway governance, and audit readiness.

“DiscInfoSec” Deura, CISSP, CISM, ISO/IEC 42001 Lead Implementer, ISO/IEC 27001 Lead Implementer. Principal Consultant, DISC InfoSec. Led ShareVault to ISO/IEC 42001 certification on the first Stage 2 audit.

Book a call: calendly.com/hd-deurainfosec · info@deurainfosec.com · (707) 998-5164

Related DISC InfoSec posts

• The Controls Are Still Being Written: Governing AI When the Technology Outruns the Audit
• The Harness Is the Contract
• US Banks Are Blocking Third-Party AI Agents from Customer Accounts
• When Structure Pays (case study with Frontier Founder)

Sources

• Google Threat Intelligence Group and Mandiant, The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources, November 2, 2026.
• OWASP Top 10 for LLM Applications (2025) and OWASP Top 10 for Agentic Applications (2026).
• MITRE ATT&CK Enterprise (Cloud) and MITRE ATLAS.
• ISO/IEC 42001:2023, ISO/IEC 27001:2022, NIST AI RMF 1.0, NIST CSF 2.0, EU AI Act (Regulation (EU) 2024/1689).

Publishing Notes

• Title: LLMJacking: How Attackers Monetize Stolen Cloud AI Access
• Meta description: LLMJacking drove $100K-a-day fraud in 2026. Learn the kill chain, LLM Mixer economy, detection queries, and ISO 42001 controls that stop denial-of-wallet.
• Slug: /llmjacking-stolen-cloud-ai-access
• Keywords: LLMJacking, LLM API key security, denial-of-wallet, AI governance, ISO 42001, model gateway security, LiteLLM CVE-2026-40217, Bedrock security
• LinkedIn post: Mandiant just documented attackers running up $100,000 a day in AI bills on stolen cloud credentials. Some victims hit $1M before anyone noticed. They didn’t jailbreak anything. They used leaked keys, quietly tested them with one-token requests, switched on model services the victim never used, and resold the access through “LLM Mixers” for $60 a month. Three controls break this business model: no static model keys, hard spend caps per key, and deny-by-default for new LLM services. Full kill chain, detection queries for AWS, Azure, and GCP, and an ISO 42001 crosswalk in the post. #AIGovernance #AISecurity #ISO42001 #CloudSecurity #LLMJacking

Book a call: calendly.com/hd-deurainfosec · Email: info@deurainfosec.com · Phone: (707) 998-5164 · Web: deurainfosec.com

• Your ISO 27001 Certificate Has an AI-Shaped Hole in It
• Someone Is Running Your AI Models Right Now. You’re Paying for It
• Your AI Agent Is Only as Secure as Its Harness: The Hidden Layer of AI Risk
• Your AI Is Live. Your Site Is Your Shop. Who’s Answering for Either?
• Sam Altman Just Issued His Scariest Warning Yet — Fear Tactic or Real Signal?

https://www.deurainfosec.com/disc-infosec-home/aims-iso42001-ai-governance/

Tags: AI Models, LLMJacking