LLMjacking Explained: How Attackers Hijack Cloud AI Credentials to Run Up Your Bedrock Bill

Stolen AWS, Azure, and GCP credentials aren't just being used to mine cryptocurrency anymore. Increasingly, they're being used to quietly run someone else's large language model — on your account, at your expense.

What Happened

In May 2024, the Sysdig Threat Research Team published findings on a cyberattack pattern they named LLMjacking.[1] The idea isn't complicated once you see it: attackers steal cloud credentials, use them to reach large language models hosted on that cloud account, and then resell the access to other people. The victim's card gets charged. The attacker never has to pay an AI vendor a cent.

This wasn't a theoretical exercise. Sysdig traced a real intrusion that started with a system running a vulnerable version of the Laravel PHP framework, tracked as CVE-2021-3129.[1] That initial foothold led to exposed AWS credentials, and from there, straight into Amazon Bedrock, where the attackers went after a hosted Anthropic Claude (v2/v3) model.[1][2] The Hacker News independently reported the same intrusion chain shortly after, describing it as a scheme built around "selling access to other threat actors" rather than direct data theft.[2]

Worth being precise here, since AI security reporting tends to blur categories: this is not a prompt-injection attack, and it's not model poisoning. It's old-fashioned credential theft aimed at a new kind of expensive resource. The vulnerability is in identity and access management, not in the model itself.

How LLMjacking Actually Works

Sysdig's researchers were able to recover the tooling the attackers used, and it's more methodical than "spray some stolen keys and see what sticks." A script the team found — referred to in their writeup as a credential checker — was built to test stolen keys against ten different AI services in one pass: AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter, and GCP Vertex AI.[1] That's a reconnaissance step, not an attack. The goal at that stage is just figuring out which stolen credentials are worth anything.

What's genuinely clever — and mildly unsettling if you're the one who has to defend against it — is how the attackers confirmed access without actually running expensive queries during the check phase. In the CloudTrail logs Sysdig captured, the attackers called Bedrock's InvokeModel API with an intentionally invalid parameter, setting max_tokens_to_sample to -1.[1] That's not a mistake. It's a probe. The malformed request throws a ValidationException rather than an AccessDenied error, which tells the attacker the credentials do have Bedrock access and the model is enabled — without spending a single token doing it.[1]

They also checked whether detailed logging was turned on, by calling GetModelInvocationLoggingConfiguration.[1] CloudTrail alone doesn't capture prompt content — that requires separately configured CloudWatch or S3 logging — so this step let the attackers gauge how visible their subsequent activity would actually be. Sysdig noted that the reverse-proxy tooling associated with this activity, an open-source project called OAI Reverse Proxy, reportedly avoids using AWS keys that have logging enabled, apparently for the attacker's own operational privacy.[1]

Once a working, sufficiently quiet credential set was identified, the model was ready to be handed off. Sysdig found evidence pointing to that reverse proxy being used to centrally manage a pool of compromised credentials and route paying "customers" — other threat actors — through them.[1] That's the resale mechanism. It's essentially a black-market API gateway sitting on top of someone else's AWS bill.

Why the Bill Is the Damage

There's no dramatic breach notification headline here, no ransom note. The damage from LLMjacking shows up as a number on an invoice, and it can be a large one. Sysdig calculated a worst-case scenario for their own reported incident: an attacker maximizing Claude 2.x usage across Bedrock's regional quota limits could generate over $46,000 in consumption costs per day.[1] That figure is based on published Bedrock pricing and quota limits at the time, multiplied across four supported regions.[1]

And that was the early estimate. By the time CSO Online followed up in September 2024, citing later Sysdig research, the picture had gotten worse: LLM requests tied to this activity had grown roughly tenfold during July 2024 alone, with the number of unique IP addresses involved roughly doubling over the first half of the year.[3] Using a more capable, more expensive model — Claude 3 Opus — pushed the worst-case daily cost estimate to over $100,000 per day.[3]

CSO Online's reporting also raised a motive that goes beyond straightforward profit: some of the LLMjacking activity Sysdig tracked appeared to originate from users based in Russia, where Western sanctions restrict direct access to services from companies like OpenAI and Anthropic.[3] If that's accurate for at least a portion of the activity, LLMjacking isn't purely a monetization play — it can also be a way around export and sanctions controls, with the compromised account owner absorbing both the financial and, potentially, the compliance exposure.

It's worth being careful with that last point. Attribution to any particular country or actor group is genuinely hard to nail down from usage patterns and IP geolocation alone, and neither Sysdig nor CSO Online frames it as a confirmed, comprehensive picture of who's behind all LLMjacking activity — just a pattern observed in some of it. Treat it as a documented data point, not a settled conclusion about the whole phenomenon.

This Isn't Just an AWS Problem

Bedrock gets the attention here mostly because Sysdig's incident happened to involve it, and because AWS's CloudTrail logging made the technical reconstruction possible. But the credential-checking tooling Sysdig recovered targeted ten separate AI services across three major cloud providers, plus direct-to-vendor APIs like OpenAI and Anthropic.[1] Any organization with a hosted LLM service — Azure OpenAI Service, Vertex AI, or a direct API key sitting in an environment variable — is a plausible target if the surrounding credential hygiene is weak.

The underlying vulnerability, in every case, is the same one that's driven cloud breaches for years: a credential that shouldn't have been reachable, was. LLMjacking is a new destination for an old attack pattern, not a new kind of vulnerability in the AI systems themselves.

