LLMjacking: Stolen Cloud Keys & $100K/Day AI Bills

LLMjacking is a cloud credential attack where threat actors steal AWS, Azure, or GCP access keys to run hosted large language models on a victim's cloud account and resell API access through reverse proxies, risking over $46,000 to $100,000 per day in unauthorized consumption charges [1], [3].

Before launching into the intrusion mechanics, the figure below illustrates how LLMjacking connects a compromised cloud access key directly to hosted commercial AI models:

Conceptual illustration of a stolen cloud key connecting to a stack of AI model icons representing hijacked LLM access in LLMjacking — Conceptual illustration of stolen cloud credentials being used in LLMjacking to reach hosted AI models.

From Laravel CVE-2021-3129 to Hijacked Claude Models

LLMjacking was first documented in May 2024 when the Sysdig Threat Research Team published findings on a post-compromise monetization pattern targeting cloud-hosted artificial intelligence services [1]. The business model behind LLMjacking is straightforward: attackers steal cloud credentials, use those keys to invoke large language models hosted on the victim's cloud account, and resell that API access to third parties while the victim's credit card absorbs the bill [1].

Sysdig's investigation of LLMjacking reconstructed a real-world intrusion that began when attackers exploited a system running a vulnerable version of the Laravel PHP framework tracked as CVE-2021-3129 [1]. That initial CVE-2021-3129 foothold exposed local AWS credentials, allowing the LLMjacking operators to pivot into Amazon Bedrock and target hosted Anthropic Claude (v2/v3) models [1], [2]. The Hacker News independently reported the LLMjacking intrusion chain, noting that the operation centered on "selling access to other threat actors" rather than exfiltrating corporate databases [2].

Separating LLMjacking from other AI security buzzwords matters for defenders. LLMjacking is neither a prompt-injection exploit nor a training-data poisoning attack; instead, LLMjacking is traditional cloud credential theft pointed at an expensive, metered AI API [4]. Much like investigating compromised cloud accounts through forensic auditing, defending against LLMjacking comes down to identity and access management (IAM) and API telemetry rather than model weights.

How LLMjacking Validates Keys and Evades Cloud Logging

LLMjacking relies on automated reconnaissance scripts to sort high-value AI keys from dead credentials before launching any resale proxy [1]. A credential-checker script recovered during Sysdig's LLMjacking analysis tested stolen keys against ten different AI services in a single pass: AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter, and GCP Vertex AI [1].

The diagram below traces the full LLMjacking progression from initial web application compromise through credential validation to reverse-proxy monetization:

Flow diagram of LLMjacking showing progression from compromised web application to stolen cloud keys to unauthorized LLM invocation to resale through a reverse proxy — Conceptual attack-flow diagram based on Sysdig's reported LLMjacking intrusion pattern.

What makes the LLMjacking reconnaissance phase stand out is how the attackers verified Amazon Bedrock permissions without generating token charges during the check. In the CloudTrail logs Sysdig captured from the LLMjacking incident, the attackers called Bedrock's InvokeModel API with an intentionally invalid parameter, setting max_tokens_to_sample to -1 [1]. When AWS returns a ValidationException rather than an AccessDenied error, the LLMjacking script knows the stolen key has valid Bedrock permissions and that the target Claude model is enabled—without spending a single token [1].

During the same reconnaissance window, the LLMjacking operators queried GetModelInvocationLoggingConfiguration to check whether detailed prompt logging was active on the victim account [1]. Because default AWS CloudTrail logs record the API call metadata but not the prompt or completion text, checking GetModelInvocationLoggingConfiguration tells the LLMjacking operator whether CloudWatch or S3 prompt logging will expose their queries [1]. Sysdig noted that the open-source reverse-proxy software used in these LLMjacking campaigns—OAI Reverse Proxy—refuses to load AWS keys that have model invocation logging enabled in order to protect the proxy users' operational privacy [1].

