AWS Metadata Service Exploitation: The Cloud’s Skeleton Key 🔑

How SSRF and Misconfigurations Expose IMDSv1, Giving Attackers Access to IAM Credentials and Your Entire AWS Kingdom

The cloud revolution promised security, scalability, and simplicity. Yet lurking within AWS’s infrastructure is a seemingly innocuous service that has become the skeleton key to countless cloud breaches: the Instance Metadata Service (IMDS). When exploited through Server-Side Request Forgery (SSRF) attacks and misconfigurations, IMDSv1 can hand attackers the keys to your entire AWS kingdom—complete with IAM credentials, instance metadata, and unfettered access to sensitive resources.

The most infamous example? The 2019 Capital One breach, where over 100 million customer records were exposed, resulting in an $80 million fine and immeasurable reputational damage. The attack wasn’t sophisticated—it exploited a well-understood vulnerability that many organizations continue to overlook today.

What is the AWS Instance Metadata Service?

The Instance Metadata Service is an API endpoint accessible from within AWS EC2 instances at the IP address 169.254.169.254. It provides crucial information that applications and services running on EC2 instances need to function properly, including:

Instance details: hostname, instance ID, network configuration
IAM role credentials: temporary access keys and session tokens
User data: custom scripts and configuration data
Security groups: network access rules

This service is essential for AWS operations. Applications use IMDS to retrieve temporary credentials associated with IAM roles, eliminating the need to hard-code AWS access keys into applications—a significant security improvement when used correctly.

IMDSv1 vs. IMDSv2: A Critical Security Divide

AWS offers two versions of the Instance Metadata Service, and understanding the difference between them is critical:

IMDSv1 (Legacy Version): - Uses simple request-response protocol - Requires only HTTP GET requests - No authentication or session management - Vulnerable to SSRF attacks - Still enabled by default on many instances

IMDSv2 (Secure Version): - Session-oriented with token-based authentication - Requires initial PUT request to generate session token - Token must be included in custom header (X-aws-ec2-metadata-token) - TTL-based protection against network-layer attacks - Effectively mitigates SSRF vulnerabilities

The problem? Despite AWS moving to make IMDSv2 the default for new instances since November 2023, research shows that as of 2022, approximately 93% of EC2 instances still don’t enforce IMDSv2. Countless organizations continue running IMDSv1, leaving themselves exposed to the same attack vectors that enabled the Capital One breach.

The Anatomy of an IMDS Exploitation Attack

To understand why IMDSv1 is so dangerous, let’s examine how attackers exploit it through SSRF vulnerabilities.

Step 1: Reconnaissance

Attackers begin by scanning for vulnerable applications running on AWS infrastructure. They look for: - Web applications with user input fields - Public-facing instances with exposed services - Applications that make HTTP requests based on user-supplied URLs - Misconfigured Web Application Firewalls (WAFs)

Step 2: Discovering SSRF Vulnerabilities

Server-Side Request Forgery occurs when an application can be tricked into making HTTP requests to unintended destinations. Common vulnerable scenarios include:

URL parameters: Applications that fetch content from user-supplied URLs
Image processors: Services that download and process images from external sources
Webhook implementations: Systems that call back to user-specified endpoints
PDF generators: Tools that render web content to PDF format
File upload features: Applications that process uploaded files containing external references

Step 3: Accessing the Metadata Service

Once an SSRF vulnerability is identified, attackers exploit it to access the metadata endpoint:

# Direct access to IMDS (only works from within EC2 instance)
curl http://169.254.169.254/latest/meta-data/

# Through SSRF vulnerability in vulnerable application
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

Step 4: Extracting IAM Credentials

The real prize is the IAM role credentials:

# List available IAM roles
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Retrieve credentials for specific role
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

This returns JSON data containing: - AccessKeyId: AWS access key - SecretAccessKey: AWS secret key - Token: Session token - Expiration: When credentials expire

Step 5: Using Stolen Credentials

