SSRF to Cloud Metadata: Why 169.254.169.254 Is Still the Highest-Value IP in Your VPC

#From one GET request to your whole S3 account#link

In the spring of 2019, an attacker walked out of Capital One with personal data on roughly 106 million credit card applicants. The initial access was not a zero-day, not a phished employee, and not a brute-forced key — it was a single web request that convinced a misconfigured WAF server to fetch a URL on the attacker's behalf. That URL pointed at 169.254.169.254, the link-local address every EC2 instance answers on, and the response contained live IAM credentials for a role with far more reach than any WAF ever needed. The OCC's subsequent $80 million consent order reads less like a story about a clever adversary and more like a story about a chain where every single link was ordinary.

What 169.254.169.254 actually serves

Cloud instances have a bootstrapping problem: they need configuration and credentials at startup, but nobody wants secrets baked into an AMI or handed around in user data. EC2's answer is the Instance Metadata Service — an HTTP endpoint on TCP port 80 at 169.254.169.254, reachable only from the machine itself. Alongside instance facts like instance-id and user-data, if an IAM role is attached to the instance, IMDS serves a live credential set at /latest/meta-data/iam/security-credentials/<role-name>: access key, secret key, and session token, which AWS rotates automatically before they expire. No long-lived secrets on disk, no manual rotation, no static keys in CI. The design is elegant, which is precisely why it is dangerous.

The entire trust model is one sentence: traffic to 169.254.169.254 originates from the operating system on this host, so the endpoint needs no authentication. That assumption holds right up until your application starts fetching URLs supplied by users — a webhook verifier, an import-from-URL button, a PDF renderer, an avatar fetcher. When your code makes that request, it makes it as the instance, from the instance's network position. Server-side request forgery turns an endpoint that was never supposed to be reachable into one that is reachable through your own code. And there is a filter-bypass detail that makes this a routine bug rather than an exotic one: SSRF blocklists tend to cover the RFC 1918 private ranges and forget that 169.254.0.0/16 is link-local, not private, so metadata addresses sail through naive allowlist checks.

What happens next is mechanical. The attacker exports the three values, and every AWS SDK will treat them as a valid identity. Enumerate S3, read what the role can read, pivot into whatever else the role's policies permit. In the Capital One case the credentials belonged to the WAF fleet's instance role, and the gap between what that role was for and what it could actually do was the breach. Two details matter enormously for incident response. First, the credentials keep working for hours after you patch the SSRF — closing the hole does not recall the keys. Second, the part responders learn the hard way: IAM evaluates role policies at call time, not at credential-issue time. Attach a restrictive policy, or an explicit deny, to the role and stolen keys go inert immediately, without waiting out their expiry.

IMDSv2: what the token handshake actually changes

AWS shipped IMDSv2 in November 2019, and the design shows they understood the attack shape. The endpoint stops answering bare GETs: a client must first issue a PUT to /latest/api/token carrying a TTL header, then attach the returned token to every metadata request via X-aws-ec2-metadata-token. Requiring PUT is the whole trick. The common SSRF primitives — parameter injection into a url= field, XXE, SSRF through image tags and redirect-chasing HTTP libraries — can make the victim issue GETs, but they generally cannot choose the HTTP method or forge arbitrary headers. It is the same class of defense as requiring a custom header or a JSON content type to defeat CSRF. A second layer, the hop limit (default 1), restricts how many routed network hops the token response may travel, so a token request relayed through a proxy or an appliance in another subnet never gets its answer back — the PUT has to come from the host itself.

Where IMDSv2 falls short

The first gap is SSRF with control of the raw request. If the primitive lets an attacker write arbitrary bytes to a TCP stream — the gopher:// family, where tools like Gopherus and SSRFmap assemble the payload for you — the PUT is just more bytes to write. The handshake slows that class of attack down; nothing in the protocol stops it. The second gap is more uncomfortable for Kubernetes shops: by default, every pod on an EKS node can reach 169.254.169.254, fetch a token, and read the node's role credentials, so one compromised container equals the node's identity. Scoping credentials per service account with IRSA or EKS Pod Identity matters more here than the IMDS version ever will. The third gap bites during incidents: the handshake protects future requests, but credentials already handed out keep evaluating successfully until they expire. IMDSv2 is prevention, not revocation.

The hop limit has its own trap. Container networking routes pod traffic to the host through a bridge, and that extra hop decrements the TTL — with the default limit of 1, perfectly legitimate pods cannot complete the token handshake and fail in confusing, quiet ways: applications hang at startup, SDKs retry into a loop, and nothing prints an obvious error. AWS's guidance to raise the limit to 2 on containerized workloads fixes the pods and, in the process, weakens the defense by exactly one relayed hop. The honest posture is hop limit 2 where containers genuinely need IMDS, paired with a CNI network policy that blocks 169.254.169.254 from every pod that doesn't.

Detection: the reads you never see in CloudTrail

None of this shows up where most teams look first. IMDS reads are not AWS API calls, so CloudTrail records nothing at the moment the credentials are pulled — your first visible evidence arrives downstream: enumeration calls like GetBucketLocation and ListBuckets, GetObject volume spikes, or API calls from addresses the role has never used before. GuardDuty covers the specific scenario with the finding type UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, which fires when credentials issued to an EC2 instance are used from outside AWS — in practice, from the attacker's own infrastructure. Host-level detection is cheap and high-signal: a single iptables or nftables LOG rule on OUTPUT matching destination 169.254.169.254 tells you which processes are talking to metadata, and the answer is usually a shorter list than you fear.

• ▪Run the fleet audit above and treat every HttpTokens: optional as open debt — internet-facing instances first.
• ▪Enforce required with hop limit 1 on plain instances and 2 on containerized ones, set in launch templates so new instances inherit it rather than relying on memory.
• ▪On EKS, scope credentials per service account with IRSA or Pod Identity, and default-deny link-local from pods with a Calico or Cilium network policy.
• ▪Inventory your SSRF surface: webhook verifiers, import-from-URL fields, avatar and image fetchers, PDF generators. These are the features that become IMDS proxies.
• ▪During an incident involving instance-role credentials, restrict the role's policies immediately — IAM evaluates them at call time, so stolen keys go inert without waiting for rotation.
• ▪Confirm GuardDuty is enabled in every region you operate in and that InstanceCredentialExfiltration.OutsideAWS pages a human.