A cloud engineer spends a sprint hardening S3: block public access on every bucket, bucket policies denying anonymous reads, versioning and logging turned on. It passes every automated scanner clean. Three weeks later a pentest engagement compromises an unrelated web app on an EC2 instance in the same account, through an ordinary file-upload bug with nothing to do with S3 at all, and within the hour the tester is reading the contents of every bucket in the account, private ones included.
The bucket policy was never the perimeter. The EC2 instance had an IAM role attached to it, because something on that box needed to write logs somewhere, and the instance metadata service hands temporary credentials for that role to anything running on the box that asks, including an attacker with code execution through the upload bug. A request to the metadata endpoint for that role's security credentials returns an access key, secret key and session token good enough to do whatever the role is allowed to do. No bucket policy gets consulted, because those temporary credentials belong to the account, not to the public internet the bucket policy was written to keep out.
The role in question had a wildcard action on a wildcard resource, attached eighteen months earlier so a one-off script could write to a bucket that no longer exists, and never revisited. Nobody who hardened the bucket policies thought to check what the compute layer could already do regardless of those policies, because the two live in different consoles and get reviewed by different people on different schedules.
That's the actual shape of a cloud pentest, and it's why the engagement exists as its own discipline instead of a rerun of a web app checklist: enumerate every piece of compute in the account first (EC2, Lambda, containers), check what identity is attached to each one and pull its effective permissions, and specifically hunt for wildcard resources, wildcard actions, and privilege-escalation chains where one role can pass or assume another with broader access. A bucket policy audit that never crosses into the identity layer only ever secures half the account. Azure and GCP have their own version of the same gap under different names, managed identities and service account impersonation, which is exactly why it needs its own methodology rather than a copy-paste checklist across clouds.
That gap between securing the storage layer and actually testing what every attached identity can do is what a real cloud pentest engagement is built to find before someone else does. The Cloud Penetration Testing book for beginners walks through IAM attacks across AWS, Azure and GCP in 60+ hands-on labs, from initial access to the actual reporting: https://resources.codelivly.com/product/cloud-pentesting-l1/
Top comments (0)