7.1 Network Pivoting & Route Addition in Metasploit

eJPT Junior Penetration Tester Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: eJPT Foundations & Assessment Workflow

1.1 eJPT Exam Blueprint, Lab Architecture & Strategy 1.2 Penetration Testing Methodology & Standards

2 Chapter 2: Assessment Methodologies: Reconnaissance & Scanning

2.1 Open Source Intelligence (OSINT) & Information Gathering 2.2 Network Mapping & Port Scanning with Nmap 2.3 Service Enumeration & Operating System Detection

3 Chapter 3: Assessment Methodologies: Vulnerability Analysis

3.1 Service Vulnerability Identification & CVE Research 3.2 Vulnerability Impact Assessment & Prioritization

4 Chapter 4: Host & Network Auditing: System Enumeration

4.1 Linux Host & Network Enumeration 4.2 Windows Host & Privilege Enumeration 4.3 Network Services Auditing: SMB, FTP, SSH & Databases

5 Chapter 5: Host & Network Auditing: Data Collection & Credential Gathering

5.1 File Transfer Techniques for Linux & Windows 5.2 Credential & Password Hash Extraction

6 Chapter 6: Host & Network Penetration Testing: Exploitation & Metasploit

6.1 Exploit Analysis & Manual Modification 6.2 Metasploit Framework Architecture & Exploitation 6.3 Meterpreter Post-Exploitation Deep Dive

7 Chapter 7: Host & Network Penetration Testing: Pivoting & Password Attacks

7.1 Network Pivoting & Route Addition in Metasploit 7.2 Port Forwarding & SOCKS Proxy Tunneling 7.3 Network Service Brute-Forcing & Offline Hash Cracking

8 Chapter 8: Web Application Penetration Testing: Reconnaissance & Enumeration

8.1 HTTP Protocol Fundamentals & Burp Suite Interception 8.2 Directory & File Discovery with Gobuster

9 Chapter 9: Web Application Penetration Testing: Web Exploitation & Injections

9.1 Web Authentication Attacks & Login Brute-Forcing 9.2 SQL Injection (SQLi) Identification & Exploitation 9.3 Cross-Site Scripting (XSS), File Inclusion & Command Injection

7.1 Network Pivoting & Route Addition in Metasploit

Key Takeaways Explain This Topic AI

Network pivoting enables a penetration tester to leverage a compromised multi-homed system as an intermediary conduit to route traffic into isolated internal subnets.

Multi-homed hosts are identified during post-exploitation by auditing network interface configurations and routing tables with commands such as ip a, ifconfig, ipconfig /all, and route print.

Metasploit's internal routing table (route add or post/multi/manage/autoroute) directs Metasploit auxiliary scanners and exploit modules through established Meterpreter sessions.

Metasploit routing functions strictly within the framework process; external tools like Nmap, cURL, or web browsers cannot route through these internal paths without a proxy.

Last updated: October 2026

7.1 Network Pivoting & Route Addition in Metasploit

In modern enterprise environments and practical penetration testing assessments, organizations rarely place critical assets directly on internet-facing network segments. Defense-in-depth network architecture isolates high-value internal infrastructure—such as database servers, domain controllers, management appliances, and development workstations—behind perimeter firewalls, Demilitarized Zones (DMZs), and internal Virtual Local Area Networks (VLANs). An external penetration tester or red team operator who compromises an edge server (such as an external web server or VPN concentrator) frequently discovers that the compromised machine cannot reach the broader corporate network through direct, externally routable pathways.

To continue the assessment and assess the organization's true security posture, the tester must perform network pivoting . Pivoting is the technique of utilizing a compromised system (referred to as a pivot host or foothold ) as a gateway or intermediary conduit to tunnel network traffic, scan internal subnets, and launch targeted exploits against secondary machines that are otherwise inaccessible from the attacker's primary workstation.

Multi-Subnet Architecture & The Pivoting Scenario

Consider a classic enterprise segmented topology. The penetration tester operates from an external testing system (such as Kali Linux) connected to an edge network or external subnet. The perimeter web server possesses two distinct network interface cards (NICs), creating a multi-homed host configuration. One interface connects to the perimeter subnet accessible to the tester, while the second interface connects directly to an internal, non-routable corporate subnet. +-----------------------------------------------------------------------------------------+

