SSRF Hunting Guide — Tools & Practical Steps

1. Mindset: How to Think Like an SSRF Hunter

SSRF is less about “one magical payload” and more about **recognizing the patterns** where a server has to make a request on behalf of the user. Whenever you see:

• Any feature that **fetches a URL** you provide.
• Any feature that **imports data** from an external resource.
• Any feature that **previews a link or file** before saving.

…you should immediately ask yourself:

“Can I make this server talk to something it should not talk to?”

Common SSRF Entry Points

• Profile picture import via URL.
• “Fetch URL and convert to PDF” / screenshot services.
• Webhook / callback URLs.
• RSS or JSON feed importers.
• URL preview / link unfurling (like link thumbnail previews).
• Any place where backend fetches a URL you control.

2. Building a Simple SSRF Recon Checklist

While testing a target, keep this mini-checklist handy:

• Search for parameters like: url, uri, link, target, callback, webhook, feed, img, avatar, redirect, next.
• Look at every “import from URL” or “fetch from URL” feature inside the app.
• Look at integration settings (Slack, Discord, email webhook, payment webhooks, etc.).
• Look at internal tools or admin panels (often more SSRF-prone than public pages).

3. Core Tools for SSRF Hunting

3.1 Burp Suite (Core Tool)

Burp is your main weapon for SSRF:

• Proxy — to capture every request and spot URL-like parameters.
• Repeater — to manually modify and resend requests with test URLs.
• Intruder — for fuzzing multiple payloads and encodings.
• Burp Collaborator — to detect **blind SSRF**.

Practical Workflow

1. Turn on Burp Proxy and browse the app normally.
2. Look in HTTP history for any parameter that clearly looks like a URL.
3. Send interesting requests to Repeater.
4. Start replacing parameter values with SSRF test URLs (examples below).

3.2 Burp Collaborator / Interactsh (for Blind SSRF)

Not all SSRF will show you a visible response. Sometimes, the server will silently request your URL in the background — that’s blind SSRF.

For this, you need an external interaction service, such as:

• Burp Collaborator (built into Burp Pro).
• Public services like Interactsh (if allowed by the program).

Basic idea:

1. Generate a unique URL in Burp Collaborator or Interactsh.
2. Put that URL as the value in the parameter you suspect is SSRF-vulnerable.
3. Send the request.
4. Check Collaborator/Interactsh — if you see a DNS/HTTP hit, the server made a request → SSRF exists.

4. Payload Sets for SSRF Testing

4.1 Basic Reachability Checks

Start simple. Does the server even try to fetch external URLs you give it?

https://your-burp-collaborator-id.oast.live
https://example.com/

If you get:

• Any preview of your site.
• Any error mentioning your domain.
• A hit on Collaborator / Interactsh.

…then the parameter is likely SSRF-capable.

4.2 Internal Network Probing

Next, try internal IPs (where SSRF gets interesting):

http://127.0.0.1
http://localhost
http://127.0.0.1:22
http://127.0.0.1:3306
http://127.0.0.1:5000
http://10.0.0.1
http://192.168.0.1

Observe:

• Different error messages for open vs closed ports.
• Time delays (longer response could mean open port / hanging connection).

4.3 Cloud Metadata Endpoints (High Impact)

For cloud-hosted apps, the metadata service is a goldmine.

If the SSRF is strong enough to reach these endpoints, you may be able to exfiltrate: IAM role names, temporary access keys, instance details, and more.

5. Bypassing Simple Protections

5.1 Localhost / Private IP Block Bypasses

Developers sometimes block obvious values like 127.0.0.1 or localhost. Try:

http://127.1
http://2130706433
http://0x7f000001
http://0177.0.0.1

These all represent the same address: localhost.

5.2 Using DNS to Reach Internal Services

Sometimes, internal services are only accessible by hostname, like http://internal-api/. If you don’t know the hostnames, try:

• Common words: http://admin/, http://api/, http://intranet/, http://grafana/.
• Brute forcing with a wordlist via an automated tool (respecting rate limits and program rules).

6. Turning a “Small” SSRF into a High-Impact Bug

Many reports stop at “I can make the server fetch my domain”. That’s a start, but not always enough for a high payout. Try to escalate impact:

• Reach metadata endpoints (cloud credentials).
• Read internal status pages (e.g., admin panels, health checks).
• Access internal developer tools (Jenkins, Grafana, Kibana, etc.).
• Hit internal APIs that return sensitive data.
• Combine SSRF with another bug (like an open Docker API → remote code execution).

7. Example: A Practical SSRF Hunting Flow

1. Step 1 — Recon

   Browse the app through Burp, list all parameters that look like URLs or redirection paths.

2. Step 2 — Initial test

   Send promising requests to Repeater and test with your Collaborator URL. Look for any external callbacks.

3. Step 3 — Internal probing

   Try 127.0.0.1, local ports, and private network IPs to see if behavior changes.

4. Step 4 — Metadata check

   Carefully test 169.254.169.254 endpoints to see if cloud metadata is reachable.

5. Step 5 — Escalate impact

   Enumerate exposed internal services/APIs and demonstrate how that can lead to data access or RCE.

8. How to Present Your SSRF Finding in a Report

When you finally find SSRF, structure your report like this:

1. Summary: One or two lines explaining what you did and why it’s serious.
2. Location: Exact endpoint and parameter, e.g. POST /api/fetch?url=.
3. Steps to reproduce: Clear instructions with full requests and responses.
4. Impact: What internal systems you accessed or could access (metadata, internal dashboards, etc.).
5. Recommendation: Short, practical fix suggestions (allow-list, block internal IP ranges, etc.).

9. What to Practice Next

You can sharpen your SSRF skills by:

• Solving SSRF labs on platforms like PortSwigger Web Security Academy.
• Recreating simple SSRF-prone apps locally (e.g. a “fetch URL” feature) and testing against them.
• Reading public bug bounty write-ups that involve SSRF → cloud compromise or SSRF → RCE chains.