Harvesting Cloud Credentials from a Metadata Endpoint You Weren't Given

The endpoint every instance has

Cloud instances ship with a built-in identity oracle: the instance metadata service, reachable at the link-local address '169.254.169.254'. It answers questions about the instance — its region, its tags, its attached IAM role — and, critically, it can vend temporary credentials for that role. The credentials are the interesting part: they are scoped to whatever policy the instance's role carries, they rotate, and they are valid for real cloud API calls.

The service has two protocol generations. IMDSv1 answers plain 'GET' requests from any process on the instance; IMDSv2 requires a session token first — a 'PUT' with a TTL header that returns a token, which subsequent requests must present. The v2 handshake is a deliberate hardening: it breaks the class of attacks where a server-side request forgery (SSRF) in an application made a bare 'GET' to the metadata address and exfiltrated role credentials. The address itself, though, remains reachable from the instance by design.

What the endpoint yields depends entirely on the role attached to the instance. A least-privilege role returns credentials that can do almost nothing; a broad admin role returns the keys to the account. The metadata service is not the vulnerability — the scope of the attached role is.