| ENTERPRISE SEGMENTED PIVOT TOPOLOGY |
+-----------------------------------------------------------------------------------------+
| |
| +-----------------------+ +--------------------------------------+ |
| | Attacker System | | Compromised Pivot Host | |
| | (Kali Linux) | | (Dual-Homed Server) | |
| | | | | |
| | IP: 10.10.14.5/24 | === [Direct Link] ==| eth0: 10.10.14.20/24 (Perimeter) | |
| +-----------------------+ | eth1: 192.168.2.15/24 (Internal) | |
| +--------------------------------------+ |
| | |
| [Internal Switch / VLAN] |
| | |
| +---------------------------+-------------------+ |
| | | |
| +-------------------------------+ +-------------------------------+ |
| | Internal Target 1 | | Internal Target 2 | |
| | (Domain Controller) | | (Database Server) | |
| | | | | |
| | IP: 192.168.2.10/24 | | IP: 192.168.2.25/24 | |
| +-------------------------------+ +-------------------------------+ |
+-----------------------------------------------------------------------------------------+

In this scenario, attempting to send ICMP echo packets ( ping 192.168.2.10 ) or initiating a port scan ( nmap 192.168.2.10 ) directly from Kali fails immediately. The attacker's local routing table has no route for 192.168.2.0/24 , and edge firewalls drop packets destined for non-routable RFC 1918 internal subnets. The tester must establish a command-and-control foothold on the dual-homed server and configure a routing mechanism to channel assessment traffic through the compromised host's internal adapter.

Discovering Multi-Homed Targets

Once initial access is achieved and a shell or Meterpreter session is established on a target, post-exploitation host enumeration must immediately prioritize network adapter discovery. Identifying multi-homed configurations uncovers previously hidden subnets and attack paths.

Linux Interface & Route Auditing

On a compromised Linux host, query interface configurations, ARP caches, and kernel routing tables using standard system utilities: # Inspect all physical and virtual network interfaces and assigned IP subnets

ip addr show
# Legacy interface inspection
ifconfig -a

# Audit kernel routing tables to identify gateways and connected networks
ip route show
# Alternative routing display
netstat -rn
route -n

# Inspect ARP cache to identify active neighbor hosts on adjacent subnets
ip neigh show
cat /proc/net/arp

If ip addr reveals eth0 with 10.10.14.20/24 and a second interface eth1 configured with 192.168.2.15/24 , the host is confirmed to be multi-homed, providing a direct gateway into 192.168.2.0/24 .

Windows Interface & Route Auditing

On a compromised Windows system, execute the following commands from an interactive cmd.exe or PowerShell prompt: :: Enumerate all network adapters, IP addresses, subnets, and DNS servers

ipconfig /all

:: Display active routing table and persistent network routes
route print

:: Review the Address Resolution Protocol (ARP) table for known local IP addresses
arp -a

:: Enumerate active network connections and listening ports with process identifiers
netstat -ano
Meterpreter Native Interface Discovery

When operating within an interactive Meterpreter session, native commands query the remote operating system APIs directly without spawning new process binaries ( cmd.exe or /bin/sh ), minimizing operational noise: meterpreter > ipconfig

Interface 1
============
Name : lo
Hardware MAC : 00:00:00:00:00:00
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0

Interface 2
============
Name : eth0
Hardware MAC : 00:0c:29:4f:8e:1a
IPv4 Address : 10.10.14.20
IPv4 Netmask : 255.255.255.0

Interface 3
============
Name : eth1
Hardware MAC : 00:0c:29:4f:8e:24
IPv4 Address : 192.168.2.15
IPv4 Netmask : 255.255.255.0

meterpreter > route

IPv4 network routes
===================
Subnet Netmask Gateway Interface
----- ------- ------- ---------
0.0.0.0 0.0.0.0 10.10.14.1 eth0
10.10.14.0 255.255.255.0 0.0.0.0 eth0
192.168.2.0 255.255.255.0 0.0.0.0 eth1
Metasploit Routing Architecture: MSF Virtual Routing vs. OS Routing Table

Understanding the boundary between the Metasploit virtual routing table and the operating system kernel routing table is essential for effective pivoting.

When a route is added inside the Metasploit Framework (using the route add command or the autoroute post module), the route is registered strictly within the memory space of the msfconsole Ruby process . Metasploit does not modify the Linux kernel routing table on Kali Linux, nor does it create a virtual network interface (TUN/TAP) on the host operating system. +-----------------------------------------------------------------------------------------+

