×

Hackers Abuse IMDS Service for Cloud Initial Access

Cloud environments rely on the Instance Metadata Service (IMDS) to provide virtual machines with temporary credentials and essential configuration data.

IMDS allows applications to securely retrieve credentials without embedding secrets in code or configuration files.

However, threat actors have found ways to misuse this convenience, turning IMDS into a springboard for stealing credentials, moving laterally, and escalating privileges.

Recent research by the Wiz team shows how data-driven threat hunting can detect unusual IMDS activity and even uncover zero-day exploits in popular services.

What Is IMDS and Why It Matters

The Instance Metadata Service runs on every cloud compute instance, offering a secure channel for retrieving data such as IAM role credentials, region information, and network configuration.

In AWS and Azure, this service is known as IMDS, while Google Cloud calls it the VM metadata service.

Applications running on a compute instance simply make an HTTP request to a link-local address (169.254.169.254 for AWS) to fetch temporary credentials tied to the instance’s role.

These credentials grant access to resources like S3 buckets or databases without hardcoded secrets.

AWS supports two versions of IMDS. IMDSv1 accepts unauthenticated HTTP requests, which makes it vulnerable to server-side request forgery (SSRF) attacks.

IMDSv2 requires a session token obtained through a PUT request before any GET requests can fetch metadata.

This token-based approach raises the bar for attackers by requiring control of both HTTP methods and headers.

Security best practices recommend enforcing IMDSv2 to block most common abuse techniques targeting IMDSv1.

Bar Charts showing the prevalence of various processes in cloud environments and their IMDS usage

Attackers seeking initial access in the cloud often exploit application flaws that allow them to proxy requests to IMDS. Two common paths include:

Server-Side Request Forgery (SSRF): Attackers leverage a vulnerable web application to send HTTP requests to the IMDS endpoint. By injecting a URL parameter that points to 169.254.169.254, they can trick the application into revealing temporary credentials.

Code Injection and Misconfigured Workloads: Flaws in application code or open network configurations can be manipulated to issue IMDS queries from within the instance itself, effectively turning the workload into an attacker-controlled proxy.

Once in possession of IMDS credentials, attackers can move laterally across the cloud environment, pivot to other instances, and escalate privileges by assuming additional roles.

Hunting Anomalous IMDS Usage

The Wiz Research team uses a four-step data-driven approach to detect suspicious IMDS access:

  1. Establishing a Baseline: Identify processes and SDKs that normally access IMDS, such as AWS SDK clients and cloud-init services.
  2. Spotting Rare Patterns: Look for processes that rarely query IMDS across environments, as these one-off events often signal exploitation.
  3. Narrowing to Sensitive Paths: Focus on metadata endpoints that reveal IAM info and security credentials, which legitimate applications seldom access.
  4. Contextual Filtering: Combine IMDS access data with instance details—public exposure, sensitive data access, and concurrent suspicious events—to prioritize alerts.

Using this method, the team discovered two real-world cases of IMDS abuse. In the first, they found a zero-day SSRF vulnerability in the Pandoc document converter (CVE-2025-51591), which rendered untrusted HTML containing iframes targeting IMDS.

Because the environment enforced IMDSv2, the exploit failed to retrieve credentials, but only by chance.

In the second case, a misconfigured ClickHouse database in GCP was abused via its URL query feature to attempt metadata theft. Missing permissions saved the day.

These findings underscore the importance of enforcing IMDSv2 and monitoring for anomalous metadata requests.

By combining telemetry, machine learning, and threat intelligence, security teams can turn the tables on attackers and safeguard cloud environments before credentials fall into the wrong hands.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.

Post Comment