Follow the Access · 22 — The Cloud Metadata Service: Stealing the Keys From the Machine Itself

Follow the Access — Case 22. This register follows the intruder from the login prompt to the foothold's fate, and closes each case on what the access becomes: RANSOMED · MINED · PROXIED · HARVESTED · WIPED · RESOLD.

This case is about how a small, ordinary web-application flaw became one of the largest data breaches in history, and the answer is a piece of cloud infrastructure that most people have never heard of: the instance metadata service. When you run a server in the cloud, that server needs to know things about itself — its configuration, its region, and, crucially, the credentials it uses to authenticate to the cloud platform. To provide these, cloud platforms expose a special internal endpoint, reachable only from the instance itself, at a fixed link-local address: 169.254.169.254. Ask that endpoint for credentials, and it hands back the temporary keys the instance uses to prove its identity to the cloud. This is a legitimate and necessary feature; it is how a cloud server gets its keys without anyone hardcoding them into its software.

But look closely at what it means. The keys to the machine's cloud identity are sitting at a URL that the machine can request. And that turns out to be a catastrophic property in the presence of a common web flaw called Server-Side Request Forgery — SSRF — which lets an attacker make a server fetch a URL of the attacker's choosing. Ordinarily an attacker uses SSRF to reach internal pages. In the cloud, its deadliest target is that metadata endpoint. The attacker finds an SSRF flaw in an application, points it at 169.254.169.254, and the application dutifully requests its own metadata — including its cloud credentials — and hands them back to the attacker. The server steals its own keys and gives them away, because it was tricked into asking for the URL where its keys live.

This is the chain behind the 2019 Capital One breach, the canonical case that made this obscure sequence famous: an SSRF flaw in a web application, pointed at the metadata service, yielded the instance's cloud credentials, which were used to reach and exfiltrate cloud-stored data — the personal records of over one hundred million people. So the disposition is HARVESTED, because the stolen instance credentials are used to reap the data the cloud account holds. This is the case about stealing the keys from the machine itself, and about how the cloud environment turned a modest web bug into a hundred-million-record harvest.

1. The Keys at a URL the Machine Can Ask For

Begin with the metadata service itself, because it is the fulcrum of the case and its danger is entirely a matter of where it places the credentials. A cloud instance cannot function without an identity: it needs credentials to read from storage, write to databases, and otherwise interact with the cloud platform's services. Hardcoding those credentials into the instance's software would be terrible practice — they would leak, they would not rotate, they would be everywhere. So cloud platforms solved the problem elegantly: they give each instance a role, and they make the temporary credentials for that role available through the metadata service, an endpoint the instance can query to retrieve its current keys on demand. The instance asks 169.254.169.254 for its credentials, gets fresh short-lived ones, and uses them. No hardcoding, automatic rotation, clean design.

The subtle danger is in the word "asks." The credentials are retrieved by the instance making an HTTP request to a URL. That is a convenient way for legitimate software on the instance to get its keys — but it means the keys are obtainable by anything that can cause an HTTP request to that URL to be made from the instance. The metadata service does not deeply verify who, within the instance, is asking; historically, it answered any request that reached it from the instance, on the reasonable-seeming assumption that anything running on the instance is entitled to the instance's identity. That assumption holds for trusted software. It fails catastrophically when an attacker can make the instance's own software issue requests on the attacker's behalf — because then the attacker, through the instance, can ask for the keys, and the metadata service, seeing a request that came from the instance, hands them over.

This is the structural vulnerability the case turns on, and it is worth stating as a general principle, because it recurs across cloud security: convenience features that make credentials easily available to legitimate software also make them available to any attacker who can borrow that software's voice. The metadata service was designed to let the instance easily obtain its own keys, and it does — but "the instance" is not a single trustworthy will; it is a collection of software, some of which may be exploitable. When one of those pieces of software can be made to request an arbitrary URL, the attacker gains the instance's voice, and with the instance's voice he can ask the metadata service for the instance's keys. The keys were placed at a URL for convenience, and the URL is exactly as reachable as the least-trustworthy request the instance can be made to send.

2. SSRF — Borrowing the Server's Voice

Now the flaw that borrows the server's voice, because SSRF is the specific bug that turns the metadata service's convenience into a breach. Server-Side Request Forgery is a class of web-application vulnerability with a simple, dangerous essence: the attacker can make the server issue an HTTP request to a URL the attacker specifies. Applications legitimately make outbound requests all the time — to fetch an image from a URL a user provides, to call a webhook, to retrieve a document — and if the application takes a URL from user input and fetches it without properly restricting where it can point, an attacker can supply a URL of their choosing, and the server will fetch it. The request comes from the server, using the server's network position and the server's identity, but it goes wherever the attacker directed.

