AWS SSRF Credential Theft: Attack, Detection and IMDSv2 Defence

On 18 April 2025, Fortinet published an anonymised incident-response case involving a large cooperative bank migrating to AWS. Investigators reported SSRF in a public-facing web application reached through its public IP, exposed an EC2 IAM role through IMDSv1 and left evidence in CloudTrail and FortiCNAPP. The environment also had an over-permissive instance role and no WAF in front of the application load balancer; the response included IMDSv2, WAF protection, tighter IAM and improved monitoring [7]. Expel separately reported that SSRF accounted for 28% of the cloud incidents its SOC observed in 2023 and identified the EC2 role-credential path at 169.254.169.254 as the main technique [8].

AWS introduced IMDSv2 as defence in depth for open proxies, firewalls and SSRF vulnerabilities. It requires a session token obtained with an HTTP PUT before metadata can be read, and AWS says this combination protects against the vast majority of SSRF paths it analysed [1]. EC2 can be configured to reject IMDSv1 by setting metadata tokens to required [2].

• Sourced factFortinet documented a 2025 AWS incident in which SSRF against a public-facing application exposed IAM role credentials through IMDSv1 [7].
• Sourced factExpel found SSRF was the second most common cloud-incident cause its SOC observed in 2023, at 28% [8].
• Sourced factIMDS can provide temporary credentials for an EC2 instance role, while IMDSv2 adds session-oriented protections [1] [2].
• Lab assumptiona preview feature validates one route, then trusts a client-controlled internal rewrite header.
• Lab assumptionthe attached role can inspect its own exact role metadata and read one harmless versioned S3 marker whose archive location is exposed by the fictional application.
• Observed resultthe private qualification completed the bounded chain and produced application, CloudTrail, Config and Security Hub evidence plus two same-run GuardDuty findings: instance-credential exfiltration and Kali Linux activity.

The important difference is the request sequence. IMDSv1 accepts a direct tokenless GET to the link-local metadata address. IMDSv2 first requires a session token obtained with an HTTP PUT, then requires that token on the later metadata GET [1] [2]. A simple SSRF path that can issue only the final GET can therefore reach IMDSv1 but cannot complete the IMDSv2 exchange.

The private lab creates an isolated VPC with paired FastAPI targets on EC2, bounded IAM, a synthetic S3 object and deterministic telemetry. Neither target accepts inbound application traffic; the operator reaches each one through an authenticated Systems Manager tunnel. The application, role and data stay the same while the EC2 metadata-token setting changes.

The weakness is not “FastAPI” by itself. It is the trust decision after validation: the application checks the requested target, then accepts a separate internal rewrite value. That lets a crafted request reach IMDSv1, retrieve a temporary instance-role credential and use only the synthetic permissions deliberately granted by this lab.

The story starts at the application, not at IMDS. A visitor sees a fictional member-document portal that accepts a Document URL and returns a preview. That user-controlled URL is the first SSRF signal: the server, rather than the browser, may be making the outbound request.

The screenshot below is mitmweb, the browser interface supplied with mitmproxy. It was used during the local Kali rehearsal to keep one harmless POST /api/preview request and its 403 response together on screen. This makes the changed target_url easy to inspect, but it is not the source of the qualified AWS attack evidence and it never receives the temporary credential.

This is validation performed by the lab builder, not knowledge available to an external attacker. It proves the target was intentionally configured to accept tokenless IMDSv1 requests before the attack evidence is interpreted.

The live_qualification.py program is a safety harness around real HTTP and AWS CLI actions. It performs the request, checks the exact disposable Range account before every AWS call, pauses the running Kali terminal so CI can photograph the genuine result, and removes the temporary credential from memory when the chain ends. It does not manufacture terminal screenshots or replay a transcript.

The following credential hand-off and account guard are copied from the executable live_qualification.py harness.

FULL_CHAIN_EXECUTED means more than reaching IMDS. The tokenless IMDSv1 request returned a temporary EC2-role credential document; that stolen session was then used outside the instance for bounded STS, IAM and S3 actions before the credential was discarded.

• Application request → FastAPI structured event in CloudWatch Logs.
• STS GetCallerIdentity and IAM actions → CloudTrail management events and event JSON.
• Synthetic S3 read → CloudTrail object-level S3 data event.
• Off-instance role use → GuardDuty InstanceCredentialExfiltration.OutsideAWS finding.
• GetRole from the recorded Kali client → GuardDuty PenTest:IAMUser/KaliLinux finding.
• Tokenless metadata posture → AWS Config and Security Hub control results.

Credential acquisition matters because the temporary session inherits the EC2 role attached to the target. The next qualified capture must show that relationship in the AWS Console rather than expecting the reader to infer it from an ARN. The lab role is intentionally narrow; a production role with broader permissions would widen the same stolen credential’s impact.

The attacker-side action_id and timestamp are the first defender pivot. Start in the FastAPI application log to prove which bounded action ran, then carry that exact time window and temporary-role context into the CloudTrail log stream. S3 object activity appears only when data-event logging is explicitly configured [4].

AWS Config evaluates whether the instance requires IMDSv2 [3]. Security Hub EC2.8 surfaces the related EC2 control state [6]. These are posture findings: they explain why the path is possible, while the application and CloudTrail events show what happened.

The same Range run produced two relevant GuardDuty findings. InstanceCredentialExfiltration.OutsideAWS detected the EC2 role credential being used away from its instance. PenTest:IAMUser/KaliLinux identified GetRole from the Kali AWS client. Filter by each exact finding ID, investigate them separately and correlate both to the same role, time window and CloudTrail events [5]. Historical findings remain retained evidence; they are not part of this run.

The efficient comparison deploys the isolated Range and Secure counterparts together, then exercises them one after the other. Both use the same scenario commit and semantic request. The Range success is captured first; the Secure replay must stop at IMDSv2 before any credential or attacker AWS action exists.

The application and request do not change between the two targets. The enforcing Terraform difference is one EC2 metadata option: the vulnerable target permits tokenless IMDSv1 requests, while the secure target requires an IMDSv2 session token.

The replay below is the same action-2 method, path, headers and metadata destination. Only the isolated Secure application origin changes.