AWS Penetration Testing Services

What is AWS Penetration Testing?

AWS penetration testing is an authorized, simulated attack against your AWS environment that goes beyond automated scanning to find architectural flaws, IAM privilege-escalation paths, and business-logic gaps. Per the AWS customer support policy, customers may pen-test eight permitted services without prior approval, including EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, and Elastic Beanstalk environments.

What an AWS Penetration Test Actually Tests

Most “AWS pen tests” are web app pen tests with the application happening to run on AWS. That’s necessary but not sufficient. A real AWS pen test attacks the cloud control plane and data plane in ways scanners cannot:

IAM and Trust

• Privilege escalation paths — can an entry-level IAM principal escalate to admin via service trust chains (Lambda → CloudFormation → IAM)?
• Trust policy abuse — overly broad AssumeRole trust policies allowing principals from unintended accounts
• Permission boundary bypass — boundary configurations that create false security
• Inline policy creep — privilege accumulation that automated drift tools miss

S3 and Storage

• Bucket policy and ACL evaluation — buckets that pass Block Public Access but still leak via signed URLs or cross-account principals
• Bucket enumeration — discovering bucket names from CloudFront, public source code, or DNS
• Object-level permissions — bucket-level deny that an object-level grant overrides

Instance Metadata Service

• IMDSv1 detection and exploitation — instances still allowing IMDSv1 are exploitable via SSRF
• IMDSv2 token weaknesses — improper token handling in application code
• Container metadata exploitation — ECS Task Metadata endpoint reachable from compromised containers

Compute and Containers

• ECS task role abuse — over-permissive task roles allowing pivot beyond the container
• EKS RBAC weaknesses — Kubernetes ServiceAccount tokens with broader IAM mappings than required
• Lambda execution role chains — Lambda functions with permissions to update their own code, enabling persistence
• CodeBuild/CodePipeline exploitation — pipelines with privileged roles and writable triggers

Application Layer (with AWS Awareness)

• SSRF chained to IMDS — a web app SSRF that reaches the instance metadata service to extract credentials
• WAF bypass techniques — encoded payloads, oversized requests, rule logic gaps
• API Gateway authorization bypass — Cognito JWT misuse, custom authorizer flaws
• Bedrock prompt injection — for AI features built on AWS Bedrock, prompt injection that exfiltrates training context

Methodology

Our testing follows industry-standard methodologies:

• OWASP Testing Guide v4 for web application coverage
• OWASP API Security Top 10 for API testing
• PTES (Penetration Testing Execution Standard) for overall structure
• NIST SP 800-115 for technical methodology
• MITRE ATT&CK Cloud Matrix for AWS-specific attacker tradecraft

Manual testing is the differentiator. Automated scanners (Burp, Nessus, ScoutSuite, Pacu in autonomous mode) run as the starting point, not the finish line. Manual exploitation finds business logic flaws, chained exploits, and architectural weaknesses no scanner is going to identify.

Engagement Process

Phase 1 — Scoping (Week 0)

• Application and AWS environment inventory
• In-scope and out-of-scope clarification (which accounts, which apps, which APIs)
• Test type selection (black box / gray box / white box)
• Production vs staging strategy
• AWS notification requirements (DDoS simulation, etc.)
• Emergency contact and kill-switch protocol

Phase 2 — Testing (Weeks 1–2)

• External reconnaissance (DNS, public assets, exposed services)
• AWS-specific reconnaissance (Pacu, ScoutSuite enumeration with appropriate credentials)
• Web application and API testing
• IAM and cross-service privilege escalation testing
• Container and serverless testing
• Network testing (VPC exposure, security group analysis)
• Continuous critical-finding notification (4-hour SLA)

Phase 3 — Reporting (Week 3)

• Executive summary
• Technical findings (CVSS + reachability + business impact)
• Compliance mapping
• Remediation guidance (AWS-specific)
• Attack narrative

Phase 4 — Retest (Optional, after remediation)

• Re-verification of each finding
• Clean retest report for audit deliverables
• Confirmation of newly introduced controls

Compliance Alignment

Common Findings — What We Actually Find

After hundreds of AWS pen tests, the recurring critical findings:

1. Overprivileged Lambda execution roles — Lambda functions with iam:* or s3:* permissions far beyond what they need, exploitable if the function code can be modified or if the function processes attacker-controlled input
2. IMDSv1 still enabled — even with IMDSv2 best practices documented, real environments often have legacy instances with IMDSv1 enabled, exploitable via SSRF
3. S3 bucket policies allowing cross-account read — buckets with Principal: "*" that pass Block Public Access checks but still allow any authenticated AWS principal to access them
4. Cross-account AssumeRole with weak conditions — AssumeRole trust policies with no sts:ExternalId and overly broad source account lists
5. Container metadata exploitation — compromised application containers reaching ECS Task Metadata to extract task role credentials
6. API authentication bypass — JWT validation flaws, missing audience checks, expired tokens accepted
7. CloudFormation pipeline privilege escalation — pipeline roles with admin permissions, exploitable by anyone who can submit a PR

Related Services and Resources

• AWS Cloud Security Consulting — for the broader security assessment
• AWS Managed SOC & MDR — for ongoing detection and response after pen test findings are remediated
• Cloud Compliance Services — for compliance program work
• Inspector v2 Production Guide — our blog post on continuous vulnerability scanning (complementary to pen testing)
• AWS WAF Production Guide — defensive control we test against

Get Started

If you’re approaching a SOC 2 audit, a PCI DSS assessment, or an enterprise procurement that asks for “evidence of penetration testing in the last 12 months” — we can help. We deliver pen tests that satisfy auditors, give engineering teams actionable guidance, and uncover the AWS-specific findings that matter.

Scope My AWS Pen Test →