InfoSecBulletin Cybersecurity for mankind
Sysdig Threat Research Team (TRT) observed an offensive cloud operation targeting an AWS environment in which the threat actor went from initial access to administrative privileges in less than 10 minutes. This incident was notable for its rapid execution and indications that the attacker used large language models (LLMs) to automate tasks, generate harmful code, and make on-the-spot decisions.
The attacker accessed the victim’s AWS account using credentials found in public S3 buckets. They quickly escalated their privileges via Lambda function code injection, spread across 19 AWS principals, misused Amazon Bedrock for LLM jacking, and started GPU instances for model training.
CISA alerts to cyberattacks affecting U.S. water utilities
“CyberStrike” AI-Driven Security Platform for Automated Testing
AIDCQ Propose to invest $2 billion in AI data center in Bangladesh
NVIDIA BlueField Flaw Enables Code Execution Attacks
Massive customer data from India’s Bank of Baroda surfaced online
Active Exploits Hit Fortinet, Arista: AI Discovered Linux Kernel Zero-Day
Sam Altman Claims AI “singularity” has arrived, Where Systems Improve by Themselves
Shinyhunters claimed and set deadline to publish E&Y data
Microsoft, NVIDIA and CrowdStrike Initiate Alliance for Open-Source AI Security
Google Search Results Reportedly Show Claude AI Shared Chats
The threat actor accessed the victim’s systems using stolen test credentials from public S3 buckets, which held RAG data for AI models. The compromised credentials belonged to an IAM user with extensive permissions on AWS Lambda and limited permissions on AWS Bedrock.
| Attack Stage | Time to Execute | Key Techniques |
|---|---|---|
| Initial Access | < 1 minute | Credential theft from public S3 buckets containing RAG data |
| Reconnaissance | 2-3 minutes | Enumeration across 10+ AWS services using ReadOnlyAccess policy |
| Privilege Escalation | 4-5 minutes | Lambda code injection targeting admin user “frick” |
| Lateral Movement | 6-7 minutes | Compromise of 19 AWS principals via role assumption |
| LLMjacking | 8-9 minutes | Invocation of 9 foundation models on Amazon Bedrock |
| Resource Abuse | 9-10 minutes | p4d.24xlarge GPU instance provisioning ($32.77/hour) |
Attack timeline:
The following timeline reconstructs the complete two-hour attack sequence, beginning with credential theft, based on CloudTrail analysis:
0:00:00 – The threat actor extracted credentials for IAM user compromised_userfrom public S3 buckets.
0:06:00 – Following initial enumeration, they failed to assume admin roles (admin, Administrator) but successfully assumed existing roles sysadmin, netadmin, and account.
0:08:00 – They replaced the code of the Lambda function EC2-init and increased the timeout from 3 to 30 seconds. The function was modified three times, first targeting adminGH (which lacked admin privileges), then successfully compromising the admin user frick.
0:11:00 – Using the admin user frick, they created a new user backdoor-adminand attached the AdministratorAccess policy.
0:58:00-1:51:00 – They invoked Bedrock models 13 times, including Claude Sonnet 4, Claude Opus 4, Claude 3.5 Sonnet, Claude 3 Haiku, DeepSeek R1, Llama 4 Scout, Amazon Nova Premier, Amazon Titan Image Generator, and Cohere Embed v3. Invoking certain Claude models required calling AcceptAgreementRequest. They leveraged cross-Region inference throughout.
1:00:00 – They created access keys for usersrocker (which had BedrockFullAccess policy) and AzureADRoleManager.
1:05:00-1:35:00 – Extensive reconnaissance across Secrets Manager, SSM, S3, ECS, Organizations, RDS, CloudWatch, Bedrock, OpenSearch Serverless, SageMaker, and KMS.
1:21:00 – Successfully assumed roles of sysadmin,developer, and external. Failed to assume EKS-access.
1:42:00 – Using backdoor-admin, they failed to run p5.48xlarge instances due to capacity constraints, then successfully launched a p4d.24xlarge instance. The instance was terminated after 5 minutes. They also shared its snapshot (SharedSnapshotVolumeCreated).
1:51:00 – The threat actor’s access was terminated and the attack ended.
Indicators of Compromise
| IP address | VPN |
|---|---|
| 104.155.129[.]177 | Yes |
| 104.155.178[.]59 | Yes |
| 104.197.169[.]222 | Yes |
| 136.113.159[.]75 | Yes |
| 34.173.176[.]171 | Yes |
| 34.63.142[.]34 | Yes |
| 34.66.36[.]38 | Yes |
| 34.69.200[.]125 | Yes |
| 34.9.139[.]206 | Yes |
| 35.188.114[.]132 | Yes |
| 35.192.38[.]204 | Yes |
| 34.171.37[.]34 | Yes |
| 204.152.223[.]172 | Yes |
| 34.30.49[.]235 | Yes |
| 103.177.183[.]165 | No |
| 152.58.47[.]83 | No |
| 194.127.167[.]92 | No |
| 197.51.170[.]131 | No |
Mitigation recommendations:
Organizations should implement the following controls to defend against similar attacks:
- Apply the principle of least privilege to all IAM users and roles, including execution roles used by Lambda functions. An overly permissive execution role enabled the threat actor to escalate privileges in this attack.
* Restrict UpdateFunctionConfiguration and PassRolepermissions carefully. Threat actors may attempt to replace a Lambda function’s execution role with a more privileged one, which requires both permissions.
* Limit UpdateFunctionCode permissions to specific functions and assign them only to principals that genuinely need code deployment capabilities.
* Enable Lambda function versioning to maintain immutable records of the code running at any point. Use function aliases to point to specific versions, requiring a threat actor to both modify code and update the alias to affect production.
* Ensure S3 buckets containing sensitive data, including RAG data and AI model artifacts, are not publicly accessible.
* Enable model invocation logging for Amazon Bedrock to detect unauthorized usage.
* Monitor for IAM Access Analyzer enumeration, as this provides threat actors with valuable reconnaissance data about your environment.
