PUBLIC-EVIDENCE AI SECURITY CASE STUDY

LLM Jacking

The Sysdig Threat Research Team discovered that malicious actors utilized stolen credentials to gain access to cloud-hosted large language models (LLMs). The actors covertly gathered information about which models were enabled on the cloud service and created a reverse proxy for…

Standalone LLM / Generative AITier 3Indicative ERS 3.5 (1.1–5.9)Evidence source date 2026-08-02

Use case sources

Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.

The Sysdig Threat Research Team discovered that malicious actors utilized stolen credentials to gain access to cloud-hosted large language models (LLMs). The actors covertly gathered information about which models were enabled on the cloud service and created a reverse proxy for LLMs that would allow them to provide model access to cybercriminals.

The Sysdig researchers identified tools used by the unknown actors that could target a broad range of cloud services including AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter, and GCP Vertex AI. Their technical analysis represented in the procedure below looked at at Amazon CloudTrail logs from the Amazon Bedrock service.

The Sysdig researchers estimated that the worst-case financial harm for the unauthorized use of a single Claude 2.x model could be up to $46,000 a day.

Update as of April 2025: This attack is ongoing and evolving. This case study only covers the initial reporting from Sysdig.

ASSESSED SYSTEM

Representative configuration: a customer cloud account with Amazon Bedrock model invocation enabled, authorised by cloud credentials left unsecured on a victim system that the adversaries compromised through a vulnerable Laravel application (CVE-2021-3129), as reconstructed by Sysdig Threat Research from Amazon CloudTrail logs for its May 2024 report. Scored as the configuration stood when the stolen credentials were used.

OUT OF SCOPE

The Laravel compromise itself as a non-AI web-application vulnerability, except as the place the credentials were exposed; the adversaries' keychecker tool and OAI Reverse Proxy service (attacker tooling); the cybercriminal customers of the proxy; and the other AI services the actors' tooling could target (AI21 Labs, Anthropic, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter, and GCP Vertex AI), for which the record contains no per-service control evidence.

Architecture: Standalone LLM / Generative AI (decision tree Q5) — Q1 to Q4 = NO: the assessed boundary is a cloud-hosted model invocation surface (the InvokeModel API) with no agent coordination, planning, tool execution, or retrieval described. Q5 = YES: the enabled models generate open-ended output for whoever holds an authorised credential, which is exactly the capability the reverse proxy resold. Tier 3: Tier 3 Internal: the record does not describe the victim's own use of its Bedrock models, so the placement for cloud model access provisioned to an organisation's own workloads applies. The harm fell on the account owner through unauthorised spend and covert resale of access rather than on members of the public interacting with the system.

Documented attack or failure path

  1. Initial access through a non-AI host. The adversaries exploited CVE-2021-3129 in a vulnerable Laravel system and found cloud credentials stored unsecured on the victim's systems.
  2. Credential replay against the model service. The stolen credentials gave access to cloud environments hosting LLM services.
  3. Permission and configuration enumeration. Using keychecker, the adversaries determined which models were enabled and whether quotas applied, confirmed invoke permission with InvokeModel calls carrying an invalid max_tokens_to_sample value of -1 (which returns AccessDenied when the credential lacks access), and called GetModelInvocationLoggingConfiguration to learn whether prompt logging was enabled.
  4. Resale of access. The adversaries placed OAI Reverse Proxy in front of the stolen model access so that it could be sold to cybercriminals.
  5. Financial impact. Unauthorised use could cost victims thousands of dollars per day; Sysdig estimated a worst case of up to $46,000 per day for one Claude 2.x model.

Observed controls and bounded outcomes

Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.

  • Bedrock enforced authorisation on model invocation: the adversaries' own probe was built around the AccessDenied response that a credential without invoke permission receives.
  • Amazon CloudTrail recorded the adversaries' Bedrock API activity in enough detail for Sysdig to reconstruct the enumeration and invocation procedure after the fact.

Layer 1 — Intrinsic Vulnerability Profile

Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.

Sub-metricScoreRubric basisEvidence
Robustness (Ro) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.40 indeterminate
Fairness (Fa) NOT APPLICABLE — axis-level applicability rule (Person-Outcome Surface test): The assessed boundary is credential-bound model invocation on a hosted Bedrock serving API whose outputs are raw completions returned to API callers; within that boundary it allocates, ranks or describes no natural person and no protected-class attribute or proxy is evidenced. Its tier weight is redistributed across the remaining axes and its MVT is not evaluated.
Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate
Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.50 indeterminate
Containment (Cn) — scenario interval 0.06–0.83 (midpoint 0.44), Tier 3 MVT 0.50 indeterminate
Cn-4Side-Channel Resistance0.25w 0.13The 0.25 anchor: basic error handling existed (the malformed request was rejected) but the error channel still revealed authorisation state, and logging-configuration telemetry was readable by the stolen credential. The 0.50 anchor requires primary side channels to be mitigated; the record shows both channels used successfully.An InvokeModel request with an invalid max_tokens_to_sample value of -1 distinguished authorised from unauthorised credentials through its error response, and GetModelInvocationLoggingConfiguration disclosed whether prompt logging was enabled, helping the adversaries avoid detection when executing prompts.source: secureflow/atlas
Cn-5Agent Identity Integrity0.25w 0.09The 0.25 anchor: credential-based authentication existed, so calls without access were refused (above 0.00), but possession of the credential alone was sufficient; nothing bound it to the originating workload, network, or session to stop replay and onward resale. The 0.50 anchor requires scoped token identity with partial verification, which is not evidenced.Cloud credentials taken from a compromised victim system authenticated the adversaries to the model service, after which access was resold through a reverse proxy to unidentified third parties.source: secureflow/atlas

