Post cover image

September 4, 2026

Pivoting: From Meterpreter to the Internal Network with SOCKS & Proxychains

قَالَ اللَّهُ تَعَالَى: “يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ ۚ وَاللَّهُ بِمَا تَعْمَلُونَ…

By Mohammed AL-Jilani

7 min read

قَالَ اللَّهُ تَعَالَى: "يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ ۚ وَاللَّهُ بِمَا تَعْمَلُونَ خَبِيرٌ" (سورة المجادلة، الآية 11).

Hello my homies, I forgot the last time I wrote a topic like this.

In this article, we will learn what the next step is after exploitation and getting a session on the victim's device. We will focus on pivoting: what it is and how we can use a simple pivoting technique to understand it.

Picture the scene: you've spent some time trying to get into a machine, tried a few things, and finally Meterpreter pops a full session on the box. You've got a shell. Nice moment, but let's be honest: this isn't the end of the story. It's only half of it.

What comes next? You use that access to go further. That's what this article is about, not how I got the first foothold, but what I did after compromising the machine, using pivoting to reach and scan an internal network I couldn't access directly.

All commands and outputs are from an isolated, authorized training environment. Real names and addresses have been replaced with Target 1 and Target 2.

So, what actually is pivoting?

Let me simplify it as much as I can: imagine you're trying to get to a house inside a gated community, and the guard at the gate doesn't know you, so he won't let you in. But you have a friend who lives inside the community and can move around freely. The obvious solution? Ask him to get you what you need from the inside, instead of trying to break through the gate yourself.

That's literally pivoting: a post-exploitation technique where an attacker uses a compromised machine as a bridge to route network traffic between themselves and other machines they can't reach directly. The machine that plays this role is called the Pivot Host because, unlike you, it has simultaneous access to both networks: the attacker's network and the isolated internal network behind it.

Pivot host bridging the attacker's subnet and the internal network's subnet

Look at the diagram: the Attacker PC and the Internal Network are on different subnets, while the Pivot Host connects them as a member of both networks.

How did I actually know Target 2 existed?

Let me be straight with you: in this particular lab, I didn't actually discover Target 2 myself. The scenario gave me two targets from the start: Target 1, which I compromised from outside, and Target 2, which was inside the internal network and only reachable from the victim machine.

But in a real pentest, you won't always be given the internal targets. So, how would you find them?

  1. Check the compromised machine's network interfaces using ipconfig (Windows) or ip a (Linux). A second interface on a different IP range is a strong sign that the machine is dual-homed and connected to an internal network.
  2. Discover live hosts in that internal range. You can use: → arp -a or Meterpreter's post/windows/gather/arp_scanner → A ping sweep such as run post/multi/gather/ping_sweep → db_nmap -sn if autoroute is already configured
  3. Scan the discovered hosts to identify open ports and services, then decide where to go next.

In my case, I skipped the discovery step because Target 2 was already provided by the lab. After stabilizing my session with migrate, I moved straight to verifying whether Target 1 could reach Target 2, and whether I could reach it through the pivot.

Before building anything, verify the hypothesis

I tried this first, straight from my own machine:

ping Target2.local

PING Target2.local (10.4.25.12) 56(84) bytes of data.
--- Target2.local ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1046ms

100% packet loss, as expected, since there's no route to that address from where I'm sitting.

But I tried the exact same command from inside the Meterpreter session, i.e. from Target 1's point of view:

C:\Windows\system32>ping 10.4.25.12

Pinging 10.4.25.12 with 32 bytes of data:
Reply from 10.4.25.12: bytes=32 time=1ms TTL=128
Reply from 10.4.25.12: bytes=32 time<1ms TTL=128

Instant reply. Target 1 sees Target 2 without any trouble, because it's a member of the internal network through a second network interface it has, and I'm not a member of it.

This exact difference is what makes pivoting possible in the first place: I can't reach it, but Target 1 can, so I can let it reach it on my behalf.

None

Step 1: Turning the Meterpreter session into a router (autoroute)

The first tool I used was autoroute. Its job is simple: it tells Metasploit to route traffic to the internal network through the Meterpreter session on Target 1.

meterpreter > run autoroute -s 10.4.25.12/20

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 10.4.25.12/255.255.240.0...
[+] Added route to 10.4.25.12/255.255.240.0 via 10.4.28.5
[*] Use the -p option to list all active routes

The warning tells us that run autoroute is the old method and that post/multi/manage/autoroute is now recommended.

The important part is the route itself: → -s 10.4.25.12/20 tells Metasploit to route the entire /20 network through this session, rather than just Target 2. → via 10.4.28.5 confirms that Target 1 is being used as the gateway to that network.

  • At this point, Metasploit knows how to reach the internal network through Target 1.
Packet path via autoroute from the attacker's machine through the Meterpreter session and into the internal network

