Server-Side Request Forgery and Cloud Metadata
On 22 July 2019, a former Amazon employee exploited a single misconfigured Web Application Firewall to exfiltrate approximately 100 million customer records from Capital One. No zero-day exploit was required. The technique: send a crafted HTTP request to the WAF that caused it to forward a request to http://169.254.169.254 — the AWS EC2 Instance Metadata Service. The WAF was running on an EC2 instance with an overprivileged IAM role. The attacker retrieved temporary AWS credentials in seconds, then used them to list and download S3 buckets containing credit card applications, Social Security numbers, and bank account data. The total regulatory fine reached $80 million.
The root vulnerability is Server-Side Request Forgery (SSRF): the server is tricked into making HTTP requests on the attacker's behalf. Unlike CSRF — where the victim's browser is the unwitting actor — SSRF makes the server the confused deputy. Because the request originates from inside the server's network, it can reach internal services that are completely inaccessible to an external attacker: internal APIs, admin panels, database management interfaces, and cloud metadata endpoints.
Cloud environments are uniquely exposed. Every AWS EC2 instance, every GCP Compute Engine VM, and every Azure Virtual Machine exposes a metadata service at the link-local address 169.254.169.254. This address is unreachable from the public internet — routers discard packets destined for it. But it is fully reachable from any process running on the instance, including the web application. And it requires no authentication. Any HTTP GET request from the instance returns configuration data. Navigate to the right path and you receive the instance's IAM role name; one more request yields AccessKeyId, SecretAccessKey, and SessionToken — working AWS credentials.
If the IAM role attached to the web application's instance has broad permissions (a common misconfiguration), those credentials grant the attacker the same access — to S3, DynamoDB, Lambda, RDS, EC2, or any other AWS service the role can reach.
What You Will Do in This Lab
You will exploit a URL-fetch endpoint that has no SSRF protection. Starting from a blank input, you will navigate the AWS metadata API step by step — discovering the instance's IAM role name and then retrieving its credentials. The credentials JSON contains a hidden CTF flag. Extract it and submit it to complete the lab.
Work methodically. The metadata service is a directory tree. Each level tells you where to go next.