Cloud Pentesting

Cloud penetration testing is largely identity penetration testing. The network perimeter that on-premise testing spends its first day mapping is mostly gone; what remains is a web of roles, trust policies and permissions, and the interesting findings are paths through that web.

The shift is fundamental: privilege escalation is not a kernel exploit, it is a chain of permissions that, followed in the right order, ends somewhere it shouldn’t.

Provider rules of engagement

Cloud providers publish penetration-testing policies. Most permit testing your own resources without notice; some activities — denial of service, testing shared infrastructure — are prohibited or require notification. Read the current policy for the provider in scope, and keep testing inside your own accounts. Rules of engagement here include the provider’s, not just the client’s.

The methodology is: enumerate, then chain

Enumerate first, exhaustively. From any foothold — a leaked key, an SSRF’d credential, a low-privilege role — map what this identity can see and do. The goal is the permission set, not an exploit.

Then find the chain. Cloud privilege escalation is composition. No single permission is the vulnerability; the sequence is. iam:PassRole plus the ability to launch compute is not two findings, it is one path to any role the account can pass.

The mindset difference from on-premise: you are not looking for a broken thing, you are looking for an intended capability used in an unintended order. That maps directly to what the IAM pillar describes defensively — the misconfigs listed there are what the enumeration is searching for.

AWS

The recurring escalation paths:

• iam:PassRole + a compute service. Pass a more-privileged role to EC2, Lambda or ECS and inherit it. The single most common cloud privesc, and it usually looks like a legitimate deployment permission.
• Policy manipulation. iam:CreatePolicyVersion, iam:AttachUserPolicy, or updating an assumable role’s trust policy — permission to change permissions is permission to have any permission.
• Metadata abuse. SSRF against 169.254.169.254 yields the instance role’s credentials. IMDSv2 raises the bar; plenty of estates still allow IMDSv1.
• Service pivots. Lambda environment variables and layers, ECS task roles, SSM command execution against instances you can reach.
• Data access as the objective. S3 bucket policies and object ACLs are their own path, and are frequently the actual goal rather than a step.

Azure

The two-plane structure — Azure RBAC over resources, Entra roles over the directory — is itself the source of the most interesting findings, because people reason about one and forget the other.

• Managed identity abuse. A compromised resource with a managed identity is that identity. Reach a VM or Function with a privileged managed identity and you inherit it.
• Service principal and app registration paths. Over-privileged service principals, stale registrations, and dangerous Graph permissions — RoleManagement.ReadWrite.Directory is directory takeover.
• Consent grant abuse for phishing-driven access to Graph.
• Azure → on-prem. Entra Connect, hybrid identity, and the sync account are the classic bridge from cloud back into the on-premise directory.

Kubernetes

A cluster is an environment inside the environment, and the paths turn one pod into all of them:

• Service account tokens. Mounted into pods by default; an over-privileged one is cluster access from a compromised container.
• RBAC abuse. create pods is close to cluster-admin — schedule a privileged pod that mounts the host or a better service account.
• Pod escape. Privileged containers, host mounts, and exposed sockets break the isolation to the node, and from the node to the rest of the cluster.
• Metadata from pods. The node’s cloud identity is reachable from inside a pod unless explicitly blocked — the container-to-cloud bridge.

Testing is bounded by logging

A point worth carrying from the defensive side: what you can do in a cloud pentest, the defender can often see — if the logging was configured. Enumeration is loud in CloudTrail; role assumption chains are visible; metadata access can be detected. Part of a good cloud engagement is noting which of your actions were observable, which is where this work becomes a purple team exercise rather than only a findings list.

Where this connects

The permissions being chained are IAM misconfigurations, exploited — this is the offensive read of that pillar. The fixes are architecture: permission boundaries, org guardrails, IMDSv2, and network policy. Tooling — Pacu, ScoutSuite, ROADrecon, BloodHound — is in tools and commands. And detectability ties to the pipeline.