Introduction
Server Side Request Forgery (SSRF) is a vulnerability that allows an attacker to abuse a vulnerable server to make HTTP requests to internal systems that are normally protected by a firewall. It is particularly dangerous because it enables indirect access to internal resources by relaying through a compromised web application.
SSRF Payload Techniques and Filter Evasion
SSRF—Server-Side Request Forgery—slips in through bad coding habits. It usually starts with a web app, built in something like PHP or Flask, that lets users submit a URL. The app then fetches or interacts with that URL on the user’s behalf. If that input isn’t cleaned up or checked properly, it opens the door for abuse.
Attackers take advantage by feeding the app internal or restricted addresses instead of external ones. The server, doing what it’s told, makes the request—sometimes hitting private services that were never meant to be exposed. That’s the core of SSRF.
The video walks through different payloads depending on how locked down the system is. It starts with basic stuff—trying to connect to 127.0.0.1:3306 to hit MySQL. If that gets blocked, attackers don’t give up. They just switch tactics.
They use IPv6 loopback like [::], or swap out the address format completely. That means decimal-style IPs (like 2130706433, which is just 127.0.0.1 in disguise), or even hexadecimal versions. These alternate formats are sneaky—they get past filters that are only looking for standard patterns.
Each trick is designed to get past one more layer of security. And often, it works, especially on apps that weren’t built with security in mind.
Bypassing Firewalls with SSRF
One of the biggest advantages of SSRF is how it sidesteps firewall rules. Instead of trying to get through the firewall from the outside, attackers use the vulnerable server itself—because that machine usually is allowed to talk to other internal services. That trust becomes a weapon.
In the video walkthrough, this plays out clearly. After getting SSRF working, the attacker uses it to do more than just check if ports are open. They take it a step further—using the server to grab data directly. In this case, it’s the /etc/passwd file, which lists local system users.
That file isn’t super sensitive on its own, but it’s a clear sign of access. It proves that SSRF can do more than poke around. If the server has broader read permissions—and often it does—it can be used to pull all kinds of internal information.
So instead of just being a tool for scanning, SSRF turns into a doorway for stealing data. Especially when web servers have sloppy permissions or access more than they should. That’s when what looks like a small bug becomes a full-blown breach.
Enumerating System Users
Once the attacker pulls the /etc/passwd file, they don’t just look at names—they start digging for patterns. One easy but effective move? Counting how many entries have home directories.
In Unix-like systems, not every line in /etc/passwd points to a real user. Many are just system accounts with no login or shell access. But if an entry has a home directory—like /home/james or /root—that usually means it’s a human user. Someone who logs in, has files, maybe even SSH keys or credentials worth stealing.
By scanning for these, the attacker gets a sense of how many actual users are on the system. It’s quiet, no alarms, just reading a file and counting lines.
But this kind of passive recon gives a lot away. It helps identify which users have been around a while, which ones might be admins, and where to focus next. All without needing to trigger noisy tools or brute force anything. Just reading and thinking.
Port Scanning via SSRF
To map out what services are running inside the network, the attacker uses a bash script to do some quiet port scanning. Instead of using noisy tools like Nmap that might trigger alerts, this method just loops through ports one by one and checks the size of the HTTP response it gets back.
The idea is simple—send a request to each port and look at how big the reply is. In this lab setup, closed ports always return a 1045-byte response. So if a port answers with something different? It probably means something’s listening there.
The script logs those ports, and by the end, five stand out as open. It’s slow, subtle, and blends into regular web traffic—making it great for sneaking around in environments where stealth matters more than speed.
TryHackMe SSRF | Room Answers
How many ports are open?
How many users are there on the system?
Video Walkthrough
