Login
ChallengesLearn
Scoreboard
Teams
SPNZ

LearnSsrfCloud Metadata Attacks
Ssrf·Lesson 3 of 8

Cloud Metadata Attacks

AWS IMDS, Azure IMDS, GCP metadata. The one URL that returns cloud credentials, access tokens, and infrastructure secrets — accessible from any compute instance.

Intermediate14 min
SSRFCloudMetadata
Loading lesson…
PreviousFinding SSRF in the WildNextInternal Network Pivot

© 2026 SPNZ.

Terms of ServicePrivacy PolicyCookie Policy

Cloud metadata services are the crown jewel of SSRF exploitation. Every major cloud provider exposes an HTTP endpoint at the link-local address 169.254.169.254 that returns instance metadata — including IAM role credentials. An SSRF that reaches this endpoint can grant the attacker the same permissions as the compromised compute instance.

What you'll be able to do
  • Explain how cloud metadata services work and why they exist at 169.254.169.254.
  • Retrieve IAM role credentials via the AWS, Azure, and GCP metadata endpoints.
  • Describe IMDSv2 and how it prevents the classic SSRF-to-metadata attack.
  • Analyse the Capital One 2019 breach from an IAM perspective.
Key terms
IMDS (Instance Metadata Service)
A service running on every cloud compute instance that exposes metadata — network config, SSH keys, user data, and IAM role credentials — via HTTP at 169.254.169.254.
IMDSv2
An improved version of the AWS metadata service that requires a session token (PUT request + TTL) before returning data. Prevents simple SSRF-to-metadata attacks that rely on a single GET request.
IAM role credential
Temporary access keys (AccessKeyId, SecretAccessKey, SessionToken) that the cloud provider assigns to the compute instance. An attacker with these keys has the same cloud API permissions as the instance.
What is it?

The link-local oracle

Every cloud compute instance — whether on AWS EC2, GCP Compute Engine, Azure VMs, or DigitalOcean droplets — has access to a metadata service at 169.254.169.254. This IP is a link-local address (169.254.0.0/16) that is not routable over the internet. It is only reachable from within the instance itself. The metadata service returns information about the instance: its hostname, network interfaces, SSH public keys, user data, and most importantly, the IAM role credentials if the instance is assigned an IAM role.

The classic SSRF-to-metadata attack is simple: find an SSRF vulnerability, send a GET request to http://169.254.169.254/latest/meta-data/, list the available metadata keys, find the IAM role, and retrieve the temporary credentials. On AWS, the full path is /latest/meta-data/iam/security-credentials/ROLENAME. The response is a JSON object with AccessKeyId, SecretAccessKey, and SessionToken — a full cloud API identity.

Azure uses the same IP but a different path: /metadata/instance?api-version=2021-02-01. GCP uses /computeMetadata/v1/with a Metadata-Flavor: Google header. In every case, the pattern is the same: one HTTP request, and the instance hands over its identity.

SSRF chain to cloud credentials
Mini Map
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
Try it

Cloud metadata shell

The terminal below simulates curl commands against an AWS metadata service. Run commands like curl http://169.254.169.254/latest/meta-data/ to explore available metadata keys, then navigate to the IAM credentials. Toggle safe mode to see how network-level blocking of the metadata IP stops the attack.

~/projects/cloud-shellprod
~/metadata-shell
curl metadata explorer · press Enter to run
Try: curl http://169.254.169.254/latest/meta-data/curl http://169.254.169.254/latest/meta-data/iam/curl http://169.254.169.254/latest/meta-data/placement/availability-zone
cloud-shell:~$ # Metadata explorer ready
$
Real-world relevance

Capital One — credentials from the metadata service

The Capital One 2019 breach is the definitive SSRF-to-metadata case study. The attacker exploited a WAF misconfiguration that allowed a modified Host header to route requests to the AWS metadata endpoint. The WAF's compute instance had an IAM role with permissions to list and read S3 buckets — a role designed for legitimate WAF operations that was far too permissive.

With a single curl to 169.254.169.254/latest/meta-data/iam/security-credentials/, the attacker obtained the WAF's IAM credentials and used the AWS CLI to enumerate S3 buckets. The role had ListBucket and GetObject on over 140 buckets. The attacker downloaded 140 GB of data over several months before being detected. The IAM role was not configured with least privilege — it had far broader access than the WAF needed.

AWS introduced IMDSv2 in response to this class of attack. IMDSv2 requires a PUT request with a TTL to obtain a session token, then uses that token for subsequent GET requests. A simple SSRF that only supports GET requests cannot complete the IMDSv2 handshake. However, IMDSv2 is optional — many workloads still run IMDSv1, and attackers can sometimes upgrade their SSRF to perform the PUT request if the vulnerability allows arbitrary HTTP methods.

Mitigation

Defending the metadata endpoint

Enable IMDSv2 on all compute instances and disable IMDSv1. This is the single most effective defence against SSRF-to-metadata attacks. At the network level, add egress firewall rules that block traffic to 169.254.169.254 from any application-tier instances that do not need metadata access.

bashvulnerable
# VULNERABLE - server-side fetch reaches metadata
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Returns IAM credentials in plaintext JSON

# SAFE - IMDSv2 requires a session token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/

# SAFE - block metadata IP at the network level
# AWS Security Group: deny egress to 169.254.169.254/32
# Kubernetes NetworkPolicy: deny egress to 169.254.0.0/16

Apply least-privilege IAM roles. The Capital One WAF role had access to far more S3 buckets than it needed. Regularly review and rotate role permissions. Use network policies to restrict which instances can reach the metadata service, and monitor for unexpected requests to 169.254.169.254 in VPC flow logs.

Further reading
  • AWS IMDSv2 Documentation(AWS)
  • GCP Metadata Service(Google Cloud)
  • Azure Instance Metadata Service(Microsoft Azure)
Key takeaways

What to remember

  • The metadata service at 169.254.169.254 returns IAM role credentials — the single most valuable SSRF target in any cloud environment.
  • AWS, GCP, and Azure all use the same IP but different paths and headers for their metadata services.
  • IMDSv2 prevents simple GET-based SSRF attacks by requiring a session token obtained via PUT.
  • Network-level egress rules blocking 169.254.169.254 provide a defence-in-depth layer.
  • Least-privilege IAM roles limit the blast radius even if metadata credentials are exfiltrated.

Knowledge check

0/3 answered · 0 correct

  1. 1.What does the AWS metadata service return at /latest/meta-data/iam/security-credentials/ROLENAME?

  2. 2.How does IMDSv2 defend against SSRF?

  3. 3.What was the IAM-related root cause that made the Capital One breach so damaging?