Cloud Usually Falls on a Single Line of Config — Tracing the Escalation | GOTROOT

If on-prem incidents were stories about getting past the firewall, cloud incidents usually start from a single line of config. More often than a flashy exploit, one IAM policy with a wildcard or one publicly open bucket becomes the way in. This is the escalation flow we follow in cloud environments, framed by the shared-responsibility model.

First, what’s ours to secure

When scoping, the first thing to align is shared responsibility: the provider secures the cloud “itself,” while the customer owns config, data, and permissions “in” it. Testing focuses on the latter — the customer-made boundaries. (We also confirm each provider’s testing policy up front.)

Tracing an escalation

Rather than describe it, here’s one path we actually meet often, step by step. It started with a plain SSRF.

one SSRF in the application
   │  (coax the server into requesting an internal address)
   ▼
call the instance metadata service  http://169.254.169.254/...
   │  (with IMDSv1, it answers without a token)
   ▼
obtain the instance role's temporary credentials (Key/Secret/Token)
   │
   ▼
use them to assume-role into another role → role chaining
   │
   ▼
reach admin privileges → move laterally across the account

Each step is ordinary on its own. What’s scary is that they connect — and the first button is usually a single line of config (IMDSv1 allowed, an over-permissive role).

IAM — the deepest part

IAM is the heart of cloud escalation. We look for leaked access keys, wildcard policies like Action:*, and “dangerous-in-combination” permissions such as iam:PassRole and iam:CreatePolicyVersion.

# start by calmly checking what this credential can do
aws sts get-caller-identity
aws iam list-attached-user-policies --user-name <user>

# risk example: PassRole + permission to create Lambda/EC2
# → opens a path to "hand off" and run a higher-privileged role

Misconfigurations we see often

Area	Common setting
Storage	Public buckets / broad ACLs, signed-URL abuse
Network	Management ports (SSH/RDP/DB) open to 0.0.0.0/0
Images/snapshots	Keys or sensitive data left in public AMIs/snapshots
Detection	CloudTrail off/evadable → activity goes unrecorded

Going deeper — the components on top of the cloud

Cloud testing doesn’t end at config. The workloads on top — container images, serverless runtimes, OSS components — if they carry known (or unknown) flaws, become another door to credential theft and escalation. It’s a favorite path for targeted attackers, so we fingerprint exposed components and check real exploitability with a 1-day mindset. (Related: How 0-days Are Found)

Field note: the advice we give most in cloud tests is surprisingly simple — enforce IMDSv2, minimize role permissions, keep CloudTrail on. Not flashy, but the surest way to cut the first button of that chain.

FAQ

We have a CSPM tool — do we still need this?

CSPM shows config “state” well. Pentesting differs by confirming, through chaining, whether that config actually leads to an escalation path. They’re complementary.

Is it okay on a production account?

Risky steps run only under prior agreement and control; we suggest a separate test account when needed, and confirm provider policy.

Closing

Cloud is sensitive enough that one line of config can decide the whole account — but the flip side is that fixing that line cuts a lot of risk at once. To trace your permission boundaries together, reach out at cloud penetration testing.