Cloud Metadata Attack

A cloud metadata attack targets the instance metadata service that cloud providers expose to running workloads at a link-local address (commonly 169.254.169.254). That service hands back instance details and, critically, the temporary credentials for the role attached to the workload. Any code that can reach the endpoint and read the response can mint API access as that role.

The classic path is SSRF. An attacker finds a feature that fetches a URL on the server's behalf, points it at the metadata IP, and reads back the role's access keys. With those keys the attacker calls cloud APIs directly, then pursues privilege escalation by chaining permissions the role holds. Local code execution on the instance reaches the same endpoint without needing SSRF at all.

The 2019 Capital One breach is the well-known example, where an SSRF flaw led to metadata-service credential theft and large-scale data access. Defenders respond by enforcing IMDSv2, which requires a session token and blocks naive SSRF, and by scoping roles tightly so a leaked credential grants little. An over-permissioned role turns this from a foothold into a takeover, which is why IAM misconfiguration and cloud misconfiguration amplify the impact.

In a Trickest workflow, you test reachable endpoints for SSRF and check whether instances still allow the unauthenticated metadata version.