SSRF: The Complete Practical Guide to Server-Side Request Forgery

Internal Network Pivoting with SSRF

Using one SSRF as a foothold into a whole subnet: mapping live hosts and ports, chaining service to service, and reaching what should never face the internet.

Published

A single SSRF is a periscope into a whole network. Reaching one internal service is useful, but the real prize is using that foothold to move, mapping the subnet, hopping from one internal host to the next, and arriving at the system the perimeter was built to protect. Pivoting is where SSRF stops being a bug on one app and becomes a route through the infrastructure behind it.

One SSRF as a periscope

The SSRF gives you the server's view of the internal network, and that view is far wider than the one app. From that single vantage point you can see and probe everything the server can reach: other services on the host, other hosts on the subnet, and the management interfaces that assume no outsider is watching. The trick is to treat the SSRF not as a way to read one page but as a lens you can point anywhere inside.

Mapping live hosts and ports

Start by drawing the map. Sweep the internal ranges and the common ports, reading the timing and error differences the way you would for a single target:

http://10.0.0.1/ ... http://10.0.0.254/        find live hosts
http://10.0.0.5:6379/   http://10.0.0.5:9200/   find what they run

An open port that answers, a refused connection, and a silent timeout each tell you something. Build a picture of which hosts are alive and which services sit on them before you try to use any of them.

Chaining service to service

Pivoting is chaining. Each internal service you reach can hand you the next step:

  • An internal service leaks a hostname or an internal URL in its response, pointing you at the next host.
  • A reachable config or metadata endpoint reveals credentials or service addresses.
  • One service can be made to talk to another, extending your reach a hop further than the SSRF alone.

You are not making one request. You are using the answer to each request to shape the next, working deeper into the network.

Why single-page labs stop here

A single-container lab can teach you the mechanics of one SSRF beautifully, but it cannot teach pivoting, because there is only one host. Moving across machines, using one foothold to reach the next, needs a network to move across. That is the gap a multi-host range fills: it models an internal environment with several hosts and services, so you practice the actual skill of chaining rather than just the single hop. If you have only ever done single-target SSRF, pivoting is the thing worth seeking out a range to learn.

Building a mental map

Good pivoting is mostly bookkeeping. Keep track of what you have found: which hosts answered, what services they run, what each one revealed, and which paths you have not yet followed. The internal network is invisible to you except through the narrow window of the SSRF, so the map you build in your notes is the only picture you have. Attackers who pivot well are disciplined mappers.

Reaching what was never meant to face the internet

The destination of a pivot is usually something that has no business being reachable: a domain controller, a secrets store, a build server, a database with everything in it. These systems are often weakly protected precisely because they sit "deep inside," behind layers everyone assumed an outsider could never cross. A chain of SSRF-driven hops crosses those layers one at a time, and the final target tends to be soft because nobody expected a stranger to ever knock on it.

Pivoting is the payoff that makes SSRF a top-tier finding: one URL field, and a path all the way to the crown jewels. Build the skill on a multi-host target, keep every payload and bypass from this cluster handy in the cheat sheet, and go practice the full chain on a free live target.

← Back to SSRF: The Complete Practical Guide to Server-Side Request Forgery