| METASPLOIT VIRTUAL ROUTING ARCHITECTURE |
+-----------------------------------------------------------------------------------------+
| |
| [Attacker Machine: Kali Linux] |
| +-----------------------------------------------------------------------------------+ |
| | Linux OS Kernel Space | |
| | - OS Routing Table: Default Gateway -> 10.10.14.1 | |
| | - Standalone CLI Tools: nmap, curl, hydra, ssh (BYPASS METASPLOIT ROUTE!) | |
| +-----------------------------------------------------------------------------------+ |
| | |
| +-----------------------------------------------------------------------------------+ |
| | msfconsole (User Space Ruby Process) | |
| | - MSF Virtual Routing Table: 192.168.2.0/24 -> Route through Meterpreter Session 1 | |
| | - MSF Modules: auxiliary/scanner/*, exploit/* (CAN ROUTE TO 192.168.2.0/24) | |
| +-----------------------------------------------------------------------------------+ |
| | |
| | [Encrypted TLS Command & Control Tunnel / Session 1] |
| v |
| [Compromised Pivot Host] |
| +-----------------------------------------------------------------------------------+ |
| | Meterpreter Payload -> Forwards packets out eth1 interface to 192.168.2.0/24 | |
| +-----------------------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------------+

Because Metasploit routes exist only within the framework:

All Metasploit modules (auxiliary scanners, exploit modules, payload handlers) automatically query the internal routing table. If a target IP address falls within a routed subnet, Metasploit encapsulates the packet data into Type-Length-Value (TLV) structures and sends it through the designated Meterpreter session.

External operating system commands executed from the Kali terminal (such as ping 192.168.2.10 , nmap 192.168.2.10 , or curl http://192.168.2.10 ) do not communicate with Metasploit's memory space. The Linux kernel evaluates its own routing table, fails to find a route to 192.168.2.0/24 , forwards the traffic to the default gateway, and drops the connection.

Adding and Managing Routes in Metasploit

Metasploit provides two methods for populating its internal routing table: manual route definition and automated discovery through post-exploitation modules.

Manual Route Addition

To route traffic destined for a newly discovered internal subnet through an established Meterpreter session, use the route command from the msf> console prompt: # Syntax:

# route add <Subnet_IP> <Netmask> <Session_ID>
# route add <CIDR_Subnet> <Session_ID>

msf6 > route add 192.168.2.0 255.255.255.0 1
[*] Route added

# Alternatively, CIDR notation is fully supported:

msf6 > route add 192.168.2.0/24 1
[*] Route added
Viewing and Deleting Routes
Verify that the route was registered correctly using route print : msf6 > route print

IPv4 Active Routing Table
=========================

Subnet Netmask Gateway
----- ------- -------
192.168.2.0 255.255.255.0 Session 1

If a session terminates or an incorrect subnet was added, remove the route or clear all active routes: # Remove a specific subnet route

msf6 > route remove 192.168.2.0 255.255.255.0 1
[*] Route removed

# Flush all registered Metasploit routes
msf6 > route flush
[*] Routing table cleared
Automated Route Management with autoroute

The post/multi/manage/autoroute post-exploitation module automates subnet discovery. It queries the target session's network adapters, identifies all attached subnets that differ from the primary connection, and automatically inserts the corresponding routes into Metasploit's routing table. # Method 1: Executing autoroute via the post module interface

msf6 > use post/multi/manage/autoroute
msf6 post(multi/manage/autoroute) > set SESSION 1
SESSION => 1
msf6 post(multi/manage/autoroute) > run

[!] SESSION 1 is active, querying interfaces...

[+] AutoRoute adding a route to 192.168.2.0/255.255.255.0 via session 1
[*] Post module execution completed

# Method 2: Running autoroute directly from within an active Meterpreter prompt
meterpreter > run post/multi/manage/autoroute

[!] SESSION 1 is active, querying interfaces...

[+] AutoRoute adding a route to 192.168.2.0/255.255.255.0 via session 1
[*] Post module execution completed

# View routes configured specifically by autoroute
meterpreter > run post/multi/manage/autoroute -p

Active Routing Table
====================
Subnet Netmask Gateway
----- ------- -------
192.168.2.0 255.255.255.0 Session 1
Executing Attacks and Scanning Across the Metasploit Route

Once Metasploit's virtual routing table contains a route to 192.168.2.0/24 via Session 1, any auxiliary scanner module or exploit module will automatically route its network requests through the Meterpreter channel.

Internal Subnet Host & Port Discovery

Because external port scanners like standalone Nmap cannot use Metasploit's internal routes directly, use Metasploit's built-in TCP port scanner auxiliary module ( auxiliary/scanner/portscan/tcp ): msf6 > use auxiliary/scanner/portscan/tcp

msf6 auxiliary(scanner/portscan/tcp) > set RHOSTS 192.168.2.1-254
RHOSTS => 192.168.2.1-254
msf6 auxiliary(scanner/portscan/tcp) > set PORTS 21,22,80,139,445,3389,8080
PORTS => 21,22,80,139,445,3389,8080
msf6 auxiliary(scanner/portscan/tcp) > set THREADS 10
THREADS => 10
msf6 auxiliary(scanner/portscan/tcp) > run

[+] 192.168.2.10:445 - 192.168.2.10:445 - TCP OPEN
[+] 192.168.2.10:139 - 192.168.2.10:139 - TCP OPEN
[+] 192.168.2.10:80 - 192.168.2.10:80 - TCP OPEN
[+] 192.168.2.25:22 - 192.168.2.25:22 - TCP OPEN
[+] 192.168.2.25:3306 - 192.168.2.25:3306 - TCP OPEN
[*] Scanned 254 of 254 hosts (100% complete)
[*] Auxiliary module execution completed

The port scanner transmits TCP SYN packets through the Meterpreter session. The pivot host completes the three-way TCP handshake with the internal targets and reports the open ports back to msfconsole.

Service Enumeration Through the Pivot

After identifying open ports, execute specialized Metasploit auxiliary modules against the newly discovered internal hosts to enumerate software versions and configurations: # Enumerate SMB versions and operating system releases on internal Windows targets

msf6 > use auxiliary/scanner/smb/smb_version
msf6 auxiliary(scanner/smb/smb_version) > set RHOSTS 192.168.2.10
msf6 auxiliary(scanner/smb/smb_version) > run

[+] 192.168.2.10:445 - Host is running Windows Server 2019 Standard Build 17763 (name:DC01) (domain:CORP.LOCAL)

# Enumerate SSH daemon banners on internal Linux servers
msf6 > use auxiliary/scanner/ssh/ssh_version
msf6 auxiliary(scanner/ssh/ssh_version) > set RHOSTS 192.168.2.25
msf6 auxiliary(scanner/ssh/ssh_version) > run

[+] 192.168.2.25:22 - SSH server version: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
Exploitation Considerations Across Routes

When launching an exploit module against an internal host across a Metasploit route, payload selection requires careful consideration:

Bind Payloads ( windows/meterpreter/bind_tcp or linux/x64/shell_bind_tcp ) : Bind payloads instruct the exploited internal target to open a listening port locally. Metasploit connects inbound to that port through the existing route. Bind shells are highly reliable across pivots because they do not require the internal target to initiate an outbound connection back to the attacker.

Reverse Payloads ( windows/meterpreter/reverse_tcp ) : If using a reverse payload, the internal victim machine cannot reach Kali's IP ( 10.10.14.5 ) directly. The payload will attempt to connect out, fail to find a route to Kali, and terminate. To use a reverse payload across a pivot, the tester must configure a multi-stage handler or use port forwarding to relay the reverse connection through the pivot host.

Metasploit Routing Commands & Workflow Reference

Action Context Command Syntax Description

Add Manual Route msf > route add 192.168.2.0 255.255.255.0 1 Registers a route to 192.168.2.0/24 through active Meterpreter Session 1.

Add CIDR Route msf > route add 192.168.2.0/24 1 Alternative CIDR syntax to register a subnet route via Session 1.

List Active Routes msf > route print Displays all subnets, netmasks, and gateway sessions in Metasploit's virtual table.

Remove Route msf > route remove 192.168.2.0/24 1 Removes a specific registered route from Metasploit's memory space.

Flush All Routes msf > route flush Clears all registered internal routes across all active sessions.

Auto-Detect Routes Meterpreter run post/multi/manage/autoroute Enumerates target interfaces and automatically adds all secondary subnet routes.

Print AutoRoutes Meterpreter run post/multi/manage/autoroute -p Prints active routes established specifically by the autoroute script.

Internal TCP Scan msf > use auxiliary/scanner/portscan/tcp Runs a multi-threaded TCP connect scan through active Metasploit routes.

SMB Version Scan msf > use auxiliary/scanner/smb/smb_version Fingerprints SMB OS and dialect versions on internal hosts via the pivot route.

Multi-Subnet Pivoting Execution Lifecycle

Phase Objective Command / Action Verification Metric

Phase 1: Initial Compromise Obtain shell on perimeter machine Launch exploit module against edge service (e.g., Apache, vsftpd) Meterpreter Session 1 opens on 10.10.14.20:4444 .

Phase 2: Interface Discovery Identify hidden internal subnets meterpreter > ipconfig or route Identify secondary adapter eth1 on 192.168.2.15/24 .

Phase 3: Route Registration Direct MSF traffic through session msf > route add 192.168.2.0/24 1 Output from route print shows 192.168.2.0/24 -> Session 1 .

Phase 4: Internal Reconnaissance Locate live hosts and open ports use auxiliary/scanner/portscan/tcp Detect internal targets (e.g., 192.168.2.10:445 , 192.168.2.25:22 ).

Phase 5: Service Auditing Fingerprint internal daemon versions use auxiliary/scanner/smb/smb_version Discover unpatched OS build or exploitable internal software.

Phase 6: Pivot Exploitation Compromise secondary target Configure exploit with set RHOSTS 192.168.2.10 and bind payload Meterpreter Session 2 opens on internal target 192.168.2.10 .