Cloud Metadata Service Exploitation: IMDSv1’s Open Door to AWS Credentials ☁️

Introduction: The Hidden Gateway to Your Cloud Kingdom

In the cloud security landscape, few vulnerabilities remain as persistently exploited yet fundamentally preventable as AWS Instance Metadata Service version 1 (IMDSv1). Despite being introduced over a decade ago as a convenience feature for EC2 instances, IMDSv1 has become what security researchers call the “skeleton key” to AWS environments—a seemingly innocuous service that, when exploited through Server-Side Request Forgery (SSRF) attacks, hands attackers complete access to temporary IAM credentials, instance metadata, and potentially your entire cloud infrastructure.

The stakes couldn’t be higher. The infamous 2019 Capital One breach, which exposed over 100 million customer records and resulted in an $80 million fine, wasn’t the result of a sophisticated zero-day exploit or advanced persistent threat. It was a straightforward SSRF attack targeting IMDSv1—a vulnerability that Amazon Web Services had known about since at least 2018. Yet as of December 2024, only 32% of EC2 instances have migrated to the more secure IMDSv2, leaving the vast majority of cloud infrastructure exposed to the same attack vectors that devastated Capital One.

This comprehensive guide investigates how SSRF attacks exploit cloud metadata endpoints, why the AWS metadata service remains a critical target for credential theft and privilege escalation, and what organizations must do to protect their cloud infrastructure before becoming the next headline.

Understanding the Instance Metadata Service: Convenience Meets Vulnerability

What is IMDS and Why Does It Exist?

The AWS Instance Metadata Service is an API endpoint accessible from within EC2 instances at the special link-local IP address 169.254.169.254. This address is intentionally non-routable across the internet, meaning only software running directly on an EC2 instance can access it—or so the design intended.

IMDS was created to solve a fundamental cloud security challenge: how do applications running on EC2 instances securely access AWS resources without hardcoding credentials? The service provides a elegant solution by making temporary, frequently rotated IAM credentials available locally to the instance, eliminating the need to embed sensitive access keys in application code or configuration files.

Beyond credentials, IMDS exposes critical instance metadata including:

• Instance ID, AMI ID, and instance type
• Network configuration (IP addresses, security groups, subnets)
• IAM role name and associated temporary credentials
• User data and initialization scripts
• Block device mappings and storage information

This metadata enables applications to self-configure, authenticate with AWS services, and adapt to their environment dynamically—a powerful capability that has become foundational to modern cloud architecture.

The Fatal Flaw: IMDSv1’s Request-Response Architecture

IMDSv1 operates on a simple request-response model that requires only HTTP GET requests. Any process capable of making HTTP calls to 169.254.169.254 can retrieve instance metadata without authentication, session management, or authorization checks. This design includes several critical security assumptions:

1. Trust boundary assumption: The service assumes that any request originating from within the instance is legitimate
2. No authentication: IMDSv1 performs zero verification of the request origin
3. No session management: Each request is completely independent with no state tracking
4. No request validation: The service doesn’t distinguish between requests from legitimate applications versus exploitation attempts

These assumptions create what security researchers call an “unauthenticated information disclosure vulnerability”—but the reality is far more severe because the disclosed information includes complete AWS credentials.

Enter IMDSv2: Session-Oriented Security

In November 2019, four months after the Capital One breach, AWS released IMDSv2 with defense-in-depth protections specifically designed to mitigate SSRF attacks. IMDSv2 implements a session-oriented architecture requiring a two-step authentication process:

Step 1: Token Generation

PUT http://169.254.169.254/latest/api/token
X-aws-ec2-metadata-token-ttl-seconds: 21600

This PUT request generates a session token with a specified time-to-live (TTL) value between 1 second and 6 hours.

Step 2: Authenticated Requests

GET http://169.254.169.254/latest/meta-data/
X-aws-ec2-metadata-token: AQAAANpaYGqH...

All subsequent requests must include the token in the X-aws-ec2-metadata-token header.

This architecture effectively blocks SSRF exploitation because:

• Attackers must control both HTTP methods (GET and PUT)
• Attackers must inject custom HTTP headers
• The token-based approach prevents simple URL-based exploitation
• TTL limits reduce the window of opportunity even if tokens are compromised

Despite these robust protections and AWS making IMDSv2 the default for new Console Quick Start launches since November 2023, the transition remains incomplete. Research from Datadog’s 2024 State of Cloud Security report reveals that 68% of EC2 instances still don’t enforce IMDSv2, representing millions of potentially vulnerable instances across the AWS ecosystem.

