LLMjacking is credential abuse with an expensive meter attached. An attacker obtains an AI provider key, or finds a self-hosted model sitting open on the internet, and runs inference on your account until someone notices the bill. Almost every guide on the subject starts inside the cloud console: rotate the key, set a budget alarm, check CloudTrail. Useful advice, but late. The credential was outside your console long before it was abused inside it, sitting in a stealer log, a public repository or a resale listing, and that is where defenders should be looking first.

This piece works the problem from the outside in, the way an attacker assembles it.

What LLMjacking Actually Is, and Why It Is Not Cryptomining With Extra Steps

The mechanic is simple. Stolen or leaked AI credentials are used to send inference requests to a provider (Amazon Bedrock, Azure OpenAI, OpenAI, Anthropic) under your identity, with the consumption charged to your account. No malware needs to persist on your estate. No lateral movement is required. The key works from anywhere on the internet, which is precisely the design intent.

Cryptojacking taught security teams to expect slow, grinding theft of CPU cycles that becomes visible over weeks. Frontier model inference bills per token, and attackers run high-volume batch workloads rather than trickling usage, so the damage accumulates in hours. Sysdig's Threat Research Team, which named the technique in May 2024, estimated that abuse of a single set of compromised credentials could cost a victim in the region of tens of thousands of US dollars per day in Claude 2.x consumption. That order of magnitude is the point: a spend pattern that would take a crypto miner a quarter to reach lands inside a weekend.

Worse, the traffic looks legitimate. It is API calls to a sanctioned provider, from a valid key, using models your organisation has already enabled.

Two exposure classes that get confused

These need separating, because the discovery method for each is different:

  • Hijacked provider credentials. API keys, IAM roles with Bedrock permissions, service principals with Azure OpenAI access. The exposure lives in text: files, logs, repositories, browser stores.
  • Exposed self-hosted models. Ollama, vLLM, LM Studio and similar, published to the internet with no authentication. The exposure lives on your perimeter as an open port, and anyone scanning the internet can find it.

Attackers use the access for uncensored content generation, for resale, and increasingly as cheap compute for reconnaissance and exploit planning against other targets. Your account becomes someone else's research budget.

Where Your AI Credentials Leak From Before Anyone Touches Your Cloud Account

Infostealer logs

This is the dominant supply line. An infostealer on a developer laptop takes browser cookies, saved credentials and local files in one pass. A .env file in a project directory is a perfect target: the AI provider key sits in the same file as a cloud access key, a database connection string and a webhook secret.

Here is the part most write-ups miss. In stealer log data, AI keys arrive bundled, not alone. Rotating the one key you were alerted to leaves the other dozen secrets from the same grab untouched, along with the session cookies that let an attacker re-enter the accounts you just secured. Triage the device, not the finding. Our 48-hour approach to triaging stealer logs sets out how to work from a single log back to the machine, the user and the full secret inventory taken with it.

Public and semi-public code

Committed keys in repositories remain the most ordinary cause. Add to that CI/CD variables echoed into build logs, Jupyter notebooks published with output cells intact, Postman collections shared with a client, and documentation sites that render an example request with a real token. Rotation alone does not help if the repository history still contains the old value and nobody has checked whether it was ever truly revoked.

Trade and test channels

Keys are traded in batches on paste sites, Discord servers and Telegram channels, where they are tested in bulk against provider endpoints to see which still authenticate and what model access they carry. A key can so be validated by three different buyers before your first billing anomaly.

Third parties holding your keys

Supplier exposure is the quiet one. Agencies, analytics vendors, data science contractors and SaaS integrations are routinely issued long-lived provider keys with no expiry and no scoping, usually during a project kick-off and never revisited. You inherit their laptop hygiene, their repository practice and their offboarding process. Most organisations cannot answer a basic question: which external parties currently hold a credential that can bill our AI spend, and how do they store it?

The Self-Hosted Problem: Exposed Inference Endpoints on Your Own Perimeter

Ollama listens on port 11434. VLLM defaults to 8000. Text Generation WebUI, LM Studio and vector database services each have their own well-known ports. Bind any of them to 0.0.0.0 on a cloud GPU instance with a permissive security group, and you have published a free inference service to the internet. Internet-wide scanning services index new hosts continuously, so exposure is discovered in hours, not at your next quarterly scan.

What an attacker does next is methodical. List the available models with a single unauthenticated request. Read the system prompt. Check what tooling or function calling is attached. Probe what the host can reach on the internal network. Then decide whether the value here is free compute or something better.

The RAG angle

If retrieval is attached, the exposure is no longer about compute. An open endpoint wired to a vector store will happily summarise the documents behind it: contracts, board papers, support tickets, source code. That is a data breach with UK GDPR consequences, not a billing dispute, and the ICO's guidance on AI and data protection is the reference point for how personal data processed through these systems is expected to be governed.

Shadow AI

Self-hosted inference is where shadow IT and LLMjacking meet. A data science team provisions a GPU instance under a departmental cloud account, binds the model to all interfaces because it is quicker than configuring a proxy, and the host never appears in the CMDB because security never knew the account existed. Finance pays for it. Nobody monitors it. External discovery that maps your footprint by provider, IP range and geography finds these hosts; an internal inventory check never will, because the asset was never entered. The same failure mode drives most attack surface drift: inventories describe what was built deliberately, attackers find what was built quickly.

Finding Your Own LLMjacking Exposure From the Outside In

