Category: Attack Techniques
Instance Metadata Attacks
Also known as: IMDS Abuse, Cloud Metadata Abuse, Instance Metadata Service Exploitation
Simply put
Instance metadata attacks target a cloud service that provides running virtual machines with configuration details and credentials about themselves. Attackers exploit weaknesses in how applications or network controls handle requests to this internal service, typically by abusing vulnerabilities in web applications to redirect requests toward it. If successful, attackers can retrieve temporary cloud credentials and use them to access other cloud resources.
Formal definition
Instance metadata attacks exploit the cloud provider Instance Metadata Service (IMDS), an HTTP endpoint typically accessible at a link-local address from within a compute instance, to retrieve sensitive data including temporary IAM credentials, instance identity documents, and configuration parameters. The most common exploitation vector is Server-Side Request Forgery (SSRF), where a vulnerable application hosted on the instance can be manipulated into issuing HTTP requests to the IMDS endpoint on behalf of the attacker. Additional vectors include remote code execution and unvalidated HTTP requests made by application logic. Retrieved temporary credentials may then be used for lateral movement or privilege escalation within the cloud environment. Mitigations include enforcing IMDSv2 (which requires session-oriented requests with PUT-based token retrieval, raising the bar for SSRF exploitation), restricting metadata endpoint access via host-based firewall rules, and applying least-privilege IAM policies to instance roles. Notably, IMDSv1, which accepts simple GET requests without session tokens, is particularly susceptible to SSRF-based exploitation and has been observed in active threat campaigns targeting AWS EC2 environments.
Why it matters
Instance metadata attacks represent a critical risk in cloud environments because a single exploitable vulnerability in a web application can lead directly to the compromise of cloud credentials and, from there, broader access to cloud resources. The Instance Metadata Service was designed for convenience, providing running instances with the configuration details they need, but its accessibility from within the instance creates a high-value target when application-layer controls are absent or insufficient. Because the credentials retrieved from IMDS are temporary but fully functional, attackers who obtain them can move laterally across cloud environments, access sensitive data stores, or escalate privileges before the credentials expire.
Who it's relevant to
Cloud Security Engineers
Cloud security engineers are responsible for configuring compute instances in ways that reduce metadata exposure. This includes enforcing IMDSv2 across EC2 or equivalent instance fleets, applying host-based firewall rules to restrict which processes can reach the metadata endpoint, and auditing IAM instance role policies to ensure they follow least-privilege principles. Configuration drift or the use of older launch templates that default to IMDSv1 can reintroduce risk even in otherwise hardened environments.
Application Security Engineers
Application security engineers need to understand that SSRF vulnerabilities in cloud-hosted web applications are a direct pathway to credential theft via the IMDS. Secure code review and DAST tooling should specifically target SSRF patterns, including URL redirection, user-controlled request destinations, and unvalidated outbound HTTP calls. Remediating SSRF at the application layer is a necessary complement to infrastructure-level IMDS hardening, because neither control alone is sufficient.
Threat Detection and Incident Response Teams
Detection and response teams should monitor for anomalous use of temporary instance credentials outside expected service boundaries, which may indicate that IMDS credentials have been exfiltrated. Threat actors such as UNC2903 have been documented performing IMDS abuse as part of broader cloud intrusion campaigns, so familiarity with post-exploitation patterns following credential theft is important. Logs from cloud provider IAM and API services can reveal credential use from unexpected source IPs or regions.
DevOps and Platform Engineers
DevOps and platform engineers who manage instance launch configurations and infrastructure-as-code templates control whether IMDSv2 is enforced at provisioning time. Allowing IMDSv1 by default, or failing to pin metadata hop limits to a value of one, can expose instances to SSRF-based metadata retrieval even when application teams believe the application is otherwise secure. Embedding IMDS hardening into standard golden AMIs or Terraform modules helps ensure that protections are applied consistently across instance fleets.
Penetration Testers and Red Teams
Penetration testers targeting cloud-hosted applications routinely probe for SSRF vulnerabilities that could be chained into IMDS access. Testing should cover both IMDSv1 and IMDSv2 scenarios, since the version enforced on a given instance determines the complexity of exploitation required. Confirming whether retrieved credentials are scoped to least-privilege roles or carry broader permissions is an important part of demonstrating business impact during an assessment.
Inside Instance Metadata Attacks
Instance Metadata Service (IMDS)
A cloud provider endpoint, typically accessible at a link-local address such as 169.254.169.254, that supplies running instances with configuration data, credentials, and environment-specific information without requiring authentication by default in earlier versions.
IAM Credential Exposure
The primary risk vector in instance metadata attacks, where an attacker retrieves temporary or long-lived cloud credentials from the metadata endpoint and uses them to authenticate against cloud provider APIs for privilege escalation or lateral movement.
Server-Side Request Forgery (SSRF)
The most common technique used to reach the metadata endpoint from an attacker-controlled request, exploiting an application that makes outbound HTTP requests without adequately restricting the destination address to internal or link-local ranges.
IMDSv2 (Instance Metadata Service Version 2)
A session-oriented version of the metadata service that requires a PUT request to obtain a session token before retrieving metadata, providing defense against simple SSRF-based access by adding a required preflight step that many SSRF attack chains cannot complete.
User Data and Bootstrap Scripts
Instance metadata may include user data payloads containing initialization scripts, configuration parameters, or embedded secrets that were supplied at instance launch, which attackers can read to extract additional credentials or infrastructure details.
Metadata Endpoint Reachability
The network-level condition that allows the attack to succeed, specifically whether a workload or container can route traffic to the link-local metadata address. Blocking this route at the network or host level is a fundamental preventive control.
Container and Kubernetes Exposure
In containerized environments, metadata endpoint access may propagate to individual pods or containers unless explicitly blocked, expanding the attack surface beyond traditional virtual machine boundaries.
Common questions
Answers to the questions practitioners most commonly ask about Instance Metadata Attacks.
Does blocking the metadata endpoint at the network level fully protect against instance metadata attacks?
Not entirely. Network-level blocking can prevent direct access to the metadata endpoint, but it does not address all attack vectors. Server-Side Request Forgery (SSRF) vulnerabilities in application code may allow an attacker to route requests through the application itself, bypassing network controls that only filter external traffic. Defense requires layering network controls with application-level SSRF mitigations and use of IMDSv2 where available.
Is IMDSv2 a complete solution that eliminates instance metadata attack risk?
IMDSv2 significantly raises the bar by requiring a session-oriented request with a PUT-based token exchange, which mitigates many SSRF-based attacks that rely on simple GET requests. However, it does not eliminate all risk. Certain SSRF conditions that allow full HTTP request control, including custom headers, may still permit token retrieval. IMDSv2 should be treated as a strong compensating control rather than a standalone solution.
How should an application be configured to minimize its exposure to instance metadata attacks?
Applications should follow the principle of least privilege for IAM roles attached to instances, ensuring roles grant only the permissions required for the application's specific function. IMDSv2 should be enforced rather than left optional. Where possible, applications should avoid making outbound HTTP requests to user-controlled or user-influenced URLs, and any such requests should be validated against an allowlist of permitted destinations.
What controls can help detect or prevent SSRF exploitation of the metadata endpoint?
Controls typically include enforcing IMDSv2 on cloud instances, applying egress filtering to block application-layer requests to the link-local address range (169.254.0.0/16), implementing SSRF-aware input validation and URL parsing in application code, and using Web Application Firewalls configured to detect metadata endpoint patterns in request payloads. Each control addresses a different layer, and combining them reduces the likelihood of successful exploitation.
How can security teams test whether their applications are vulnerable to instance metadata attacks via SSRF?
Testing typically involves SSRF-focused dynamic application security testing (DAST) that attempts to reach the metadata endpoint through application request parameters. Static analysis (SAST) can identify code patterns where user input influences HTTP request destinations, though SAST cannot confirm exploitability without runtime context. Penetration testing in a controlled environment provides the most reliable confirmation, as it can validate whether the full credential retrieval chain is achievable given the application's actual network and IAM configuration.
What should an organization do if instance metadata credentials are confirmed to have been exfiltrated?
The immediate response should include revoking or rotating the affected IAM role credentials and reviewing CloudTrail or equivalent audit logs to determine what actions were taken using the compromised credentials. The instance should be isolated for forensic review if operational constraints permit. The SSRF or other vulnerability that enabled access should be remediated before the instance or role is returned to service. Post-incident review should assess whether credential scope was appropriately limited and whether monitoring alerts were triggered during the event.
Common misconceptions
Enforcing IMDSv2 fully eliminates instance metadata attack risk.
IMDSv2 raises the bar by requiring a session token obtained via a PUT request, which blocks many simple SSRF scenarios. However, it does not eliminate risk in cases where the SSRF vulnerability allows the attacker to perform the PUT preflight step, where misconfigured proxies forward arbitrary headers, or where the application itself fetches and exposes metadata content after legitimately authenticating to the service.
Instance metadata attacks only affect virtual machines and do not apply to containerized workloads.
Containers running on cloud instances can typically reach the metadata endpoint unless network-level controls or admission policies explicitly block access. In Kubernetes environments without appropriate node-level or network policy restrictions, compromised pods may access instance credentials belonging to the underlying node.
Static analysis or SAST tools can reliably detect instance metadata attack exposure in application code.
Static analysis can identify patterns such as user-controlled URLs being passed to HTTP client calls, which represent potential SSRF conditions, but it cannot determine at the code level whether the deployment environment exposes a metadata endpoint, whether network controls are in place, or whether IMDSv2 is enforced. Confirming actual metadata endpoint reachability requires runtime or infrastructure configuration assessment.
Best practices
Enforce IMDSv2 on all cloud instances by requiring session-oriented token-based access and disabling IMDSv1 to reduce the effectiveness of simple SSRF-based metadata retrieval attempts.
Apply network-level controls, such as host firewall rules or container network policies, to block outbound traffic to the link-local metadata address (169.254.169.254) from workloads and containers that have no legitimate need to access instance metadata.
Restrict IAM roles attached to instances to the minimum permissions required for the workload, so that even if credentials are retrieved from the metadata endpoint, the blast radius of their misuse is limited.
Audit and remediate SSRF vulnerabilities in application code by validating and allowlisting outbound request destinations, preventing user-controlled or externally influenced input from directing requests to internal or link-local addresses.
Avoid storing secrets, credentials, or sensitive configuration values in instance user data, since user data is readable through the metadata endpoint and is not an appropriate secret storage mechanism.
In Kubernetes environments, use workload identity mechanisms and node-level metadata endpoint hop restrictions to ensure that pod-level workloads do not inherit instance credentials, and apply network policies to limit pod access to the metadata address.