Beginner Friendly 
SSRF to Pwned
Learn how EC2 instance metadata makes SSRF vulnerabilities much more dangerous!
Overview
We created this beginner-friendly lab to showcase how a Server Side Request Forgery (SSRF) vulnerability can potentially be much more severe, when the website is hosted on an EC2 instance.
Scenario
Rumors are swirling on hacker forums about a potential breach at Huge Logistics. Your team has been monitoring these conversations closely, and Huge Logistics has asked you to assess the security of their website. Beyond the surface-level assessment, you're also to investigate links to their cloud infrastructure, mapping out any potential risk exposure. The question isn't just if they've been compromised, but how deep the rabbit hole goes.
Lab prerequisites
Learning outcomes
- Familiarity with the AWS CLI
- Web enumeration and SSRF identification
- Understanding of EC2 instance metadata, and how it can facilitate further access
S3 bucket enumeration - Understanding of mitigations and best practices that could have prevented the attack
Real-world context
The Capital One breach was carried out by exploiting a SSRF vulnerability, which allowed the attacker to send requests to resources that should have been inaccessible. This vulnerability was used to access metadata of an AWS EC2 instance, which then provided the attacker with security credentials for an IAM role that had excessive permissions. This allowed the attacker to access data stored in an AWS S3 bucket that contained sensitive information of Capital One customers.
The data breach resulted in the exposure of personal information of over 100 million people in the United States and 6 million people in Canada. The exposed data included names, addresses, zip codes/postal codes, phone numbers, email addresses, dates of birth, and self-reported income. Also compromised were customer status data, credit scores, credit limits, balances, payment history, contact information, and fragments of transaction data.
The breach was a major event in cybersecurity and has led to extensive discussions about cloud security, the principle of least privilege, and the appropriate use of security measures like firewalls and monitoring systems. It highlighted the need for organizations to rigorously follow best practices for securing their systems and data. This attack scenario was in part possible due to insecure default settings, and is still exploitable at the time of writing.
KEY TAKEAWAY
Server-side request forgery is rated as a web vulnerability and behaves as a credential disclosure vulnerability in the cloud. The instance metadata service hands temporary credentials to whatever asks from the host, and an application that can be made to send a request is asking on the attacker's behalf.
What this lab covers
You enumerate a web application, identify a feature that fetches a URL supplied by the user, and use it to reach the metadata endpoint and obtain credentials for the instance's IAM role.
This is the canonical cloud attack chain and it is worth doing early. Once you have seen it, a large fraction of cloud incident reporting becomes legible, because the same shape recurs constantly.
It assumes no prior AWS experience and is one of the best starting points for web testers moving into cloud security.
How SSRF reaches AWS credentials
SSRF occurs when an application fetches a resource from a location influenced by user input. Features that import from a URL, render a preview, fetch a webhook or convert a remote document are all candidates, and the vulnerability is the server making the request rather than the user.
The instance metadata service answers on a link-local address reachable only from the instance. It returns instance configuration and, critically, temporary credentials for the attached IAM role, without any authentication, because reaching it is treated as proof of being the instance.
That assumption is what SSRF breaks. The application is on the instance, so its requests come from the instance, and an attacker who controls the destination is effectively making requests as the host. The credentials returned are legitimate and time-limited, and they carry whatever the role permits.
How to detect this in your own environment
Alert on instance role credentials used from outside the instance. AWS surfaces this pattern directly, and it is one of the highest-fidelity cloud detections available because there is no benign explanation.
Watch for metadata endpoint access from application processes rather than from the SDK or agent. This is the host-level signal and it fires earlier than credential misuse.
Log outbound request destinations from your applications. Requests to link-local or internal addresses from a feature that should be fetching public URLs are visible if anyone is recording them.
How to prevent it
Require IMDSv2. The session-oriented method requires a token obtained by a specific request type before credentials are returned, which defeats the common SSRF case where the attacker can only cause a simple request.
Validate destinations against an allow list and resolve addresses before connecting, so a hostname resolving to a link-local or internal address is rejected. Deny lists of known-bad targets are consistently bypassed.
Scope the instance role narrowly. SSRF will happen eventually somewhere in an estate, and the role attached to the workload decides whether that is an incident or a breach.
Real-world context
The 2019 Capital One breach is the defining example, documented in the US Department of Justice case record. According to the company's disclosure and the subsequent US Department of Justice indictment, an SSRF weakness against a misconfigured web application firewall led to instance metadata credentials being obtained and used to access data in S3, affecting around 106 million people.
That incident is the reason IMDSv2 exists and why the guidance shifted so firmly. The chain required no vulnerability in AWS itself, only an application flaw and a role with more access than the workload needed.
The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application and T1552.005 Cloud Instance Metadata API.
Applying this at work
- Audit whether IMDSv2 is required rather than optional across your instances, and enforce it. Many accounts still permit the older method.
- Review the IAM roles attached to internet-facing workloads and reduce them to what the application actually uses.
- Search your applications for features that fetch user-supplied URLs and validate destinations against an allow list.
- Add detection for metadata access from web application processes.
- Confirm you would be alerted if instance credentials were used from outside the instance.
Frequently asked questions
Why is SSRF worse in the cloud than on-premises?
Because the instance metadata service returns credentials to anything that can request them from the host. A request forgery therefore becomes credential theft, without the application itself being compromised.
Does IMDSv2 fully prevent this?
It defeats the most common case, where the attacker can only cause a simple request, by requiring a token obtained through a specific request method first. It is a strong control rather than an absolute one, so scoping the role still matters.
What is the correct way to prevent SSRF?
Validate destinations against an allow list and resolve addresses before connecting so names resolving to internal ranges are rejected. Filtering for known-bad targets is repeatedly bypassed.
Do I need my own AWS account to practice this?
No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.
Which certification covers this in depth?
The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.