A discovery-led method, in the order it actually works:

  1. Map everything that could host or call a model. Domains, subdomains, cloud IP ranges across every account you can account for, API gateways, forgotten staging environments, and the shadow assets that sit outside all of it. You cannot assess AI exposure against an asset list you do not trust.
  2. Run credential exposure checks against stealer log and leaked credential sources. Filter hard. A raw feed returns thousands of hits for any mid-sized organisation, most of them old, recycled, or a personal account registered with a work email address. Without AI-assisted filtering and clear internal versus external identity classification, teams stop reading the alerts within a fortnight, which is exactly how a live AI key slips past.
  3. Watch the resale layer. Monitor hacker and ransomware channels for your domain, your provider account identifiers and your brand name appearing in access listings. Hijacked access is frequently packaged behind reverse proxies and resold, which means the abuse in your logs may represent dozens of unrelated buyers rather than one attacker. It also means a listing can appear before any usage anomaly does. The practical difficulties of this work, including how quickly channels rotate, are covered in our piece on how dark Telegram channels operate.
  4. Scan infrastructure and web applications together. An exposed inference port and an unauthenticated AI chat widget on a marketing subdomain are the same class of problem reached by different routes. Run both, deduplicate before anything becomes a ticket, and prioritise by what is reachable and exploitable rather than by raw CVSS.
  5. Turn on change detection. A newly exposed port on a GPU host should raise a flag the day it appears. Continuous monitoring is the only control that keeps pace with teams who can stand up an AI service in an afternoon.

The First 48 Hours After You Suspect AI Credential Abuse

Revoke first, investigate second. Unusually for incident response, the containment step is cheap and reversible here. Kill the key, then reconstruct: which key was it, which identity issued it, which device or repository did it leave from, and what else left with it.

Then establish blast radius. What permissions were attached to the IAM role or service principal beyond model invocation? Which regions were enabled, and were new ones enabled during the abuse? Which models were granted? Critically, was anything retrieved rather than merely generated, because inference abuse and data access have very different disclosure consequences.

On cost: collect your evidence while you talk to the provider, not afterwards. Request logs, timestamps, source IP ranges, token counts per model, and the point at which the key was issued and revoked. Providers will often discuss disputed charges arising from credential compromise, but the conversation goes better with a timeline than with an estimate.

Finally, check whether the same identity appears elsewhere. A developer whose machine was logged almost certainly reused credentials across personal services, and the same applies at board level, where executive and VIP identity exposure tends to be broader and less monitored than staff exposure. Supplier accounts deserve the same sweep.

Controls That Hold Up Longer Than a Key Rotation

Replace static keys with short-lived workload identity. Per-application scoping, time-bound credentials, no shared keys across environments. A key that expires in an hour has very little resale value.

Alert on tokens, not money. Billing alarms are a poor detection control for AI abuse because thresholds are set against a monthly budget, so a key being hammered on a Friday evening may not trip anything until Tuesday. Token-volume and request-rate anomalies on a per-key basis fire far earlier, and they work even when the spend is within budget.

Enforce bind-address and egress discipline for self-hosted models. Localhost or private interface by default, authenticated reverse proxy in front, egress restricted. Pair it with a simple rule: no GPU workload goes live until the host appears in the external asset inventory.

Put supplier key handling in the contract. ISO 27001 Annex A controls covering cryptographic key management and supplier relationships give you a recognised basis for asking how a vendor stores your credentials, and continuous supplier accreditation tracking tells you when that status changes. The NCSC's guidelines for secure AI system development are a reasonable baseline to reference in schedules where a supplier builds or hosts anything model-adjacent.

Report exposure change, not vulnerability counts. Leadership will read a page showing how your AI-facing exposure moved week to week: new inference endpoints discovered, credentials found and revoked, supplier keys outstanding. They will not read a list of 400 findings. That reporting discipline is one of the things a managed threat intelligence provider should deliver as standard.

Frequently Asked Questions

What is LLMjacking and how does it differ from cryptojacking?

LLMjacking is the abuse of stolen or exposed AI credentials to run inference on a victim's account, billed to the victim. Cryptojacking steals compute cycles and surfaces slowly; LLMjacking is billed per token at frontier model rates, so costs accumulate within hours. The traffic also blends in, because it consists of valid API calls to a provider you already use.

How do attackers get hold of AI API keys in the first place?

Mostly from outside your cloud account. Infostealer logs harvested from developer machines (including .env files and browser-stored secrets), keys committed to public repositories, CI/CD variables echoed into build logs, shared notebooks and Postman collections, and long-lived keys held by agencies and contractors. Keys are then tested and traded in batches on paste sites and private channels.

How quickly can an LLMjacking bill grow before anyone notices?

Fast enough that monthly budget alarms are the wrong control. Sysdig's May 2024 research, which first documented the technique, estimated potential consumption costs in the region of tens of thousands of US dollars per day from a single compromised credential set. Per-key token-volume alerting detects that pattern far sooner than spend thresholds.

Are self-hosted models like Ollama and vLLM at risk of LLMjacking?

Yes, and often more so, because many deployments have no authentication at all. Ollama on port 11434 or vLLM on 8000, bound to 0.0.0.0 on a cloud GPU instance, can be enumerated with one unauthenticated request. If retrieval is attached, an attacker can extract the documents behind the model as well as using the compute.

What should we do first if we think our AI credentials have been hijacked?

Revoke the credential immediately, then investigate. Identify the issuing identity, the source device or repository, and every other secret that left in the same grab, since AI keys in stealer logs rarely travel alone. Establish whether data was retrieved as well as generated, and preserve provider logs before opening any billing discussion.

LLMjacking rewards attackers for the same reason most external exposure does: assets and credentials exist in places the asset inventory does not describe. If you want to see your AI-facing footprint the way an attacker sees it, including the keys and endpoints you did not know were public, take a look at the DarkInvader platform.