Server-Side Request Forgery: The IMDS Exploitation Pathway

Anatomy of an SSRF Attack

Server-Side Request Forgery is a web application vulnerability that allows attackers to manipulate a server into making unintended HTTP requests to attacker-specified destinations. SSRF ranks among the OWASP Top 10 vulnerabilities and has been weaponized consistently against cloud metadata services since their introduction.

The fundamental issue is that many web applications accept user-supplied URLs as input—for URL preview features, webhook callbacks, document processing, image fetching, or API integrations—and then make HTTP requests to those URLs without proper validation. When these applications run on EC2 instances with IMDSv1 enabled, they become conduits for metadata service exploitation.

The IMDSv1 Attack Chain

The complete attack chain progresses through several distinct phases:

Phase 1: Reconnaissance Attackers begin by identifying EC2-hosted web applications through various techniques: - Analyzing DNS records and IP ranges - Identifying AWS infrastructure through headers, error messages, or response timing - Scanning for publicly accessible applications - Exploiting other vulnerabilities to gain initial foothold

Phase 2: SSRF Vulnerability Discovery Attackers probe for SSRF vulnerabilities by testing user input fields that might trigger server-side HTTP requests: - URL parameters in preview or fetch features - Webhook configuration endpoints - File upload mechanisms accepting URLs - XML external entity (XXE) injection points - Open redirect vulnerabilities - PDF generation services

Phase 3: Metadata Service Access Once an SSRF vector is identified, attackers craft requests targeting the metadata service:

https://vulnerable-app.com/preview?url=http://169.254.169.254/latest/meta-data/

The application dutifully fetches this URL and returns the metadata, revealing available information categories.

Phase 4: IAM Credential Extraction Attackers then enumerate IAM roles and extract credentials:

http://169.254.169.254/latest/meta-data/iam/security-credentials/
→ Returns: "ec2-production-role"

http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-production-role
→ Returns: {
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2024-12-08T01:23:45Z"
}

Phase 5: Credential Weaponization With valid AWS credentials, attackers configure the AWS CLI or SDK:

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

aws sts get-caller-identity
# Confirms identity and role

Phase 6: Privilege Escalation and Lateral Movement Depending on the IAM role’s permissions, attackers can: - List and access S3 buckets containing sensitive data - Enumerate other AWS resources - Launch additional EC2 instances - Modify security groups and network access controls - Access databases, secrets, and configuration data - Pivot to additional AWS accounts via role assumption

Real-World Exploitation: The Capital One Case Study

The 2019 Capital One breach provides the definitive case study in IMDSv1 exploitation. On March 22-23, 2019, an attacker (later identified as former AWS employee Paige Thompson) exploited a misconfigured web application firewall (WAF) running on EC2 instances. The attack methodology demonstrates how organizational failures compound technical vulnerabilities:

Technical Attack Path: 1. Identified ModSecurity WAF configuration allowing command execution 2. Exploited SSRF vulnerability in application behind the WAF 3. Accessed metadata service at 169.254.169.254 4. Retrieved IAM role named *****-WAF-Role 5. Extracted temporary credentials from the role endpoint 6. Used credentials to list S3 buckets via AWS CLI 7. Synced 700+ S3 buckets containing customer data (approximately 30GB) 8. Exfiltrated 106 million customer records including: - 140,000 Social Security numbers - 80,000 bank account numbers - 1 million Canadian Social Insurance numbers - Extensive personal information (names, addresses, credit scores, payment history)

The Compounding Failures: - WAF misconfiguration allowed unauthorized access to backend applications - SSRF vulnerability in web application went undetected - IMDSv1 provided unauthenticated credential access - Overly permissive IAM role granted broad S3 access - Lack of egress monitoring failed to detect large-scale data exfiltration - Detection took nearly four months (discovered July 19, 2019)

The Aftermath: - $80 million civil penalty from banking regulators - $50+ million in additional fines and settlements - Immeasurable reputational damage - Class action lawsuits from affected customers - Criminal prosecution of the attacker

AWS released IMDSv2 in November 2019, just months after the breach became public. The timing was not coincidental—the Capital One incident demonstrated conclusively that IMDSv1’s lack of defense-in-depth protections created unacceptable risk.

Active Exploitation Campaigns

The threat hasn’t diminished since 2019. Security researchers continue observing active campaigns targeting IMDS:

March 2025 Campaign: F5 Labs documented a coordinated campaign targeting websites hosted on EC2 instances, specifically exploiting SSRF vulnerabilities to access IMDSv1. The campaign utilized infrastructure from French and Romanian ASN 34534 (FBW NETWORKS SAS), demonstrating organized, persistent targeting of AWS metadata services.

UNC2903 Campaign (2021): Mandiant identified threat actor UNC2903 exploiting CVE-2021-21311 in the Adminer database management tool. The attackers used a relay box with 301 redirect scripts to trick victim servers into following redirects and exposing AWS API credentials via IMDS access.

Ongoing Vulnerability Research: HackerOne bug bounty reports consistently include IMDS-related vulnerabilities, including critical findings affecting organizations like the US Department of Defense and DuckDuckGo, underscoring that SSRF-to-IMDS attack chains remain viable and valuable to attackers.

Why IMDSv1 Remains a Critical Target

The Persistence Problem

Despite IMDSv2 being available since 2019 and becoming the default for new instances since November 2023, adoption remains alarmingly low. Multiple factors contribute to this persistence:

Legacy Infrastructure: Organizations running multi-year-old EC2 instances may never have revisited their metadata service configuration. These long-running instances continue using IMDSv1 unless manually migrated.

Software Compatibility: Older AWS SDKs, third-party libraries, and custom applications may not support IMDSv2’s token-based authentication, requiring code updates before migration is possible.

Organizational Inertia: Migrations require coordination across development, operations, and security teams. Without executive sponsorship or regulatory pressure, these initiatives get deprioritized behind feature development.

Knowledge Gaps: Many organizations lack awareness of the risks. Development teams focused on application functionality may not understand the infrastructure-level security implications.

Perceived Complexity: While AWS provides robust migration tools, the process still requires inventory, testing, and coordinated deployment—efforts that compete with other priorities.

The Privilege Escalation Multiplier

What makes IMDSv1 particularly dangerous is its role as a privilege escalation mechanism. A relatively minor SSRF vulnerability in a low-privilege web application can instantly provide attackers with the full permissions of the instance’s IAM role. This creates scenarios where:

• A simple URL preview feature becomes a gateway to production databases
• A webhook testing endpoint exposes S3 bucket contents
• A file processing service grants access to secrets management systems
• A developer tool provides administrative AWS access

The security boundary collapses because the metadata service doesn’t distinguish between legitimate application code and attacker-controlled requests.

The Credential Theft Sweet Spot

From an attacker’s perspective, IMDSv1 exploitation offers unique advantages:

No Authentication Required: Unlike most credential theft techniques, accessing IMDSv1 requires no passwords, API keys, or authentication tokens.

Temporary But Sufficient: While the credentials are temporary (typically valid for 6-12 hours), this window provides ample time for reconnaissance, data exfiltration, and lateral movement.

Difficulty in Detection: Credential access via IMDS appears as normal instance behavior, making it challenging to distinguish from legitimate application traffic without specialized monitoring.

Audit Challenges: IMDSv1 provides no native logging or auditing capabilities. Organizations often lack visibility into which processes are accessing the metadata service and when.

Policy Context Keys: Credentials retrieved via IMDSv1 include the context key ec2:RoleDelivery: "1.0", which can be used in IAM policies to restrict their usage—but only if organizations have implemented such policies, which most haven’t.

Detection and Migration Strategies

Identifying IMDSv1 Usage

Organizations must first understand their current IMDSv1 exposure before implementing protections. AWS provides several detection mechanisms:

AWS Console Visibility: The EC2 console displays an “IMDSv2” column indicating each instance’s configuration. Instances showing “Optional” have IMDSv1 enabled, while “Required” indicates IMDSv2-only operation.

AWS Config Rules: The managed rule ec2-imdsv2-check continuously monitors instance metadata configurations and flags non-compliant instances in the AWS Config console.

AWS Security Hub: Control EC2.8 (“Amazon EC2 instances should use Instance Metadata Service Version 2”) provides centralized visibility across accounts and regions, with cross-Region aggregation and organizational consolidation capabilities.

CloudWatch Metrics: The MetadataNoToken metric tracks IMDSv1 call frequency per instance, helping identify which instances and applications are actively using the legacy service.

IMDS Packet Analyzer: This open-source AWS tool uses network packet capture to identify and log all IMDSv1 calls from an instance, pinpointing exactly which software needs updates.

