Expose privilege escalation paths and overly permissive IAM policies
We test your AWS IAM configuration for privilege escalation paths, overly permissive policies, cross-account trust abuse, role chaining vulnerabilities, and federation misconfigurations. Our testers evaluate IAM Access Analyzer findings, identify resource-based policy weaknesses across S3, SQS, SNS, and Lambda, and attempt lateral movement through AssumeRole chains and instance profile exploitation.
Privilege escalation in AWS rarely looks like an exploit. It looks like a policy that grants iam:PassRole alongside ec2:RunInstances, or a role whose trust policy names a principal broader than anyone intended. We enumerate every path from the identities you give us to the permissions they can reach, including the indirect ones: policy versions that can be set back to a permissive state, roles reachable through service integrations, and permissions granted transitively via group membership or permission sets in IAM Identity Center.
Where relevant we use the same tooling the offensive community does, including Pacu and custom scripts built against the AWS APIs, alongside manual analysis that automated tools cannot replicate. Automated IAM analyzers report what a policy says. We report what an attacker can actually do with it.
Find exposed buckets, misconfigured access controls, and data exfiltration paths
We assess your S3 buckets, DynamoDB tables, RDS instances, EFS shares, and other AWS data stores for access control weaknesses, encryption gaps, and data exposure risks. Our testing covers bucket policy misconfigurations, ACL bypass techniques, pre-signed URL abuse, cross-account access vulnerabilities, and data exfiltration paths through VPC endpoints, DNS tunnelling, and legitimate AWS services.
Storage findings are the ones most likely to end up in a breach notification, and they are rarely as simple as a public bucket. We look for the combinations that matter: a bucket policy that is technically private but readable by a role your CI pipeline can assume, object ACLs that survived a migration to bucket-owner-enforced, versioned objects still holding secrets that were rotated in the current version, and snapshots or AMIs shared more widely than the account owner realised.
We also test the exfiltration side rather than stopping at access. Demonstrating that data can leave the account, and showing exactly which log would have caught it, is far more useful to a defender than a finding that says a bucket is misconfigured.
Test event-driven architectures, API Gateway, and serverless attack surfaces
Our testers evaluate Lambda functions, API Gateway configurations, Step Functions, and EventBridge rules for injection vulnerabilities, insecure environment variable handling, overly permissive execution roles, and event source manipulation. We assess serverless-specific risks including function chaining abuse, cold start exploitation, layer poisoning, and unauthorized invocation through misconfigured triggers and resource policies.
Serverless widens the attack surface in ways that are easy to miss. An execution role attached to a function is a standing set of credentials reachable by anyone who can influence that function's input. We test for injection into event payloads, secrets left in environment variables rather than Secrets Manager, and functions whose resource policies allow invocation from principals well outside the intended caller.
Container workloads get the same treatment: task roles on ECS, IRSA and pod identity on EKS, and access to the instance metadata service from inside a running container, which remains one of the most reliable routes from application compromise to cloud credentials.
Structured, repeatable, and aligned with MITRE ATT&CK Cloud for AWS
Every AWS penetration test follows a structured methodology aligned with PTES, OWASP, and the MITRE ATT&CK Cloud matrix. We begin with threat modeling and scoping tailored to your AWS architecture, followed by reconnaissance, vulnerability identification, exploitation, and post-exploitation analysis that mirrors real adversary behavior.
We go beyond automated scanning - our testers chain misconfigurations, abuse trust relationships, and exploit cloud-native features the way actual threat actors do. Deliverables include executive and technical reports with findings mapped to ATT&CK techniques and prioritized remediation guidance.
Scoping matters more in cloud than on premises, because the blast radius of a test can cross account boundaries. Before any testing begins we agree the accounts, regions, and services in scope, confirm what is shared infrastructure, and align on AWS's customer support policy for penetration testing so that permitted activity is clearly separated from anything requiring prior authorisation.
Every finding arrives with the evidence behind it, the specific API calls involved, and the detection that should have fired. That last part matters: a finding you cannot detect the next time is a finding you have not really fixed.
AWS security specialists who build, break, and defend cloud environments
Pwned Labs is not a traditional consultancy - we are practitioners who build, break, and defend AWS environments every day. Our penetration testers hold certifications including CREST CRT, ACRTP and AWS Security Specialty, and actively contribute to the offensive security community through research, tooling, and training content used by thousands of professionals worldwide.
Every engagement is led by operators with direct experience across Fortune 500 AWS environments, startups, and government agencies. We understand AWS-native threats because we research and simulate them daily on our own cloud security training platform.
That research feeds directly back into the testing. The techniques in our AWS labs and in the Amazon Cloud Red Team Professional certification are the same ones our testers use on engagements, which means the methodology is continuously exercised against current AWS behavior rather than a snapshot from whenever the methodology document was last updated.