7.2 Port Forwarding & SOCKS Proxy Tunneling

7.2 Port Forwarding & SOCKS Proxy Tunneling

While adding routes within Metasploit enables the framework's internal auxiliary and exploit modules to communicate with isolated subnets, penetration testers inevitably encounter operational bottlenecks when relying exclusively on Metasploit modules. Modern security assessments require specialized external utilities—such as comprehensive Nmap port scanning scripts, web vulnerability scanners, web browsers for manual application auditing, database administration clients, and protocol-specific authentication tools like smbclient or xfreerdp.

Because these external binaries run natively on the host operating system and cannot interface directly with Metasploit's internal virtual routing table, offensive operators bridge the network divide using two primary tunneling techniques: static port forwarding via Meterpreter (portfwd) and dynamic SOCKS proxy tunneling combined with Proxychains.

---

Port Forwarding with Meterpreter (portfwd)

Meterpreter includes a built-in port forwarding subsystem accessed via the portfwd command. Port forwarding creates a dedicated point-to-point network tunnel through an established Meterpreter session. It operates by instructing the attacker's machine to open a local TCP listening port. Whenever an application on Kali connects to that local port, Meterpreter encapsulates the data stream, transmits it across the encrypted Command & Control (C2) channel to the compromised pivot host, and instructs the pivot host to open a connection to the specified internal target IP and port.

+-----------------------------------------------------------------------------------------+
|                            METERPRETER PORT FORWARDING FLOW                             |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|  [Attacker: Kali Linux]                                                                 |
|  +-----------------------------------------------------------------------------------+  |
|  | Client Application: xfreerdp /v:127.0.0.1:3389                                    |  |
|  | Connects to local port 3389                                                       |  |
|  |                                                                                   |  |
|  | Meterpreter Client listens on 127.0.0.1:3389                                      |  |
|  | Encapsulates RDP traffic into Meterpreter TLV packets                            |  |
|  +-----------------------------------------------------------------------------------+  |
|         |                                                                               |
|         | [Encrypted C2 Channel over 10.10.14.20:4444]                                  |
|         v                                                                               |
|  [Compromised Pivot Host]                                                               |
|  +-----------------------------------------------------------------------------------+  |
|  | Meterpreter Payload unpackages TLV stream                                         |  |
|  | Forwards raw TCP packets to 192.168.2.50:3389 (Internal DC)                      |  |
|  +-----------------------------------------------------------------------------------+  |
|         |                                                                               |
|         | [Internal Network Link]                                                       |
|         v                                                                               |
|  [Isolated Target Host: 192.168.2.50]                                                   |
|  +-----------------------------------------------------------------------------------+  |
|  | Windows RDP Service (Port 3389) replies to Pivot Host (192.168.2.15)              |  |
|  +-----------------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------------+

Local Port Forwarding Syntax

In a local port forwarding configuration, the listening port is bound on the attacker's local machine (-l), forwarding traffic to the remote target's IP (-r) and port (-p):

# Syntax:
# portfwd add -l <Local_Port> -p <Remote_Port> -r <Remote_Target_IP>

# Example 1: Forward local port 3389 to an internal Windows host's RDP port
meterpreter > portfwd add -l 3389 -p 3389 -r 192.168.2.50
[*] Local TCP relay created: :3389 <-> 192.168.2.50:3389

# Example 2: Forward local port 8080 to an internal intranet web server
meterpreter > portfwd add -l 8080 -p 80 -r 192.168.2.10
[*] Local TCP relay created: :8080 <-> 192.168.2.10:80

Interacting with Forwarded Services

Once the local TCP relay is established, the penetration tester interacts with the remote internal target by directing tools to 127.0.0.1 (localhost) at the designated local port:

# Connect to the internal Windows Remote Desktop service via the forwarded port
xfreerdp /v:127.0.0.1:3389 /u:Administrator /p:'Password123'

