{
	"id": "36dd4a75-37ac-4a05-9b02-5de4b24b1b67",
	"created_at": "2026-04-06T03:37:44.11888Z",
	"updated_at": "2026-04-10T03:21:31.682693Z",
	"deleted_at": null,
	"sha1_hash": "c5de4ac3e69f0ef40e4eabd5f1d4f83e82577b3b",
	"title": "LLMjacking: Stolen Cloud Credentials Used in New AI Attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1242455,
	"plain_text": "LLMjacking: Stolen Cloud Credentials Used in New AI Attack\r\nBy Alessandro Brucato\r\nPublished: 2024-05-06 · Archived: 2026-04-06 03:14:19 UTC\r\nPublished:\r\nMay 6, 2024\r\nTable of contents\r\nfalco feeds by sysdig\r\nFalco Feeds extends the power of Falco by giving open source-focused companies\r\naccess to expert-written rules that are continuously updated as new threats are\r\ndiscovered.\r\nlearn more\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 1 of 13\n\nThe Sysdig Threat Research Team (TRT) recently observed a new attack that leveraged stolen cloud credentials in\r\norder to target ten cloud-hosted large language model (LLM) services, known as LLMjacking. The credentials\r\nwere obtained from a popular target, a system running a vulnerable version of Laravel (CVE-2021-3129). Attacks\r\nagainst LLM-based Artificial Intelligence (AI) systems have been discussed often, but mostly around prompt\r\nabuse and altering training data. In this case, attackers intend to sell LLM access to other cybercriminals while the\r\ncloud account owner pays the bill.\r\nOnce initial access was obtained, they exfiltrated cloud credentials and gained access to the cloud environment,\r\nwhere they attempted to access local LLM models hosted by cloud providers: in this instance, a local Claude\r\n(v2/v3) LLM model from Anthropic was targeted. If undiscovered, this type of attack could result in over $46,000\r\nof LLM consumption costs per day for the victim.\r\nSysdig researchers discovered evidence of a reverse proxy for LLMs being used to provide access to the\r\ncompromised accounts, suggesting a financial motivation.  However, another possible motivation is to extract\r\nLLM training data.\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 2 of 13\n\nBreadth of Targets\r\nWe were able to discover the tools that were generating the requests used to invoke the models during the attack.\r\nThis revealed a broader script that was able to check credentials for ten different AI services in order to determine\r\nwhich were useful for their purposes. These services include:\r\nAI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter, and\r\nGCP Vertex AI\r\nThe attackers are looking to gain access to a large amount of LLM models across different services. No legitimate\r\nLLM queries were actually run during the verification phase. Instead, just enough was done to figure out what the\r\ncredentials were capable of and any quotas. In addition, logging settings are also queried where possible. This\r\nis done to avoid detection when using the compromised credentials to run their prompts.\r\nBackground\r\nHosted LLM Models\r\nAll major cloud providers, including Azure Machine Learning, GCP's Vertex AI, and AWS Bedrock, now host\r\nlarge language model (LLM) services. These platforms provide developers with easy access to various popular\r\nmodels used in LLM-based AI. As illustrated in the screenshot below, the user interface is designed for simplicity,\r\nenabling developers to start building applications quickly.\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 3 of 13\n\nThese models, however, are not enabled by default. Instead, a request needs to be submitted to the cloud vendor in\r\norder to run them. For some models, it is an automatic approval; for others, like third-party models, a small form\r\nmust be filled out. Once a request is made, the cloud vendor usually enables access pretty quickly. The\r\nrequirement to make a request is often more of a speed bump for attackers rather than a blocker, and shouldn't be\r\nconsidered a security mechanism.\r\nCloud vendors have simplified the process of interacting with hosted cloud-based language models by using\r\nstraightforward CLI commands. Once the necessary configurations and permissions are in place, you can easily\r\nengage with the model using a command similar to this:\r\naws bedrock-runtime invoke-model –model-id anthropic.claude-v2 –body '{\"prompt\": \"Human: story of\r\ntwo dogsAssistant:\", \"max_tokens_to_sample\" : 300}'  –cli-binary-format raw-in-base64-out  invoke-model-output.txt\r\nLLM Reverse Proxy\r\nThe key checking code that verifies if credentials are able to use targeted LLMs also makes reference to another\r\nproject: OAI Reverse Proxy. This open source project acts as a reverse proxy for LLM services. Using software\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 4 of 13\n\nsuch as this would allow an attacker to centrally manage access to multiple LLM accounts while not exposing the\r\nunderlying credentials, or in this case, the underlying pool of compromised credentials. During the attack using\r\nthe compromised cloud credentials, a user-agent that matches OAI Reverse Proxy was seen attempting to use\r\nLLM models.\r\nThe image above is an example of an OAI Reverse Proxy we found running on the Internet. There is no evidence\r\nthat this instance is tied to this attack in any way, but it does show the kind of information it collects and displays.\r\nOf special note are the token counts (\"tookens\"), costs, and keys which are potentially logging.\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 5 of 13\n\nThis example shows an OAI reverse proxy instance, which is setup to use multiple types of LLMs. There is no\r\nevidence that this instance is involved with the attack.\r\nIf the attackers were gathering an inventory of useful credentials and wanted to sell access to the available\r\nLLM models, a reverse proxy like this could allow them to monetize their efforts.\r\nTechnical Analysis\r\nIn this technical breakdown, we explore how the attackers navigated a cloud environment to carry out their\r\nintrusion. By employing seemingly legitimate API requests within the cloud environment, they cleverly tested the\r\nboundaries of their access without immediately triggering alarms. The example below demonstrates a strategic use\r\nof the InvokeModel API call logged by CloudTrail. Although the attackers issued a valid request, they\r\nintentionally set the max_tokens_to_sample parameter to -1. This unusual parameter, typically expected to trigger\r\nan error, instead served a dual purpose. It confirmed not only the existence of access to the LLMs but also that\r\nthese services were active, as indicated by the resulting ValidationException. A different outcome, such as an\r\nAccessDenied error, would have suggested restricted access. This subtle probing reveals a calculated approach to\r\nuncover what actions their stolen credentials permitted within the cloud account.\r\nInvokeModel\r\nThe InvokeModel call is logged by CloudTrail and an example malicious event can be seen below. They sent a\r\nlegitimate request but specified \" max_tokens_to_sample \" to be -1. This is an invalid error which causes the\r\n\"ValidationException\" error, but it is useful information for the attacker to have because it tells them the\r\ncredentials have access to the LLMs and they have been enabled. Otherwise, they would have received an\r\n\"AccessDenied\" error.\r\n{\r\n \"eventVersion\": \"1.09\",\r\n \"userIdentity\": {\r\n \"type\": \"IAMUser\",\r\n \"principalId\": \"[REDACTED]\",\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 6 of 13\n\n\"arn\": \"[REDACTED]\",\r\n \"accountId\": \"[REDACTED]\",\r\n \"accessKeyId\": \"[REDACTED]\",\r\n \"userName\": \"[REDACTED]\"\r\n },\r\n \"eventTime\": \"[REDACTED]\",\r\n \"eventSource\": \"bedrock.amazonaws.com\",\r\n \"eventName\": \"InvokeModel\",\r\n \"awsRegion\": \"us-east-1\",\r\n \"sourceIPAddress\": \"83.7.139.184\",\r\n \"userAgent\": \"Boto3/1.29.7 md/Botocore#1.32.7 ua/2.0 os/windows#10 md/arch#amd64 lang/python#3.12.1 md/pyimp\r\n \"errorCode\": \"ValidationException\",\r\n \"errorMessage\": \"max_tokens_to_sample: range: 1..1,000,000\",\r\n \"requestParameters\": {\r\n \"modelId\": \"anthropic.claude-v2\"\r\n },\r\n \"responseElements\": null,\r\n \"requestID\": \"d4dced7e-25c8-4e8e-a893-38c61e888d91\",\r\n \"eventID\": \"419e15ca-2097-4190-a233-678415ed9a4f\",\r\n \"readOnly\": true,\r\n \"eventType\": \"AwsApiCall\",\r\n \"managementEvent\": true,\r\n \"recipientAccountId\": \"[REDACTED]\",\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 7 of 13\n\n\"eventCategory\": \"Management\",\r\n \"tlsDetails\": {\r\n \"tlsVersion\": \"TLSv1.3\",\r\n \"cipherSuite\": \"TLS_AES_128_GCM_SHA256\",\r\n \"clientProvidedHostHeader\": \"bedrock-runtime.us-east-1.amazonaws.com\"\r\n }\r\n}\r\nExample Cloudtrail log\r\nAWS Bedrock is not supported in all regions so the attackers called \"InvokeModel\" only in the supported regions.\r\nAt this time, Bedrock is supported in us-east-1, us-west-2, ap-southeast-1, ap-northeast-1, eu-central-1, eu-west-3,\r\nand us-gov-west-1, as shown here. Different models are available depending on the region; here is the list of\r\nmodels supported by AWS Region.\r\nGetModelInvocationLoggingConfiguration\r\nInterestingly, the attackers showed interest in how the service was configured. This can be done by calling\r\n\"GetModelInvocationLoggingConfiguration,\" which returns S3 and Cloudwatch logging configuration if enabled.\r\nIn our setup, we used both S3 and Cloudwatch to gather as much data about the attack as possible.\r\n{\r\n \"loggingConfig\": {\r\n \"cloudWatchConfig\": {\r\n \"logGroupName\": \"[REDACTED]\",\r\n \"roleArn\": \"[REDACTED]\",\r\n \"largeDataDeliveryS3Config\": {\r\n \"bucketName\": \"[REDACTED]\",\r\n \"keyPrefix\": \"[REDACTED]\"\r\n }\r\n },\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 8 of 13\n\n\"s3Config\": {\r\n \"bucketName\": \"[REDACTED]\",\r\n \"keyPrefix\": \"\"\r\n },\r\n \"textDataDeliveryEnabled\": true,\r\n \"imageDataDeliveryEnabled\": true,\r\n \"embeddingDataDeliveryEnabled\": true\r\n }\r\n}\r\nExample GetModelInvocationLoggingConfiguration response\r\nInformation about the prompts being run and their results are not stored in Cloudtrail. Instead, additional\r\nconfiguration needs to be done to send that information to Cloudwatch and S3. This check is done to hide the\r\ndetails of their activities from any detailed observations. OAI Reverse Proxy states it will not use any AWS key\r\nthat has logging enabled for the sake of \"privacy.\" This makes it impossible to inspect the prompts and responses\r\nif they are using the AWS Bedrock vector.\r\nImpact\r\nIn an LLMjacking attack, the damage comes in the form of increased costs to the victim. It shouldn't be surprising\r\nto learn that using an LLM isn't cheap and that cost can add up very quickly. Considering the worst-case scenario\r\nwhere an attacker abuses Anthropic Claude 2.x and reaches the quota limit in multiple regions, the cost to the\r\nvictim can be over $46,000 per day.\r\nAccording to the pricing and the initial quota limit for Claude 2:\r\n1000 input tokens cost $0.008, 1000 output tokens cost $0.024.\r\nMax 500,000 input and output tokens can be processed per minute according to AWS Bedrock. We can\r\nconsider the average cost between input and output tokens, which is $0.016 for 1000 tokens.\r\nLeading to the total cost: (500K tokens/1000 * $0.016) * 60 minutes * 24 hours * 4 regions = $46,080 / day\r\nBy maximizing the quota limits, attackers can also block the compromised organization from using models\r\nlegitimately, disrupting business operations.\r\nDetection\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 9 of 13\n\nThe ability to detect and respond swiftly to potential threats can make all the difference in maintaining a robust\r\ndefense. Drawing insights from recent feedback and industry best practices, we've distilled key strategies to\r\nelevate your detection capabilities:\r\nCloud Logs Detections: Tools like Falco, Sysdig Secure, and CloudWatch Alerts are indispensable allies.\r\nOrganizations can proactively identify suspicious behavior by monitoring runtime activity and analyzing\r\ncloud logs, including reconnaissance tactics such as those employed within AWS Bedrock.\r\nDetailed Logging: Comprehensive logging, including verbose logging, offers invaluable visibility into the\r\ninner workings of your cloud environment. Verbose information about model invocations and other critical\r\nactivities gives organizations a nuanced understanding about activity in their cloud environments.\r\nCloud Log Detections\r\nMonitoring cloud logs can reveal suspicious or unauthorized activity. Using Falco or Sysdig Secure, the\r\nreconnaissance methods used during the attack can be detected, and a response can be started. For Sysdig Secure\r\ncustomers, this rule can be found in the Sysdig AWS Notable Events policy.\r\nFalco rule:\r\n- rule: Bedrock Model Recon Activity\r\n desc: Detect reconaissance attempts to check if Amazon Bedrock is enabled, based on the error code. Attackers\r\n condition: jevt.value[/eventSource]=\"bedrock.amazonaws.com\" and jevt.value[/eventName]=\"InvokeModel\" and jev\r\n output: A reconaissance attempt on Amazon Bedrock has been made (requesting user=%aws.user, requesting IP=%a\r\n priority: WARNING\r\nIn addition, CloudWatch alerts can be configured to handle suspicious behaviors. Several runtime metrics for\r\nBedrock can be monitored to trigger alerts.\r\nDetailed Logging\r\nMonitoring your organization's use of language model (LLM) services is crucial, and various cloud vendors\r\nprovide facilities to streamline this process. This typically involves setting up mechanisms to log and store data\r\nabout model invocations.\r\nFor AWS Bedrock specifically, users can leverage CloudWatch and S3 for enhanced monitoring capabilities.\r\nCloudWatch can be set up by creating a log group and assigning a role with the necessary permissions. Similarly,\r\nto log into S3, a designated bucket is required as a destination. It is important to note that the CloudTrail log of the\r\nInvokeModel command does not capture details about the prompt input and output. However, Bedrock settings\r\nallow for easy activation of model invocation logging. Additionally, for model input or output data larger than\r\n100kb or in binary format, users must explicitly specify an S3 destination to handle large data delivery. This\r\nincludes input and output images, which are stored in the logs as Base64 strings. Such comprehensive logging\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 10 of 13\n\nmechanisms ensure that all aspects of model usage are monitored and archived for further analysis and\r\ncompliance.\r\nThe logs contain additional information about the tokens processed, as shown in the following example:\r\n{\r\n \"schemaType\": \"ModelInvocationLog\",\r\n \"schemaVersion\": \"1.0\",\r\n \"timestamp\": \"[REDACTED]\",\r\n \"accountId\": \"[REDACTED]\",\r\n \"identity\": {\r\n \"arn\": \"[REDACTED]\"\r\n },\r\n \"region\": \"us-east-1\",\r\n \"requestId\": \"bea9d003-f7df-4558-8823-367349de75f2\",\r\n \"operation\": \"InvokeModel\",\r\n \"modelId\": \"anthropic.claude-v2\",\r\n \"input\": {\r\n \"inputContentType\": \"application/json\",\r\n \"inputBodyJson\": {\r\n \"prompt\": \"\\n\\nHuman: Write a story of a young wizard\\n\\nAssistant:\",\r\n \"max_tokens_to_sample\": 300\r\n },\r\n \"inputTokenCount\": 16\r\n },\r\n \"output\": {\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 11 of 13\n\n\"outputContentType\": \"application/json\",\r\n \"outputBodyJson\": {\r\n \"completion\": \" Here is a story about a young wizard:\\n\\nMartin was an ordinary boy living in a smal\r\n \"stop_reason\": \"max_tokens\",\r\n \"stop\": null\r\n },\r\n \"outputTokenCount\": 300\r\n }\r\n}\r\nExample S3 log\r\nRecommendations\r\nThis attack could have been prevented in a number of ways, including:\r\nVulnerability management to prevent initial access.\r\nSecrets management to ensure credentials are not stored in the clear where they can be stolen.\r\nCSPM/CIEM to ensure the abused account had the least amount of permissions it needed.\r\nAs highlighted by recent research, cloud vendors offer a range of tools and best practices designed to mitigate the\r\nrisks of cloud attacks. These tools help organizations build and maintain a secure cloud environment from the\r\noutset.\r\nFor instance, AWS provides several robust security measures. The AWS Security Reference Architecture outlines\r\nbest practices for securely constructing your cloud environment. Additionally, AWS recommends using Service\r\nControl Policies (SCP) to centrally manage permissions, which helps minimize the risk associated with over-permissioned accounts that could potentially be abused. These guidelines and tools are part of AWS's commitment\r\nto enhancing security and providing customers with the resources to protect their cloud infrastructure effectively.\r\nOther cloud vendors offer similar frameworks and tools, ensuring that users have access to essential security\r\nmeasures to safeguard their data and services regardless of the platform.\r\nConclusion\r\nStolen cloud and SaaS credentials continue to be a common attack vector. This trend will only increase in\r\npopularity as attackers learn all of the ways they can leverage their new access for financial gain. The use of LLM\r\nservices can be expensive, depending on the model and the amount of tokens being fed to it. Normally, this would\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 12 of 13\n\ncause a developer to try and be efficient — sadly, attackers do not have the same incentive. Detection and\r\nresponse is critical to deal with any issues quickly.\r\nIoCs\r\nIP Addresses\r\n83.7.139.184\r\n83.7.157.76\r\n73.105.135.228\r\n83.7.135.97\r\nCloud Security\r\nThreat Research\r\nfeatured resources\r\nTest drive the right way to defend the cloudwith a security expert\r\nSource: https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nhttps://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/"
	],
	"report_names": [
		"llmjacking-stolen-cloud-credentials-used-in-new-ai-attack"
	],
	"threat_actors": [],
	"ts_created_at": 1775446664,
	"ts_updated_at": 1775791291,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c5de4ac3e69f0ef40e4eabd5f1d4f83e82577b3b.pdf",
		"text": "https://archive.orkl.eu/c5de4ac3e69f0ef40e4eabd5f1d4f83e82577b3b.txt",
		"img": "https://archive.orkl.eu/c5de4ac3e69f0ef40e4eabd5f1d4f83e82577b3b.jpg"
	}
}