Study guide
7.2 Port Forwarding & SOCKS Proxy Tunneling
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.2 Port Forwarding & SOCKS Proxy Tunneling
Key Takeaways Explain This Topic AI
Meterpreter port forwarding (portfwd) binds a local listening port on the attacker's system and tunnels TCP traffic directly to an arbitrary internal IP and port via the compromised host.
Metasploit's auxiliary/server/socks_proxy module creates a dynamic SOCKS4a or SOCKS5 proxy listener that routes arbitrary TCP traffic across established Metasploit routes.
Proxychains intercepts dynamic library network socket calls to route external binaries (such as Nmap, cURL, and smbclient) through the Metasploit SOCKS proxy.
SOCKS proxies and Proxychains strictly support TCP traffic; raw packet scans like Nmap SYN (-sS) and UDP (-sU) fail, requiring TCP Connect (-sT) scanning and ping suppression (-Pn).
Last updated: October 2026
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
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.
strict_chain : Every connection must traverse every listed proxy in exact order. If a single proxy is unreachable, the entire connection fails immediately.
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
- Feature / Attribute Meterpreter portfwd Metasploit SOCKS + Proxychains
- Tunnel Scope Point-to-Point (Single IP & Port) Dynamic Multi-Host / Multi-Subnet
Local Port Binding Binds a distinct local port per service (e.g., 3389, 8080) Binds a single proxy port (e.g., 1080)
External Tool Syntax Connect directly to 127.0.0.1:<local_port> Prefix commands with proxychains <tool>
Configuration Overhead Requires manual portfwd add for every target port Set up once in MSF and /etc/proxychains4.conf
Scanning Capability Infeasible for scanning ranges or multi-port sweeps Capable of scanning entire subnets ( nmap -sT -Pn )
Performance High throughput for individual data streams Slight latency overhead due to proxy negotiation
Primary Use Case Dedicated RDP sessions, internal web apps, SSH relays Initial internal subnet reconnaissance and multi-tool testing
Proxychains Configuration Directives & Recipes Reference
Directive / Recipe Context Syntax / Setting Operational Purpose
Dynamic Chain /etc/proxychains4.conf dynamic_chain Ensures connections skip dead proxies in the list without failing.
Proxy DNS /etc/proxychains4.conf proxy_dns Resolves hostnames via the proxy, preventing DNS leaks and resolving internal domains.
Proxy Definition /etc/proxychains4.conf socks5 127.0.0.1 1080 Specifies the local Metasploit SOCKS proxy IP, port, and protocol version.
Nmap TCP Scan Shell proxychains nmap -sT -Pn -p 22,80,445 192.168.2.10 Executes TCP connect scan without ping probes across the SOCKS tunnel.
Web Assessment Shell proxychains curl -s http://192.168.2.10/info.php Fetches internal web page headers and content via the pivot.
Directory Discovery Shell proxychains gobuster dir -u http://192.168.2.10/ -w list.txt -t 5 Performs throttled web path brute-forcing against internal intranet services.
SMB Client Shell proxychains smbclient -L //192.168.2.10 -N Queries internal Windows hosts for accessible null or anonymous shares.