IMDSv2 Enforcement: Blocking SSRF Credential Theft

IMDSv2 enforcement closes the cheapest credential theft path in AWS: a single SSRF flaw or misconfigured reverse proxy that asks the instance metadata service for role credentials and receives them with no authentication challenge. IMDSv1 answers any plain GET issued from inside the instance, so switching instances to IMDSv2-only mode forces an attacker to complete a session-oriented PUT handshake that most SSRF payloads and proxies cannot perform. Enforce it fleet-wide, keep the response hop limit tight, and alert on any request pattern that resembles metadata enumeration.

Why IMDS Is a Target

The instance metadata service hands out the temporary credentials of whatever IAM role is attached to the instance. An application rarely needs more than its own role scope, but an attacker who can make one request to the metadata endpoint inherits that entire scope — which is why the payoff per exploited bug is so high relative to the effort.

MITRE ATT&CK catalogs this behavior as Unsecured Credentials: Cloud Instance Metadata API. Attackers reach the metadata service at 169.254.169.254 either from a foothold on the instance itself or by chaining an SSRF vulnerability in a public-facing web proxy. The same address works across AWS, GCP, and Azure because it is the de facto standard location for the metadata API, so tooling written for one cloud often works against all of them.

Real malware families treat this as routine. Hildegard queried the metadata API to source credentials for cloud cryptojacking campaigns, and the Shai-Hulud worm harvested instance credentials inside container and CI/CD supply chain compromises. Neither needed a zero-day; both needed only code execution or SSRF on a workload with an over-permissive role.

How IMDSv2 Sessions Work

IMDSv2 issues a session token that lasts between one second and six hours, and the token is instance-specific: it is rejected on any other EC2 instance. The client first sends a PUT to the token endpoint with a TTL header (up to 21,600 seconds), then presents that token on every subsequent metadata GET. Once token usage is set to required, requests without a valid or unexpired token receive a 401 response instead of metadata.

Two built-in details do quiet defensive work. AWS rejects the token-issuing PUT when it arrives with an X-Forwarded-For header, which is the exact signature of a reverse-proxy-relayed request rather than a legitimate on-instance client. And the default IP-level response hop limit of 1 means a token response dies after a single network hop, so containerized services that legitimately need metadata from further away must raise the limit deliberately — a measured trade-off, not a default worth copying blindly.

The IMDSv2 Enforcement Checklist

Treat this as an ordered procedure; skipping the SDK step is what turns a security project into an outage.

1. Inventory the fleet: list every instance whose metadata options still allow the tokenless request/response mode, and tag owners.
2. Update SDKs and CLIs first. AWS publishes minimum versions that support IMDSv2 — for example Boto3 1.12.6 and AWS CLI 1.16.289 — and older clients will break the moment enforcement lands.
3. Set token usage to required in launch templates and AMIs so every new instance is born compliant, then flip existing instances in waves by workload risk.
4. Verify each workload actually authenticates: run a token-based retrieval against the metadata endpoint before and after cutover.
5. Set the PUT response hop limit explicitly: leave it at 1 where nothing containerized runs on the instance, and raise it only for the container hosts that demonstrably need it.
6. Enforce the setting with an organization policy or config rule so drift on new instances fails closed.
7. Shrink the blast radius in parallel: prefer short-lived role sessions and scoped permissions over instance roles that can read, write, and bill across the account.

SSRF Controls Beyond the Metadata Endpoint

IMDSv2 is defense in depth, not a fix for SSRF. The flaw class itself lives in application code that fetches URLs from user input — avatar imports, webhook handlers, PDF renderers, PDF and file preview features. Allow-list outbound destinations for every URL-fetching feature, disable automatic redirect following in HTTP clients, and resolve hostnames yourself before connecting so that a domain cannot pass validation and then point at a link-local address.

OWASP calls deny-lists bypass-prone and recommends allow-lists first, listing 169.254.169.254 and metadata.amazonaws.com among the minimum ranges to block when a deny-list is unavoidable. If you must run a deny-list as a backstop, cover at least the metadata endpoints of every provider you run on:

Detection Signals for Metadata Abuse

Enforcement without monitoring is a one-time project. The signals worth alerting on: token-issuing PUTs from processes or containers that never needed metadata before; any surviving plain GET toward the metadata address once token usage is required; token issuance spikes concentrated in a single workload; and requests toward metadata endpoints originating from proxy or edge tiers that should never touch IMDS at all. MITRE’s detection guidance for this technique centers on exactly that pattern — access attempts to cloud metadata endpoints from virtual machines and containerized workloads, including SSRF-shaped variants that arrive through a web tier.

Sources

• AWS — Use the Instance Metadata Service to access instance metadata
• MITRE ATT&CK — Unsecured Credentials: Cloud Instance Metadata API (T1552.005)
• OWASP Cheat Sheet Series — Server-Side Request Forgery Prevention