Detection and Response

Sysdig's writeup is unusually specific about what defenders can actually watch for, which is useful because a lot of AI-security advice stays vague. Two detection angles stand out.

The first is watching for the reconnaissance pattern itself. Because the credential-check step relies on a deliberately malformed InvokeModel call, it leaves a distinctive CloudTrail signature: an InvokeModel event against bedrock.amazonaws.com that returns a ValidationException error code.[1] Sysdig published a Falco rule built specifically around that signature, and noted the same detection logic is packaged into their Secure product's AWS Notable Events policy.[1] Even without Sysdig's tooling, the same CloudTrail field combination can be turned into a CloudWatch alert or a Falco rule of your own — it doesn't require anything proprietary to detect, just the awareness that the pattern exists.

The second angle is basic usage visibility. CloudTrail records that an InvokeModel call happened, but not what was in the prompt or the response — that requires explicitly enabling Bedrock's model invocation logging to CloudWatch and S3.[1] Sysdig's own incident response benefited directly from having that logging already turned on.[1] If it isn't enabled in your account, an LLMjacking actor could run a substantial volume of queries with only a CloudTrail event count to go on, and no record of what was actually asked or returned.

Practical steps

• Fix the entry point. In Sysdig's own case study, the intrusion began with an unpatched, publicly known Laravel vulnerability.[1] Basic vulnerability management on internet-facing applications remains the first line of defense — LLMjacking doesn't start with the AI service, it starts wherever credentials get exposed.
• Stop storing keys in the clear. Sysdig's own recommendations list secrets management as a direct mitigation, so credentials can't simply be read off disk or out of a config file by whoever compromises the host.[1]
• Enforce least privilege on anything that can call Bedrock, Vertex AI, or Azure OpenAI. Sysdig specifically recommends CSPM/CIEM tooling to confirm that a compromised identity only has the permissions it actually needs — not broad account access that happens to include AI services.[1] This lines up with AWS's own published guidance: unrestricted Bedrock service-role permissions and long-lived API keys are flagged as common misconfigurations in current cloud security posture checks for Bedrock.[6]
• Turn on model invocation logging and route it to CloudWatch and S3, rather than relying on CloudTrail's event record alone, which doesn't capture prompt or response content.[1]
• Alert on the specific recon signature — InvokeModel calls against Bedrock returning a ValidationException — and treat it as a precursor worth investigating, not noise.[1]
• Watch for models being newly enabled on an account that didn't request them. Model access being disabled by default is not a security control in itself; Sysdig and CSO Online both note that attackers with sufficient permissions can request and enable new models on a compromised account to expand what they can abuse.[1][3]

What Remains Unverified

A few things are worth flagging honestly rather than glossing over. Sysdig's original report ties the intrusion to CVE-2021-3129 in the Laravel framework based on their own incident investigation; that specific CVE-to-incident linkage comes from Sysdig's writeup and was not independently re-confirmed against CVE.org/NVD in the course of preparing this article — it's reported here as Sysdig's finding, not independently re-verified from the CVE record itself. The claim connecting some LLMjacking traffic to sanctions evasion by Russia-based actors is also based on IP-level and behavioral inference reported by Sysdig and relayed by CSO Online, not on confirmed attribution.[3] And cost figures like $46,000/day and $100,000/day are explicitly framed by Sysdig as worst-case, quota-maximizing scenarios — useful for understanding exposure, not a claim that every LLMjacking incident costs that much.[1][3]

Security Takeaway

LLMjacking doesn't require a flaw in any AI model. It requires a flaw in identity and access management, plus an expensive resource sitting behind it. That combination is what makes it worth taking seriously even for organizations that think of themselves as cautious AI adopters — the exposure isn't really about how the LLM is used, it's about how ordinary the underlying credential theft is. The Laravel CVE that started Sysdig's traced incident wasn't exotic.[1] Neither is a stray access key in a public repo, or an over-permissioned service role.

The practical fix looks a lot like standard cloud hardening: patch what's internet-facing, keep credentials out of places they can be read by an attacker who lands on a box, scope IAM permissions tightly, and turn logging on before you need it rather than after. What's new is simply that the resource on the other end of a stolen key can now generate a five- or six-figure daily bill by itself.

Sources & References

• [1] Sysdig Threat Research Team — LLMjacking: Stolen Cloud Credentials Used in New AI Attack — May 6, 2024 — View source
• [2] The Hacker News — Researchers Uncover 'LLMjacking' Scheme Targeting Cloud-Hosted AI Models — May 10, 2024 — View source
• [3] CSO Online (Lucian Constantin) — LLMjacking: How attackers use stolen AWS credentials to enable LLMs and rack up costs for victims — September 20, 2024 — View source
• [4] Infosecurity Magazine — New 'LLMjacking' Attack Exploits Stolen Cloud Credentials — May 2024 — View source
• [5] MSSP Alert — Sysdig: LLMjacking Victims Can Lose Money, and Fast — 2024, citing Sysdig's 2024 Global Threat Year-in-Review — View source
• [6] KodeKloud — Securing Amazon Bedrock and SageMaker Endpoints: A Practitioner's Guide — background context on IAM/least-privilege practices for Bedrock, cited for general defensive context rather than as a source for the incident itself — View source

---