With these credentials, attackers can: - List and access S3 buckets containing sensitive data - Launch new EC2 instances for crypto-mining or further attacks - Modify security groups and network configurations - Access databases and other AWS services - Exfiltrate data to external locations - Establish persistence mechanisms

Real-World Impact: The Capital One Breach

The 2019 Capital One breach exemplifies the devastating potential of IMDS exploitation. Here’s what happened:

The Attack Timeline: - March 22-23, 2019: Paige Thompson, a former AWS employee, exploited an SSRF vulnerability in Capital One’s Web Application Firewall - Vulnerability Exploited: A misconfigured WAF component allowed SSRF attacks to reach the metadata service - Credentials Stolen: Thompson obtained temporary AWS credentials from the EC2 instance’s IAM role - Data Accessed: Using the stolen credentials, she listed over 700 S3 buckets and downloaded approximately 30GB of data - July 19, 2019: Breach discovered after Thompson bragged about it on GitHub and IRC channels

The Damage: - 106 million customer records exposed (100 million US, 6 million Canadian) - 140,000 Social Security numbers compromised - 80,000 bank account numbers leaked - 1 million Canadian Social Insurance Numbers exposed - Personal information including names, addresses, credit scores, and transaction data - $80 million fine from regulatory authorities - $150 million+ total cost including remediation and lost trust - Severe reputational damage and stock price decline

The Root Causes: 1. SSRF vulnerability in the WAF application 2. IMDSv1 in use instead of the more secure IMDSv2 3. Overly permissive IAM roles with broad S3 access 4. Unencrypted data stored in S3 buckets 5. Insufficient monitoring leading to four-month delay in detection

The most troubling aspect? This attack required no sophisticated techniques—just exploitation of well-understood vulnerabilities that should have been mitigated.

Recent Exploitation Campaigns and Emerging Threats

IMDS exploitation isn’t confined to history books. Active campaigns continue to target vulnerable AWS infrastructure:

March 2025 Campaign

Security researchers detected a novel campaign targeting websites hosted on EC2 instances through SSRF vulnerabilities. The campaign primarily exploited:

CVE-2017-9841: PHPUnit Remote Code Execution (15x more active than second-place CVE)
CVE-2024-4577: Showing sustained upward activity trends
CVE-2019-9082: Steady increase in exploitation attempts

The campaign originated from IP addresses belonging to ASN 34534 (FBW NETWORKS SAS), with attack infrastructure based in France and Romania. Attackers used straightforward SSRF techniques to query IMDSv1 endpoints and extract credentials.

Pandoc CVE-2025-51591 Exploitation

In September 2025, security firm Wiz discovered attackers exploiting a vulnerability in Pandoc (a popular document converter) to target AWS IMDS. The vulnerability allowed attackers to include iframe elements with src attributes pointing to the metadata service.

The attack was ultimately unsuccessful due to enforcement of IMDSv2, demonstrating the critical importance of upgrading from the legacy version. However, the continued efforts show attackers actively seeking new SSRF vectors to exploit IMDS vulnerabilities.

UNC2903 Threat Actor

In June 2021, the threat group UNC2903 exploited a vulnerability in the Adminer database management tool using a clever redirect technique. They set up relay boxes with 301 redirect scripts to trick victim servers into following redirects that returned errors containing AWS API credentials. The harvested credentials provided access to victim AWS accounts.

Why IMDSv1 Remains a Critical Risk

Despite the availability of IMDSv2 since 2019, IMDSv1 continues to pose significant risks:

Technical Vulnerabilities

No Authentication Required: IMDSv1 uses unauthenticated GET requests, making it trivially easy to access once an SSRF vulnerability is found.

Request-Response Protocol: The simple request-response pattern makes it a perfect target for SSRF attacks, as attackers need only force the server to make HTTP GET requests.

No Header Requirements: Unlike IMDSv2, no custom headers are needed, making exploitation possible through even basic SSRF vulnerabilities.

Organizational Challenges

Legacy Systems: Long-running instances may have applications that only support IMDSv1, creating migration challenges.

