AWS Security Testing: IAM, S3, and Beyond

AWS security testing requires a fundamentally different mindset from traditional infrastructure penetration testing. The cloud introduces an entirely new attack surface built around APIs, identity policies, and service integrations. As a penetration tester who regularly assesses AWS environments, I want to walk through the key areas I focus on and the methodology that consistently uncovers critical findings.

The Shared Responsibility Model and Where Pentesters Focus

AWS operates under a shared responsibility model: Amazon secures the infrastructure (hypervisors, physical data centers, network fabric), while the customer secures everything built on top of it. This means penetration testers focus almost exclusively on the customer's configuration, identity management, network architecture, and application layer. The most common findings are not exotic zero-days but rather misconfigurations in IAM policies, storage permissions, and network exposure. Understanding this boundary is essential for scoping an AWS engagement correctly.

IAM Misconfigurations in Detail

Identity and Access Management is the single most critical attack surface in any AWS environment. IAM policies define who can do what, and small mistakes create massive exposure.

• Overly permissive policies - Policies granting broad actions like s3:* or ec2:* instead of the minimum required permissions. I frequently encounter managed policies like AdministratorAccess or PowerUserAccess attached to service accounts that only need narrow permissions.
• Wildcard resource specifications - Policies using "Resource": "*" when they should scope to specific ARNs. This is especially dangerous with data-plane actions like s3:GetObject or dynamodb:Scan.
• IAM users instead of roles - Long-lived access keys for IAM users are a frequent source of credential leaks. Roles with temporary credentials via STS are always preferred. I check for access keys older than 90 days and keys that have never been rotated.
• Missing MFA enforcement - Root accounts without MFA, IAM users with console access but no MFA requirement, and missing aws:MultiFactorAuthPresent conditions on sensitive API calls.
• Policy simulation - I use the IAM Policy Simulator and enumerate-iam to determine effective permissions for a given set of credentials. The gap between what administrators think a role can do and what it actually can do is often significant.

S3 Security

S3 remains one of the most commonly misconfigured AWS services, despite years of attention and AWS adding multiple layers of protection including S3 Block Public Access.

• Public bucket enumeration - I enumerate bucket names based on naming conventions (company-backup, company-logs, company-dev) and test for public read/write access. Tools like bucket_finder and custom wordlists are effective here.
• ACL misconfigurations - Legacy ACLs can grant access to the AuthenticatedUsers group (any AWS account) or AllUsers (the internet). Even with bucket policies in place, a permissive ACL can override intended restrictions.
• Bucket policy issues - Policies with "Principal": "*" or conditions that reference attacker-controllable values. I also look for policies that allow s3:PutBucketPolicy, which enables an attacker to rewrite the policy entirely.
• Missing encryption - Buckets without default server-side encryption (SSE-S3 or SSE-KMS) and objects uploaded without encryption headers. I verify that bucket policies enforce s3:x-amz-server-side-encryption on PutObject calls.
• Pre-signed URL abuse - Applications that generate pre-signed URLs with excessively long expiration times or that expose pre-signed URLs through client-side code. A leaked pre-signed URL provides unauthenticated access to the object.

Privilege Escalation Paths

AWS privilege escalation is one of the most interesting areas for a pentester. Unlike traditional environments where you escalate from user to root, in AWS you escalate permissions through service interactions. The research by Rhino Security Labs documenting over 20 privilege escalation paths remains essential reading.

• iam:PassRole with Lambda - If an attacker can create a Lambda function and pass it a high-privilege role, they can execute code with that role's permissions. This requires iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction.
• iam:PassRole with EC2 - Creating an EC2 instance with an instance profile that has higher privileges, then accessing the metadata service from the instance to retrieve temporary credentials.
• Lambda function code injection - If an attacker can update existing Lambda function code (lambda:UpdateFunctionCode), they inherit whatever role is already attached to that function.
• CloudFormation stack manipulation - Creating or updating CloudFormation stacks with iam:PassRole to the CloudFormation service, allowing the stack to create IAM resources or other high-privilege resources on the attacker's behalf.
• SSM RunCommand - With ssm:SendCommand permission, an attacker can execute arbitrary commands on EC2 instances running the SSM agent, inheriting those instances' IAM roles.
• EC2 instance profile abuse - Compromising an EC2 instance and querying the metadata service at 169.254.169.254 to retrieve temporary credentials for the attached instance profile.

Other AWS Attack Surfaces

• SQS/SNS misconfigurations - Queues and topics with overly permissive resource policies that allow cross-account access or message injection.
• Secrets in Parameter Store and Secrets Manager - Applications often store database credentials and API keys in these services. I check whether compromised IAM credentials grant access to retrieve stored secrets.
• RDS public access - Database instances with the PubliclyAccessible flag enabled and security groups allowing inbound access from 0.0.0.0/0.
• EBS snapshot sharing - EBS snapshots shared publicly or with unintended AWS accounts. These can contain sensitive data, credentials, or private keys.

Post-Exploitation

Once initial access is obtained, the focus shifts to expanding access and demonstrating impact:

• Credential harvesting from metadata service - The EC2 instance metadata service (IMDS) provides temporary credentials. IMDSv1 is vulnerable to SSRF-based attacks, while IMDSv2 requires a session token but is still accessible from the instance itself.
• Lateral movement via SSM - Systems Manager Session Manager provides shell access to EC2 instances without needing SSH keys or open ports. Compromised credentials with SSM permissions enable lateral movement across the fleet.
• Data exfiltration - S3 is a common exfiltration path. I also look at DNS-based exfiltration through Route 53 resolvers and VPC endpoints that allow data to flow to attacker-controlled destinations.

Detection, Defense, and Monitoring

• CloudTrail - Ensure CloudTrail is enabled in all regions with log file validation. Monitor for high-risk API calls like CreateAccessKey, PutRolePolicy, and CreateLoginProfile.
• GuardDuty - AWS threat detection service that identifies anomalous API calls, cryptocurrency mining, and compromised credentials. It is one of the highest-value security services to enable.
• AWS Config rules - Enforce compliance rules such as S3 buckets requiring encryption, IAM users having MFA, and security groups not allowing 0.0.0.0/0 ingress.
• Service Control Policies (SCPs) - Organization-level policies that restrict what member accounts can do, regardless of their IAM policies. SCPs are the strongest guardrail in AWS Organizations.

Tools and Methodology

A well-scoped AWS penetration test typically begins with read-only enumeration, progresses to identifying privilege escalation paths, and concludes with demonstrating impact through controlled exploitation.

• Pacu - The AWS exploitation framework by Rhino Security Labs. It automates enumeration, privilege escalation, and post-exploitation tasks.
• ScoutSuite - Multi-cloud security auditing tool that generates comprehensive HTML reports of misconfigurations across all AWS services.
• Prowler - AWS security best practices assessment tool aligned with CIS benchmarks and other compliance frameworks.
• enumerate-iam - Brute-forces IAM permissions for a given set of credentials by attempting API calls across all AWS services.
• aws_consoler - Converts AWS access keys into a browser console session URL, useful for exploring the environment visually during assessments.

Always ensure your testing is properly scoped with a signed Rules of Engagement document. AWS requires notification for certain types of testing, and all activity must stay within the boundaries of owned accounts and explicitly authorized services.