Penetration Testing
AWS Penetration Testing Services
Vulnerability scanners find what is in the CVE database. Penetration testers find what your architecture decisions accidentally enabled — overprivileged Lambda execution roles, S3 bucket policies that let any authenticated AWS account read your data, IMDSv1 enabled on instances handling PHI. We run AWS-aware penetration tests under AWS's acceptable-use policy and deliver the proof of concept your auditor will sign off on.
AI & assistant-friendly summary
This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.
Summary
AWS-aware penetration testing — IAM privilege escalation, S3 misconfiguration, instance metadata exploitation, web app and API testing. OSCP-certified testers, OWASP/PTES methodology, AWS-compliant scope.
Key Facts
- • AWS-aware penetration testing — IAM privilege escalation, S3 misconfiguration, instance metadata exploitation, web app and API testing
- • OSCP-certified testers, OWASP/PTES methodology, AWS-compliant scope
- • We run AWS-aware penetration tests under AWS's acceptable-use policy and deliver the proof of concept your auditor will sign off on
- • Cloud Penetration Testing (AWS): IAM privilege escalation, cross-account trust abuse, S3 bucket misconfiguration, IMDS exploitation, Lambda code injection, and EKS cluster takeover
- • We use Pacu, ScoutSuite, and custom AWS attack tooling alongside manual exploitation — all within AWS's acceptable-use policy for customer testing
- • Web Application Penetration Testing: OWASP Top 10 + business logic testing
- • SQL injection, XSS, IDOR, broken access control, server-side request forgery (SSRF) — including AWS-specific SSRF chains that pivot to instance metadata
- • API Security Testing: REST and GraphQL API testing for authentication bypass, authorization flaws, rate-limit weaknesses, mass assignment, GraphQL introspection abuse, and JWT misuse
Entity Definitions
- AWS Bedrock
- AWS Bedrock is an AWS service used in aws penetration testing services implementations.
- Bedrock
- Bedrock is an AWS service used in aws penetration testing services implementations.
- Lambda
- Lambda is an AWS service used in aws penetration testing services implementations.
- EC2
- EC2 is an AWS service used in aws penetration testing services implementations.
- S3
- S3 is an AWS service used in aws penetration testing services implementations.
- RDS
- RDS is an AWS service used in aws penetration testing services implementations.
- CloudFront
- CloudFront is an AWS service used in aws penetration testing services implementations.
- IAM
- IAM is an AWS service used in aws penetration testing services implementations.
- VPC
- VPC is an AWS service used in aws penetration testing services implementations.
- EKS
- EKS is an AWS service used in aws penetration testing services implementations.
- ECS
- ECS is an AWS service used in aws penetration testing services implementations.
- API Gateway
- API Gateway is an AWS service used in aws penetration testing services implementations.
- EventBridge
- EventBridge is an AWS service used in aws penetration testing services implementations.
- WAF
- WAF is an AWS service used in aws penetration testing services implementations.
- AWS WAF
- AWS WAF is an AWS service used in aws penetration testing services implementations.
Frequently Asked Questions
Do I need permission from AWS to penetration test my own AWS environment?
Mostly no — AWS permits customers to perform security assessments and penetration testing of their own AWS resources without prior approval, under the AWS Customer Support Policy for Penetration Testing. The exceptions: DDoS simulation testing, port flooding, protocol flooding, and network stress testing all require advance approval through the AWS Vulnerability Reporting form. We handle the approval process when applicable. Testing of AWS infrastructure itself (data centers, hypervisors, AWS services as a service) is never permitted.
How is AWS penetration testing different from a regular pen test?
Regular pen tests focus on web apps, networks, and operating systems. AWS pen tests add a cloud-specific attack surface: IAM trust relationships (overly permissive AssumeRole), S3 bucket policies (public read accidentally enabled, condition keys missing), instance metadata service (IMDSv1 still enabled, leaking credentials via SSRF), KMS key policies (cross-account access too broad), Lambda execution roles (over-privileged, allowing privilege escalation via writable code), and AWS service-to-service trust (CloudFormation, CodePipeline, EventBridge) that can be abused for lateral movement. Tools like Pacu and ScoutSuite are AWS-specific; competent testers use them alongside manual review.
How long does an AWS penetration test take?
A standard scope (one application stack, one AWS account, web + API + infrastructure) takes 2 weeks for testing plus 1 week for reporting and retest. Complex environments (multi-account, microservice architectures, EKS, multiple business logic flows) take 3–4 weeks. We scope based on environment complexity, not flat per-application pricing — a 50-microservice EKS deployment is not the same effort as a 3-Lambda serverless app.
What deliverables do I get?
A penetration test deliverable package includes: (1) Executive summary (1–2 pages) for leadership, (2) Technical findings report with each finding documented at CVSS + reachability + business impact, with full proof-of-concept reproduction steps, (3) Remediation guidance specific to AWS — exact IAM policy changes, exact bucket policy fixes, exact code patches, (4) Compliance mapping (which findings affect which SOC 2 / ISO 27001 / HIPAA / PCI controls), (5) Attack narrative documenting the pathways tested and which succeeded, (6) Retest report after remediation confirming clean status, (7) Auditor-ready evidence package with raw test artifacts.
Do you support PCI DSS, SOC 2, HIPAA penetration test requirements?
Yes. Our pen tests are explicitly designed to satisfy: PCI DSS 4.0 Requirement 11.4 (annual external + internal pen test, methodology following industry-accepted approaches), SOC 2 Type II evidence for CC7.1 (monitoring) and CC4.1 (control testing), HIPAA §164.308(a)(8) (periodic technical evaluation), and ISO 27001 A.5.30 / A.8.34 (technical compliance review and ICT readiness). Each finding is mapped to the applicable control during reporting.
What if you find a critical vulnerability mid-test?
We notify within 4 hours of confirmed critical findings, with a brief description of the issue and immediate remediation guidance — separate from the formal report. For findings that represent active risk (e.g., publicly exposed credentials, ongoing data exposure), we recommend immediate containment and continue testing only after the issue is contained. Critical findings are handled out-of-band; we do not wait until the final report to disclose them.
Can you test production environments, or only staging?
Both, with appropriate care. Production testing carries operational risk (a payload that crashes a service, an authentication test that locks out real users) and we mitigate it through: (a) limiting destructive tests to staging or sandbox, (b) coordinating disruptive tests during maintenance windows, (c) maintaining a kill-switch hotline during testing, (d) avoiding tests with broad operational blast radius (mass account enumeration, denial-of-service simulation against production). Most clients run a full test against staging and a more constrained verification test against production.
How often should I run an AWS penetration test?
PCI DSS requires annual + after significant change. SOC 2 expects at least annual testing as part of CC4.1. ISO 27001 A.8.34 requires periodic testing — most certified organizations interpret this as annual. Regulatory baselines aside, we recommend testing after every major architectural change (new account structure, new service introduced, significant feature with new attack surface), after security incident response activities, and at least annually as a standalone assessment. Continuous testing programs (red teaming) are appropriate for high-target organizations and high-value workloads.
Related Content
- AWS Security Consulting — Related AWS service
- AWS Managed SOC & MDR Services — Related AWS service
- Cloud Compliance Services — HIPAA, SOC 2, PCI DSS on AWS — Related AWS service
- Cyber-Led AI Security Readiness Check — Related AWS service
## 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 | Framework | Requirement | Our pen test deliverable | | -------------- | ------------------------------------------------- | ------------------------------------------------------------- | | PCI DSS 4.0 | Req 11.4.1–11.4.6 (penetration testing) | Annual external + internal test, segmentation testing for CDE | | SOC 2 Type II | CC4.1 (control testing), CC7.1 (monitoring) | Annual independent testing evidence | | ISO 27001:2022 | A.5.30 (ICT readiness), A.8.34 (technical review) | Periodic technical compliance verification | | HIPAA | §164.308(a)(8) (periodic evaluation) | Documented technical evaluation | | NIST CSF 2.0 | DE.CM-08 (vulnerabilities tested) | Penetration test report and findings | ## 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](/services/aws-cloud-security) — for the broader security assessment - [AWS Managed SOC & MDR](/services/aws-managed-soc-mdr) — for ongoing detection and response after pen test findings are remediated - [Cloud Compliance Services](/services/cloud-compliance-services) — for compliance program work - [Inspector v2 Production Guide](/amazon-inspector-v2-container-lambda/) — our blog post on continuous vulnerability scanning (complementary to pen testing) - [AWS WAF Production Guide](/aws-waf-web-application-firewall-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. [Book a Free Pen Test Scoping Call →](/contact-us)
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
AssumeRoletrust 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
| Framework | Requirement | Our pen test deliverable |
|---|---|---|
| PCI DSS 4.0 | Req 11.4.1–11.4.6 (penetration testing) | Annual external + internal test, segmentation testing for CDE |
| SOC 2 Type II | CC4.1 (control testing), CC7.1 (monitoring) | Annual independent testing evidence |
| ISO 27001:2022 | A.5.30 (ICT readiness), A.8.34 (technical review) | Periodic technical compliance verification |
| HIPAA | §164.308(a)(8) (periodic evaluation) | Documented technical evaluation |
| NIST CSF 2.0 | DE.CM-08 (vulnerabilities tested) | Penetration test report and findings |
Common Findings — What We Actually Find
After hundreds of AWS pen tests, the recurring critical findings:
- Overprivileged Lambda execution roles — Lambda functions with
iam:*ors3:*permissions far beyond what they need, exploitable if the function code can be modified or if the function processes attacker-controlled input - IMDSv1 still enabled — even with IMDSv2 best practices documented, real environments often have legacy instances with IMDSv1 enabled, exploitable via SSRF
- 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 - Cross-account AssumeRole with weak conditions —
AssumeRoletrust policies with nosts:ExternalIdand overly broad source account lists - Container metadata exploitation — compromised application containers reaching ECS Task Metadata to extract task role credentials
- API authentication bypass — JWT validation flaws, missing audience checks, expired tokens accepted
- 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.
Key Features
IAM privilege escalation, cross-account trust abuse, S3 bucket misconfiguration, IMDS exploitation, Lambda code injection, and EKS cluster takeover. We use Pacu, ScoutSuite, and custom AWS attack tooling alongside manual exploitation — all within AWS's acceptable-use policy for customer testing.
OWASP Top 10 + business logic testing. SQL injection, XSS, IDOR, broken access control, server-side request forgery (SSRF) — including AWS-specific SSRF chains that pivot to instance metadata. Manual testing follows OWASP Testing Guide methodology.
REST and GraphQL API testing for authentication bypass, authorization flaws, rate-limit weaknesses, mass assignment, GraphQL introspection abuse, and JWT misuse. We test against your API Gateway and ALB-fronted endpoints with awareness of WAF and Shield deployment.
External network testing for exposed VPC resources — public RDS instances, accidentally public ElastiCache, exposed admin ports on EC2, vulnerable third-party services in your VPC. Internal network testing via authenticated VPN or Systems Manager Session Manager pivot points.
ECS task escape, EKS RBAC bypass, container image vulnerability exploitation, Lambda function code injection, and event source confusion attacks. Including AWS-specific pivots: a compromised Lambda using its execution role to escalate cross-service.
Once you remediate, we retest at no additional cost — confirming each finding is closed and producing a clean retest report. Critical for audit deliverables: assessors want to see "finding identified, remediated, retested clean," not "finding identified, remediated."
Why Choose FactualMinds?
Most pen test firms test web apps and infrastructure that happens to live on AWS. We test the AWS layer specifically — IAM trust policies, S3 bucket policies, KMS key permissions, cross-service privilege chains. The findings that web pen testers miss because they aren't looking.
Our offensive team holds OSCP, OSEP, and CREST certifications. Manual testing is the differentiator — automated scanners find ~30% of what we find. The other 70% is business logic, chained exploits, and architectural flaws that only show up under skilled manual testing.
AWS permits customer-authorized penetration testing of customer resources without prior approval — but several activities still require approval. We operate within AWS policy, document scope precisely, and notify AWS when required (e.g., DDoS simulation testing).
Reports are formatted as audit evidence — executive summary for leadership, technical findings with CVSS and reachability scoring for engineers, and a compliance mapping section that ties findings to SOC 2 / ISO 27001 / HIPAA / PCI requirements. The same document satisfies your auditor and your sprint planning.
Step-by-Step Guides
Implementation guides for this service from our team of AWS experts.
Inspector v2 continuously scans EC2, ECR container images, and Lambda functions without agents. Production guide to CI/CD integration, finding management, risk scoring, and multi-account deployment.
How to build a vulnerability management program that scales beyond CVE-counting. Inspector v2 deployment, CVSS + CISA KEV + reachability for risk-based prioritization, container and IaC scanning in CI/CD, and remediation SLAs that survive audits.
AWS Security Hub aggregates security findings from 200+ sources (GuardDuty, Config, IAM Access Analyzer, Inspector). This guide covers setup, compliance standards (PCI-DSS, CIS, NIST), automated remediation, and building a compliance dashboard without hiring a SOC team.
From Our Blog
In-depth guides and best practices from our certified AWS architects.
Building a Vulnerability Management Program on AWS: CVSS, KEV, and Reachability
How to build a vulnerability management program that scales beyond CVE-counting. Inspector v2 deployment, CVSS + CISA KEV + reachability for risk-based prioritization, container and IaC scanning in CI/CD, and remediation SLAs that survive audits.
Read articleGDPR Compliance on AWS: A Practical Guide for SaaS Companies
GDPR compliance on AWS for SaaS companies handling EU resident data. Region selection, the AWS DPA, data subject rights automation, RoPA documentation, breach notification, and the technical controls regulators expect.
Read articleISO 27001 Certification on AWS: ISMS Implementation Guide for 2026
A practical guide to ISO 27001:2022 certification on AWS — building an ISMS that survives Stage 1 and Stage 2 audits, mapping the 93 Annex A controls to AWS services, and producing the evidence packages assessors actually request.
Read articleFrequently Asked Questions
Do I need permission from AWS to penetration test my own AWS environment?
How is AWS penetration testing different from a regular pen test?
How long does an AWS penetration test take?
What deliverables do I get?
Do you support PCI DSS, SOC 2, HIPAA penetration test requirements?
What if you find a critical vulnerability mid-test?
Can you test production environments, or only staging?
How often should I run an AWS penetration test?
Find What Scanners Miss
Vulnerability scanners catch known CVEs. Penetration testers catch the architectural flaws and business logic gaps that scanners cannot. Get a scoped, AWS-aware pen test with auditor-ready reporting.