On an ordinary, non-cloud server, SSRF is dangerous but bounded: the attacker can make the server reach internal systems the attacker could not reach directly — an internal admin page, a database, a service behind the firewall — because the server sits inside the network and can reach things the outside attacker cannot. That is bad, but it is the familiar bad of internal reconnaissance. In the cloud, SSRF acquires a far more dangerous target, because now there is something reachable from the server that is worth vastly more than any internal page: the metadata service, sitting at 169.254.169.254, holding the instance's cloud credentials. The attacker who finds an SSRF flaw in a cloud-hosted application does not aim it at an internal admin page; he aims it at the metadata endpoint. He supplies, as the URL for the application to fetch, http://169.254.169.254/ followed by the path to the credentials, and the application — reaching that URL from the instance, as any legitimate metadata request would — retrieves the instance's IAM credentials and returns them in its response, straight to the attacker.

The elegance, from the attacker's side, is that no part of this requires defeating the metadata service's protections, because there were none to defeat: the metadata service answered because the request came from the instance, and the request came from the instance because the SSRF flaw made the instance send it. The attacker never authenticated to anything. He never guessed a credential. He found a web bug that let him borrow the server's voice, and with that borrowed voice he asked the machine to read out its own keys. This is why SSRF-to-metadata is so prized and so dangerous: it is a clean, unauthenticated path from a modest web flaw to the cloud credentials of the instance, requiring nothing more than an application that can be tricked into fetching a URL and a metadata service that answers whatever the instance asks. The server was made to betray itself, in its own voice, to a stranger.

3. Capital One — The Modest Bug That Breached a Hundred Million

Now the case that made this famous, because the 2019 Capital One breach is the SSRF-to-metadata chain in its full, catastrophic form, and it is the reason this obscure technical sequence became a first-rank cloud risk that every cloud practitioner now knows. The breach followed the chain exactly as described, and its scale is what makes it the register's clearest illustration of a small flaw amplified into a disaster by the cloud environment.

The sequence: a Capital One web application, running on cloud infrastructure, contained an SSRF flaw. An attacker exploited that flaw to make the application request the cloud metadata service, retrieving the temporary IAM credentials of the underlying instance — the instance's cloud identity. Those credentials carried permissions to access cloud storage, and the attacker used them to reach the storage buckets the role could access and exfiltrate the data held there. The data was the personal information of over one hundred million people — names, addresses, credit scores, and more — making it one of the largest data breaches in the history of the financial sector. A single SSRF flaw in a single web application, chained through the metadata service to a set of over-provisioned instance credentials, exposed the records of a hundred million individuals, and it did so through a technique that, before this breach, most security practitioners had never seriously considered.

What makes Capital One the definitive case is precisely the mismatch between the modesty of the initial flaw and the enormity of the outcome. An SSRF vulnerability is not an exotic, sophisticated bug; it is a common web flaw, one of many an application might have. On a traditional server, this particular SSRF might have been a moderate finding — reach some internal endpoint, cause some mischief. But because the server was in the cloud, the same modest SSRF could reach the metadata service, and the metadata service handed out credentials, and the credentials — over-provisioned, as the next section will discuss — opened the door to a hundred million records. The severity did not come from the flaw; it came from what the flaw could reach in the cloud environment. This is the lesson Capital One burned into the industry's memory: in the cloud, the blast radius of a common vulnerability can be extraordinary, because the environment places extraordinarily powerful credentials within reach of an ordinary bug. The breach was not a failure of an exotic defense against a genius attacker; it was a common flaw meeting a powerful, reachable credential store, and that combination is the cloud's characteristic danger.

4. HARVESTED — And the Over-Provisioning That Made It Worse

Now the disposition and the amplifier that determined its scale, because the SSRF-to-metadata chain's fate is HARVESTED — the reaping of data — and how much data is reaped depends on a second failure that compounds the first: over-provisioning, the same failure that made the leaked key of Case 20 so dangerous. The chain's outcome is data theft: the attacker, having stolen the instance's cloud credentials, uses them to reach the storage and databases those credentials permit, and exfiltrates the sensitive data held there. The credential is the means; the harvest is the data. The disposition is HARVESTED because the whole point of stealing a cloud identity, in this chain, is to reap what that identity can reach.

