AWS Penetration Testing

Identity and access management

• ▸Privilege escalation paths: iam:PassRole, policy-version manipulation, role chaining
• ▸Over-permissive policies, wildcard actions and resources, unused administrative access
• ▸Cross-account trust relationships that widen the blast radius further than intended
• ▸Long-lived access keys where a role or OIDC federation would do
• ▸Federated and SSO configuration, including permission set drift

Storage and data exposure

• ▸S3 buckets public by policy, ACL or a permissive CloudFront distribution in front
• ▸Presigned URL generation with excessive lifetimes or scope
• ▸Unencrypted volumes and snapshots, and snapshots shared more widely than intended
• ▸RDS instances reachable from the internet or from workloads that should not see them
• ▸Secrets in environment variables, user data, task definitions or Lambda configuration

Network and exposure

• ▸Security groups permitting 0.0.0.0/0 on management or database ports
• ▸Instance metadata service reachable from a compromised workload (IMDSv1 vs IMDSv2)
• ▸Load balancer and API Gateway configuration exposing internal services
• ▸VPC peering and transit routes that connect environments that should stay separate
• ▸Egress unrestricted, enabling exfiltration from a compromised instance

Serverless and containers

• ▸Lambda execution roles broader than the function needs
• ▸Function URLs and API Gateway routes without authorisation
• ▸Event-source injection: SQS, SNS, S3 events treated as trusted input
• ▸ECS and EKS task roles, and whether one task can assume another's identity
• ▸Secrets pulled at runtime and then logged

The applications you run

• ▸Authorisation across roles and tenants in whatever runs on the infrastructure
• ▸Injection, SSRF (which in AWS reaches the metadata endpoint), and deserialisation
• ▸Business logic in payment, entitlement and workflow paths
• ▸Multi-step chains: an application flaw, then a role, then data

Do we need permission from AWS to run a penetration test?

For standard testing of your own resources across the common service types, AWS permits customer-initiated penetration testing without prior approval, and has done for years. What still requires authorisation is a short list — simulated denial of service and similar disruptive activity — and there is a prohibited list worth reading before any engagement.

Practically: we do not perform DoS-style testing at all, so most Penetrify engagements need no ticket. What you do need is to be certain the accounts in scope are yours, which matters more in AWS than people expect once cross-account roles and shared services are involved.

What actually causes AWS breaches?

Rarely anything exotic. The recurring pattern is an application flaw that reaches the instance metadata service, credentials lifted from there, a role with more permissions than anyone remembers granting, and then data. Alongside that: storage made public by a policy nobody reviewed, and long-lived access keys in places they should not be.

Which is why testing IAM in isolation misses the point. The escalation only matters because something reachable let the attacker in, and the application flaw only matters because the role behind it was broad. Testing the chain is the difference between a list of warnings and knowing your blast radius.

Can you test without giving you access to our account?

Yes. External testing needs nothing: exposed services, applications and storage are assessed the way an attacker would, and that alone finds the classes that most often leak data.

Granting a read-only role adds the internal view — identities, policies, network configuration — which is where escalation paths become visible. It is read-only by design: nothing we do creates, modifies or deletes a resource. If you would rather not grant access at all, exported configuration works, with the caveat that a snapshot ages faster than a role.

How does this compare with Security Hub and GuardDuty?

They answer different questions and you should keep them. Config and Security Hub tell you whether your resources match rules; GuardDuty tells you when something suspicious is happening. Neither attempts an attack, so neither tells you whether a specific role can be escalated or whether your application can be used to reach it.

The useful division: native tools for continuous posture and detection, penetration testing for whether the posture actually holds. Teams that treat a green Security Hub as evidence of security are measuring compliance with rules, not resistance to attack.

Every finding with severity, the exact policy statement or resource setting responsible, reproduction, and the change that fixes it.

The path from initial access to data, documented as a sequence rather than split across tickets that individually look minor.

What each role and function can actually reach, which is the input to least-privilege work that would otherwise be guesswork.

What closed, what regressed and when — evidence for auditors and enterprise security reviews.

CC6.1: logical access controls, commonly evidenced with penetration testing of the cloud environment

A.12.6: technical vulnerability management including cloud configuration

Requirement 11.4.1: documented methodology, testing at least every 12 months and after significant change; segmentation testing where AWS hosts the cardholder data environment

45 CFR §164.308(a)(8): regular evaluation, including workloads processing ePHI

Security *in* the cloud is yours: IAM, configuration, data and applications. AWS covers security *of* the cloud.