Once the LLMjacking script identifies a working, unlogged key, the operators load the credential into an OAI Reverse Proxy pool that routes queries from external threat actors through the victim's cloud account [1], [2]. That abused built-in cloud API workflow closely mirrors how defenders must approach hunting living-off-the-land (LOTL) activity in telemetry, since every request after initial key theft uses legitimate AWS SDK calls.

The table below summarizes the documented stages of an LLMjacking intrusion alongside the specific API telemetry and financial exposure at each step:

LLMjacking Stage	Documented Technique / Artifact	Defensive & Financial Impact
1. Initial Access & Key Theft	Exploitation of Laravel `CVE-2021-3129` to harvest plaintext cloud environment keys [1].	Exposes long-lived IAM credentials tied to cloud compute or app hosts.
2. Multi-Cloud Key Enumeration	Credential-checker script tests keys against 10 AI platforms (Bedrock, Azure, Vertex AI, OpenAI, Anthropic, etc.) [1].	Identifies active AI quotas across cloud and SaaS providers.
3. Zero-Token Permission Probe	Bedrock `InvokeModel` call with `max_tokens_to_sample: -1` triggering `ValidationException` [1].	Confirms model access without billing tokens; high-signal CloudTrail alert trigger.
4. Logging Evasion Check	Calls `GetModelInvocationLoggingConfiguration` to verify prompt logging is disabled [1].	Blinds defenders to prompt/completion payloads if S3/CloudWatch logging is off.
5. OAI Reverse Proxy Resale	Pools stolen keys behind a reverse proxy for third-party users and enables additional models [1], [3].	Worst-case quota consumption of $46,000/day (Claude 2.x) to $100,000+/day (Claude 3 Opus) [1], [3].

Why the Cloud Bill Is the Primary Damage in LLMjacking

LLMjacking inflicts immediate financial damage rather than leaving behind encrypted servers or a ransom note. Sysdig calculated that in their documented LLMjacking incident, an attacker maxing out Anthropic Claude 2.x regional quotas across four supported Amazon Bedrock regions could generate over $46,000 in LLM consumption charges per day [1].

Those LLMjacking cost projections escalated rapidly as attackers shifted to larger frontier models. When CSO Online reported follow-up Sysdig telemetry in September 2024, LLMjacking requests had surged roughly tenfold during July 2024 alone, while the number of unique IP addresses participating in LLMjacking roughly doubled over the first half of 2024 [3]. Abusing stolen credentials to invoke Anthropic's higher-tier Claude 3 Opus model pushed the worst-case LLMjacking daily cost estimate to over $100,000 per day [3].

The visual below illustrates how LLMjacking turns unmonitored cloud AI quotas into six-figure daily billing exposure:

Conceptual illustration of a rising cost gauge next to a cloud server icon representing runaway AI usage charges from LLMjacking — Conceptual illustration of rapidly accumulating cloud AI usage costs, the primary documented impact of LLMjacking.

Beyond direct black-market resale, LLMjacking also serves as a sanctions-bypass mechanism [3]. CSO Online noted that a portion of the LLMjacking traffic tracked by Sysdig originated from users based in Russia, where Western sanctions block direct commercial sign-ups for OpenAI and Anthropic services [3]. Still, IP geolocation and language patterns in LLMjacking proxy logs do not constitute formal threat-group attribution, so defenders should treat the sanctions-evasion angle as an observed usage pattern rather than proof of a single state-sponsored operator [3].

Cross-Cloud Exposure: Why LLMjacking Reaches Beyond AWS Bedrock

LLMjacking is not restricted to Amazon Web Services even though Sysdig's primary case study reconstructed an AWS Bedrock intrusion [1], [4]. Because the recovered LLMjacking credential-checker script explicitly probes ten separate AI platforms across AWS, Microsoft Azure, Google Cloud Platform, and standalone SaaS providers like OpenAI, Anthropic, Mistral, and ElevenLabs, any environment with loosely scoped API keys is exposed [1], [4]. Organizations struggling with how to detect shadow AI in enterprise networks face an even wider blast radius for LLMjacking when developers hardcode unmonitored AI keys into test servers or code repositories.

Detecting LLMjacking in CloudTrail and Securing IAM

