LLMjacking — How AI API Key Theft Works and How to Prevent It
LLMjacking — How AI API Key Theft Works and How to Prevent It
TLDR: The startup's monthly OpenAI bill was normally $400. The invoice that arrived was $67,000. Their API key had been in a public GitHub repository for 11 days. Automated bots found it within minutes of the commit. They had been running commercial AI services — on the startup's account — for over a week before anyone noticed. This is LLMjacking — a named attack category that Sysdig first documented in May 2024, and that Microsoft took to court in January 2025 against a criminal syndicate called Storm-2139 that had industrialised the practice across Azure, OpenAI, AWS Bedrock, Anthropic, Google Vertex AI, and Mistral. If your application calls any AI API, this post is directly relevant to you.
What LLMjacking Is and Why It Has Its Own Name
LLMjacking follows the same pattern as two older attack categories: cryptojacking — where stolen compute resources are used to mine cryptocurrency — and proxyjacking — where stolen bandwidth is resold. In LLMjacking, stolen AI API credentials are used to run large language model inference at the victim's expense, either for the attacker's own use or resold to third parties on illicit marketplaces.
The term was coined by Sysdig's threat research team in May 2024, when they documented an active campaign targeting AI credentials across every major cloud AI provider — OpenAI, Azure, AWS Bedrock, Anthropic, Google Cloud Vertex AI, and Mistral — all using the same method: stolen credentials scraped from public sources and used to run inference through reverse proxy infrastructure.
What makes LLMjacking economically attractive to attackers is simple: modern frontier AI models are expensive to run. GPT-4o, Claude Opus, and Gemini Ultra operate at costs that scale rapidly with usage. An attacker who gains access to a victim's API key can run inference at industrial volume — selling the access to other criminals who want to generate content, bypass ethical guardrails, or run AI workloads — while the victim pays the bill without knowing it.
How API Keys Get Exposed
The most common exposure vector is also the most preventable: keys committed to source code repositories.
A developer sets an environment variable locally, tests the integration, and accidentally commits the .env file — or hardcodes the key directly in the source to "test quickly" and forgets to remove it before pushing. The repository is public. Within minutes, automated scanners operated by criminal groups and independent researchers are indexing that commit and extracting the credential.
GitGuardian's 2025 State of Secrets Sprawl Report found that over 23 million secrets were exposed on GitHub in 2024 — a 25% increase year on year. AI provider API keys were among the fastest-growing categories. The report found that the median time between a secret being committed and it being found by an external actor is under four minutes.
Beyond GitHub, the other common exposure vectors are: API keys embedded in frontend JavaScript bundles that are shipped to users' browsers; .env files included in Docker images pushed to public container registries; keys hardcoded in mobile app binaries (which can be extracted through reverse engineering); and misconfigured cloud storage buckets where configuration files are publicly readable.
What Attackers Do With Stolen Keys
Microsoft's investigation into Storm-2139 — the criminal group it sued in January 2025 — is the most detailed public account of how a professionalised LLMjacking operation works.
Storm-2139 consisted of three broad categories of participants: Creators who developed the illicit tools to exploit AI services; Providers who modified and distributed these tools at various price points; and End Users who used the tools to generate content that violated AI providers' acceptable use policies.
The syndicate built a custom tool called de3u — a web application that allowed users to generate DALL-E images using stolen Azure API keys, with built-in features specifically designed to circumvent Microsoft's content safety filters. Microsoft alleges that the defendants used stolen Azure OpenAI Service API keys belonging to U.S.-based customers to create a "hacking-as-a-service" scheme. They also operated aitism.net, a reverse proxy service that routed requests through Cloudflare tunnels, masking the origin and making abuse significantly harder for Microsoft to detect and attribute.
After the release of the DeepSeek R1 model, Sysdig detected LLMjacking attackers targeting it within days. This is characteristic of how quickly criminal groups adapt: any new AI service with sufficient capability becomes a target almost immediately after launch.
The uses for stolen AI access fall into three categories. First, financial — reselling access at a fraction of the legitimate cost. Second, content generation that would be refused by the AI provider's safety systems, using the compromised account to bypass guardrails that apply to legitimate users. Third, operational — running AI workloads (translation, code generation, research) for criminal enterprises without incurring the direct cost.
The Financial Exposure Is Real and Immediate
The billing impact of LLMjacking is not gradual. Attackers operate at scale — running thousands of requests in parallel through the victim's credentials — which means a single compromised key can generate enormous charges within hours.
The exact figures depend on which model is being abused and at what volume. GPT-4o is priced at $2.50 per million input tokens and $10 per million output tokens. An attacker running high-volume image generation or large-context completions through a stolen key can exhaust a $10,000 monthly budget in under 24 hours.
Most AI providers do offer spending limits and billing alerts — but these features are optional, are not configured by default in all cases, and require the account holder to have anticipated the risk. An organisation that set up its OpenAI account two years ago and never revisited the billing configuration is exposed by default.
Microsoft vs. Storm-2139: January–February 2025
In December 2024, Microsoft filed a civil complaint in the U.S. District Court for the Eastern District of Virginia against 10 unnamed defendants. In January 2025, the lawsuit became public and Microsoft obtained a court order to seize aitism.net, the reverse proxy server central to the operation.
The legal actions taken by Microsoft, including the seizure of a key website, resulted in significant disruption to the network. Members of the group reacted with alarm, engaging in online chatter, attempting to identify other members, and even resorting to doxing Microsoft's legal counsel.
In February 2025, Microsoft publicly named four of the ten defendants: Arian Yadegarnia ("Fiz") of Iran, Alan Krysiak ("Drago") of the UK, Ricky Yuen ("cg-dot") of Hong Kong, and Phát Phùng Tấn ("Asakuri") of Vietnam. Two additional US-based members were identified but not named to avoid interfering with ongoing criminal investigations.
Evidence Microsoft uncovered indicated that the Azure Abuse Enterprise had been targeting and victimising other AI service providers, not just Microsoft. Storm-2139 is not a one-provider problem. It represents a professionalised criminal operation targeting the entire AI infrastructure ecosystem.
How to Check If Your Keys Are Exposed Right Now
Before implementing any future prevention, check your current exposure.
Search GitHub for your organisation name plus common secret patterns. GitHub's own search can surface public commits containing API keys if you know what to look for. Search for your domain name alongside terms like api_key, OPENAI_API_KEY, or Bearer.
Run TruffleHog against your repositories. TruffleHog is an open-source tool that scans git history — including deleted commits — for credentials. It recognises AI provider key formats specifically. Running it against your full commit history, not just the current state of the repository, is essential: deleting a committed key from the repository does not remove it from git history.
Check your AI provider's usage dashboard. An unexpected spike in API usage — especially at unusual hours or from unfamiliar IP addresses — is the most direct signal of active abuse. Most providers expose usage logs in their dashboards; few organisations review them regularly.
Audit your public container registries. Images pushed to Docker Hub or similar public registries that include .env files or configuration with credentials are a common and underappreciated exposure vector.
Prevention Checklist
Never store API keys in source code or client-side code. API keys belong in environment variables on the server, in a secrets manager (AWS Secrets Manager, HashiCorp Vault, or similar), never in frontend JavaScript bundles and never in committed files.
Rotate keys immediately if any doubt about exposure exists. Rotation is free, instant, and eliminates the risk from any key that may have been compromised. Most organisations rotate API keys far less frequently than they should.
Set spending limits and billing alerts on every AI provider account. These must be configured actively — they are not on by default in most cases. Set an alert at 50% of expected monthly spend and a hard limit above that. A $400-per-month account should have a hard cap at $500, not unlimited.
Use least-privilege API key scoping where available. Some providers allow keys to be scoped to specific models, endpoints, or IP ranges. A key that can only call the specific model your application uses cannot be redirected to run DALL-E image generation at scale.
Enable usage logging and review it. Unusual request volumes, unusual model usage, unusual geographic origins — these are all detectable if you're looking. Set a calendar reminder to review your AI provider usage logs monthly at minimum.
Add pre-commit hooks that scan for secrets before they can be committed. Tools like detect-secrets and git-secrets intercept commits containing credential-like patterns before they reach the repository.
What to Do If You've Already Been LLMjacked
Revoke the compromised key immediately from the AI provider's dashboard. Do not wait for investigation — revoke first, investigate after. A revoked key cannot be further abused.
Issue a new key and update your application configuration. Treat the new key with the prevention controls above from day one.
Contact your AI provider's trust and safety or billing team. Some providers will credit or waive charges incurred through documented credential theft, particularly if reported promptly. There is no guarantee — but the conversation is worth having.
Audit what was done with the key during the exposure window. Review usage logs for the period of suspected compromise: what models were called, at what volume, what was generated. If your application processed user data through the compromised API, you may have data handling obligations to consider.
Conduct a full secrets audit across all repositories and infrastructure before issuing replacement keys. Replacing one exposed key without finding the others leaves the underlying exposure in place.
How Kuboid Secure Layer Can Help
At Kuboid Secure Layer, secrets scanning and AI API key security are a specific component of our security assessment services. We scan your repositories — including full commit history — for exposed credentials, review your AI infrastructure configuration against current best practices, and test your broader AI application attack surface for the vulnerabilities covered across this blog series.
If you're building on AI APIs and want confidence that your key management, billing controls, and application architecture are properly secured, get in touch with us here. You can also read more about our approach to understand how we work.
Final Thought
LLMjacking is not a sophisticated attack. It does not require expertise in AI systems, reverse engineering, or exploit development. It requires finding an exposed credential — a task that automated scanners perform at scale, continuously, for free.
The organisations that get hit are not careless organisations. They are organisations that built fast, followed patterns they learned before AI APIs existed, and didn't update their secrets management practices when a new, expensive-to-abuse credential type entered their stack.
The fix is not complex. It is a checklist of hygiene practices that most engineering teams can implement in a day. The question is whether they do it before a $67,000 invoice arrives, or after.
Kuboid Secure Layer provides AI security assessments, secrets scanning, and application penetration testing for businesses building on modern AI infrastructure. Learn more at www.kuboid.in or visit our blog for more posts in this series.