Port Forwarding

Imagine we are conducting a penetration test and discover a critical vulnerability on a public-facing web server. By exploiting this flaw, we achieve remote code execution, which gives us a shell on a Linux-based e-commerce web server exposed to the internet on port 8000.

At this point, we already have a foothold. The next question from a red team mindset is simple:

What else can this compromised server access that we cannot see from the internet?

This is where internal networks, secondary interfaces, and pivoting techniques come into play.

After initial enumeration, we notice something interesting:

• The web server has two network interfaces:
  
  • One interface connected to the internet
    
  • Another interface connected to the internal organizational network
    

Through this internal interface, the web server communicates with a PostgreSQL database server running on port 5432, which is not accessible from the internet.

This is a classic and realistic architecture:

• Public web server in a DMZ
  
• Backend database isolated inside the internal network
  

While exploring the compromised web server, we find a configuration file where the database credentials are hardcoded:

• Database username
  
• Database password
  
• Internal database IP address
  

From an attacker’s perspective, this is a valuable discovery. However, there is a limitation.

Normally, we would connect to PostgreSQL using the psql client. But in this case:

• The psql client is not installed on the web server
  
• We do not have root access, so we cannot install new packages
  

So even though we have valid credentials, we cannot connect to the database directly from the compromised host.

Since the web server can already reach the internal database, we can use it as a bridge between our attack machine and the internal network.

The goal is to:

• Expose a port on the compromised web server
  
• Forward any traffic received on that port to the internal PostgreSQL service
  

This technique is known as port forwarding or pivoting.

We assume the utility socat is already installed on the compromised web server (a common scenario).

What We Want to Achieve

• Listen on port 9000 on the web server’s internet-facing interface
  
• Forward all incoming traffic to:
  
  • Internal database server: 10.10.10.20
    
  • PostgreSQL port: 5432
    

Command Executed on the Compromised Web Server

What This Command Does

• TCP-LISTEN:9000→ Listens for incoming TCP connections on port 9000
  
• fork → Creates a new process for each connection, allowing multiple sessions
  
• TCP:10.10.10.20:5432 → Forwards all traffic to the internal PostgreSQL database server
  

At this point, the web server is acting as a tunnel into the internal network.

Now we move back to our attacker machine (for example, Kali Linux).

Even though the database is internal, we can connect to it indirectly through the web server.

Assume:

• Public IP of the web server: 203.0.113.10
  
• Forwarded port: 9000
  

Connection Command from the Attacker Machine

What This Command Does

• -h 203.0.113.10 → Public IP of the compromised web server
  
• -p 9000 → Forwarded port
  
• -U postgres → Database username found in the config file
  

From the database’s point of view, the connection still comes from the web server. But we are now controlling that connection remotely.

Once connected to the database, the attack surface expands significantly.

Typical red team actions may include:

• Enumerating tables and schemas
  
• Extracting user accounts and password hashes (for example, from a cwd_user table)
  
• Cracking password hashes using tools like Hashcat
  
• Testing for credential reuse across other services
  

If any recovered credentials are reused elsewhere (such as SSH access), this can lead to:

• Lateral movement
  
• Privilege escalation
  
• Deeper compromise of the internal network
  

socat is powerful and flexible, but it is not the only option.

Depending on the environment, operating system, and level of access, a red team operator can choose from several port forwarding techniques:

rinetd

A lightweight and simple TCP port forwarding tool, useful when minimal configuration is required.

iptables (NAT rules)

Effective when root access is available on Linux systems, allowing transparent and high-performance port forwarding at the network layer.

SSH tunneling

A common choice when SSH access exists and outbound connections are allowed. It provides encryption and blends well with legitimate administrative traffic.

Netsh portproxy (Windows)

A native Windows port forwarding method. Using netsh interface portproxy, inbound traffic on a Windows host can be forwarded to an internal service. When combined with a temporary Windows Firewall rule, this technique enables pivoting through Windows systems without dropping external tools.

Each method has different requirements, limitations, and detection footprints. An effective red team operator selects the approach that best fits the target environment and the constraints imposed by the network and host defenses.

Port forwarding is a foundational pivoting technique that allows red teams to extend their reach beyond the initial compromise, turning a single foothold into a gateway for deeper network exploration.

In this scenario, we demonstrated how a compromised public-facing web server—with direct connectivity to an isolated internal PostgreSQL database—can be leveraged as a pivot point. By using lightweight tools like socat, we established a simple yet effective tunnel:

• Listening on an attacker-accessible port on the web server
• Forwarding traffic seamlessly to the internal database service
• Enabling direct interaction (via psql) from the attacker’s machine as if the restrictions didn’t exist

This approach requires minimal tools, no privilege escalation, and leaves a relatively small footprint—making it ideal for real-world engagements where stealth and reliability matter.

Key Takeaways

• Even without native clients on the victim host, valid credentials combined with port forwarding can unlock restricted internal services.
• Tools like socat, rinetd, iptables, SSH tunneling, and netsh provide flexible options depending on OS, access level, and network constraints.
• Successful pivoting often leads to high-value post-exploitation outcomes: credential harvesting, hash dumping, lateral movement, and further compromise.
• Always evaluate multiple forwarding methods and choose the one that best balances capability, detectability, and stability in the target environment.

Mastering basic port forwarding techniques like these is essential for any red team operator. They form the building blocks for more advanced tunneling methods (such as the SSH and HTTP-based approaches covered in later sections) and enable consistent progress through segmented, defense-in-depth networks.

Practice these methods extensively in labs, combine them with proper enumeration, and you’ll find that few internal services remain truly out of reach once a suitable pivot host is compromised.