SSRF to Cloud Takeover: Anatomy of a Metadata Attack Chain

Server-Side Request Forgery sounds modest on paper: you trick a server into making a request it should not. In a cloud environment, that modest primitive is often one hop away from the keys to the entire account. The reason is a quiet endpoint that every major cloud runs on every instance, the metadata service, and the implicit trust that surrounds it.

This is a deep look at how an SSRF becomes a full cloud takeover, why the chain works, and the specific controls that break it. The canonical example is real and well documented, so we start there.

The canonical case: Capital One, 2019

In July 2019, Capital One disclosed that an attacker had stolen the personal data of over 100 million people in the United States and roughly 6 million in Canada. The mechanism was an SSRF.

The entry point was a misconfigured Web Application Firewall (a ModSecurity instance) running on an EC2 host. The attacker used the SSRF to make the WAF issue a request to the EC2 Instance Metadata Service (IMDS) at 169.254.169.254, retrieved the temporary IAM credentials attached to the WAF's role, and used those credentials to list and copy data from S3 buckets. Around 30 GB of customer data, much of it unencrypted, was exfiltrated. Capital One later paid an $80 million regulatory penalty and a $190 million class-action settlement.

Two design facts made this possible, and both are still common today:

1. The metadata endpoint required no authentication. Any process that could make an HTTP request from the instance could read the role's credentials.
2. The WAF's IAM role was overprivileged. It had read access to S3 buckets it never needed, so once the credentials leaked, the blast radius was enormous.

SSRF is now formally recognized as its own category in the OWASP API Security Top 10 (API7:2023), precisely because of chains like this one.

Why the metadata endpoint is the prize

Every cloud gives instances a link-local metadata service so software can discover its own configuration and, critically, fetch short-lived credentials for its assigned identity. Each provider exposes it differently:

The credentials returned are real, signed, and immediately usable against the cloud's APIs. They expire, but they do not need to last long. An attacker reads them, assumes the role, and acts within minutes.

This is what makes SSRF in the cloud different from SSRF on a flat network. On-premises, an SSRF reaches internal services. In the cloud, it reaches an identity provider that hands out credentials to anyone who asks from the right network position.

The attack chain, step by step

Rendering diagram

The full chain is short:

1. Find the SSRF. Common sources are any feature that fetches a URL: webhooks, link previews, PDF or image generators that take a URL, document importers, "fetch from URL" upload flows, and outbound proxies. Anything where user input becomes the target of a server-side HTTP request.
2. Aim at the metadata IP. The attacker supplies http://169.254.169.254/... (or the GCP or Azure equivalent) as the URL the server will fetch.
3. Read the role, then the credentials. On AWS IMDSv1 this is two unauthenticated GET requests.
4. Assume the identity. The returned AccessKeyId, SecretAccessKey, and Token are plugged into the cloud SDK or CLI.
5. Enumerate and escalate. With the role's permissions, the attacker lists buckets, reads secrets, queries databases, and looks for a path to broader access.

The chain is only as damaging as the role is privileged, which is why least privilege is a load-bearing control, not a nicety.

Bypasses that make SSRF filters fail

Naive defenses block the literal string 169.254.169.254. That is not enough. Attackers routinely defeat simple blocklists with:

• Alternate IP encodings. 2852039166 (decimal), 0xA9FEA9FE (hex), and 0251.0376.0251.0376 (octal) all resolve to the same address.
• DNS rebinding. The attacker controls a domain whose DNS record resolves to a safe IP at validation time and to 169.254.169.254 at request time, defeating any check that happens before the actual connection (a TOCTOU gap).
• Redirects. The supplied URL points at an attacker-controlled host that returns a 302 to the metadata endpoint. Filters that validate the original URL but follow redirects blindly are bypassed.
• Protocol smuggling. Where the fetcher allows it, gopher:// and file:// schemes reach services that plain HTTP cannot, including internal databases and the local filesystem.
• IPv6 and obscure literals. [::ffff:169.254.169.254] and similar forms slip past IPv4-only checks.

A robust defense must validate the resolved destination at connection time, not the input string at submission time.

Defenses that actually break the chain

Defense in depth here means cutting the chain at more than one link.

Enforce IMDSv2 and a hop limit (AWS). IMDSv2 requires a session token obtained with a PUT request carrying X-aws-ec2-metadata-token-ttl-seconds before any credential read. Most SSRF primitives can only issue GET requests, so they cannot complete the handshake. Just as important, IMDSv2 sets the response hop limit to 1 by default, so the credentials cannot traverse a forwarding proxy or container boundary. Set instance metadata options to HttpTokens: required. This single change would have stopped the Capital One chain at step 3.

Apply least privilege to instance roles. The role attached to an internet-facing component should grant only what that component needs. A WAF does not need read access to customer data in S3. Scope policies tightly, and prefer per-service roles over broad shared ones.

Block egress to the metadata IP from application code. Network policy or a local firewall rule that denies outbound traffic to 169.254.169.254 (and the GCP and Azure equivalents) from application processes removes the destination entirely.

Validate the request destination at connect time. Resolve the hostname, confirm the resolved IP is not link-local, private, or loopback, and pin that resolution through the actual connection to defeat rebinding. Disable or strictly limit redirects, and allow only the http and https schemes.

Use an allowlist, not a blocklist. If a feature only ever needs to reach a known set of hosts, allow exactly those and deny everything else. Allowlists do not suffer from the encoding and rebinding bypasses that sink blocklists.

How Breachline tests for this

SSRF is a class where point-in-time scanners frequently report nothing, because the vulnerability lives in how an endpoint handles a URL parameter under adversarial input, not in a signature. When Nebula encounters a parameter that influences a server-side request, it systematically tests the full chain: internal and loopback targets, the cloud metadata endpoints for AWS, GCP, and Azure, encoded and rebinding variants, redirect following, and protocol smuggling. Because it reasons about the chain rather than matching a pattern, it can demonstrate the realistic impact, reaching the metadata service and proving credential exposure, rather than flagging a theoretical issue and moving on. That is the difference between knowing you have an SSRF and knowing it leads to account takeover.

Takeaways

• In the cloud, SSRF is rarely the end of the story. The metadata service turns it into credential theft and, with an overprivileged role, full account compromise.
• Enforce IMDSv2 with a hop limit of 1. It is low effort and breaks the most common version of this chain outright.
• Defend at multiple links: least-privilege roles, egress controls to the metadata IP, and connect-time destination validation that resists encoding and DNS rebinding.
• Test SSRF for real impact, not just presence. The question that matters is what the forged request can reach.

Sources

• OWASP API Security Top 10: API7:2023 Server-Side Request Forgery
• Capital One breach case study
• Hacking the Cloud: Steal EC2 Metadata Credentials via SSRF
• AWS: Use IMDSv2
• Wiz Academy: Server-Side Request Forgery