👻 When a Proxy Becomes a Spy: Hunting an SSRF That Led Straight Into the Server Room

Back again with another write-up, and this one's a personal favorite because the bug didn't come from hours of manual clicking — it came from my own tool quietly waving a little flag going "psst… hey… you might wanna look at this one." 🚩

So grab your chai ☕, get comfy, and let me tell you about the day a friendly little proxy endpoint decided it trusted literally everyone on the internet a bit too much.

⚠️ Quick heads-up: The real target is redacted throughout. I'll be using example.com everywhere. Please don't go poking at random endpoints without permission — that's not hacking, that's just volunteering for a very awkward legal email. 😅

So, What Even Is SSRF? 🤔

SSRF (Server-Side Request Forgery) is a vulnerability where you trick the server into making HTTP requests on your behalf. 🎭

Picture it like this: you're standing outside a fancy office building with a strict "employees only" door. You can't get in. But there's a super helpful intern (the server) who is allowed inside, and he'll happily fetch anything you ask for. So instead of breaking in, you just smile and say "hey buddy, could you grab me that file from the back room?" — and off he goes. 🏃‍♂️💨

That "back room" is the internal network. Databases, admin panels, cloud metadata endpoints, health-check pages — all the stuff that's supposed to be firewalled far, far away from the outside world. If the intern never checks where he's being sent… congratulations, you've got yourself an SSRF.

Now, onto the fun part. 🍿

Enter HackLens 🔦

So I've been building my own recon tool called HackLens (github.com/yogeshbhandage/hacklens) — a bug bounty automation tool that runs straight from your terminal. You point it at a domain, hit enter, and go make a sandwich 🥪 while it handles the whole boring-but-crucial part: subdomain enumeration, alive checks, JS & URL collection, secret scanning, and a pile of vuln checks — then it spits out a clean JSON report and a pretty HTML report you can actually read without crying.

One command. That's the whole vibe:

bash run.sh -d example.com --deep --subs

bash run.sh -d example.com --deep --subs

While it was busy enumerating subdomains and hoovering up every URL and endpoint it could find, one particular request in the crawled-endpoints output made me stop mid-sandwich-bite. 🥪👀

It was a WordPress admin-ajax.php call — and sitting right there in the query string was a parameter named url:

https://example.com/wp-admin/admin-ajax.php?mbuilder_ajax=12&action=proxy&url=http://...

https://example.com/wp-admin/admin-ajax.php?mbuilder_ajax=12&action=proxy&url=http://...

action=proxy… url=… a server-side proxy handler with a user-controlled destination. 🚨

Look, if you've done this long enough, a parameter named url sitting in a request is like finding a door labeled "DO NOT OPEN" in a horror movie. You know you're going to open it. It was never a choice. 🚪😈

The Vibe Check: does it actually fetch what I tell it to? 🎯

First question — does this thing genuinely go fetch whatever I stuff into the url parameter? Only one way to find out. I pointed it at a domain I control:

...&action=example_proxy&url=http://evil.com

...&action=example_proxy&url=http://evil.com

And… it fetched it. 🎉 The application reached out to my attacker-controlled domain and cheerfully rendered the content right back to me.

At this point the intern had officially agreed to run errands for a complete stranger off the street. Excellent. But fetching external stuff is only mildly spicy. 🌶️ The real question hanging in the air was: would he go inside the building? 🏢

Turning the Server Against Itself 🔁

Time to point the proxy right back at itself. And what better target than the most iconic address in all of hacking — good ol' localhost:

...&action=example_proxy&url=http://127.0.0.1:80

...&action=example_proxy&url=http://127.0.0.1:80

And the server… happily returned content from the service running on 127.0.0.1:80. 😮

That right there is the "oh no" moment. The moment a mildly-curious bug graduates into a genuine security problem. The server was now reaching into its own internal network — a place I have absolutely zero business being — and handing me the results on a silver platter. 🍽️

Can I Map the Internal Network? (Spoiler: yep) 🗺️

Getting a response from port 80 was great, but a single open port is a party of one. 🎈 The real prize would be enumerating internal services — basically using this endpoint as a port scanner that the server runs on my behalf.

So I aimed it at a port I was pretty sure was shut:

...&action=example_proxy&url=http://127.0.0.1:1234

...&action=example_proxy&url=http://127.0.0.1:1234

And the response came back different from the port 80 one — not an error I caused, but a genuinely distinct "yeah, nothing's listening there" behavior. 🔍

And that's the golden insight right there: open ports and closed ports respond differently.

• Port 80 (open) → content comes back ✅
• Port 1234 (closed) → different response, connection fails ❌

Which means by just cycling the port number, I could sit comfortably on the outside and map out exactly what's listening on the inside. The server had quietly become my personal reconnaissance drone. 🛸 It wasn't a proxy anymore — it was an accomplice. 🤝

The Plot Twist That Bumped It to Critical 💥

Honestly? I could've stopped here. It was already a solid finding. But then my brain did that thing brains do and whispered "…what if the internal Apache has its status page exposed?" 😈 — you know, the mildly cursed intrusive thought every hacker eventually gets.