# Audit the internal web application using cURL or a browser pointing to localhost
curl -i http://127.0.0.1:8080/admin/login.php

# Run Nikto or Gobuster against the forwarded internal web service
gobuster dir -u http://127.0.0.1:8080/ -w /usr/share/wordlists/dirb/common.txt

Managing Active Port Forwards

Meterpreter allows inspecting, deleting, and clearing active forwarding relays:

# List all active port forwarding rules
meterpreter > portfwd list

Active Port Forwards
====================
   Index  Local                  Remote               Direction
   -----  -----                  ------               ---------
   1      0.0.0.0:3389           192.168.2.50:3389    Forward
   2      0.0.0.0:8080           192.168.2.10:80      Forward

# Delete a specific port forward by its local port
meterpreter > portfwd delete -l 3389
[*] Successfully stopped TCP relay on :3389

# Clear all active port forwarding rules simultaneously
meterpreter > portfwd flush
[*] Successfully flushed all port forwards

---

Dynamic SOCKS Proxy Tunneling with Metasploit

While Meterpreter's portfwd is ideal for interacting with specific known services (such as an RDP port or internal web server), it is impractical when conducting broad network discovery across an entire subnet. Forwarding ports individually for hundreds of potential IP addresses and thousands of destination ports is unmanageable.

A SOCKS proxy solves this problem by providing dynamic, application-level proxying. Rather than binding a static port for a single destination, a SOCKS proxy opens a single local port (typically port 1080) that accepts connection requests destined for any arbitrary IP address and port on the internal network.

Deploying the Metasploit SOCKS Proxy Server

Metasploit provides a dedicated auxiliary module that acts as a SOCKS server. The module interfaces directly with Metasploit's virtual routing table. When any application sends traffic to the SOCKS listener, Metasploit inspects the destination IP, matches it against its routing table, and relays the connection through the corresponding Meterpreter session.

# Select the SOCKS proxy module (Metasploit 6)
msf6 > use auxiliary/server/socks_proxy

# Configure proxy parameters
msf6 auxiliary(server/socks_proxy) > set SRVHOST 127.0.0.1
SRVHOST => 127.0.0.1
msf6 auxiliary(server/socks_proxy) > set SRVPORT 1080
SRVPORT => 1080
msf6 auxiliary(server/socks_proxy) > set VERSION 5
VERSION => 5

# Disable authentication for local lab testing
msf6 auxiliary(server/socks_proxy) > show options
msf6 auxiliary(server/socks_proxy) > run -j
[*] Auxiliary module running as background job 0.
[*] Starting the SOCKS proxy server on 127.0.0.1:1080...

Note on Metasploit versions: In legacy Metasploit 5 frameworks, the module was named auxiliary/server/socks4a. In modern Metasploit 6, auxiliary/server/socks_proxy supports both SOCKS4a and SOCKS5 protocols (configured via set VERSION 5 or set VERSION 4a).

# Verify the background job is active
msf6 > jobs

Jobs
====
  Id  Name                           Payload
  --  ----                           -------
  0   Auxiliary: server/socks_proxy  

---

Configuring and Using Proxychains

Although the Metasploit SOCKS proxy server is now listening on 127.0.0.1:1080, external tools on Kali Linux do not automatically know to send their traffic there. Many tools (such as Nmap, smbclient, and Hydra) do not have native SOCKS proxy support built into their command-line flags.

Proxychains (specifically proxychains4, the modern version of Proxychains-NG) overcomes this limitation. Proxychains relies on the dynamic linker preload facility (LD_PRELOAD) in Linux. When a command is executed with proxychains, Proxychains injects a shared library that hooks into standard C library (libc) network socket functions—specifically connect(), gethostbyname(), and close(). The injected library intercepts the connection attempt and redirects it through the configured SOCKS proxy server transparently.

Editing the Proxychains Configuration File

The configuration file is located at /etc/proxychains4.conf (or /etc/proxychains.conf on older systems). Open it in a text editor to verify or adjust the following directives:

# /etc/proxychains4.conf

# Chaining method: dynamic_chain is strongly recommended for penetration testing
dynamic_chain

# Quiet mode: suppress diagnostic connection logging
# quiet_mode

# Proxy DNS requests through the proxy to prevent DNS leakage and resolve internal hostnames
proxy_dns

# Timeouts (in milliseconds)
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
# Configuration format:
# protocol  ip         port   [username] [password]
socks5      127.0.0.1  1080

Chaining Modes Explained

1. dynamic_chain (Recommended): Each connection is tunneled through the proxies listed in [ProxyList] in sequential order. If one of the proxies is offline, it is simply skipped, and the connection attempts to proceed through the remaining active proxies.
2. strict_chain: Every connection must traverse every listed proxy in exact order. If a single proxy is unreachable, the entire connection fails immediately.
3. random_chain: Randomly selects proxies from the list, primarily used for anonymity routing.

---

Executing External Tools Through Proxychains

Prefixing any command with proxychains forces its network socket connections through the local SOCKS proxy and across the Metasploit pivot:

# 1. Scanning internal host TCP ports with Nmap
proxychains nmap -sT -Pn -p 21,22,80,139,445,3389 192.168.2.10

# 2. Interacting with internal web servers using cURL
proxychains curl -i http://192.168.2.10/admin/

# 3. Enumerating SMB shares on internal Windows targets
proxychains smbclient -L //192.168.2.10/ -N

# 4. Connecting via SSH directly to an internal Linux server
proxychains ssh admin@192.168.2.25

# 5. Launching an interactive browser routed into the target intranet
proxychains firefox &

---

Critical Technical Constraints & The TCP-Only Rule

Penetration testers frequently encounter frustrating scan failures when using Proxychains for the first time. Understanding the underlying protocol mechanics prevents these common errors:

1. The Strict TCP Limitation

SOCKS proxies (both SOCKS4a and standard SOCKS5 implementations used in security tools) encapsulate standard TCP byte streams. They do not support raw IP packet crafting or raw socket operations. As a result:

• Nmap SYN Scan (-sS) Fails: The default Nmap scan is a SYN stealth scan (-sS), which crafts raw TCP packets lacking full handshake completion. Raw packet creation bypasses the standard connect() library calls hooked by Proxychains. If executed, Nmap either crashes, reports all ports as filtered, or leaks raw packets out the local physical interface.
• Mandatory -sT Flag: Testers must explicitly instruct Nmap to use the TCP Connect scan (-sT). The -sT flag forces Nmap to utilize standard libc connect() system calls, which Proxychains successfully intercepts and routes.
• UDP Scanning (-sU) Fails: UDP packets cannot be tunneled through standard Proxychains SOCKS configurations. Scanning UDP services (SNMP, DNS, TFTP) through a basic SOCKS pivot is not supported.

2. Ping Suppression (-Pn)

By default, Nmap sends ICMP echo requests and TCP ACK/SYN probes to determine whether a target host is online before scanning ports. Because ICMP packets cannot traverse SOCKS proxies, all ping probes fail. Nmap will conclude that the target host is offline ("Host seems down") and terminate the scan without probing any ports. Testers must always specify -Pn to disable host discovery and treat all internal targets as alive.

3. Latency & Concurrency Throttling

Every TCP packet routed through Proxychains and Metasploit traverses multiple translation layers: socket hooking -> local SOCKS server -> Ruby process routing -> TLS encryption -> C2 network packet -> pivot host OS stack -> internal network transmission. Aggressive, multi-threaded scans (-T4 or -T5 in Nmap, or high-thread directory brute-forcing) will overwhelm the Meterpreter channel, causing dropped packets, false negative scan results, or session termination. Always throttle scan speeds to moderate levels (-T3 or -T2, --max-rate 50).

---

Port Forwarding vs. SOCKS Proxy & Proxychains Comparison

---

Proxychains Configuration Directives & Recipes Reference