Port Foward
Port forwarding is a technique where a host listens on one port and relays traffic to another destination. It’s commonly used for:
Allowing access to internal services from external networks.
Home routers directing specific traffic (e.g. gaming, remote access).
Attackers bypassing segmentation by routing traffic through a compromised host (pivot point).
Linux
In this scenario:
Attacker (Kali): On the WAN.
Target Web Server (
CONFLUENCE01): Exposed to the WAN and connected to a DMZ.Internal Database (
PGDATABASE01): In DMZ, not directly reachable from Kali.
A Wide Area Network (WAN) represents a large or public network, while a Demilitarized Zone (DMZ) acts as a buffer zone between a less trusted network and internal systems. Since Kali can’t directly access the DMZ, we'll need to leverage
CONFLUENCE01’s dual-network position to reachPGDATABASE01.

After exploiting a vulnerable Confluence instance (CVE-2022-26134) we gain a reverse shell on CONFLUENCE01. and enumerate its position on the network.
SSH
Socat
Socat is a powerful command-line utility for bidirectional data transfer between two data channels. In this case, we use it to forward TCP connections from one network interface on a compromised host to a service on a different network that’s otherwise unreachable.
Recap
We obtained a reverse shell on
CONFLUENCE01and we can execute commands as the limitedconfluenceuser.We identified that it has:
A WAN interface (
192.168.50.63) that our Kali machine can reachA DMZ interface (
10.4.50.63) that can reachPGDATABASE01at10.4.50.215:5432
CONFLUENCE01does not have (and we can't install) the tools needed (e.g.psql) to access the database server onPGDATABASE01.
Since we can’t install new software on CONFLUENCE01 and PGDATABASE01 isn’t accessible directly from our Kali machine, we can leverage socat to create a TCP port forward.
Listen on a chosen TCP port (e.g.,
2345) onCONFLUENCE01’s WAN-facing interface.Forward any connections received on this port to
10.4.50.215:5432on the DMZ side.
On
CONFLUENCE01, we'll start a verbose (-ddd) Socat process. It will listen on TCP port2345(TCP-LISTEN:2345), fork into a new subprocess when it receives a connection (fork) instead of dying after a single connection, then forward all traffic it receives to TCP port5432onPGDATABASE01(TCP:10.4.50.215:5432).
Once this forward is active:
From our Kali machine on the WAN, we connect to
192.168.50.63:2345.Socat relays this traffic internally from
CONFLUENCE01to10.4.50.215:5432.From our perspective, it’s as though the PostgreSQL service is directly accessible at
192.168.50.63:5433.

After some more enumeration of the internal network, we'll find PGDATABASE01 is also running an SSH server, so we can check for password reuse. We can kill the original Socat process listening on port 2345 and create a port forward on CONFLUENCE01 that will allow us to SSH directly from our Kali machine to PGDATABASE01.

In addition to classic utilities like socat, modern red teams and penetration testers often turn to newer tools built for better performance, stealth, and encryption. Two widely used tools in this category are chisel and ligolo-ng. Both simplify pivoting and port forwarding tasks, often in environments where direct connections are blocked by network segmentation or firewall rules. We’ll revisit our original scenario, substituting socat with these tools.
Chisel
Chisel is a fast, cross-platform, single-binary tool for tunneling TCP/UDP over HTTP or WebSockets. It can perform normal and reverse port forwarding and is a lightweight choice for pivoting through segmented environments.
Tansfer the binary to the target and connect back to our Kali on port 8000 and forward the client's 3306 port to the server's 6033 port:
Common Issues
System architecture and binary mismatch. Check if your binary matches system architecture:
Directory with no execute permissions: If a directory is mounted with noexec, binaries can’t run from there. Check mounts:
GLIBC compatibility issues. If you see:
…it means the binary expects a newer GLIBC than what’s installed. Use a statically linked version of the binary. Statically linked executables bundle their own libraries and don't rely on system GLIBC. Avoid .deb, .apk, or .rpm packages — those require elevated privileges and install system-wide. Instead, grab the raw, statically linked .gz binary:
Ligolo-NG
Ligolo-NG is a modern, agent-based tunneling utility for secure pivoting that establishes reverse TCP/TLS connections using a TUN interface, effectively creating a lightweight userland VPN for interactive pivoting and port forwarding — without relying on SOCKS proxies.
Tool Comparison
Socat
Low
Medium
No
✔️
❌
Classic and reliable
Chisel
Medium
High
Optional (HTTPS)
✔️
❌
HTTP/WebSocket tunnels
Ligolo-NG
Medium-High
High
✔️
✔️
✔️
Agent-based pivoting
Windows
SSH
On Windows versions with SSH installed, the ssh-* utilities can be found in %systemdrive%\Windows\System32\OpenSSH. Our scenario:
We have RDP access to
MULTISERVER03(198.168.177.64).We need to pivot into the internal network to reach services like PostgreSQL on
PGDATABASE01(10.4.177.215).Direct outbound connections from Kali to internal targets are blocked.
Only RDP is allowed into
MULTISERVER03.

Start zn SSH server on Kali and RDP into MULTISERVER03.
Create the remote port forward on MULTISERVER03.
Plink
OpenSSH might be intentionally removed from Windows machines, but other remote tools might be available. Plink is PuTTY's CLI version. On this scenario:
MULTISERVER03(192.168.177.64) has TCP port80exposed.All other inbound ports are blocked (no RDP).
MULTISERVER03is compromised and we got a webshell at/umbraco/forms.aspx.

We will first need to make sure that our SSH server is configured appropriately, i.e., the GatewayPorts and AllowTcpForwarding settings are set to yes. If there aren't and we change them, we will need to restart ssh for the changes to take place.
Send a reverse shell to Kali through the web shell on MULTISERVER03:80.
Cath the reverse shell, transfer the plink binary, and create the remote port forward.
Confirm that the setup is up and running and use it to RDP directly to MULTISERVER03.

When we want to use plink within a non-interactive session, e.g. WinRM, which prevents us from answering the ssh prompts, including trusting our ssh hostkey, we need pass the command's arguments are a list:
We can also automate SSH client key acceptance in non-TTY shells on Windows using Plink with cmd.exe /c echo y | plink.exe, bypassing manual prompts.
Netsh
Network Shell (netsh) is a native Windows tool use to configure network settings, including port forwarding via portproxy within the interface context.
The
netsh interface portproxycommand requires admin rights, so UAC may block changes in some cases. In this example, we’re using an admin RDP session, so UAC isn’t an issue.
In our scenario:
MULTISERVER03(192.168.246.64) has TCP ports80and3389open.CONFLUENCE01(192.168.246.63) isn't accessible on the WAN interface.MULTISERVER03allows all outbound traffic.
Our aim is to SSH directly from Kali to PGDATABASE01 (10.4.246.125) by creating a port forward on MULTISERVER03.

RDP directly into MULTISERVER03 from Kali.
Open an admin cmd.exe, run netsh to add a portproxy rule (v4tov4) that listens on port 2222 at MULTISERVER03 and forwards to port 22 on PGDATABASE01.

The nmap results shows port 2222 as filtered, which probably means that Windows Firewall blocks inbound connections to this port.
We need to create a "hole" by creating a rule that allows connections on the local port (2222) for incoming traffic (dir=in).
Now the 2222 port shows as open, and we can SSH directly into it.
After we are done with the connection, we need to delete the rule and the port forward.
Note: There is no PowerShell equivalent for
netsh interface portproxy. However, Firewall management has PowerShell cmdlets (New-NetFirewallRule, etc.).
Last updated
Was this helpful?