The AWS Metadata Attack (IMDS) Deep Dive

This post is about one specific cloud target that turns a medium bug into a CRITICAL: the metadata service. It's the reason SSRF is so scary in the cloud, and it's the mechanism behind the Capital One breach. Let me demystify it.

The Setup: What Is IMDS?

When a company runs a server on AWS (an EC2 instance), that server needs a way to know things about itself — its config, and importantly, its temporary CREDENTIALS for accessing other AWS services. AWS provides this through the Instance Metadata Service (IMDS), reachable from INSIDE the server at a special address:

http://169.254.169.254/

That address is magic: it only works from ON the server, and it returns metadata — including, at certain paths, the temporary AWS credentials the server uses. (Azure and GCP have their own metadata endpoints too.)

Why This Is A Critical Primitive

Here's the chain that makes hunters drool:

1. You find an SSRF (you can make the server fetch a URL you choose — remember post 5?)
2. You point that SSRF at 169.254.169.254
3. The metadata service returns the server's AWS credentials
4. You now have keys to access the company's AWS — storage, databases, more
5. Depending on the role's permissions → potential full cloud takeover

That's how a "medium" SSRF becomes a "critical" cloud breach. The metadata service is the bridge.

IMDSv1 vs IMDSv2

This is the key modern detail:

• IMDSv1 (old): responds to ANY request that reaches it. If you have SSRF, you just ask and it hands over credentials. This is what made Capital One possible.
• IMDSv2 (new, hardened): requires a special token obtained via a PUT request first, with headers that are hard to forge through a basic SSRF. AWS built it specifically to kill this attack.

So on modern targets, if IMDSv2 is enforced, the simple version won't work — you'll need a more capable SSRF (one that can send PUT requests and custom headers) or you'll find it's blocked. But PLENTY of servers still run IMDSv1 or allow both. Always test it.

How To Hunt It

1. Find an SSRF (URL-fetch feature, webhook, PDF generator, "import from URL")
2. Confirm it by pointing at your own listener first
3. Point it at 169.254.169.254/latest/meta-data/
4. If blocked, try bypasses (alternate IP encodings, redirects) — see post "The SSRF I Almost Didn't Report"
5. If you reach credentials paths, you've got a critical — verify minimally, DON'T go rummaging through their whole cloud, and report fast
6. Getting cloud credentials is serious — prove the exposure, don't exploit deeper than needed