Cloud Metadata Service Attacks Explained

📅 September 20, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single HTTP request to a non-routable IP address — 169.254.169.254 — has been responsible for some of the most damaging cloud breaches in the past decade. The 2019 Capital One breach, which exposed over 100 million customer records, was executed in part by exploiting a misconfigured Web Application Firewall that allowed a Server-Side Request Forgery (SSRF) attack to reach the AWS Instance Metadata Service (IMDS). The attacker retrieved temporary IAM credentials from that endpoint, pivoted laterally across S3 buckets, and exfiltrated data worth an estimated $80 million in regulatory fines and remediation costs. The metadata service, a utility designed to help cloud instances bootstrap themselves, had become a master key to an entire cloud environment. Understanding how these attacks work — and precisely how to stop them — is not optional for any organization running workloads in AWS, Azure, or GCP.

What the Cloud Metadata Service Actually Does

Every major cloud provider provisions virtual machine instances with a special internal HTTP endpoint that the instance itself can query to retrieve configuration information. This endpoint is accessible exclusively from within the running instance — or so the architecture intends. The service responds to unauthenticated GET requests with data that the instance needs to function: its hostname, network interfaces, instance ID, user data scripts, and critically, temporary security credentials attached to its IAM role or service account.

The Metadata Endpoint Across Cloud Providers

The implementation differs slightly across the three dominant hyperscalers, but the fundamental risk surface is consistent:

AWS IMDSv1, the original version, accepts any HTTP request from the instance without requiring session tokens. This is the version that made the Capital One breach possible. AWS subsequently released IMDSv2, which requires a session-oriented PUT request before metadata can be retrieved — a meaningful but frequently under-deployed improvement. A 2023 Datadog State of Cloud Security report found that approximately 36% of AWS EC2 instances still had IMDSv1 enabled, years after IMDSv2 became the recommended default.

What Attackers Actually Retrieve

The most dangerous data returned by metadata endpoints is the temporary security credential bundle: an Access Key ID, Secret Access Key, and Session Token. These credentials carry the full permissions of the IAM role attached to the instance. If that role has broad S3 read access, database permissions, or the ability to create new IAM principals — common in developer environments with overly permissive “Admin” roles — an attacker who successfully queries the metadata service gains a functional set of cloud API keys that are valid for hours.

The Attack Vectors: SSRF and Beyond

The metadata service only listens on a link-local address, which means it is not directly reachable from the internet. Attackers must therefore use the victim’s own infrastructure as a proxy. Server-Side Request Forgery is the dominant technique, but it is not the only one.

Server-Side Request Forgery (SSRF) in Depth

SSRF occurs when an attacker can cause a server-side application to make HTTP requests to an arbitrary destination of the attacker’s choosing. Common injection points include:

• URL-fetching features: PDF generators, image preview tools, URL validators, and webhook processors that fetch remote resources
• XML parsers with external entity resolution enabled (XXE): Can force outbound HTTP requests to arbitrary hosts
• Misconfigured reverse proxies and load balancers: Proxy pass rules that do not restrict internal network destinations
• Open redirect chains: An application that follows 301/302 redirects from user-controlled URLs can be redirected to 169.254.169.254
• PDF rendering engines: Tools like wkhtmltopdf, Headless Chrome, and PhantomJS are notorious for executing embedded JavaScript that can make internal HTTP requests

The attack sequence is deceptively simple. An attacker identifies an endpoint that fetches a URL — for example, a feature that generates a PDF preview of a webpage. They submit http://169.254.169.254/latest/meta-data/iam/security-credentials/ as the “page URL.” The application server fetches that address from its own network context, receives the role name in the response, makes a second request with the role name appended, and returns temporary credentials. The entire operation can take under 60 seconds.

Other Delivery Mechanisms

SSRF is not the only path. Container escapes from poorly isolated Kubernetes pods can grant access to the underlying node’s metadata endpoint. Compromised EC2 user data scripts — injected through supply chain attacks or misconfigured CI/CD pipelines that write to instance launch configurations — can be retrieved and modified. In GCP environments, the default Compute Engine service account historically had project editor privileges, meaning a single metadata credential retrieval on any instance in a project could yield near-total project control. Google has since deprecated this default, but legacy environments remain exposed.