Here's the context: Apache's /server-status page (from mod_status) is normally locked down to localhost only, because it spills. Like, a lot. Active requests, client IPs, the exact URLs being hit, request methods, internal endpoints — it's basically the server live-tweeting everything it's doing in real time. 📡

And here's the beautiful, terrible part: from the server's own point of view, I am localhost. The proxy was making the request from inside the building. 🎭

So instead of guessing internal paths one by one like a caveman 🦴, I let a wordlist do the heavy lifting and fuzzed the path:

...&action=example_proxy&url=http://127.0.0.1/FUZZ

...&action=example_proxy&url=http://127.0.0.1/FUZZ

…and one of the hits that came flying back was /server-status. 🎯 So naturally, I pointed the proxy straight at it:

...&action=example_proxy&url=http://127.0.0.1/server-status

...&action=example_proxy&url=http://127.0.0.1/server-status

And there it was. The full internal Apache status page — live requests and all — rendered right back to me through the SSRF. 🤯

That is the exact moment a Medium-severity SSRF grows up, gets a job, and becomes a Critical. I now had a live window into the server's internal activity, a proven way to enumerate internal services, and a clear path to reach resources that were never, ever meant to see daylight. 🌑

Why This Actually Matters (the "so what" bit) 📊

Let's zoom out on everything this one little url= parameter quietly handed over:

• 🌐 Arbitrary external requests — the server fetches any URL you feed it
• 🏠 Internal service access — localhost and internal-only services become reachable
• 🔎 Internal port enumeration — open vs. closed ports respond differently, so the internal network becomes mappable
• 📡 Sensitive info disclosure — the exposed /server-status page leaked live internal request data

In the wrong hands, an SSRF like this is a launchpad — for hitting cloud metadata endpoints, pivoting to internal admin panels, or chaining into something even nastier. It's the classic "looks small until you realize the entire internal network was standing right behind it" bug. 🚪💀

The Fix (for the blue team reading this) 🛡️

If you're maintaining a proxy-style endpoint, here's how you stop your intern from running errands for strangers:

• ✅ Allowlist, don't blocklist. Only permit the specific external domains the feature actually needs. Everything else gets a firm, polite "no."
• 🚫 Block internal ranges. Reject 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.169.254 (hello there, cloud metadata) — after resolving DNS, not before.
• 🧭 Validate the resolved IP, not just the string. Attackers adore DNS rebinding and sneaky redirect tricks. Check where the URL actually lands.
• 🎯 Ask if you even need a proxy at all. Half the time the safest SSRF fix is a hard look in the mirror and "…why does this endpoint exist?"

Wrapping Up 🎁

And that's the tale of the proxy that trusted everyone. It started as a single suspicious parameter that HackLens surfaced during recon, snowballed into internal network access, and ended as a Critical thanks to one exposed status page and one gloriously intrusive thought. 🧠✨

Moral of the story: never trust user input, never trust a url= parameter, and definitely never let your server become someone else's errand boy. 🏃‍♂️

🛠️ The Tool Behind This Hunt

Since folks always ask — yep, HackLens is my own tool, it's open source, it's free, and it's the reason this endpoint ever crossed my radar.

🔦 HackLens — automated recon & vuln scanning from your terminal

👉 github.com/yogeshbhandage/hacklens

Point it at a domain and it runs the entire pipeline end-to-end so you don't have to babysit ten different tools:

• 🌐 Subdomain enumeration — 10+ sources (crt.sh, Subfinder, Amass, Assetfinder & friends)
• 💓 Alive checks with httpx
• 🕸️ JS & URL collection — this is the stage that surfaced this very endpoint
• 🔑 Secret scanning — 240+ patterns (AWS, Stripe, JWTs, OAuth, DB URIs, you name it)
• 🎯 Reflected XSS — 3-phase, context-aware, ready-to-use PoC URLs
• ↪️ Open redirect — 3-layer detection with bypass probes
• 🗂️ Information disclosure — 70+ probe paths (actuators, .git, .env, stack traces & more)

When it's done, it hands you a clean JSON report plus a visual HTML report you can review and submit. One command:

bash run.sh -d example.com --deep --subs

bash run.sh -d example.com --deep --subs

It can also chew through a pre-crawled URL list (-l urls.txt) or a full Burp Suite XML export (-b burp_export.xml) if you've already got traffic to feed it.

🧩 HackLens for Burp — the passive watcher

👉 github.com/yogeshbhandage/burp_hacklens

And if you live inside Burp like the rest of us, there's a companion extension too. HackLens for Burp is a Burp Suite scanner that quietly watches your traffic and flags interesting stuff while you browse like a normal human being — no loud active scans, no noise, just a chill little extension in the background going "psst, you might wanna look at this." 👀 Perfect for manual testing where you want a second pair of eyes on everything flowing through Burp.

Stars ⭐, forks 🍴, and PRs are always appreciated on both. If you build something cool on top of them, I'd genuinely love to hear about it.

Thanks for reading, folks! If you enjoyed this one, drop a clap 👏 and I'll catch you in the next write-up. Happy (and ethical) hacking! 🐛🔨

Disclaimer: This was found and reported responsibly through proper disclosure channels. All identifying details have been redacted. Only test systems you're authorized to test. Stay legal, stay curious. 🤝