Listen to this Post
Introduction:
The rapid adoption of Generative AI has created a new attack surface, giving rise to “LLMjacking”—a technique where threat actors compromise cloud credentials specifically to steal large language model (LLM) quota and tokens. Unlike traditional cryptojacking which steals compute cycles for crypto mining, LLMjacking targets AI models hosted on platforms like AWS Bedrock, draining financial resources and potentially accessing sensitive data processed by the models. This article dissects a recent campaign where attackers exploited stolen AWS keys to access paid Anthropic models, and provides a comprehensive guide on detecting, mitigating, and preventing such attacks.
Learning Objectives:
- Understand the mechanics of LLMjacking and how AWS Bedrock is exploited.
- Learn to identify indicators of compromise (IoCs) related to unauthorized AI model invocation.
- Implement multi-layered defensive strategies, including IAM hardening, monitoring, and anomaly detection.
You Should Know:
- Anatomy of the Attack: Stolen Keys and Model Access
In the observed campaign, attackers utilized stolen AWS Access Keys that possessed permissions to invoke models within Amazon Bedrock. The primary objective was not data exfiltration, but resource theft. By accessing paid models like Anthropic’s , the attackers could resell access or use the models for their own purposes, incurring significant costs for the victim.
– Initial Access: The attack begins with the compromise of an AWS Access Key ID and Secret Access Key, often obtained from exposed code repositories (GitHub), misconfigured build environments, or phishing.
– Discovery: Once authenticated, the attacker typically runs the AWS CLI command to list available models to identify high-value targets.
Linux/macOS command to list Bedrock models aws bedrock list-foundation-models --region us-east-1 --profile compromised-profile
– Invocation: The attacker then uses the `invoke-model` API call to send prompts to the model. While the original post highlights a generic request, defenders should look for a high volume of these calls.
Example of a malicious invocation (Windows PowerShell alternative)
aws bedrock-runtime invoke-model `
--model-id anthropic.-v2 `
--body "{\"prompt\":\"Human: Tell me a story\nAssistant:\",\"max_tokens_to_sample\":300}" `
--cli-binary-format raw-in-base64-out `
--region us-east-1 `
response.json
- Detection: Hunting for Anomalies with CloudTrail and Athena
Detection requires shifting focus from server logs to API logs. AWS CloudTrail is the primary source for identifying malicious Bedrock activity. You need to analyze `BedrockRuntime` events.
– Key IoCs: Look for unusual patterns such as invocations from unexpected geographic locations, calls made outside business hours, or a sudden spike in `InvokeModel` or `InvokeModelWithResponseBody` events.
– Querying with Athena: If you have CloudTrail logs centralized in S3 and queried via Athena, use the following SQL to find suspicious activity:
-- Athena query to find Bedrock invocations from unusual IPs
SELECT
useridentity.arn,
eventsource,
eventname,
sourceipaddress,
useragent,
eventtime,
responseelements
FROM
your_cloudtrail_logs_table
WHERE
eventsource = 'bedrock.amazonaws.com'
AND eventname LIKE '%InvokeModel%'
AND sourceipaddress NOT IN ('YOUR_CORPORATE_IP_RANGE')
ORDER BY
eventtime DESC
LIMIT 100;
- IAM Hardening: The Principle of Least Privilege for Bedrock
The root cause of these attacks is overly permissive IAM policies. A user or service should never have blanket access to all Bedrock models.
– Before (Vulnerable): A policy allowing `bedrock:` or `bedrock:InvokeModel` on “.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": ""
}
]
}
– After (Secure): Restrict access to specific models and impose conditions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.-v2",
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.0.2.0/24"
},
"Bool": {
"aws:ViaAWSService": "false"
}
}
}
]
}
Note: The `ViaAWSService` condition helps prevent a compromised key from being used by a service on the attacker’s behalf.
4. Network Control and SCPs for AI Services
For organizations using AWS Organizations, Service Control Policies (SCPs) can provide a guardrail to prevent LLMjacking across all accounts, even if a key is stolen.
– Deny Access Based on IP: Create an SCP that denies Bedrock actions unless the request originates from a trusted VPC or IP address.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyBedrockOutsideVPC",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseBody"
],
"Resource": "",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "10.0.0.0/8"
},
"BoolIfExists": {
"aws:ViaAWSService": "false"
}
}
}
]
}
– Require VPC Endpoints: Enforce that Bedrock API calls must go through a VPC Endpoint by checking the `aws:SourceVpce` or `aws:SourceVpc` conditions.
5. Implementing Budget Alerts and Cost Anomaly Detection
Financial observability is a critical security control for AI services.
– AWS Budgets: Create a budget specifically for the Bedrock service. Set an alert for forecasted costs or actual costs exceeding a threshold (e.g., $10). This provides early warning of a potential quota draining attack.
– Cost Anomaly Detection: Use AWS Cost Anomaly Detection to monitor for unusual spend patterns. Configure a monitor for the Bedrock service dimension. If attackers suddenly invoke thousands of times, the anomaly detection service will trigger an alert, allowing you to revoke keys before a massive bill accumulates.
6. Incident Response: Isolating the Compromised Credential
If you detect suspicious Bedrock activity, immediate isolation is required.
1. Immediate Containment: Delete or deactivate the compromised Access Key.
AWS CLI command to deactivate a key aws iam update-access-key --access-key-id AKIAEXAMPLE --status Inactive --user-name compromised_user
2. Log Preservation: Ensure the CloudTrail logs for the relevant time frame are protected from tampering and are being sent to a secure S3 bucket with MFA delete enabled.
3. Root Cause Analysis: Rotate all keys for the compromised user. Check GitHub and CI/CD logs for exposure. Review the last 24 hours of CloudTrail for data exfiltration events (e.g., `GetObject` from S3, `GetSecretValue` from Secrets Manager) performed by that key.
7. Hardening CI/CD and Code Repositories
Since exposed keys are the primary vector, securing the development pipeline is paramount.
– Pre-commit Hooks: Use tools like `truffleHog` or `git-secrets` to prevent developers from committing secrets to git.
Linux/macOS: Install git-secrets and scan git clone https://github.com/awslabs/git-secrets cd git-secrets sudo make install cd /path/to/your/repo git secrets --install git secrets --register-aws git secrets --scan
– Environment Variables: Never hardcode keys. Use AWS Secrets Manager or Parameter Store to inject secrets into build environments (e.g., GitHub Actions, Jenkins).
What Undercode Say:
- Key Takeaway 1: LLMjacking represents a paradigm shift in cloud resource theft—attackers are no longer just after compute, but after the expensive intellectual property of AI models themselves. The financial impact can be instantaneous and severe.
- Key Takeaway 2: Traditional perimeter defenses fail against API-based abuse. The battlefront has moved to IAM precision, anomaly detection in API logs, and financial monitoring. If you can’t see who is calling your model and why, you are already compromised.
The analysis of this campaign reveals a critical blind spot in modern cloud security. We are so focused on securing data at rest and in transit that we neglect the cost and access implications of the AI services themselves. This attack succeeded not because of a zero-day vulnerability in AWS, but because of the fundamental failure to apply least-privilege access to a new, highly expensive resource. Organizations must treat API keys with access to AI models as crown jewels, equivalent to database admin credentials. The integration of AWS Budgets into the incident response workflow is no longer a finance function, but a security imperative. As AI models become more powerful and expensive, we can expect LLMjacking to evolve from simple quota draining to data poisoning and model extraction, where the prompts and responses themselves become the target for intelligence gathering.
Prediction:
We predict the emergence of specialized malware that specifically hunts for cloud credentials with AI permissions, coupled with underground markets for “AI tokens” similar to the DDoS-for-hire scene. Defenders will need to implement real-time model input/output auditing to detect not just theft, but also attempts to manipulate the model’s behavior via the stolen account.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Leyredelacalzada Github – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