Datadog Cloud Workload Security: Third-party solutions like Datadog’s CWS implement network detection rules that identify IMDSv1 calls in real-time, overcoming limitations of AWS’s native tooling.

The Migration Roadmap

Successful migration to IMDSv2 requires systematic planning and execution across three phases:

Phase 1: Assessment and Planning (Week 1-2)

1. Inventory Current State: Use AWS Config and Security Hub to identify all IMDSv1-enabled instances across all accounts and regions.

2. Analyze Application Dependencies: Deploy the IMDS Packet Analyzer on representative instances to identify which applications and libraries are accessing metadata.

3. Prioritize Critical Workloads: Begin with new deployments and non-production environments, then progress to production systems based on risk assessment.

4. Update Software Stack: Ensure AWS SDKs, CLIs, and frameworks support IMDSv2:

   • AWS CLI v2.x natively supports IMDSv2
   • AWS SDKs released after 2020 support IMDSv2
   • Update systems management agents (SSM, CloudWatch)
   • Test custom applications with token-based authentication

Phase 2: Gradual Enforcement (Week 3-8)

1. Enable IMDSv2 Support: Configure instances to support both versions while monitoring for issues:

   aws ec2 modify-instance-metadata-options \
   --instance-id i-1234567890abcdef0 \
   --http-tokens optional \
   --http-endpoint enabled
   

   1. Monitor Transition: Watch CloudWatch MetadataNoToken metrics to identify remaining IMDSv1 calls.
   2. Enforce IMDSv2: Once IMDSv1 usage drops to zero, enforce IMDSv2-only: bash aws ec2 modify-instance-metadata-options \ --instance-id i-1234567890abcdef0 \ --http-tokens required

2. Update Launch Templates: Modify EC2 launch templates and Auto Scaling group configurations to require IMDSv2 for new instances:

   {
   "MetadataOptions": {
   "HttpTokens": "required",
   "HttpPutResponseHopLimit": 1,
   "HttpEndpoint": "enabled"
   }
   }
   

   Phase 3: Enforcement and Prevention (Ongoing) 1. Implement Service Control Policies (SCPs): Prevent organization-wide IMDSv1 usage at the AWS Organizations level:

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