Lack of Awareness: Many organizations don’t understand the security implications of running IMDSv1 versus IMDSv2.

Default Settings: While AWS has changed defaults for new instances, existing infrastructure often retains IMDSv1 compatibility.

Complex Environments: Large-scale AWS deployments may have thousands of instances, making comprehensive migration efforts daunting.

Detection and Identification

Before you can fix the problem, you need to identify where IMDSv1 is still in use:

Using AWS Console

Navigate to the EC2 dashboard and check the “IMDSv2” attribute column for each instance. Instances showing “Optional” have IMDSv1 enabled.

AWS Config Rules

Deploy the ec2-imdsv2-check AWS Config rule, which flags instances as NON_COMPLIANT if HttpTokens is set to “optional” (meaning IMDSv1 is enabled).

CloudWatch Metrics

Monitor the MetadataNoToken metric in CloudWatch, which tracks IMDSv1 calls. Zero values indicate the instance is ready to require IMDSv2 exclusively.

AWS Security Hub

Configure Security Hub with cross-Region and cross-account aggregation to identify IMDSv1-enabled instances across your entire AWS organization.

IMDS Packet Analyzer

Use AWS’s IMDS Packet Analyzer tool to pinpoint exactly which software components are making IMDSv1 calls, helping you prioritize updates.

Comprehensive Mitigation Strategies

Protecting against IMDS exploitation requires a multi-layered approach:

1. Enforce IMDSv2 Immediately

For New Instances:

# Launch instance with IMDSv2 required
aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.micro \
  --metadata-options HttpTokens=required,HttpPutResponseHopLimit=1

For Existing Instances:

# Require IMDSv2 on existing instance
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1

Using Terraform:

