When a red team engages a cloud environment, the old mental model of scanning subnets and pivoting through firewalls barely applies. Compute is ephemeral, network boundaries are software-defined, and the thing that actually grants access is an identity token. The cloud control plane, the API layer that provisions and governs every resource, is the real battleground, and a single over-permissioned role can be worth more than a domain admin account on-premises.
The shift is fundamental. In a data center, an attacker who compromises a host still has to move laterally through a network. In AWS, Azure, or GCP, an attacker who obtains the right set of credentials can enumerate, escalate, and exfiltrate entirely through authenticated API calls, often without deploying a single implant. That makes identity and access management (IAM) the primary attack surface and the primary place a red team spends its time.
From network perimeter to identity perimeter
Cloud attack paths are built from permissions, not ports.
- ▸Role assumption chains: An identity permitted to assume a more privileged role, which can assume another, produces escalation paths that look benign per step but compound into full control.
- ▸Trust policy flaws: Overly broad trust relationships let external or unintended principals assume internal roles, the cloud analogue of a delegation abuse.
- ▸Federated identity abuse: Misconfigured OIDC federation between a CI/CD provider and a cloud account can let anyone who controls a pipeline mint cloud credentials.
Instance metadata and credential harvesting
The classic cloud escalation still works wherever it is left unguarded: an application vulnerable to server-side request forgery (SSRF) can reach the instance metadata service and read the credentials of the role attached to the workload. The public Capital One breach remains the canonical example of this exact chain, SSRF to metadata to over-scoped role to data exfiltration, and it is the reason IMDSv2, which requires a session token and blocks naive SSRF, exists. Red teams routinely check whether IMDSv1 is still reachable, whether workload roles are scoped to least privilege, and whether harvested credentials can be used from outside the expected network context.
Where the loot lives
- ▸Secrets in the wrong place: Access keys hardcoded in code, CI variables, or container images give attackers durable, portable credentials.
- ▸Storage misconfiguration: Object stores with permissive policies remain one of the most common sources of large data exposure.
- ▸Serverless and container roles: Functions and tasks often run with broad roles because scoping them is tedious, handing an attacker who compromises the code a generous identity.
A cloud red team checklist
1. Enumerate identities and policies first, mapping who can assume what before touching any data-plane resource. 2. Test for SSRF into metadata on every internet-facing application and confirm IMDSv2 enforcement. 3. Hunt for exposed credentials across code repositories, pipeline configs, and image layers. 4. Trace role-assumption graphs to find escalation chains, using cloud-native IAM analysis or graph tooling. 5. Attempt cross-account and federation abuse where trust policies or OIDC subjects are loosely scoped. 6. Exfiltrate against a canary so the blue team can validate detection without real data leaving the boundary.
Catching it with cloud-native telemetry
The upside of an API-driven attack surface is that nearly every action is logged. AWS CloudTrail, Azure activity and sign-in logs, and GCP audit logs record the control-plane calls a red team makes, which means the defensive question is whether anyone is watching and correlating them. Anomalous role-assumption activity, credential use from an unexpected geography or network, first-seen API calls for a principal, and metadata-service access patterns are all high-signal detections. Mapping these to the cloud matrices in MITRE ATT&CK gives a defender a structured coverage target rather than a pile of raw logs.
For an organization moving workloads to the cloud, this reframing is the strategic takeaway: your security posture is now a function of how tightly you scope identities and how well you watch the control plane, not how high you build the network wall. A red team that walks your IAM graph and abuses your metadata service is stress-testing the exact controls that matter in a cloud-first architecture. Closing those gaps, least-privilege roles, enforced IMDSv2, and monitored trust policies, is what lets a business scale in the cloud without scaling its blast radius.