But the size of the harvest is set by the scope of the stolen credential, and this is where over-provisioning turns a bad breach into a catastrophic one. The credentials the metadata service hands out are the instance's IAM role — its cloud identity — and that role carries whatever permissions the organization granted it. In principle, an instance's role should be scoped narrowly: if the web application only needs to read a specific set of files, the role should permit only that, so that stolen credentials can reach only those files. In practice, roles are routinely over-provisioned — granted far broader permissions than the application needs, because narrow scoping is careful work and broad grants are convenient. So the attacker who steals an instance's credentials via SSRF inherits not the narrow access the application actually used, but the wide access the role was carelessly given. In the Capital One case, the stolen instance credentials could reach far more data than the application's function required, and that over-provisioned scope is what turned an SSRF into a hundred-million-record harvest rather than a limited one. The chain had two failures, and they compounded: the SSRF let the attacker steal the credentials (failure one), and the over-provisioned role made those credentials open the whole data store (failure two).

This is the same compounding the register saw in the leaked key of Case 20, and the parallel is deliberate, because it points at the deepest defensive lesson of cloud security. Stealing a credential is only as damaging as the credential is powerful, and the power of a credential is a choice the organization makes when it scopes the role. An SSRF flaw that stole a credential scoped to read one bucket would have been a minor incident; the same SSRF flaw stealing a credential scoped to read everything was a historic breach. The difference was not the attacker's skill or the flaw's severity but the organization's decision about how much to permit the credential that leaked. This is why least privilege recurs as a foundational cloud defense: you cannot prevent every SSRF flaw, and you cannot guarantee the metadata service will never be reached, but you can decide that even a stolen instance credential reaches as little as possible, so that when the chain completes — as it eventually will somewhere — the harvest is bounded to a bucket rather than the whole account. The disposition is HARVESTED; whether the harvest is a field or an empire is decided by how the role was scoped.

5. Break Any Link in the Chain

The register owes the defense, and the cloud metadata SSRF offers something the register values: a chain with multiple independent links, any one of which, if broken, breaks the whole attack. The chain runs SSRF flaw → metadata service → stolen credentials → data harvest, and there is a defense at each link, so defense-in-depth here is not a slogan but a literal set of independent chances to stop the same attack.

The most specific and effective link to break is the metadata service itself, and cloud providers have provided the tool: a hardened version of the metadata service — in AWS, called IMDSv2 — that changes how credentials are retrieved. Where the original metadata service answered any simple request from the instance, the hardened version requires a session-oriented request: the caller must first obtain a session token via a special request that sets a particular header, and then use that token to retrieve credentials. The crucial property is that a typical SSRF flaw cannot do this — it can usually make only a simple, attacker-directed request and cannot set the required headers or manage a session token — so the hardened metadata service blocks the exact SSRF-to-metadata path that Capital One went through. Enforcing IMDSv2 and disabling the legacy version directly closes the door the breach used, which is why cloud providers now push it hard and why leaving the legacy service enabled is treated as a serious misconfiguration. This one control, applied, would have prevented the canonical case.

The other links offer independent defenses. Scope instance IAM roles to least privilege — the Section 4 lesson — so that even if credentials are stolen, they reach as little as possible and the harvest is bounded. Fix the SSRF flaws themselves: validate and restrict the URLs an application is willing to fetch, and specifically block requests to link-local and internal addresses like 169.254.169.254, so the application refuses to fetch the metadata endpoint no matter what URL it is handed. And monitor for anomalous use of instance credentials — in particular, instance credentials being used from an IP address outside the instance they belong to, which is a high-fidelity signal that the credentials have been stolen and are being used by an attacker elsewhere, because legitimate instance credentials are used by the instance, not from a stranger's machine. Each of these breaks the chain at a different point: harden the metadata service and the SSRF cannot reach the credentials; scope the role and the stolen credentials cannot reach the data; fix the SSRF and the attacker cannot borrow the server's voice; monitor credential use and the theft is caught. The register's summary is optimistic for once: the cloud metadata SSRF is a chain, and a chain is only as strong as its weakest link, so the defender needs to make only one link strong — and the hardened metadata service makes the most important link strong by default, if only it is enabled.

6. The counter-narrative, steelmanned

The strongest objection to this case is that it is a solved problem memorialized — that IMDSv2 closed the SSRF-to-metadata path years ago, that Capital One was a wake-up call the industry heeded, and that dwelling on it describes a vector the cloud has already fixed.

The argument runs like this. The hardened metadata service directly defeats the SSRF-to-metadata chain, cloud providers now enable or strongly encourage it, and any competently-run cloud environment enforces it — so the specific attack that breached Capital One is closed for anyone who has adopted the fix. The industry, the objection continues, learned the lesson viscerally from a hundred-million-record breach and moved decisively; SSRF-to-metadata is now a well-known risk with a well-known control, taught in every cloud-security course. To present it as a live threat, on this view, overstates a vector that its own definitive case already prompted the industry to close, and the case is really a history lesson about 2019 dressed as current threat intelligence.

