IMDS (Instance Metadata Service) emerges as a critical yet overlooked security weakness in cloud environments. Threat actors now exploit IMDS as a springboard to steal credentials, move laterally, and escalate privileges. Cloud architects designed this service to help applications retrieve credentials safely without embedding secrets in code. Hackers found ways to turn this convenience into a security nightmare.
Security differences between AWS IMDS versions stand out clearly. The original IMDSv1 accepts HTTP requests without authentication, which makes it an easy target for Server-Side Request Forgery (SSRF) attacks. IMDSv2 introduces a more secure session-oriented approach that demands token authentication. These differences matter a lot when you troubleshoot "no EC2 IMDS role found" errors that might point to security risks. Azure IMDS brings its own unique security challenges to the table. This piece explores IMDS fundamentals, attacker exploitation methods, and analytical insights that help detect suspicious activities in real-world scenarios. The quickest way to enforce stronger security policies lies in IMDS automation across your cloud infrastructure.
Understanding IMDS in Cloud Environments
Cloud platforms depend on Instance Metadata Service (IMDS), which is a vital component to manage infrastructure securely. A good grasp of this service helps you understand how attackers target cloud environments and develop better defensive strategies.
What is IMDS and how it works in AWS, Azure, and GCP
The Instance Metadata Service gives you everything you need to know about running virtual machine instances in major cloud platforms. Each provider has its own way of implementing IMDS, but they all follow similar architectural principles. Virtual machines in AWS, Azure, and GCP can get information about themselves without external API calls or hardcoded credentials.
IMDS has several uses:
- Providing VM configuration details like region, availability zone, and subnet information
- Offering access to security group configurations
- Supplying temporary credentials for cloud service access
- Enabling retrieval of user-supplied data passed at instance launch time
IMDS works differently from regular APIs. It operates inside the host system, and communication between the VM and metadata service stays within the host environment. This creates a self-contained information system. But this isolation doesn't make IMDS secure by default - any process running on the VM can access the service without authentication.
Temporary credentials via 169.254.169.254 endpoint
Cloud providers use a standard non-routable IP address for the IMDS endpoint: 169.254.169.254. AWS Nitro-based instances also offer an IPv6 option at fd00:ec2::254. This standardization makes it easy to find the target for both legitimate applications and attackers.
Applications get temporary credentials from this endpoint instead of storing hardcoded secrets to access cloud resources. AWS applications can get security credentials from /latest/meta-data/iam/security-credentials/role-name. The service returns temporary credentials with an access key, secret key, and session token that expire after a set time.
These credentials look like this:
{
"AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token": "token",
"Expiration": "2017-05-17T15:09:54Z"
}
Cloud providers limit the rate of metadata requests to prevent abuse. AWS allows only 5 requests per second for each VM instance, which helps balance availability and protection.
Differences between IMDSv1 and IMDSv2
IMDSv1, the original version, accepts simple HTTP GET requests without any authentication. This makes it easy to use but creates security problems, especially with Server-Side Request Forgery (SSRF) attacks.
IMDSv2 fixes these issues with session-based authentication and better security:
- Session token requirement: You need to get a token through HTTP PUT before accessing metadata
- Method restriction: Token requests must use PUT instead of GET, which reduces SSRF attack risks
- Header protections: IMDSv2 won't accept requests with X-Forwarded-For headers
- TTL limitations: Session token packets have a TTL of 1, so they can't leave the EC2 instance
These changes make attacks much harder. IMDSv2 sessions can last up to six hours, giving you both security and convenience. The session token stops working if the requesting process ends, adding another security layer.
Security experts strongly recommend using IMDSv2 whenever possible because many attack techniques target the weaker IMDSv1.
Common Exploitation Techniques Targeting IMDS
Attackers often target cloud environments by exploiting the Instance Metadata Service (IMDS). They steal credentials and gain unauthorized access. Their techniques have become more sophisticated, and security teams need to understand these patterns to protect their infrastructure.
Server-Side Request Forgery (SSRF) to access IMDS
SSRF stands out as the most common way to exploit IMDS. Attackers trick vulnerable applications into making requests to the metadata service endpoint at 169.254.169.254. These requests come from the application and can access internal resources that outside users can't normally reach.
The attack usually works like this:
- Identify a web application running on a cloud instance with SSRF vulnerability
- Craft a malicious request that targets the IMDS endpoint
- Retrieve temporary IAM credentials from the metadata service
- Use these credentials to access other cloud resources
Mandiant's research showed that UNC2903 threat actors used a dedicated operational relay box to scan and exploit IMDSv1. The attackers:
- Scanned websites and did manual reconnaissance
- Exploited SSRF vulnerabilities to trick servers into requesting metadata
- Used HTTP redirects to complete the SSRF attack
- Captured metadata credentials from error messages
AWS research on real-life vulnerabilities shows that IMDSv2's session tokens through PUT requests block most SSRF vulnerabilities. In spite of that, some SSRF vulnerabilities still work even with IMDSv2, especially those that let attackers set any headers they want.
Code injection and misconfigured workloads
Attackers use code injection vulnerabilities and misconfigured workloads as alternatives to get IMDS access when SSRF doesn't work. These methods give them different ways to break in.
Code injection lets attackers add malicious commands into vulnerable applications. The commands tell applications to query the IMDS endpoint from inside. This turns the workload into the attacker's proxy.
Security researchers found two new vulnerabilities being exploited:
- Pandoc vulnerability (CVE-2025-51591): Attackers created HTML documents with iframe elements pointing to AWS IMDS endpoints. The problem came from pandoc's unsafe handling of iframe tags in HTML documents.
- ClickHouse SSRF: Attackers used ClickHouse's SELECT * FROM URL SQL method. The misconfiguration let anyone query any URL without authentication. This affected many cloud providers, including GCP.
These examples show how simple utilities become dangerous when they're not set up right or handle untrusted input.
No EC2 IMDS role found: Misconfiguration risks
Threat actors check for IAM roles by querying http://169.254.169.254/latest/meta-data/iam/. A 404 response means there's no IAM role connected - what we call a "no EC2 IMDS role found" situation.
This leads to two possible cases:
- No role assigned: The damage potential is lower since there are no privileged credentials
- Revoked role: An empty 200 response shows that someone removed a previously assigned role
Instances without IMDS roles are nowhere near as risky. Yet poorly configured applications on these instances might expose internal network resources. Attackers could use these instances to move around the network.
Even without credentials, attackers can pull useful information from IMDS like instance IDs, security groups, and network details. This helps them scout and target more valuable resources.
These instances still need proper IMDS setup and protection. They remain valuable targets to help attackers get in and gather information during their campaigns.
Behavioral Detection of IMDS Abuse
Security teams need sophisticated behavioral analytics to identify suspicious access patterns that could indicate IMDS abuse. A multi-layered detection strategy helps spot exploitation attempts before credential compromise occurs.
Establishing baseline IMDS access patterns
Understanding normal IMDS usage in cloud environments starts the detection process. Security researchers utilize telemetry data to spot legitimate IMDS clients like AWS SDK implementations, EC2 agents, and tools like nm-cloud-setup that keep interacting with metadata services. This creates a strong foundation to detect anomalies by knowing which processes should access IMDS and how often. Security teams can build reliable lists of expected IMDS clients by looking at data from thousands of cloud environments.
Detecting rare or anomalous process behavior
Security teams can spot suspicious activities once they know what's normal. They look closely at processes that rarely touch IMDS—those showing up in just a few environments but trying to get instance metadata. Adversaries often use tools like curl, wget, python, and perl to reach metadata endpoints, so these need extra attention. Elastic Security's detection rule watches these specific processes while leaving out known safe paths to reduce false alarms.
Filtering by sensitive metadata paths
Attackers value some IMDS endpoints more than others. Detection accuracy improves when security tools focus on requests to critical metadata paths:
/latest/meta-data/iam/info: Returns information about instance IAM roles/latest/meta-data/iam/security-credentials/: Lists available security credentials/computeMetadata/v1/instance/service-accounts/: In GCP, provides service account details
Regular software rarely needs these endpoints, which makes such requests suspicious. Security teams should break down any access to these paths by unusual processes immediately.
Contextual filtering using compute instance metadata
Instance-specific context helps prioritize alerts better. Runtime sensors collect key data about processes and their host instances. Security teams should pay special attention to IMDS access from instances that have:
- Internet exposure
- Access to sensitive data
- Concurrent suspicious activities
- Unusual parent processes or execution paths
Analysts should look at process command lines, working directories, parent processes, and network events during investigations. Looking at other security events helps reveal broader patterns of compromise.
Detecting IMDS abuse requires more than just signature matching. Teams need to track which processes should never query IMDS and flag any departures from normal patterns right away.
Case Studies: Real-World IMDS Exploits
Security teams have found sophisticated attacks targeting the Instance Metadata Service (IMDS) through previously unknown vulnerabilities. These real-life examples show how attackers actively look for creative paths to access cloud credentials.
CVE-2025-51591: SSRF in Pandoc via
Security researchers found a zero-day Server-Side Request Forgery (SSRF) vulnerability in Pandoc, a popular document converter used in many cloud environments. The exploit, tracked as CVE-2025-51591, came from Pandoc's feature of rendering HTML content with iframe elements. Attackers crafted HTML documents with iframe tags that specifically targeted AWS IMDS endpoints (169.254.169.254). They wanted to extract sensitive metadata paths like /latest/meta-data/iam/info and /latest/meta-data/iam.
Applications using Pandoc failed to implement recommended security flags (--sandbox or -f html+raw_html) when processing untrusted HTML input, which led to this vulnerability. The exploit attempts started in August 2025 and continued for several weeks. The attackers ended up bypassing recommended --raw_html and --sandbox flags, but their exploit failed to achieve its goal.
ClickHouse SSRF via SELECT FROM URL misuse
Security teams also found another SSRF exploitation with ClickHouse, a popular database system. Attackers exploited ClickHouse's SELECT * FROM url SQL method when it was misconfigured to let unauthenticated users query any URL. This feature became dangerous because it allowed direct connections to internal resources, including the IMDS endpoint.
The attack targeted a Google Cloud Platform environment, which showed that IMDS exploitation techniques work with different cloud providers. Attackers used ClickHouse's feature to fetch remote content, turning a legitimate database capability into an attack vector. The exploited instance had no privileged credentials, which limited potential damage.
Impact of IMDSv2 enforcement in both cases
IMDSv2 enforcement played a crucial role in stopping both exploitation attempts. IMDSv2's session-oriented approach blocked stateless GET requests from iframes in the Pandoc case. The metadata service automatically rejected all requests because attackers couldn't perform the required token retrieval.
Both attacks would likely have succeeded in getting credentials if IMDSv1 had been active. These examples clearly show why security experts strongly recommend IMDSv2 across all compute instances. These case studies prove that proper cloud infrastructure configuration can stop even sophisticated zero-day exploits. Finding vulnerabilities is just one part of launching a successful attack.
Mitigation Strategies and Automation Tools
Your cloud infrastructure needs proactive security measures to limit IMDS exploitation. Let's get into the best ways to reduce these risks.
Enforcing IMDSv2 across all instances
IMDSv2 acts as the primary defense against metadata service attacks. The full security benefits come from completely disabling IMDSv1. New instances need launch templates with "Metadata version" set to "V2 only" or "HttpTokens" parameter set to "required". Service control policies should prevent users from launching instances without IMDSv2 enforcement:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:MetadataHttpTokens": "required"
}
}
}]
}
IMDS automation for policy enforcement
AWS Systems Manager automation with the AWSSupport-ConfigureEC2Metadata runbook helps automate IMDSv2 configuration at scale. Event-driven workflows can enforce IMDSv2 automatically each time new instances launch. This approach ensures security policies stay consistent as your infrastructure grows.
Using Wiz Runtime Sensor for anomaly detection
Wiz Runtime Sensor provides immediate protection against IMDS exploitation and spots unusual request patterns and access from unexpected processes. This lightweight eBPF-based tool monitors suspicious activities like network scanning or malicious IOCs with minimal performance impact.
Applying least privilege to IAM roles
The least privilege principles mean granting only essential permissions for specific tasks. Regular IAM role reviews help spot and remove unnecessary permissions, especially wildcard permissions like "Action": "*". IAM Access Analyzer helps create right-sized policies based on actual usage patterns. Instances without application needs should not have assigned roles.
Conclusion
IMDS attacks pose a major threat to cloud environments despite their low profile. We looked at how attackers steal credentials, move sideways within networks, and gain higher privileges by exploiting this critical service. The security improvements from IMDSv1 to IMDSv2 show why upgrades matter. IMDSv2's session-based approach blocks most SSRF attacks that would succeed against IMDSv1 endpoints.
Security teams can defend against these attacks by detecting unusual behavior patterns. They can spot suspicious processes trying to access metadata services by establishing normal access patterns first. Detection capabilities improve substantially when teams focus on sensitive metadata paths and apply contextual filtering.
The Pandoc and ClickHouse vulnerability cases prove an important point. Even advanced zero-day exploits can fail when proper security controls are in place. Companies should make IMDSv2 enforcement their top priority across all instances.
Organizations need multiple layers of protection. They should set up automated policy enforcement and runtime sensors to detect anomalies. Strict application of least privilege principles to IAM roles is essential. These defenses create a strong security setup that cuts down the risk of credential theft through IMDS.
Cloud security demands constant alertness as attack methods keep changing. IMDS offers valuable features for cloud applications, but its capabilities make it an attractive target. Security teams face a balancing act. They must keep metadata services available to legitimate workloads while stopping exploitation attempts. Organizations can safely use cloud infrastructure with the right security controls and monitoring in place.
