SSRF → cloud metadata → IAM credential theft

When it applies

You have SSRF and the app runs on a cloud VM/container with an attached role. The metadata endpoint hands out temporary credentials to anything that can reach it from the instance.

Why it works

IMDS lives at a link-local IP (169.254.169.254) and trusts network position, not identity. SSRF gives you that position, so the app fetches the instance's role credentials for you — then you use them against the cloud API with the app's permissions.

Method

1. AWS IMDSv1 (no token): SSRF to http://169.254.169.254/latest/meta-data/iam/security-credentials/ → role name → .../security-credentials/<role> returns AccessKeyId, SecretAccessKey, Token.
2. AWS IMDSv2 (token required): needs a PUT to get a token, then a header on the GET — possible only if the SSRF can set method + X-aws-ec2-metadata-token header. Many SSRFs can't; note IMDSv2 as the mitigation if it blocks you.
3. GCP: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token with header Metadata-Flavor: Google (needs header-setting SSRF).
4. Azure: http://169.254.169.254/metadata/identity/oauth2/token?... with Metadata: true.
5. Use the creds (in scope only): configure the CLI with the temp key/secret/token and run read-only calls (aws sts get-caller-identity, s3 ls) to prove impact — don't touch data.

Gotchas

• IMDSv2/Metadata header requirements defeat header-less SSRF — that's a finding (says v2 is on), not a dead end.
• Temp creds expire fast; grab sts get-caller-identity immediately as proof.
• Containers may hit the ECS task metadata (169.254.170.2) instead of EC2 IMDS.

Verify success

aws sts get-caller-identity (or GCP/Azure equivalent) returns the instance role identity using credentials pulled through the SSRF.

References

PortSwigger SSRF labs; AWS IMDSv2 docs; "SSRF to cloud takeover" write-ups.