LLMjacking: Hackers Are Turning Stolen AI API Keys Into Cash

One attacker made more than 500,000 calls to a company's AI service in under eight hours and walked away having run up close to a million dollars in charges — all billed to a victim who never approved a single request. That's not a hypothetical. It's one of several incidents Google's Threat Intelligence Group (GTIG) and its incident-response arm Mandiant have now documented, and it points to a problem that's grown faster than most security teams have noticed: stolen AI API keys have become their own underground economy.

What "LLMjacking" Actually Looks Like

The term is LLMjacking — hijacking someone else's paid access to a large language model (think the API key a company's app uses to call Gemini, Claude, or GPT) to run inference the attacker never pays for. It's the AI-era cousin of cryptojacking, where hackers quietly mined cryptocurrency on someone else's servers. The difference is speed: where cryptojacking bleeds a victim slowly, LLMjacking can blow through a six-figure cloud bill in a single afternoon.

What makes this more than opportunistic key theft is the layer built on top of it: GTIG has tracked the rise of what it calls "LLM Mixers" — underground services that pool stolen credentials and resell access to other criminals, no questions asked. In Google's own words:

"LLM Mixers function as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers."

One such service, tracked under the name Jet Night, was caught selling "unlimited" token plans for around $60 a month, against a typical legitimate rate of $100–$250. GTIG's researchers concluded the only way the math works is if the service is quietly running those plans on someone else's stolen key. In one case tied to a group Google tracks as UNC6993, the operators racked up over $100,000 in billing charges almost as soon as they got hold of a company's LLM API key.

How the Keys Get Out in the First Place

Most of this starts in boring, familiar ways. GTIG's incident responders found that the dominant entry point wasn't some exotic AI-specific exploit — it was plain old credential exposure: cloud identity and access management (IAM) logins, service account keys, GitHub access tokens, and active session tokens, often leaked through misconfigured repositories or "infostealer" malware — the kind that quietly scrapes saved passwords and login tokens off an infected computer — already sitting on an employee's machine. Separately, researchers at Okta pulled apart a 7-gigabyte infostealer log dump circulating on Telegram since August, sourced from nearly 6,000 infected machines across 162 countries, and found 555 tokens specifically tied to AI services — 24 of them still live, spanning Gemini, OpenAI, Groq, and OpenRouter accounts.

Attackers have also gotten quieter about using what they steal. Instead of hammering a stolen key with requests, GTIG documented "validation sweeps" — sending a single-token test request just to confirm a key still works, specifically to stay under the volume thresholds that trip security alerts. Some groups also exploited a real vulnerability, CVE-2026-40217, in the popular open-source LLM gateway LiteLLM, which let them escalate a low-privilege key into full admin access on a company's AI proxy. Code24 covered an earlier, separate LiteLLM supply-chain breach in October, and this is the same software showing up again as a soft target. The pattern echoes a story we covered where a campaign called GhostAction compromised hundreds of GitHub accounts specifically to harvest keys like these.

Why This Should Worry Indian Developers and Startups Specifically

This isn't a problem that stays confined to Silicon Valley balance sheets. India has one of the fastest-growing bases of companies wiring LLM API calls directly into products — from fintech apps doing AI-assisted support to the thousands of smaller SaaS and services teams shipping AI features under tight deadlines. The exact mistake GTIG flags as the top entry point — an API key accidentally committed to a public GitHub repo — is an extremely common habit among fast-moving dev teams anywhere, and India's enormous base of outsourced and in-house engineering work means plenty of surface area for it. A single leaked key sitting in a public repo overnight can mean a bill in the lakhs of rupees before anyone notices, and if the compromised account also had access to customer data routed through that AI pipeline, it could trigger breach-notification obligations under India's Digital Personal Data Protection (DPDP) Act. For a startup running lean, that's the kind of bill and compliance headache that doesn't show up in anyone's threat model until it's already happened.

What Actually Helps

None of this requires exotic defenses — just treating AI credentials with the same discipline teams (should) already apply to database passwords and cloud admin keys. GTIG and Okta's findings point to a few concrete steps:

• Scan code repositories, including private ones, for accidentally committed API keys before they ever reach GitHub's public side.
• Set hard spending caps and usage alerts on every AI API account, not just the production ones — test and staging keys get stolen too.
• Rotate any credential that touches infostealer-prone endpoints (developer laptops, CI/CD pipelines) on a routine schedule, not just after an incident.
• Treat an unexpected spike in AI API billing as a security event first and a finance question second.

GTIG's own assessment is blunt about where this is heading: the group expects threat actors to increasingly prioritize LLMjacking over older moneymakers like cryptojacking, simply because the payout arrives faster and the victim often doesn't notice until the invoice lands. For any company treating its AI rollout as a product decision rather than a security one, that invoice is the wake-up call arriving a month too late.