Real-World Breach Anatomy: Capital One and Beyond

The Capital One incident of July 2019 remains the canonical case study. The attacker, a former cloud service provider employee, identified an SSRF vulnerability in a Capital One WAF misconfiguration. By crafting a request that caused the WAF instance to query the AWS metadata endpoint, the attacker retrieved the IAM role credentials attached to that WAF. Those credentials had s3:ListBuckets and s3:GetObject permissions across more than 700 S3 folder paths. Over a period of months, the attacker exfiltrated approximately 30 GB of data including names, addresses, credit scores, and partial Social Security numbers of over 100 million individuals in the US and Canada.

The breach was eventually discovered not through Capital One’s internal monitoring but because the attacker posted details to GitHub. This highlights a secondary failure: the absence of anomalous API call detection. AWS CloudTrail recorded every GetObject API call, but no alert was triggered on the unusual volume or unusual source identity of those calls.

Other Notable Incidents

Capital One is the most publicized case, but it is not isolated. The cybersecurity firm Palo Alto Networks’ Unit 42 documented a 2021 campaign by the threat group known as TeamTNT specifically targeting AWS and Azure metadata endpoints for credential harvesting at scale. The group automated SSRF scanning across exposed Kubernetes clusters and Docker APIs, harvesting credentials from metadata endpoints to fund cryptomining operations. Unit 42 estimated the group compromised over 50,000 cloud instances across the campaign. More recently, a 2024 incident involving a European financial services firm saw attackers chain an SSRF vulnerability in an internally deployed Jupyter notebook server with metadata credential theft to achieve lateral movement into their Azure SQL infrastructure — a route that bypassed perimeter network controls entirely because the requests originated from a trusted internal service identity.

Detection Strategies: Seeing the Attack in Progress

Detection of metadata service abuse is achievable, but it requires instrumentation at layers that many organizations neglect. The core challenge is that legitimate applications also call the metadata service — so raw volume is not a reliable signal by itself. Effective detection requires behavioral baselining and context-aware alerting.

Cloud-Native Logging and Anomaly Detection

AWS CloudTrail captures every API call made with credentials, including those obtained from the metadata service. Effective detection rules should monitor for:

• IAM credential use from geographic regions inconsistent with the instance’s region (e.g., credentials obtained from an EC2 in us-east-1 being used from an IP in Eastern Europe)
• Unusually high volumes of s3:GetObject or sts:GetCallerIdentity calls from instance profiles within short time windows
• API calls that occur outside the instance’s normal operational hours or involve service categories the instance role has never previously accessed
• Use of instance profile credentials from an IP address that is not the instance’s known public IP (indicating credential exfiltration and off-host use)

AWS GuardDuty provides several managed detection rules specifically for this threat class, including UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, which fires when instance credentials are used from an external IP. Azure Defender for Cloud and GCP Security Command Center offer analogous anomaly detections for their respective identity systems.

Application-Layer SSRF Detection

At the application layer, Web Application Firewalls should be configured with rules that block or alert on outbound request destinations matching 169.254.169.254, metadata.google.internal, and other internal link-local ranges. Modern WAF solutions including AWS WAF, Cloudflare WAF, and Imperva can enforce egress filtering at the application tier. Additionally, runtime application security tools (RASP) can intercept outbound HTTP calls from within the application process and enforce allowlists of permitted destinations.

Hardening the Metadata Service: Defense in Depth

Detection is necessary but insufficient. The stronger investment is in reducing the attack surface of the metadata endpoint itself and limiting the blast radius when credentials are successfully obtained.

Enforcing IMDSv2 and Equivalent Controls

For AWS environments, the most direct mitigation is mandatory enforcement of IMDSv2 across all EC2 instances. IMDSv2 requires a PUT request with a TTL-limited header to obtain a session token, which must then be included in all subsequent metadata requests. This breaks SSRF exploitation because most SSRF vulnerabilities only support GET requests — they cannot complete the two-step session initiation that IMDSv2 requires. Enforcement should be applied through:

• EC2 instance launch configurations: Set HttpTokens: required in instance metadata options at launch
• AWS Organizations Service Control Policies (SCPs): Deny ec2:RunInstances unless the request includes IMDSv2 configuration, preventing any team from launching IMDSv1-capable instances
• AWS Config Rules: Continuously audit existing instances for IMDSv1 enablement with automatic remediation lambdas

GCP’s equivalent control is enforcing the Metadata-Flavor: Google request header requirement, which is non-standard and therefore not typically issued by SSRF-vulnerable application code. Azure’s IMDS endpoint similarly requires a non-standard header (Metadata: true) that provides a comparable SSRF break.

Least Privilege IAM and Credential Scope Reduction

Even if an attacker successfully obtains metadata credentials, their impact is constrained by what those credentials can do. The principle of least privilege applied to instance IAM roles is the most durable mitigation. Specific guidance:

• Restrict S3 permissions to specific bucket ARNs and required actions — never s3:* or resource: *
• Use IAM Condition keys to restrict credential use to specific VPC endpoints or source IP ranges where technically feasible
• Reduce credential TTLs for sensitive roles using aws:TokenIssueTime conditions
• Audit instance roles quarterly using AWS IAM Access Analyzer to identify unused permissions that can be removed
• For containerized workloads, use Kubernetes service accounts bound to specific namespaces rather than relying on node-level instance profiles

Cloud Security Posture Management and Continuous Validation

No point-in-time hardening effort survives the entropy of an active cloud environment. Teams deploy new instances, engineers override launch configurations for “temporary” testing, and new services introduce novel SSRF vectors. Cloud Security Posture Management (CSPM) platforms provide continuous visibility into metadata service configurations, IAM role permissions, and related misconfigurations across multi-cloud environments.

Tools in this category — including Wiz, Orca Security, Prisma Cloud, and open-source options like CloudSploit — continuously inventory every EC2 instance, Azure VM, and GCP Compute Engine node for metadata service hardening state. They map IAM permissions to identify roles with excessive privilege relative to actual usage, and they surface SSRF-exploitable application configurations through integration with cloud-native security services. A 2025 Gartner survey found that organizations deploying CSPM platforms detected cloud misconfigurations 74% faster than those relying solely on manual review and native cloud tooling.

Red Team Validation of Metadata Attack Paths

Purple team exercises specifically targeting SSRF-to-metadata attack chains are underutilized in most enterprise security programs. Effective exercises should include attempting SSRF exploitation against internal applications running on cloud instances, verifying that IMDSv2 enforcement actually blocks the credential retrieval, testing that CloudTrail alerts fire correctly when test credentials are used from unauthorized locations, and validating that IAM boundaries prevent lateral movement even when test credentials are obtained. Tools like Pacu (an AWS exploitation framework), ScoutSuite, and Metabadger (specifically designed for IMDSv2 assessment) support structured testing of these attack paths in authorized environments.

Key Takeaways

• The metadata service is a high-value target by design: It was built to provide instance credentials conveniently, which makes it an ideal target for any attacker who can route a request through the instance. Treat access to this endpoint as equivalent to access to your cloud API keys.
• IMDSv2 enforcement is non-negotiable for AWS: With 36% of EC2 instances still running IMDSv1 as recently as 2023, most organizations have material exposure. Enforce IMDSv2 via SCPs at the organization level — not just as a recommendation.
• SSRF is the primary delivery mechanism, but the application layer is the real vulnerability: Any application that fetches user-controlled URLs, processes XML with external entity resolution, or renders remote content is a potential pivot point. Secure the application before hardening the metadata endpoint.
• Detection must combine cloud API telemetry with behavioral baselining: Raw logging without alert logic is insufficient. GuardDuty, Defender for Cloud, and SCC provide actionable detections, but they must be enabled, tuned, and connected to incident response workflows.
• Least privilege is the blast radius limiter: When a breach occurs — and the statistical reality is that it will — the difference between a contained incident and a catastrophic data loss event is almost always determined by how much the compromised credentials could actually do. Audit and shrink IAM permissions continuously.

Conclusion: Operationalizing Your Metadata Security Posture</h2

---

💡 Enjoyed this article?

Subscribe for more expert insights delivered to your inbox.

Follow us or subscribe below xe2x80x94 free, no spam.