But there's a problem: autoroute alone isn't enough

I got stuck here for a bit because I tried running regular Nmap straight at Target 2, and it didn't work, even though I'd already added the route.

The reason? autoroute only defines the route inside Metasploit itself. Metasploit-aware tools like db_nmap can use it, but regular Nmap, smbclient, and other tools running outside Metasploit have no idea that this route exists.

So I needed one more step.

Step 2: Routing my own tools through a SOCKS proxy

This is where the SOCKS proxy comes in, and it's what actually solves the problem above. The idea is that it acts as a bridge that takes traffic from any tool I run on my own machine and passes it to Metasploit, which then routes it through Target 1 to the internal network, allowing that traffic to reach the internal network as if I were sitting right there myself.

Think of it like an ambassador: it takes your message as it is, delivers it to the other side, and brings the reply back, without you ever needing to connect to the internal network directly.

a) Confirm the proxychains configuration

First, I opened the config file and made sure the last line was set correctly:

nano /etc/proxychains4.conf

socks4  127.0.0.1 9050

This line tells proxychains: "Take any tool that passes through me and route its traffic through a SOCKS4 proxy running locally on port 9050." The port has to match the port used by the SOCKS proxy in Metasploit; otherwise, the chain won't work.

b) Background the session and start socks_proxy

I went back to Metasploit and backgrounded the current Meterpreter session, without closing it, since I still needed it as the pivot:

meterpreter > background
[*] Backgrounding session 1...

Then I started the module responsible for running the SOCKS server:

msf > use auxiliary/server/socks_proxy
msf auxiliary(server/socks_proxy) > set SRVPORT 9050
SRVPORT => 9050
msf auxiliary(server/socks_proxy) > set VERSION 4a
VERSION => 4a
msf auxiliary(server/socks_proxy) > exploit
[*] Auxiliary module running as background job 0.
[*] Starting the SOCKS proxy server

Quick breakdown of each option:

  • SRVPORT 9050: the same port I set in proxychains4.conf earlier. This is the meeting point between the two tools.
  • VERSION 4a: tells Metasploit to run the server as SOCKS4a, while proxychains is configured to use SOCKS4. Both sides need to use a compatible SOCKS version.

Finally, I confirmed the service was actually running with the jobs command:

msf auxiliary(server/socks_proxy) > jobs

Jobs
====

Id  Name                            Payload  Payload opts
--  ----                            -------  ------------
0   Auxiliary: server/socks_proxy

As long as job 0 shows up here, the SOCKS server is up and waiting for connections.

The full chain, now

  • From this point on, any tool I run through proxychains travels along this path:
proxychains <any tool> --> Metasploit (SOCKS on port 9050) --> Target 1 (Pivot Host) --> Internal network

I didn't need to move any of my tools onto Target 1. They all stayed on my own machine, while the chain above handled the routing to the internal network.

None

The real test: scanning Target 2 through the chain

The real test was Target 2, the same machine I couldn't even ping earlier. This time, I scanned it through proxychains :

proxychains nmap Target2.local -sT -Pn -sV -p 445

[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-08-21 15:59 IST
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  10.4.25.12:445  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  10.4.25.12:445  ...  OK
Nmap scan report for Target2.local (10.4.25.12)
Host is up (0.10s latency).

PORT    STATE SERVICE      VERSION
445/tcp open  microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
Service Info: OS: Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Nmap done: 1 IP address (1 host up) scanned in 6.52 seconds

A few points are worth clarifying here:

  • [proxychains] Strict chain ... OK: each line means that a connection successfully made it through the chain (my machine → SOCKS 9050 → Target 1 → 10.4.25.12:445). If the chain breaks anywhere, you'll see <--denied instead of OK.
  • -sT: I used a TCP connect scan instead of the default SYN scan because proxychains can't pass raw packets the way a SYN scan requires—it needs a full TCP handshake.
  • -Pn: I skipped host discovery (ping) because ICMP doesn't work through this type of proxy.

The result: the scan went through successfully and even identified the OS, Windows Server 2008 R2/2012, without me having to interact with Target 1 manually.

What to take away from all this

If you had to boil the whole idea down to one sentence: pivoting isn't some mysterious "advanced" step, it's simply exploiting trust that already exists in the network's design. One dual-homed machine, one foot outside and one foot inside, is enough to expose an entire network you thought was completely out of reach.

Here's how you should think about it in any environment you're working on:

  • If you have a shell on a box, first check what it can reach that you can't, using ipconfig/ip a, arp -a, and route print.
  • autoroute lets Metasploit's own tools use the internal route, while socks_proxy + proxychains lets your regular tools use it too.
  • From a defensive angle, a new route or a SOCKS proxy running on an ordinary server is a strong indicator worth monitoring, while proper network segmentation between the perimeter and the internal network can break this chain at the first step.

Follow me for more security content!