The register grants the fix's effectiveness and denies that the vector is closed in practice. Yes, IMDSv2 defeats the chain, and yes, the industry learned from Capital One — genuine, important progress, and the case credits the fix as the decisive control. But "a fix exists and is encouraged" is not "the fix is universally applied," and the register has now made this same point across many cases because it is the truest recurring fact of security: the legacy metadata service still exists, is still enabled on countless instances, and is still reachable by SSRF wherever an organization has not enforced the hardened version — and enforcement is not automatic everywhere, especially across the vast population of smaller organizations, legacy deployments, and hastily-configured cloud accounts that make up most of the cloud, not the well-run minority the objection imagines. Moreover, the case's value is not confined to the specific SSRF-to-metadata instance; it is the general lesson, which remains entirely live: that a modest vulnerability is amplified into a catastrophe by a cloud environment that places powerful credentials within reach of ordinary flaws, and that over-provisioned roles turn any credential theft into a maximal breach. That lesson applies to metadata SSRF and to every future variant of the same pattern — a common flaw meeting a reachable, powerful credential store — which cloud environments will keep producing. And the least-privilege half of the defense is not solved at all: over-provisioned IAM roles remain endemic, so even where the metadata service is hardened, the next credential-theft path (through a different flaw) will still find over-scoped roles waiting to be abused. The case earns its place not as a memorial to 2019 but as the clearest instance of the cloud's permanent characteristic danger, closed in one specific form for the diligent, wide open in that form for the many who have not enforced the fix, and structurally recurring in every new form the pattern takes.

7. Disposition — HARVESTED

Case 22 followed the cloud metadata SSRF — the chain that turned a modest web flaw into one of the largest data breaches in history. Cloud instances expose an internal metadata service at 169.254.169.254 that hands out the instance's IAM credentials, placing the keys to the machine's cloud identity at a URL the instance can request. A Server-Side Request Forgery flaw lets an attacker borrow the server's voice and make it request that URL, so the application fetches its own credentials and hands them to the attacker — the server steals its own keys and gives them away, having authenticated to nothing. Capital One is the canonical case: an SSRF flaw chained through the metadata service to stolen instance credentials exfiltrated the records of over a hundred million people.

The disposition — the foothold's fate — is HARVESTED, because the stolen instance credentials are used to reach the cloud storage and databases the role permits, and the sensitive data held there is reaped. The chain is a harvesting engine — web flaw to cloud identity to the data the account holds — and the size of the harvest is set by a second failure that compounds the first: over-provisioning, the same amplifier as the leaked key of Case 20. A credential scoped to one bucket would have made a minor incident; a credential scoped to everything made a historic breach. The severity came not from the flaw but from what the flaw could reach, which is the cloud's recurring lesson.

The defense is a chain of independent links, any one of which breaks the attack: enforce the hardened metadata service (IMDSv2), which blocks the SSRF-to-metadata path directly and would have prevented the canonical case; scope IAM roles to least privilege so a stolen credential reaches little; fix the SSRF flaws and block requests to the metadata address; and monitor for instance credentials used from outside their instance. The vectors do not lie: the attacker found a bug that let him borrow the server's voice, asked the machine to read out its own keys, and used those keys to walk out with a hundred million people's records — a modest flaw made monstrous by a cloud that kept the keys at a URL the machine could ask for. We do not judge. We record. We let people judge — and then, if they are wise, harden the metadata service, scope the role to nothing, and never let an ordinary bug reach an extraordinary key.

Follow the Access continues. Case 22 disposition: HARVESTED. Confidence: HIGH — the Capital One SSRF-to-metadata breach (2019), the instance metadata credential mechanism, the IMDSv2 mitigation, and the over-provisioned-IAM-role amplifier are all extensively documented in public reporting, the legal record, and cloud-provider guidance; the SSRF technique is catalogued by OWASP. The HARVESTED disposition reflects the data-exfiltration outcome of the canonical case; the over-provisioning amplifier connects directly to the leaked key of Case 20, and the cloud-cryptojacking alternative outcome connects to Cases 08 and 20. The multi-link defense (IMDSv2, least privilege, SSRF fixes, credential-use monitoring) follows AWS/CISA and OWASP guidance. Classification: TLP:WHITE. Include everything — the vectors do not lie, and they do not judge. The reader judges the metadata endpoint, the borrowed voice, and the hundred million records reaped through the machine's own stolen keys.