AWS Security Testing Best Practices

Introduction

Consider a common scenario: a healthcare startup migrates to AWS to improve scalability. The engineering team configures S3 buckets, Lambda functions, and RDS databases while moving quickly. Months later, the team discovers an S3 bucket was accidentally made public during initial setup, exposing sensitive records. Incidents like this can trigger regulatory notifications, contractual fallout, and major reputational damage.

Cloud misconfigurations account for a significant portion of data breaches. The shared responsibility model means AWS secures the infrastructure, but customers are responsible for securing their configurations and data. This guide covers AWS penetration testing rules, common misconfigurations to test for, and strategies to validate your AWS security posture.

AWS Penetration Testing Policy

AWS allows security assessments against your own resources without prior approval for most services, including:

• EC2 instances, NAT Gateways, and Elastic Load Balancers
• Amazon RDS and Aurora
• Amazon CloudFront and API Gateway
• AWS Lambda and Lambda Edge functions
• Amazon ECS and EKS

Prohibited activities include DNS zone walking via Route 53, DoS attacks, and any flooding attacks (port, protocol, or request flooding).

For activities outside the permitted scope, submit a request through the AWS Vulnerability and Penetration Testing Request Form. Testing third-party applications hosted on AWS requires separate permission from the application owner.

Testing IAM Configurations

IAM misconfigurations create high-impact vulnerabilities. Testing should enumerate policies, roles, and permissions:

# List all users
aws iam list-users --query 'Users[*].UserName'
 
# Check attached policies for a user
aws iam list-attached-user-policies --user-name <username>
 
# Get inline policy details
aws iam get-user-policy --user-name <username> --policy-name <policy>

Overly Permissive Policies: Look for policies granting * actions or resources. Any compromised credential with such a policy can control the entire account.

Privilege Escalation Paths: Test for dangerous permission combinations:

• iam:CreatePolicy + iam:AttachUserPolicy (create and attach admin policy)
• iam:PassRole + ability to create Lambda/EC2 (pass high-privilege role to resource)
• sts:AssumeRole to high-privilege roles
• lambda:CreateFunction + iam:PassRole (execute code with elevated permissions)

Cross-Account Access: Review IAM role trust policies. A trust policy with "Principal": {"AWS": "*"} allows any AWS account to assume the role—a critical misconfiguration.

Access Keys: Old, unused keys should be rotated or deleted:

aws iam list-access-keys --user-name <username>
aws iam get-access-key-last-used --access-key-id <key-id>

Keys older than 90 days without recent use are candidates for removal.

Testing S3 Security

S3 buckets frequently appear in breach reports due to misconfigured permissions:

# Check public access block configuration
aws s3api get-public-access-block --bucket <bucket-name>
 
# Get bucket policy
aws s3api get-bucket-policy --bucket <bucket-name>
 
# List bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name>
 
# Check default encryption
aws s3api get-bucket-encryption --bucket <bucket-name>

Dangerous configurations include:

• "Principal": "*" in bucket policies (grants public access)
• ACL grants to AllUsers or AuthenticatedUsers
• Public access block settings disabled
• Server-side encryption not enforced

Also verify logging and versioning are enabled for audit trails and tampering detection.

Testing EC2 Security

Security Groups: Find overly permissive rules:

# Find security groups with SSH open to the internet
aws ec2 describe-security-groups --filters "Name=ip-permission.from-port,Values=22" \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]]'
 
# Find all security groups with broad inbound rules
aws ec2 describe-security-groups --query 'SecurityGroups[*].[GroupId,GroupName,IpPermissions]'

Common misconfigurations: SSH (22) or RDP (3389) exposed to 0.0.0.0/0, database ports accessible from the internet, and overly broad CIDR ranges.

Instance Metadata Service: Test for SSRF vulnerabilities that could access the metadata service at 169.254.169.254. Verify IMDSv2 is enforced (requires session tokens, mitigating many SSRF attacks):

aws ec2 describe-instances --instance-ids <id> \
  --query 'Reservations[*].Instances[*].MetadataOptions'

User Data Scripts: Check for secrets in startup scripts:

aws ec2 describe-instance-attribute --instance-id <id> --attribute userData

Hardcoded credentials in user data scripts are a common finding.

Testing Database Security

# List RDS instances with public access
aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].[DBInstanceIdentifier,Endpoint.Address]'
 
# Check storage encryption
aws rds describe-db-instances \
  --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]'
 
# Check snapshot sharing settings
aws rds describe-db-snapshot-attributes --db-snapshot-identifier <snapshot>

RDS snapshots can be shared publicly—a common misconfiguration that exposes database contents.

Testing Lambda Security

# Get function configuration including environment variables
aws lambda get-function-configuration --function-name <name>
 
# Get resource policy (who can invoke the function)
aws lambda get-policy --function-name <name>
 
# Get the execution role
aws lambda get-function --function-name <name> --query 'Configuration.Role'

Lambda environment variables may contain secrets (use Secrets Manager instead). Execution roles often have excessive permissions—test what each role can access.

Testing CloudTrail and Logging

Verify audit logging captures security-relevant events:

# Check if CloudTrail is enabled
aws cloudtrail describe-trails
 
# Verify trails are logging
aws cloudtrail get-trail-status --name <trail-name>

Test for multi-region trail coverage, log file validation, secure log storage, and CloudWatch integration for alerting.

Compliance Considerations

Many compliance frameworks have specific AWS security requirements:

• PCI DSS: Requires network segmentation, encryption, access controls, and regular penetration testing of cardholder data environments
• HIPAA: Requires encryption of PHI, access logging, and security assessments
• SOC 2: Requires documented security controls, access management, and regular testing

AWS provides compliance-specific documentation and AWS Artifact for audit evidence.

Conclusion

AWS security testing requires systematic assessment of IAM policies, S3 configurations, network security groups, and service-specific settings. The flexibility of AWS means misconfigurations can easily occur—a single overly permissive IAM policy or public S3 bucket can expose your entire organization.

Regular security testing helps catch misconfigurations before attackers find them. On-demand testing enables teams to validate changes as they deploy, rather than waiting for annual assessments. RedVeil's AI-powered platform can help identify exploitable AWS misconfigurations alongside application vulnerabilities, providing verified findings with remediation guidance.

Start testing your AWS environment with RedVeil today.