3. Block IMDSv1 Credentials: Use IAM policies to prevent credentials obtained via IMDSv1 from accessing sensitive resources:

   {
   "Version": "2012-10-17",
   "Statement": [{
   "Sid": "RequireIMDSv2Credentials",
   "Effect": "Deny",
   "Action": "*",
   "Resource": "*",
   "Condition": {
     "NumericLessThan": {
       "ec2:RoleDelivery": "2.0"
     }
   }
   }]
   }
   

   1. Automated Remediation: Deploy AWS Systems Manager automation documents like EnforceEC2InstanceIMDSv2 to automatically configure non-compliant instances.

   2. Continuous Monitoring: Maintain Security Hub rules and CloudWatch alarms to detect any regression to IMDSv1 configuration.

      Defense-in-Depth: Beyond IMDSv2

      While IMDSv2 addresses SSRF-based IMDS exploitation, comprehensive cloud security requires layered defenses: Application Security:

   • Implement robust input validation on all user-supplied URLs

   • Use allowlists for permitted domains rather than denylists

   • Deploy Web Application Firewalls with SSRF detection rules

   • Conduct regular security testing including SSRF vulnerability assessments IAM Least Privilege:

   • Grant EC2 instance roles only the minimum required permissions

   • Avoid wildcard permissions (e.g., s3:*, *:*)

   • Use resource-level permissions to limit access scope

   • Regularly audit and remove unused permissions Network Segmentation:

   • Implement security groups restricting outbound traffic

   • Use VPC endpoints for AWS service access instead of internet routing

   • Deploy network monitoring for unusual egress patterns

   • Consider blocking 169.254.169.254 at Layer 3 where appropriate Monitoring and Alerting:

   • Enable AWS CloudTrail for all API activity logging

   • Configure AWS GuardDuty for threat detection

   • Implement security information and event management (SIEM) integration

   • Create alerts for unusual metadata service access patterns

   • Monitor for large data transfers to external destinations Secrets Management:

   • Avoid storing sensitive data in S3 without encryption

   • Use AWS Secrets Manager or Parameter Store for secrets

   • Implement S3 bucket policies restricting access

   • Enable S3 bucket logging and monitoring

     Industry Lessons and Future Outlook

     The Shared Responsibility Reality

     The Capital One breach sparked intense debate about cloud provider versus customer responsibility. AWS maintains that the breach resulted from customer misconfigurations—the SSRF vulnerability, overly permissive IAM roles, and firewall configuration issues. Critics argue AWS knew about SSRF risks to IMDSv1 since 2018 but didn’t implement mitigations until after a major breach. The reality is nuanced: cloud security is genuinely shared. AWS provides the tools and secure-by-default configurations (like IMDSv2), but customers must actually use them. As Evan Johnson, Cloudflare’s former product security manager, noted: “There’s a lot of specialized knowledge that comes with operating a service within AWS, and to someone without specialized knowledge of AWS, [SSRF attacks are] not something that would show up on any critical configuration guide.” Organizations must recognize that cloud adoption requires security expertise that extends beyond traditional infrastructure. The assumption that following AWS documentation guarantees security is demonstrably false—you must understand the threat landscape, recognize architectural vulnerabilities, and proactively implement defense-in-depth.

     The Timeline Toward IMDSv2 Universality

     AWS has been steadily tightening IMDSv2 requirements:

   • November 2019: IMDSv2 released

   • November 2023: Console Quick Start launches default to IMDSv2

   • Mid-2024: Newly released EC2 instance types use IMDSv2 by default

   • Ongoing: AWS continues encouraging migration through documentation, tools, and account-level controls However, the transition remains voluntary for existing instances. AWS has not announced plans to force-migrate legacy instances to IMDSv2, likely due to concerns about breaking customer workloads. This means organizations bear responsibility for completing their own migrations.

     Learning from Other Breaches

     IMDSv1 exploitation isn’t unique to Capital One. Multiple organizations have suffered similar breaches, though many remain unreported due to settlement agreements or incomplete disclosure:

   • Financial institutions have quietly remediated SSRF-to-IMDS vulnerabilities after security assessments

   • Government agencies have hardened cloud infrastructure following successful penetration tests

   • Technology companies have discovered credential theft via IMDS during incident response investigations The pattern is consistent: SSRF vulnerabilities are common, IMDSv1 remains prevalent, and the combination creates critical risk.

     Conclusion: The Imperative for Action

     Six years after the Capital One breach, IMDSv1 remains a critical vulnerability affecting the majority of AWS infrastructure. Despite AWS providing robust mitigation through IMDSv2, widespread adoption has been slow, leaving organizations exposed to well-understood, actively exploited attack vectors. The security imperative is unambiguous: every organization running EC2 instances must migrate to IMDSv2 and disable IMDSv1 completely. This isn’t a “nice-to-have” security enhancement—it’s a fundamental requirement for cloud security hygiene equivalent to patching critical vulnerabilities or enforcing multi-factor authentication. The migration process requires effort, coordination, and testing, but the alternative is accepting the risk of becoming the next headline breach. The tools, documentation, and automation capabilities exist to make this transition manageable. The only missing ingredient is organizational commitment.

     Your Action Plan Starting Now

     This Week:

   • Run AWS Config rule ec2-imdsv2-check to inventory your current state

   • Enable AWS Security Hub control EC2.8 for continuous monitoring

   • Identify and prioritize critical workloads for migration This Month:

   • Deploy IMDS Packet Analyzer on representative instances

   • Update AWS SDKs, CLIs, and dependencies to IMDSv2-compatible versions

   • Begin enforcing IMDSv2 on non-production environments This Quarter:

   • Complete IMDSv2 migration for all production instances

   • Implement SCPs preventing new IMDSv1 instances

   • Deploy IAM policies blocking IMDSv1 credential usage

   • Conduct security testing to verify SSRF protections The cloud revolution promised security, scalability, and simplicity. The AWS metadata service delivered on that promise—but only if organizations use it securely. IMDSv1 was an acceptable design for 2012. In 2024 and beyond, it’s an unacceptable risk. The Capital One breach cost $150+ million and exposed 106 million records. Your organization’s breach will cost differently, but it will cost.

     The choice is yours: migrate to IMDSv2 proactively on your timeline, or reactively in the aftermath of a breach. History has shown which path is less painful.

     About the Author: This analysis is based on the latest security research, AWS documentation, and real-world incident reports as of December 2024. Organizations should consult with qualified cloud security professionals when implementing these recommendations. References: AWS Security Blog, Datadog Security Labs, Mandiant Threat Intelligence, OWASP Foundation, ACM Transactions on Privacy and Security