Instance Metadata & SSRF-to-Cloud-Takeover

After this chapter you will be able to turn a server-side request — yours or the provider's — into stolen workload credentials, and recognise when that SSRF reaches past the tenant into the cloud provider's own internal endpoints.

The problem

Every virtual machine in the cloud needs to know things about itself: its own name, its region, the start-up script it should run. It also needs an identity — a way to prove to the cloud's APIs that it is allowed to read a storage bucket or write to a queue. The provider solves both needs with one piece of plumbing: a tiny built-in web server that the VM can query about itself. That server is the instance metadata service, and it is the subject of this chapter.

If the metadata service only returned inert facts — instance ID, region, hostname — it would be a curiosity. It returns more than that. It returns live credentials.

What goes wrong is now easy to state. Anything that can make a workload send an HTTP request to 169.254.169.254 — a server-side request forgery (SSRF), an XXE external entity, an open redirect followed server-side, a misconfigured proxy — can vend that workload's cloud credentials. You already know how to find an SSRF. The only new knowledge is the URL.

Here is the AWS request and its response — the exact shape the firewall SSRF from the cold open retrieved:^[7]

# Step 1 — discover the role name attached to the instance
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# -> WAF-Role

# Step 2 — vend a live credential for it
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/WAF-Role

{
  "Code": "Success",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIA................",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCY................",
  "Token": "IQoJb3JpZ2luX2VjE......",
  "Expiration": "2026-05-16T18:42:11Z"
}

Export those three fields and you are that role — no login flow, no MFA, no further trust to satisfy. The credential is short-lived, but you need it only long enough to AssumeRole into something durable: the privilege-escalation machinery of Chapter 3.

Why it matters: this is not a tenant pentest

In a traditional pentest, an SSRF that reaches a metadata service is a serious finding — and it stops there. It steals that customer's credentials, inside that customer's account. The firewall breach from the cold open was exactly this: catastrophic, 106 million records, and still entirely contained within one tenant.^[7]

The cloud-provider angle is different, and it is the reason this chapter exists. Two shifts in perspective:

• The metadata endpoint is a wormhole between planes. It lives in the data plane — a thing your VM talks to, no different in principle from a local DNS resolver. Yet the token it dispenses is honoured by the global control plane. A humble data-plane endpoint, asked the right question, hands you an identity you can drive against the provider's management APIs.
• The SSRF can live inside a provider-operated service. When the vulnerable HTTP client belongs to AWS or Azure — a template renderer, a managed bot's data connector — the credential it vends is not a customer's. It is the provider's. And a provider service's identity is frequently scoped to see every tenant.

Run the metadata service through the book's six-part lens and the danger is plain. Plane: data plane by location, control plane by consequence. Isolation boundary: barely one — the service is authenticated by network position alone, so any primitive that borrows the VM's network position borrows its authority. Identity propagation: this is the moment a workload's identity gets attached, and the moment you can steal it. Shared component: inside a provider service, the metadata endpoint belongs to a fleet shared by every tenant. Provider "magic": plumbing the tenant was never meant to think about — and magic that works invisibly can be invoked invisibly. Detection surface: thin; a request to a link-local address never leaves the host.

The methods at a glance

The rest of the chapter breaks down four techniques, in roughly increasing severity. The first three are things you can do with the SSRF/XXE skills you already have; the fourth is the provider-side payoff.

The three cloud providers are not interchangeable. The pattern is universal; the details are not. Learn the pattern, then look up the vendor.

Technique 1 — From SSRF and XXE to workload credentials

The simplest version is the firewall version: a classic SSRF in a customer workload, pointed at 169.254.169.254. You can already do this; the only new knowledge was the URL. Two variations are worth your attention because single-tenant pentest experience does not prepare you for them.

The SSRF source need not be a server-side HTTP client. An XXE delivers the same primitive. A SYSTEM entity with an http:// scheme is, functionally, a blind SSRF — and again the relevant question is which URL. The most instructive corpus example puts that XXE inside a provider's own service.

<!DOCTYPE r [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">       <!-- local file read off the renderer host -->
  <!-- swap the scheme for step 2: -->
  <!-- <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/"> -->
]>
<root>&xxe;</root>

The SSRF "engine" can be the victim's own browser session. AWS SageMaker's managed Jupyter notebooks ship a "security extension" meant to block notebook code from reaching IMDS. Research described an XSS in the notebook chained to CSRF that subverts that extension and issues a request to the EC2 instance's metadata service, lifting the AWS token of the notebook's attached IAM role.^[2]#011 The teaching point is sharp: a provider can put a guard in front of IMDS, but if the guard runs in the same trust context the attacker just took over, it is decoration.

Technique 2 — Forging what metadata says

So far you have read from the metadata service. There is an inverse attack: because IMDS speaks plaintext HTTP, you can also forge what it says back — and the components that consume those answers trust them. Inside a provider-operated service, that inversion is an escape route off the tenant's sandbox and onto the provider's own host.

Technique 3 — Bypassing the hardened service