resource "aws_instance" "example" {
  ami           = "ami-xxxxx"
  instance_type = "t3.micro"
  
  metadata_options {
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

2. Implement IAM Role Least Privilege

Never assign IAM roles with broad permissions. Follow these principles:

Grant only the minimum permissions required for the instance’s function
Use specific resource ARNs instead of wildcards
Implement IAM condition keys to restrict credential usage
Regularly audit and scope down permissions using Access Advisor

Use IAM Condition Keys:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::sensitive-bucket/*",
    "Condition": {
      "StringEquals": {
        "ec2:RoleDelivery": "2.0"
      }
    }
  }]
}

This policy ensures only credentials retrieved via IMDSv2 can access the S3 bucket.

3. Disable IMDS When Unnecessary

For instances that don’t need IMDS access:

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-endpoint disabled

4. Implement Network-Level Protections

WAF Configuration: - Deploy AWS WAF with rules to detect and block SSRF attempts - Implement strict input validation - Monitor for suspicious patterns targeting metadata endpoints

VPC Security: - Use Security Groups to restrict outbound traffic - Implement network segmentation - Deploy VPC endpoints for AWS services to avoid internet routing

5. Secure Application Code

Input Validation: - Never trust user input when making HTTP requests - Implement allowlists for permitted domains - Reject requests to private IP ranges (including 169.254.x.x) - Validate and sanitize all URL parameters

URL Parsing:

from urllib.parse import urlparse

def is_safe_url(url):
    parsed = urlparse(url)
    
    # Block private IPs and metadata service
    blocked_ips = ['169.254.169.254', '127.0.0.1', 'localhost']
    if parsed.hostname in blocked_ips:
        return False
    
    # Allow only specific domains
    allowed_domains = ['trusted-domain.com']
    if parsed.hostname not in allowed_domains:
        return False
    
    return True

6. Enable Comprehensive Monitoring

AWS GuardDuty: Enable GuardDuty to detect unusual credential usage patterns and potential IMDS credential theft.

CloudTrail Logging: Monitor for: - Unusual API calls from EC2 instances - Credential usage from unexpected locations - Large data transfers to external destinations - Modifications to IAM roles and policies

AWS Security Hub: Aggregate findings across accounts and regions to maintain visibility into security posture.

7. Implement Service Control Policies

For AWS Organizations, enforce IMDSv2 at the organizational level:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotEquals": {
        "ec2:MetadataHttpTokens": "required"
      }
    }
  }]
}

This SCP prevents launching instances without IMDSv2 enforcement across your entire organization.

The Path Forward: Migration Best Practices

Transitioning from IMDSv1 to IMDSv2 requires careful planning:

Phase 1: Assessment (Weeks 1-2)

Inventory all EC2 instances across regions and accounts
Identify instances using IMDSv1
Document applications and services running on each instance
Assess software compatibility with IMDSv2

Phase 2: Testing (Weeks 3-4)

Update AWS SDKs, CLIs, and tools to versions supporting IMDSv2
Test applications in non-production environments with IMDSv2 enforced
Monitor MetadataNoToken metrics during testing
Identify and update custom scripts making IMDSv1 calls

Phase 3: Gradual Migration (Weeks 5-8)

Start with non-critical workloads
Enable IMDSv2 while keeping IMDSv1 optional
Monitor for issues over several days
Proceed to production workloads with proven compatibility

Phase 4: Enforcement (Week 9+)

Require IMDSv2 on migrated instances
Implement SCPs preventing IMDSv1 usage
Establish continuous monitoring
Document lessons learned and update runbooks

Software Compatibility

Modern AWS tools support IMDSv2: - AWS SDKs (all major languages) - AWS CLI v2 - AWS Systems Manager Agent - Amazon ECS Agent - Amazon Linux 2023 (IMDSv2-only by default)

For legacy applications, consider containerization or updating to compatible versions before enforcing IMDSv2.

Beyond AWS: Cross-Cloud Perspective

While this article focuses on AWS, similar metadata services exist in other cloud providers:

Google Cloud Platform: - Metadata service at 169.254.169.254 - Requires Metadata-Flavor: Google header - This header requirement provides SSRF protection similar to IMDSv2

Microsoft Azure: - Metadata service at 169.254.169.254 - Requires Metadata: true header - API version must be specified in URL

Oracle Cloud Infrastructure: - Metadata service with enhanced authentication - Multi-layered access controls

These providers implemented header-based protections earlier than AWS, highlighting the importance of defense-in-depth approaches.

Conclusion: Time to Act

The AWS Instance Metadata Service remains a critical attack surface that organizations cannot afford to ignore. While IMDSv1 provided a foundation for secure cloud operations when introduced in 2012, the evolving threat landscape has made it obsolete and dangerous.

The Capital One breach demonstrated that SSRF vulnerabilities combined with IMDSv1 create a perfect storm for attackers—one that resulted in over $150 million in damages and exposed 106 million customer records. Recent campaigns show attackers continue actively seeking SSRF vulnerabilities to exploit IMDS, with new attack vectors emerging regularly.

The good news: AWS provides robust mitigation tools through IMDSv2, and comprehensive security controls are available to protect your cloud infrastructure.

The bad news: The majority of organizations haven’t implemented these protections, leaving themselves vulnerable to the same attacks that have devastated others.

The imperative: Every day you run IMDSv1 is a day you’re handing potential attackers a skeleton key to your cloud kingdom. The Capital One breach happened in 2019—six years later, there’s no excuse for not implementing IMDSv2.

Action Items for Immediate Implementation

This Week: Inventory all EC2 instances and identify IMDSv1 usage
This Month: Deploy AWS Config rules and Security Hub for continuous monitoring
This Quarter: Complete IMDSv2 migration for all instances
Ongoing: Enforce IMDSv2 for all new instances via SCPs
Continuous: Monitor, audit, and improve IAM role permissions

The skeleton key to your AWS kingdom is lying in plain sight. Will you secure it before attackers find it, or will your organization become the next cautionary tale?

Additional Resources

Keywords: AWS IMDS, IMDSv1, IMDSv2, SSRF attacks, EC2 security, AWS metadata service, Capital One breach, cloud security, IAM credentials, instance metadata service, AWS security best practices, server-side request forgery, cloud exploitation, AWS vulnerability, EC2 credential theft