Unknown, not N/A: 19 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.

Architecture-based NOT APPLICABLE: declared with an architecture rationale in the workpaper: Cn-9; excluded with the Fairness axis.

Layer 2 — Operational Risk Posture

DimensionScoreJustification
AaAutonomy Amplification0.25w 0.20The assessed service generates output and holds no tool, write, or transaction authority on the observed path. Placed at 0.25 rather than 0.00 because responses flowed to automated consumers with no human review, which the 0.00 anchor ('every output reviewed') does not describe.
AsAttack Surface Exposure0.75w 0.25The model invocation API is internet-reachable by any holder of a valid credential, the authorising credential was exposed on a compromised system, and input then came from arbitrary proxy customers. Not 1.00: no untrusted retrieval, multi-agent, or MCP integration lies inside the boundary.
CpCascade Potential1.00w 0.30No verified System Dependency Graph with DGC at least 0.90 is public for this boundary, so the specification's worst-case graph default governs rather than an assessor-estimated blast radius.GDCP: worst-case default — no verified dependency graph published elevated
RfRemediation Feasibility0.25w 0.25Model-adjacent infrastructure change measured in days with no model change: revoke and rotate the exposed credentials, remove unsecured credential storage, patch the Laravel host, enable model invocation logging, and add spend and token alerting. Not 0.00, because closure spans credential hygiene, monitoring, and quota configuration rather than one deterministic patch.

Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.

Layer 3 — Public-evidence confidence diagnostic

ComponentScoreBasis
Pc — Public provenance evidence0.15Below the 0.25 anchor, which requires a documented deployment owner: Sysdig describes victims' cloud environments from CloudTrail analysis without identifying an owner, a model inventory, or the victims' intended use of the models.
Ec — Public evaluation coverage0.08coverage 0.10 (2 of 21 applicable sub-metrics) × independence 1.00 × fidelity 0.85. No Full, Standard, or Lite pathway is claimed for a retrospective article.
Tf — Public-evidence freshness0.03Evidence dated 2024-05-06; age 895 days on the workpaper reference date. Components: T_calendar 0.03 · C_event 0.35 · C_monitor 0.65 · C_evidence 0.85. Binding term: T_calendar. dt_days = 895, measured from Sysdig's initial report (MITRE ATLAS AML.CS0030 incident date 2024-05-06) to the 2026-10-18 evidence reference date; ATLAS notes that the activity is ongoing and evolving, but this case covers only the initial reporting. agentic = false and baw = false: hosted model invocation with no tool, memory, or feedback loop inside the boundary. C_monitor 0.65: the abuse was surfaced by an external researcher, and the adversaries checked whether prompt logging was enabled specifically to evade detection. C_event 0.35: confirmed unauthorised use of the assessed model service with stolen credentials. C_evidence 0.85: credential revocation and closure are not evidenced for the victim population.

Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.07 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.

Indicative ERS — normalized-assurance scenario

Worp · ORP0.20(0.25) + 0.25(0.75) + 0.30(1.00) + 0.25(0.25) = 0.600
CRMNelevated = 1 → 1.00
ORPeffective0.600 × 1.00 = 0.600
Wivp · IVP midpoint0.24(0.50) + 0.24(0.50) + 0.29(0.50) + 0.24(0.44) (tier weights renormalized over the applicable axes) = 0.487
IVP mitigation0.15 + 0.85(1 − 0.487) = 0.586
Scenario assuranceACI fixed at 1.000 for cross-case comparison; public-evidence ACI 0.074 is diagnostic only
Indicative ERS midpointmin(10, 0.600 × 0.586 × 1/1.000 × 10) = 3.5
Unknown-input interval1.1–5.9; 19 unknown applicable sub-metrics set to 1.00 / 0.00 at the bounds

Published CVSS beside indicative ERS

Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.

INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO

3.5 midpoint, interval 1.1–5.9; Low-Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.

PUBLISHED CVSS

CVSS — no applicable published score verified.

CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.

AIDEFEND defences → AITBM sub-metrics

Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.

