🔗 Cloud Attack Chains Overview
Intro: Attack chains matter because individual findings rarely stay individual for long. A leaked token, a metadata endpoint exposure, or an over-scoped service account often becomes a multi-step identity and deployment incident.
What this page includes
- the cross-cloud pattern that repeats in AWS, Azure, and GCP
- where the chain usually begins
- where defenders can still break it cheaply
- links to provider-specific deep dives
Figure: Cross-cloud chain from foothold to persistence and business impact.
The pattern that repeats across providers
A surprisingly high percentage of cloud incidents follow the same six-stage pattern:
| Stage | What the attacker wants | Typical examples |
|---|---|---|
| 1. foothold | execute code or obtain a credential | SSRF, exposed admin panel, leaked CI token, public bucket artifact, poisoned dependency |
| 2. identity harvest | turn execution into cloud identity | IMDS/metadata token, managed identity token, service account token, stolen OIDC token |
| 3. discovery | understand blast radius | list roles, projects, subscriptions, storage, registries, clusters, secrets |
| 4. privilege expansion | gain a better path than the first credential | assume role, use pass-role style permissions, abuse service principal grants, impersonate service account |
| 5. platform control | change deployment or data paths | push image, modify pipeline, update cluster, change policy, read secrets, exfiltrate storage |
| 6. persistence / cover tracks | stay alive and make future access easier | create new credentials, add federation trust, leave malicious image, alter logging, create backdoor automation |
Why cloud attack chains accelerate fast
Cloud-native estates compress several control planes into one place:
- identity is programmable;
- compute can mint new credentials at runtime;
- deployment is usually API-driven;
- logging is rich, but only if the right categories are enabled;
- misconfigurations compound instead of staying isolated.
That combination makes the first foothold less important than the first usable credential.
The five most common starting points
1) workload code execution plus metadata access
This is the classic “application bug becomes cloud incident” path. The attacker lands code execution or SSRF, then immediately checks whether runtime credentials are available.
2) leaked CI/CD or developer token
The attacker skips the application and goes straight to the delivery layer. If the token can read variables, assume roles, or push artifacts, the whole deployment path may be at risk.
3) over-privileged workload identity
The app is not necessarily vulnerable in the traditional sense. It simply runs with more cloud privileges than its job requires.
4) storage and registry exposure
Public or weakly protected buckets, blobs, artifact registries, and package feeds can leak code, secrets, templates, or allow poisoned artifacts.
5) logging blind spots
The chain moves faster when defenders only log management activity and miss the data or workload layer.
The cheapest breakpoints for defenders
| Breakpoint | Why it matters |
|---|---|
| require short-lived workload identity instead of static secrets | removes the easiest theft-and-reuse pattern |
| harden metadata access and isolate workloads | stops app-level bugs from immediately becoming cloud identity incidents |
| minimize role grants to workloads and CI/CD | reduces lateral movement after the first credential |
| enable the right logs before the incident | makes scoping possible without guessing |
| require promotion controls for images and manifests | blocks poisoned delivery paths |