AWS-aware pen testing — IAM, S3, Lambda, IMDS
Vulnerability scanners find what is in the CVE database. Penetration testers find what your architecture decisions left exposed — 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.
This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.
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.
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.
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.
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.
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.
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.
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.
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.
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.
## 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](https://aws.amazon.com/security/penetration-testing/), 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 | 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. [Scope My AWS Pen Test →](/contact-us/)
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.
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:
AssumeRole trust policies allowing principals from unintended accountsOur testing follows industry-standard methodologies:
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.
| 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 |
After hundreds of AWS pen tests, the recurring critical findings:
iam:* or s3:* permissions far beyond what they need, exploitable if the function code can be modified or if the function processes attacker-controlled inputPrincipal: "*" that pass Block Public Access checks but still allow any authenticated AWS principal to access themAssumeRole trust policies with no sts:ExternalId and overly broad source account listsIf 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.
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."
We test the AWS control plane itself — IAM trust policies, S3 bucket policies, KMS key permissions, Lambda execution-role chains, and cross-service privilege paths. The architectural findings a web-only pen test never surfaces.
Automated scanners surface CVEs. The other 70% — business-logic flaws, chained exploits, and AWS-specific privilege paths — only shows up under manual testing. Our offensive team holds OSCP, OSEP, and CREST certifications and reviews every finding by hand.
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.
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.
In-depth guides and best practices from our certified AWS architects.
GitHub Actions OIDC role sessions are short-lived by design—teams still paste static access keys into workflow logs until scanners or audits catch the diff; supply-chain writeups keep repeating the pattern into 2026.
Read articleBedrock Automated Reasoning checks ground LLM outputs against formal logic policies you encode and mathematically validate that the response is consistent with the policy. This guide covers when to use Automated Reasoning vs contextual grounding, how to author the policy in production, the integration with Bedrock Guardrails, and the regulated use cases (HR, insurance, eligibility, regulatory determinations) where the difference matters.
Read articleCloudTrail Event History on the default plan isn't your audit trail — it's a 90-day story you tell auditors. A production CloudTrail setup with multi-region trails, KMS encryption, log file integrity validation, and CloudTrail Lake as the queryable layer for incident response and compliance evidence.
Read articleVulnerability 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.
We use cookies and similar technologies to analyze site traffic, personalize content, and provide social media features. By clicking "Accept," you consent to our use of cookies. You can adjust your preferences at any time.