A dashboard will tell you a role has broad permissions. It won't tell you whether that role can actually be chained through three other services to reach your production database. That difference — between "flagged" and "proven" — is the entire reason cloud penetration testing exists as its own discipline, distinct from posture management.
This piece picks up where a general assessment overview leaves off. No breach statistics, no shared responsibility model — just the actual technical work involved in testing each layer of a cloud environment, the way a practitioner would approach it.
IAM: Start Here, Because Everything Else Depends on It
Identity and access management is almost always where a cloud penetration test begins, because privilege escalation paths through IAM are what turn a minor foothold into full account compromise.
The methodology typically starts with enumeration — pulling every user, role, policy, and group across the environment to understand what access actually exists, not what the documentation claims exists. Tools like Prowler audit configurations against CIS, NIST, or PCI benchmarks and surface an initial map of weak policies and over-permissioned identities. From there, a visualizer like pmapper builds out the actual relationship graph between users and roles, which is where privilege escalation paths become visible — a role with S3 read access and EC2 launch permissions, for instance, might look harmless in isolation but combine into something far more dangerous.
Rhino Security Labs has documented more than 20 distinct IAM privilege escalation paths in AWS alone — techniques like attaching a more permissive policy to your own low-privilege user, creating a new policy version with elevated access, or abusing iam:PassRole to hand a Lambda function permissions it shouldn't have. Frameworks like Pacu automate testing these paths directly, running enumeration and escalation modules against a live environment to confirm — not just suggest — that a path is exploitable.
A practitioner's tip worth internalizing
Don't stop at proving one escalation path works. Map the full graph. Environments rarely have a single path from low-privilege to admin — they usually have several, and a remediation that closes one path while leaving two others open creates false confidence that's arguably worse than knowing nothing had been fixed.
Cross-account and cross-project access deserves its own pass here too — AssumeRole abuse, condition-key bypasses, and trust relationships between accounts are a common way testers move laterally once they've established a foothold in one part of a multi-account environment.
Storage: Assume Nothing Is Private Until You've Checked
Public storage exposure remains one of the most consistently exploitable findings in cloud environments, and testing it goes well beyond checking whether a bucket is flagged "public" in a console view.
The methodology involves systematically enumerating storage resources across every region and account, then testing actual access — not just configuration flags. A bucket can be technically "private" by one setting while still granting broader access than intended through a misconfigured policy, an overly permissive ACL, or a pre-signed URL that never expires. Tools purpose-built for this, like GCPBucketBrute on the Google Cloud side, brute-force bucket names and test access permissions directly rather than relying on the console's summary judgment.
Best practice
Test versioning and backup storage with the same rigor as primary storage. Backup buckets are frequently an afterthought in access reviews — configured once, never revisited — which makes them a disproportionately common place to find forgotten public access or stale credentials still holding write permissions.
Encryption-at-rest verification belongs in this phase too, not as a checkbox, but as a genuine test: confirming that sensitive data stores are actually encrypted with keys the organization controls, rather than relying on a default that was never explicitly configured.
APIs: Test the Logic, Not Just the Endpoint
API testing in a cloud context overlaps significantly with general application security testing, but cloud-native APIs introduce their own specific failure modes worth testing deliberately.
Authentication and authorization testing comes first — attempting to access endpoints without credentials, with expired tokens, and critically, with valid credentials belonging to a different tenant or user to test for authorization bypass. This is where insecure direct object reference (IDOR) testing lives: systematically attempting to access resources through predictable or sequential identifiers to confirm the API actually checks whether the requester has permission, rather than simply checking whether the identifier is valid.
Rate limiting and abuse testing matters more in cloud-native APIs than it often gets credit for, particularly for APIs backing pay-per-use services, where an abuse path can translate directly into a cost-based attack, not just a data exposure one.
A tip from practice
Always test API behavior at the boundary between microservices, not just at the public-facing gateway. Internal service-to-service calls are frequently built with far weaker authentication assumptions — "it's internal, so it's trusted" — which is exactly the assumption a tester should be trying to break.
Containers and Kubernetes: Test the Cluster, Not Just the Image
Container security testing splits into two related but distinct efforts: testing the images themselves, and testing the orchestration layer running them.
Image scanning catches known vulnerabilities in base images and dependencies — necessary, but far from sufficient on its own. The more revealing testing happens at the cluster level: RBAC misconfiguration testing (can a pod's service account reach further than it should), network policy validation (can a compromised pod reach services it has no legitimate reason to talk to), and privilege escalation testing specific to Kubernetes — including pod escape scenarios, where a container running with excessive privileges can be used to break out to the underlying node.
Purpose-built tools exist for exactly this kind of testing — automated hunters that actively probe a running cluster for known attack vectors, and benchmark tools that check configuration against CIS Kubernetes standards systematically rather than relying on manual review.
Best practice worth flagging specifically
Newly deployed clusters can face scanning activity within minutes of going live if any component is exposed to the public internet, which makes point-in-time testing alone insufficient for this layer — Kubernetes environments benefit disproportionately from continuous or frequently repeated testing compared to more static infrastructure.
CI/CD Pipelines: The Attack Surface Everyone Forgets
A pipeline that builds and deploys your code holds credentials with real reach, and testing it deserves the same rigor as testing production infrastructure.
Secrets scanning across repository history — not just the current codebase — catches credentials committed and later removed but never actually rotated, which remain exploitable as long as they're valid. Build injection testing examines whether a pipeline trusts its inputs appropriately: can a pull request from an untrusted source influence what code actually executes during a build, and what does that build process have access to if it can be manipulated.
Deployment credential scoping is worth testing directly rather than assuming it's correct: does the pipeline hold broader access than the specific deployment task requires, and would a compromised pipeline step be able to reach systems well beyond its intended scope.
SaaS Integrations and Logging: The Layer Most Assessments Skip
Every third-party integration connected via OAuth carries a scope of access that's worth testing directly — not just reviewing on paper. Testing here means confirming that granted scopes match actual need, and checking whether tokens for disconnected or deprecated integrations have actually been revoked, rather than simply left inactive.
Logging and detection testing closes out a thorough engagement, and it's arguably the most commonly skipped step: deliberately triggering the techniques used earlier in the engagement and confirming whether they actually generated an alert anyone would see. A finding that says "this path is exploitable" is useful. A finding that says "this path is exploitable, and it would go completely unnoticed if it happened" is the one that actually changes budget conversations.
The Discipline Behind the Tooling
None of the tools named here do the thinking. Pacu will run a privilege escalation module; it won't tell you which of the three paths it found matters most given your specific environment, or whether chaining a storage misconfiguration with an IAM weakness creates a genuinely different risk than either issue in isolation. That judgment — sequencing findings into a real attack path and understanding which one an actual adversary would take — is what separates a tooling run from a penetration test.
At ILLUME, this is the standard our cloud engagements are built around: methodical testing across every layer covered here, using the same tooling and techniques real attackers rely on, with every finding validated for exploitability before it reaches your remediation backlog. If you're evaluating what a properly scoped cloud penetration test should actually include, we're glad to walk through the methodology in detail. Reach out to ILLUME to scope an engagement for your environment.