Stopping LLMjacking starts with hunting the exact reconnaissance signature that the credential-checker script leaves behind in cloud audit logs [1]. Because the LLMjacking probe sends an intentionally out-of-bounds parameter (max_tokens_to_sample: -1), defenders can write a deterministic detection rule watching for an InvokeModel event against bedrock.amazonaws.com that returns an error code of ValidationException alongside calls to GetModelInvocationLoggingConfiguration [1].

The second detection requirement for LLMjacking is full model invocation logging. Standard AWS CloudTrail logs confirm that an LLMjacking actor called InvokeModel, but only Bedrock Model Invocation Logging routed to Amazon CloudWatch or S3 records the actual prompt and completion payloads [1]. Turning on model invocation logging serves a dual purpose against LLMjacking: it gives incident responders full forensic visibility and actively deters OAI Reverse Proxy instances that skip logged keys [1].

The illustration below highlights the layered IAM, logging, and anomaly-detection controls that block LLMjacking across cloud accounts:

Conceptual illustration of a shield and monitoring dashboard protecting a vault of cloud credentials against LLMjacking — Conceptual illustration of layered defenses—least-privilege IAM, logging, and anomaly alerts—protecting cloud AI credentials from LLMjacking.

Practical Steps to Block LLMjacking

Patch internet-facing web frameworks to cut off LLMjacking entry points: Because Sysdig's documented LLMjacking intrusion began with an unpatched Laravel vulnerability (CVE-2021-3129) [1], running a disciplined vulnerability management plan on perimeter applications prevents attackers from harvesting host environment variables in the first place.
Eliminate plaintext long-lived cloud keys: Replace static AWS access keys on disk with short-lived IAM roles and dedicated secrets managers so an attacker who compromises a web server cannot extract reusable credentials for LLMjacking [1], [5].
Lock down human console access with strong authentication: Pair least-privilege service roles with phishing-resistant MFA and FIDO2 conditional access on cloud administrator accounts so attackers cannot hijack console sessions to generate new API keys.
Enforce strict IAM least privilege on Bedrock, Vertex AI, and Azure OpenAI: Audit cloud identities with CSPM/CIEM tools to verify that web application roles cannot call bedrock:InvokeModel unless explicitly required [1], [5].
Enable Model Invocation Logging and alert on ValidationException probes: Route Bedrock prompt and response logs to S3 and CloudWatch, and wire your incident response plan to trigger immediate credential rotation whenever an InvokeModel call returns ValidationException or when previously disabled foundational models are newly activated [1], [3].

What Remains Unverified About LLMjacking Campaigns

Several aspects of reported LLMjacking activity require careful qualification. First, while Sysdig traced its initial May 2024 LLMjacking case study to Laravel CVE-2021-3129, that specific entry vector reflects one documented intrusion rather than a universal prerequisite for all LLMjacking attacks [1]. Second, the connection reported by CSO Online between LLMjacking proxy usage and Russia-based users evading Western AI sanctions relies on IP geolocation and behavioral telemetry rather than formal attribution to a specific threat group [3]. Finally, the $46,000/day and $100,000/day LLMjacking cost figures represent theoretical worst-case scenarios calculated by maxing out regional model quotas, not the median loss of every victimized cloud account [1], [3].

Why LLMjacking Changes Cloud Credential Risk

LLMjacking proves that attackers no longer need to spin up noisy EC2 GPU clusters for cryptomining to monetize a stolen cloud key [1]. By routing third-party API requests through managed endpoints like Amazon Bedrock, Azure OpenAI, or GCP Vertex AI, LLMjacking turns a single over-permissioned IAM role into a silent, five- or six-figure daily billing liability [1], [3].

Even organizations that do not actively use generative AI in production remain vulnerable to LLMjacking if their IAM roles carry wildcard permissions that allow an attacker to enable foundational models on demand [3]. Locking down LLMjacking requires stripping `bedrock:*` and equivalent AI permissions from default compute roles, enabling model invocation logging before an incident occurs, and alerting on `ValidationException` credential probes across your cloud accounts [1], [5].