Metadata Credentials at 18:40 on a Friday
An e-commerce marketplace lets its 200 sellers import product images by URL. While testing the import feature you submit http://169.254.169.254/latest/meta-data/iam/security-credentials/ and receive a role name; appending that name to the path returns an AccessKeyId, SecretAccessKey and Token that expire in six hours. The endpoint follows redirects, and any authenticated seller can reach it. The instance uses IMDSv1. The rules of engagement state: no lateral movement, no access to customer data, no modification of production resources, and critical findings must be reported within 24 hours to the client's 24/7 number. It is Friday at 18:40 and the client's security team is reachable. You have not used the credentials for any API call.
1. What are your actions in the next 60 minutes?
Read the worked answer
Do not use the credentials. Not even sts:GetCallerIdentity. It is read-only and it is tempting as proof, but the RoE says no lateral movement, and using a credential harvested from the instance is the step that converts an exposure into an access. The client can validate the credential from their side; I hand it over and let them decide.
Call now. Friday 18:40 is still their business day, the 24/7 number exists for exactly this, and the 24-hour clause is a ceiling rather than a target. The keys expire in six hours, so the misuse window for these specific values is short - but the role is durable, and every instance assuming it is exposed by the same bug.
Transmit safely. Report the vulnerable URL and the role name over the agreed channel. Do not paste the secret access key into email, chat or a ticket. If the client needs to confirm the exact values, encrypt the annex to their PGP key, or point them at their own records - the SSRF request appears in the application log, and IMDS retrieval itself is not a CloudTrail event, so the application log is their only trace.
Record. Exact request and path, timestamp, source IP, response hash, and a screenshot with the secret truncated.
Advise immediately. Attach a session-revocation policy that denies requests made with tokens issued before a cutoff (or move the instance profile to a new, narrower role), enforce IMDSv2 with HttpTokens: required and a hop limit of 1, and block 169.254.169.254 at the egress proxy so that the next SSRF of this class does not reach the metadata service at all.
2. How do you document the finding so it is actionable but does not itself become a credential leak, and should the client treat this as a breach?
Read the worked answer
Report content. Critical: an SSRF reachable by any of 200 sellers, resolving to IMDSv1 and yielding role credentials. Include the request, the role name, the fact that key material was returned (without printing it), the six-hour expiry, and the redirect-following behaviour and absent destination validation, which are the fix surface.
What stays out. Secrets. If the client insists on seeing exact values, deliver them through an encrypted annex or a one-time link, labelled as containing credentials, so they land in the incident file rather than a shared drive.
Breach determination - the reasoning chain. Credentials left the instance and were received by a party outside the instance: me, under authorisation. That is not unauthorised access, but it establishes that the same data was reachable by anyone who could hit the endpoint, including a seller with a valid account and bad intent. The client cannot distinguish my retrieval from a hostile one using the metadata service alone, because IMDS calls are not recorded in CloudTrail. So my position is: treat it as a potential credential compromise, not a theoretical finding, and run the checks that would tell them which it was.
What they should check. CloudTrail for API calls made with that role from IPs outside their ranges between the exposure time and revocation; GuardDuty findings for instance credential exfiltration; and the application log for other requests to 169.254.169.254 from other seller accounts. Then revoke, then fix the SSRF and the IMDS configuration.
Timeline. Reported by phone within the hour, written report inside the 24-hour clause, retest after the fix, and an explicit note that the credentials were never used so their forensic timeline stays clean. If they ask me to validate the credential myself, I want it in writing with a defined scope, and I would still prefer they do it.