SSRF Attack: Steal Cloud Metadata Credentials

What is an SSRF attack?

A server-side request forgery (SSRF) attack tricks a server into making HTTP requests on the attacker's behalf. When an application fetches a user-supplied URL - to build a link preview, render a thumbnail, or call a webhook - an attacker can point it at addresses the server can reach but the attacker cannot: internal admin panels, databases, and, most dangerously in the cloud, the instance metadata service. This lab is built around that exact pattern.

How this lab works

You are looking at Previewly, a link-preview SaaS that turns any URL into a rich card by fetching it server-side. That fetch has no allow-list. Working entirely from the Attack Terminal with curl and jq, you will turn the preview feature into an SSRF primitive, reach the cloud metadata service at 169.254.169.254, read a secret leaked into the instance user-data for the user flag, then steal the instance's temporary IAM role credentials. Replaying that stolen session token against Previewly's over-permissive internal control-plane gives you the root flag. Every step is hands-on; nothing is simulated away.

Why practice SSRF and cloud metadata attacks?

SSRF against the metadata service is one of the highest-impact cloud attacks there is. In the 2019 Capital One breach, an SSRF flaw let an attacker read IAM credentials from 169.254.169.254 and exfiltrate over 100 million records from S3. The fix - IMDSv2, which requires a session token and blocks the naive SSRF - is now standard, but plenty of instances still allow IMDSv1. Practicing the full chain on HackerDNA builds the instinct to spot a vulnerable URL-fetch feature, recognize the metadata endpoint, and understand why least-privilege IAM roles matter.