What Is a Cloud Attack Path and How Do Attackers Exploit It?

A cloud attack path is a connected chain of small misconfigurations an attacker walks from a public entry point to your data. In Amazon Web Services it typically runs from an SSRF bug to the EC2 metadata service to stolen role credentials to one over-scoped IAM permission to S3. Enforcing IMDSv2 breaks the chain at its first hop.

What a cloud attack path actually is

A vulnerability scanner hands you a ranked list. Every finding gets a severity score, and the standard advice is to work down from critical to low. That list carries a hidden assumption: it treats each finding as if it stood alone.

An attacker never reads a list. An attacker reads a graph. In that graph every resource is a node, a virtual machine, an identity, a storage bucket, an IAM role, and every permission or network route is an edge that connects two nodes. A cloud attack path is a walk across that graph. It begins at a node the attacker can already touch and ends at a node holding something worth taking.

Framed this way, the severity of any single node barely matters. What matters is whether the edges line up into one continuous route. Two medium findings joined by a single permission can outrank a critical finding that connects to nothing, because the mediums form a path and the critical is a dead end.

The rest of this walk follows one concrete route through Amazon Web Services, hop by hop, from a public web app to data in S3, and then finds the single link that makes the whole path collapse.

The foothold: SSRF turns a feature into a doorway

The path starts where your cloud meets the internet. In this walk that edge is a web application running on an EC2 instance, a virtual machine. The app accepts a URL from the user and fetches it on the server, a preview or import feature that looks harmless.

The flaw is server-side request forgery, or SSRF. Instead of an outward address, the attacker supplies a URL that points back at the machine itself. Trusting its own input, the application makes that request on the attacker's behalf. Now traffic that should have been blocked at the network edge originates from inside the instance, using the app as a relay.

No code has been dropped on the box and no password has been cracked. A trusted component has simply been persuaded to make a request it should have refused. MITRE ATT&CK records this exact move against the metadata API: adversaries may exploit a Server-Side Request Forgery vulnerability in a public facing web proxy to reach internal services.

This is the first edge in the graph. It rarely tops a severity report on its own, yet every later hop depends on this one being possible. Remove it and the path never begins.

Credential theft at the metadata service

Here is what the relay reaches. Every EC2 instance can query a small internal service for facts about itself, the instance metadata service, at a fixed link-local address. Among the things it returns are the temporary credentials for the IAM role attached to the instance. Those credentials are how the machine calls the rest of your cloud without a stored password.

The attacker points the forged request at the metadata address and reads the role's access key, secret, and session token straight out of the response. MITRE ATT&CK states the technique plainly: adversaries may attempt to access the Cloud Instance Metadata API to collect credentials from cloud instances.

This is not theory. In the 2019 Capital One breach the same two hops, an SSRF bug reaching the metadata service, turned a request-forgery flaw into stolen role keys, and those keys reached more than one hundred million customer records.

The lesson of this hop is that "internal" was never a boundary. Anything that can make a request from the instance, including a request the attacker forced, can read the credentials the instance was trusted with. The foothold now carries an identity, and the attacker stops being an outsider.

Escalation: assume-role and one over-scoped permission

Holding the instance role's credentials, the attacker is now that role to your control plane, acting with exactly its permissions. The first move is reconnaissance that looks identical to a legitimate automation script: list the role's policies, list other roles, and check what this identity is allowed to assume.

Roles in Amazon Web Services can hand their permissions to whoever is trusted to take them, through sts:AssumeRole. If the compromised role is trusted by a stronger role, the attacker requests that trust and steps into the stronger identity. Each assume-role is another edge, another node reached.

Sometimes no second role is needed, because the current identity can grant itself more power. Rhino Security Labs catalogued twenty-one distinct ways a single over-scoped permission lets a low-privileged identity become administrator. Two are enough to show the shape. With iam:PassRole, the attacker passes a powerful role to a machine or function they control, and that resource runs with the powerful role's rights. With iam:CreatePolicyVersion, the attacker writes a fresh policy version that grants everything and sets it as the default, because they were allowed to edit policies.

On paper each was one checkbox in a permission set. In the graph each is an edge that jumps the attacker from limited to unlimited, and the account did nothing it was not configured to allow.

Exfiltration without an alarm

Now the path reaches what it came for. With administrative rights, or just the narrow rights the sensitive data requires, the attacker enumerates storage, lists the S3 buckets, finds the one holding customer data, and reads it.

There is no alarm in the act itself. The credentials are valid and the API calls are the same ones your own services make every day. If the objects are encrypted, the same identity usually holds the key to decrypt them, so encryption at rest stops nothing on this route. The attacker copies the objects to storage they control and the path is complete.

Trace it backward and every hop was small: a fetch feature, a metadata read, a role assumption, a policy edit, a bucket list. Not one of them alone would top a severity report. Joined end to end, they moved an anonymous internet request into a copy of your most sensitive records.

Break one link: least privilege and IMDSv2

Because the path is a chain, you do not have to fix every link. You have to break one well-chosen link, and everything after it falls.

The credential-theft hop needed the metadata service to hand a role's keys to a forged request. Amazon Web Services already ships the fix. IMDSv2 uses session-oriented requests: the caller must first send a PUT request to obtain a token, then include that token in every metadata read. A blind SSRF that can only issue a GET cannot perform the PUT step, so requests without a valid token receive a 401 — Unauthorized response. The SSRF still fires, but it comes back empty, and the seven hops that followed never start.

That is the real shape of least privilege. It is not one wall at the perimeter. It is a boundary at every hop that assumes the previous hop has already fallen. Give the instance role only the permissions it truly uses and the assume-role step finds nothing to take. Deny pass-role and create-policy-version to anything that does not need them and the escalation edge disappears from the graph.

Map the graph before an attacker does

The takeaway changed how defenders work. Ranking findings in isolation misses the routes that matter, so teams began computing the same graph the attacker would and walking it backward from sensitive data until an edge touches the internet. Any route you find is a route they can find.

Modern cloud security tools draw those graphs across a whole account and rank the edges that the most paths share, so you can cut the one link that collapses many routes at once. That is the highest-value work: not clearing the longest list, but finding the choke points.

A cloud attack path is a chain of small, legal steps. Your job is to make sure the chain never connects. Find your paths first, break the shared links, enforce IMDSv2 and least privilege, and the exposed edge at the perimeter leads nowhere.

Source: Cloud Instance Metadata API, MITRE ATT&CK T1552.005.