The firewall breach forced AWS's hand. In November 2019 — months after the incident — AWS shipped IMDSv2, a re-engineered protocol designed to make the SSRF-to-credential chain hard.^[8] It is good engineering. It is also, emphatically, not a cure, and a CSP security engineer who treats it as one will miss live attack paths.

# Step 1 — obtain a session token (a PUT, with a request header)
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2 — every data request must carry the token header
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

Why this defeats most SSRF: a textbook SSRF gives the attacker a GET with no control over method or headers. It can neither issue the PUT nor attach the token header. But the limits matter, because the chapter's credibility depends on stating them:

• Opt-in by enforcement. For years IMDSv2 shipped alongside v1. An instance launched without HttpTokens=required still answers v1. The fix is a configuration, not a removal.
• It only stops GET-only, header-blind SSRF. A full-request SSRF where the attacker controls method and headers — typically via a "make an HTTP request" feature in a managed service — can complete the v2 handshake itself. So can XXE, RCE, or a proxy that forwards arbitrary methods.
• It is AWS-only. Azure IMDS requires a Metadata: true header; GCP requires Metadata-Flavor: Google. Real friction against a blind GET — but, as we are about to see, smuggle-able.
• Adjacent surfaces never got it. ECS task metadata and the newer microVM endpoints are still plain-GET surfaces.

The redirect bypass. When a provider service does validate the SSRF target — "you may not request internal or RFC 1918 hosts" — it almost always validates the URL string the tenant supplied, then hands that string to an HTTP client that follows redirects. So the attacker hosts a public URL that answers with a 301 whose Location points at IMDS:

# attacker-controlled server, lab-scoped
class H(http.server.BaseHTTPRequestHandler):
    def do_GET(s):
        s.send_response(301)
        s.send_header('Location',
            'http://169.254.169.254/metadata/instance?api-version=2021-12-13')
        s.end_headers()

The allow-list inspected a perfectly public address and approved it; the HTTP client then followed the redirect onto 169.254.169.254. In 2024 this exact bypass appeared in three independent disclosures against three different Azure services from the same research team.^[4]#258 The defensive lesson writes itself: validate the connection target — the resolved IP at socket time, on every hop — not the user-supplied string.

Header smuggling. Azure IMDS demands Metadata: true and rejects any request bearing X-Forwarded-For. When a service's HTTP-request feature lets the user set headers but auto-appends its own X-Forwarded-For, an attacker can terminate the Metadata header value with newline characters, pushing the service-injected X-Forwarded-For down past the header block and into the request body — where IMDS simply ignores it.^[5]#254 "Require a header" is a soft control when the attacker has even partial control of the request structure.

Technique 4 — When the SSRF reaches the provider's internals

Here is the chapter's thesis. An in-tenant SSRF that only hits 169.254.169.254 steals the tenant's own credentials — the firewall-breach scale. The course-relevant escalation is an SSRF inside a provider-operated service. There, the very same SSRF reaches targets a tenant should never touch: the metadata identity of a provider-owned host, provider-internal management APIs, and host-agent channels — the host-to-guest channel like the Azure WireServer, which gets its own full treatment in Chapter 5.

GET https://management.azure.com/subscriptions?api-version=2020-01-01
Authorization: Bearer <managed-identity token>

GET https://management.azure.com/subscriptions/<id>/resources?api-version=2020-10-01
Authorization: Bearer <managed-identity token>

The Health Bot finding did not stand alone. Two sibling 2024 disclosures from the same team show the pattern is structural:

Copilot Studio (CVE-2024-38206). Copilot Studio Topics expose an HttpRequestAction with a user-controllable URL and headers. Tenable bypassed the IP filter with the same attacker-hosted 301, then smuggled past the Metadata/X-Forwarded-For controls with the newline trick. The loot: managed-identity tokens, access to two Azure subscriptions, a Cosmos DB instance with master read/write keys, and visibility into internal 10.0.x.0/24 subnets — rated a Critical Information Disclosure.^[5]#254

Azure Machine Learning. The data-connection endpoints on ml.azure.com and ai.azure.com had internal-host filtering; a 301/302 from an attacker server bypassed it. The PoC reached http://127.0.0.1:4191/metrics# — a Linkerd service-mesh metrics endpoint — leaking the identities of other internal hosts and services on the shared, region-scoped ML infrastructure; Microsoft documented the fix in an MSRC blog.^[4]#258 Note this SSRF never reached IMDS at all — it reached region-shared internal infrastructure, which is its own prize.

An older case shows the pattern is neither new nor Azure-specific. Azure Stack DataService (CVE-2019-1234): the User Portal's "deploy template from URL" feature was a GET with no host validation, IPv6-capable so it slipped past IPv4-only filtering, reaching an unauthenticated internal DataService API whose GetVmScreenshot method returned screenshots of arbitrary tenant and infrastructure VMs.^[9]#059 SSRF in a provider portal → provider-internal API → cross-tenant disclosure, years before the 2024 trio.