TechniqueDefence PriorityEvidences
AID-H-004.002Service & API AuthenticationExact SecureFlow defense-map identifier (flow atlas-aml-cs0030-llm-jacking), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-2, step-3, step-6. Presence supplies no score credit.Candidate evidence routeTr-3 Cn-5
AID-E-001.001Root & Long-Lived Credential Object EvictionExact SecureFlow defense-map identifier (flow atlas-aml-cs0030-llm-jacking), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-2, step-3. Presence supplies no score credit.Candidate evidence routeCn-5
AID-D-005.007Token, Tool-Use, Request-Parameter & Cost Spike Detection & AlertingExact SecureFlow defense-map identifier (flow atlas-aml-cs0030-llm-jacking), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-5, step-7. Presence supplies no score credit.Candidate evidence routeTr-3 Cn-7
AID-I-003.003Resource, Token & Spend Budget ThrottlingExact SecureFlow defense-map identifier (flow atlas-aml-cs0030-llm-jacking), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-6, step-7. Presence supplies no score credit.Candidate evidence routeCn-5 Cn-6 Cn-7
AID-D-005.003Proactive AI Threat HuntingExact SecureFlow defense-map identifier (flow atlas-aml-cs0030-llm-jacking), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit.Candidate evidence routeTr-3 Cn-7

WHAT THIS CASE TEACHES

For a hosted model service the decisive control is credential binding, not the model: authorisation worked as designed, yet a replayable credential plus an error-oracle side channel let attackers confirm access, check logging, and resell inference, so AITBM records the loss on Cn-5 and Cn-4 and leaves the model's own behaviour unscored.

Sources: AIDEFEND SecureFlow — LLM Jacking · MITRE ATLAS case study AML.CS0030 · LLMjacking: Stolen Cloud Credentials Used in New AI Attack (sysdig.com) · The Growing Dangers of LLMjacking: Evolving Tactics and Evading Sanctions (sysdig.com) · LLMjacking targets DeepSeek (sysdig.com) · AIID Incident 898: Alleged LLMjacking Targets AI Cloud Services with Stolen Credentials (incidentdatabase.ai)

SecureFlow attack flow

This record mirrors an AIDEFEND SecureFlow flow (MITRE ATLAS case-study conversion): an ordered attack path with MITRE ATLAS tactic and technique labels and the AIDEFEND controls matched to each step. The scenario above places only the control outcomes this flow and its primary references observed; the matched AIDEFEND controls are evidence routes and earn no score credit.

MITRE ATLAS case studyAML.CS0030 (incident)
TargetCloud-Based LLM Services
ActorUnknown
ReporterSysdig Threat Research
Primary evidence date2024-05-06
SecureFlow record updated2026-08-02
AI layersAI infrastructure
Risk impactResource hijacking / cost, Credential and identity theft
Affected componentscloud-hosted LLM services, stolen cloud credentials, Amazon Bedrock InvokeModel API, OAI reverse proxy service

Attack steps

#StepATLAS tactic / technique
1Exploit Vulnerable Laravel SystemThe adversaries exploited a vulnerable version of Laravel (CVE-2021-3129 (https://www.cve.org/CVERecord?id=CVE-2021-3129)) to gain initial access to the victims' systems.AML.TA0004
AML.T0049
2Find Unsecured Cloud CredentialsThe adversaries found unsecured credentials to cloud environments on the victims' systemsAML.TA0013
AML.T0055
3Access Cloud LLM Services with Stolen CredentialsThe compromised credentials gave the adversaries access to cloud environments where large language model (LLM) services were hosted.AML.TA0012
AML.T0012
4Obtain Bulk AI Service Key CheckerThe adversaries obtained keychecker (https://github.com/cunnymessiah/keychecker), a bulk key checker for various AI services which is capable of testing if the key is valid and retrieving some attributes of the account (e.g. account balance and available models).AML.TA0003
AML.T0016.001
5Enumerate LLM Access and Logging ConfigurationThe adversaries used keychecker to discover which LLM services were enabled in the cloud environment and if the resources had any resource quotas for the services. Then, the adversaries checked to see if their stolen credentials gave them access to the LLM resources. They used legitimate `invokeModel` queries with an invalid value of -1 for the `max_tokens_to_sample` parameter, which would raise an `AccessDenied` error if the credentials did not have the proper access to invoke the model. This test revealed that the stolen credentials did provide them with access to LLM resources. The adversaries also used `GetModelInvocationLoggingConfiguration` to understand how the model was configured. This allowed them to see if prompt logging was enabled to help them avoid detection when executing prompts.AML.TA0008
AML.T0075
6Proxy Stolen LLM Access to OthersThe adversaries then used OAI Reverse Proxy (https://gitgud.io/khanon/oai-reverse-proxy) to create a reverse proxy service in front of the stolen LLM resources. The reverse proxy service could be used to sell access to cybercriminals who could exploit the LLMs for malicious purposes.AML.TA0003
AML.T0016.001
7Inflict Unauthorized LLM Usage CostsIn addition to providing cybercriminals with covert access to LLM resources, the unauthorized use of these LLM models could cost victims thousands of dollars per day.AML.TA0011
AML.T0048.000

Threat references

Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=atlas-aml-cs0030-llm-jacking; AIDEFEND content CC BY 4.0), converted from MITRE ATLAS case study AML.CS0030 (Apache License 2.0; MITRE ATLAS is a trademark of The MITRE Corporation).

AITBM sub-metrics referenced