Cloud-Native Attack Paths
Cloud breaches rarely come from a single misconfiguration — they come from chaining several the way an attacker does: an SSRF leads to the metadata endpoint, which yields role credentials, whose over-privileged permissions allow reading data and escalating to admin. Seeing these chains is what turns a list of "findings" into a real risk picture.
This topic assembles the chapter's controls into the attack paths an adversary actually walks through a cloud account — the cloud version of the kill chain from Chapter 1 — and shows how breaking any one link stops the chain.
Thinking in Attack Paths, Not Findings
A posture tool's list of 500 misconfigurations is noise until you see which few chain to reach the crown jewels. Attack-path analysis — like ATT&CK (Chapter 1) for the cloud — prioritizes the misconfigurations that actually compose into compromise, so a "medium" that completes a path to admin gets the attention a flat severity list would deny it.
The Canonical Chain — SSRF to Admin
A worked path: a web SSRF (Chapter 6) reaches the instance metadata endpoint, which returns role credentials, which — because the role is over-privileged (this chapter) — allow reading data and assuming broader roles, ending in account compromise. Each link is a control from this chapter, and fixing any one breaks the chain: harden the metadata endpoint, or scope the role, or block the SSRF, and the path is severed.
Credential and Identity Chains
Other chains need no exploit at all. A leaked key (Chapter 12) or a compromised CI pipeline (Chapter 12) with broad cloud access, or an identity that can assume roles or edit IAM (this chapter), reaches admin through pure identity misconfiguration. These no-exploit paths are why cloud detection has to watch API calls and role assumptions, not just look for exploitation.
Detection and Response in the Cloud
Cloud audit logs (Chapter 10) are the detection substrate: anomalous API calls, new role assumptions, and access from unusual sources are the signals, and cloud incident response (Chapter 11) adds snapshot-based forensics and fast credential revocation. Meridian's cloud attack-path review traces the top paths end to end, notes which control from this chapter breaks each, and prioritizes by exploitability — the chapter's synthesis and the cloud parallel to Chapter 5's kill chain.
Findings-based — a flat list of misconfigurations ranked by generic severity; overwhelming, and a "medium" that completes a chain to admin looks less urgent than an isolated "high."
Attack-path-based — models how misconfigurations chain toward the crown jewels and prioritizes the links that actually enable compromise. Path thinking is what makes a huge findings list actionable.
- Drowning in a flat posture findings list without seeing which few misconfigurations chain into a real path to the crown jewels.
- Fixing high-severity findings in isolation while a chain of "mediums" quietly reaches admin.
- No cloud audit logging or detection, so identity-based attack paths (no exploit, just API calls) leave no trace.
- Treating cloud incident response like on-premises, without snapshot forensics and fast credential revocation.
- Prioritizing by generic severity instead of by path to the crown jewels.
- Prioritize cloud misconfigurations by attack path to the crown jewels, not by isolated severity — break the chains that matter.
- Close the canonical chains (SSRF to metadata to role, leaked-key to broad-access, IAM-escalation) using this chapter's controls.
- Enable cloud audit logging and detect anomalous API calls, role assumptions, and unusual-source access (Chapter 10).
- Build cloud-specific incident response: snapshot forensics, rapid credential and role revocation, and infrastructure rebuild (Chapter 11).
- Remember any single link broken severs the whole chain, so fix the cheapest reachable link first.
Knowledge Check
Why is attack-path analysis more useful than a flat findings list in the cloud?
- It shows which misconfigurations chain to reach the crown jewels
- It produces a longer, more exhaustive list of findings to review
- It automatically fixes every misconfiguration it detects for you
- It only works if there are no high-severity findings present
In the canonical SSRF-to-admin chain, how many controls must fail for it to succeed?
- Every link — so fixing any one breaks the chain
- Only the final admin step matters; the earlier links are all irrelevant
- None — the chain succeeds even if all controls hold
- Exactly two specific controls, always the same two
Why must cloud detection watch API calls and role assumptions, not just look for exploits?
- Identity-only paths use no exploit — they show only in API activity
- Exploits never occur anywhere in the cloud environment
- API calls are the only kind of activity that a cloud is ever able to log
- Role assumptions are, by definition, always malicious
You got correct