SSH Local Port Forwarding Unleashed: The Red Team’s Silent Tunnel to Internal Networks + Video

By /

Listen to this Post

Featured Image

Introduction:

Local port forwarding is a powerful technique that allows an attacker—or a penetration tester—to securely access internal services by redirecting traffic from their local machine to a remote target through an encrypted SSH tunnel. This method is widely used during post‑exploitation and lateral movement phases to bypass firewalls, access internal web applications, and pivot into restricted networks without triggering typical network‑level alerts.

Learning Objectives:

  • Understand the mechanics of SSH local port forwarding and how it differs from remote and dynamic forwarding.
  • Execute local port forwarding commands on both Linux and Windows environments to tunnel traffic to internal resources.
  • Apply pivoting techniques to compromise restricted networks and implement defensive countermeasures to detect or block such tunnels.

You Should Know:

1. SSH Local Port Forwarding Fundamentals

Local port forwarding forwards a port on your local machine to a port on a remote target machine via an SSH server acting as a jump host. The syntax is: ssh -L [local_addr:]local_port:target_host:target_port user@ssh_server. Traffic sent to the local port is encrypted and tunneled through the SSH connection, then decrypted and forwarded to the target. This allows you to access an internal web server or database that would otherwise be unreachable.

Step‑by‑step guide (Linux/macOS):

  1. Identify a compromised SSH server inside the target network (e.g., `jumphost` at 10.10.10.5).
  2. Suppose an internal web server runs at 192.168.1.100:80, not directly accessible.

3. Run: `ssh -L 8080:192.168.1.100:80 [email protected]`

  1. On your local machine, open a browser to `http://localhost:8080` – you see the internal web app.
    5. Verify the tunnel with `netstat -tulpn | grep 8080` (Linux) or `netstat -an | findstr 8080` (Windows).
  2. To keep the tunnel alive in background, add -fN: ssh -fN -L 8080:192.168.1.100:80 [email protected].

Windows commands (OpenSSH client):

  • Same syntax if OpenSSH is installed: `ssh -L 8080:192.168.1.100:80 [email protected]`
    – To test connectivity to the forwarded port: curl http://localhost:8080` orTest-NetConnection -ComputerName localhost -Port 8080`.

2. Windows Implementation with PuTTY and PowerShell

Many Windows environments lack native SSH clients, but PuTTY or the built‑in OpenSSH client (Windows 10/11) can be used. This section covers both.

Step‑by‑step with PuTTY:

1. Download PuTTY and launch it.

  1. Enter the SSH server IP (e.g., 10.10.10.5) and port 22.

3. Navigate to Connection → SSH → Tunnels.

  1. In “Source port”, enter 8080. In “Destination”, enter 192.168.1.100:80.
  2. Select “Local” and “Auto” (or “IPv4”), then click “Add”.
  3. Go back to Session, save the configuration, and click “Open”. Log in with credentials.
  4. Access `http://localhost:8080` from any browser on the Windows machine.

Step‑by‑step with PowerShell / plink (command line):

– `plink.exe -ssh -L 8080:192.168.1.100:80 [email protected]`
– To run silently: `plink.exe -ssh -N -L 8080:192.168.1.100:80 [email protected] -pw password`

3. Pivoting into Restricted Networks – Real‑World Attack Scenario
Imagine you have compromised a Linux jump host (10.10.10.5) that has access to an internal database server (10.10.10.50:3306 – MySQL) and an internal RDP server (10.10.10.60:3389). Your attacking machine cannot reach these directly due to firewall rules. Local port forwarding enables you to pivot.

Step‑by‑step exploitation:

  1. Forward MySQL port: `ssh -L 3306:10.10.10.50:3306 [email protected] -fN`
    2. Forward RDP port: `ssh -L 3389:10.10.10.60:3389 [email protected] -fN`
    3. Now connect to MySQL from your local machine: `mysql -h 127.0.0.1 -u root -p` (assuming you have credentials).
  2. For RDP, launch `mstsc` and connect to 127.0.0.1:3389.
  3. To automate multiple forwards, use an SSH config file (~/.ssh/config): 
    Host pivot
HostName 10.10.10.5
User attacker
LocalForward 3306 10.10.10.50:3306
LocalForward 3389 10.10.10.60:3389

Then run `ssh pivot -fN`.

Mitigation for defenders: Monitor for unusual SSH connections with `netstat -anp | grep ESTABLISHED` on the jump host. Look for SSH processes holding open forwarded ports using lsof -i :3306.

4. Bypassing Firewalls and IDS/IPS with Encrypted Tunnels

Because SSH traffic is encrypted, many firewalls and intrusion detection systems cannot inspect the payload. Attackers often run SSH on port 443 (HTTPS) or 53 (DNS) to blend in. Local port forwarding effectively bypasses egress filters that only allow web traffic.

Step‑by‑step firewall evasion:

  1. On the target internal machine, ensure SSH is listening on port 443 (edit /etc/ssh/sshd_config: Port 443).

2. Restart SSH: `sudo systemctl restart sshd`.

  1. From the attacker’s machine behind a restrictive firewall, connect: ssh -L 8080:internal-web:80 [email protected] -p 443.
  2. Use `proxychains` to force any tool through the tunnel. Install proxychains, edit `/etc/proxychains.conf` to add `socks4 127.0.0.1 9050` (for dynamic forwarding) or simply use local port forwarding for specific apps.
  3. For a more stealthy approach, use `ssh -D 1080 user@ssh-server` to create a SOCKS proxy, then configure your browser or `proxychains` to use 127.0.0.1:1080. This is dynamic forwarding – it sends all traffic through the tunnel without defining individual ports.

Detection tip for blue teams: Look for unexpected SSH daemons on non‑standard ports using nmap -p 22,443,53 <internal_IP_range>. Also monitor volume of encrypted traffic; SSH sessions with very high packet counts but low interactivity may indicate tunneling.

  1. Defensive Countermeasures: Detecting and Blocking Local Port Forwarding
    As a defender, you can limit or detect local port forwarding in several ways. The most effective controls focus on SSH server configuration and network monitoring.

Step‑by‑step hardening (Linux SSH server):

  1. Disable TCP forwarding globally in /etc/ssh/sshd_config: AllowTcpForwarding no.
  2. For users who need forwarding, create a separate group or use `Match` directive: 
    Match User tunneluser
AllowTcpForwarding yes
  3. Disable shell access for dedicated tunnel users: Match User tunneluser, ForceCommand /bin/false, AllowTcpForwarding yes.
  4. Restrict which ports can be forwarded using PermitOpen:

`PermitOpen 192.168.1.100:80 10.10.10.50:3306`

  1. Audit authorized_keys for `command=` restrictions that might bypass controls.

Detection commands:

  • On the SSH server, run `ss -tulpn | grep ssh` to see which ports are being forwarded.
  • Monitor SSH logs (/var/log/auth.log) for `”local port forwarding”` or "forwarding request".
  • On the internal target (e.g., web server), look for connections originating from the SSH server’s IP on unexpected ports using netstat -an | grep ESTABLISHED.

Windows defender actions:

  • Use Windows Defender Firewall to block outbound SSH (port 22) except for authorized jump servers.
  • Deploy Sysmon to log network connections and detect `ssh.exe` or `plink.exe` creating local listeners.

6. Advanced Usage: Chaining Tunnels and ProxyJump

For multi‑layered networks, you may need to tunnel through several SSH servers. OpenSSH’s `ProxyJump` option simplifies this.

Step‑by‑step nested tunneling:

  1. Scenario: Attacker → Jump host A (10.10.10.5) → Jump host B (172.16.1.10) → Internal web (192.168.1.100:80).
  2. Use `ProxyJump` to chain directly: `ssh -L 8080:192.168.1.100:80 -J [email protected] [email protected]`
    3. Alternatively, manually chain using netcat or ssh -W:

– First, create a tunnel to host A: `ssh -L 2222:172.16.1.10:22 [email protected] -fN`
– Then, from that tunnel, forward to the internal web: `ssh -L 8080:192.168.1.100:80 userB@localhost -p 2222`
4. For dynamic forwarding through multiple hops, combine `-D` with ProxyJump:

`ssh -D 1080 -J [email protected] [email protected]`

Now configure your tools to use SOCKS proxy at 127.0.0.1:1080.

Practical command for red teams:

 One‑liner to access a hidden internal RDP through two jump hosts
ssh -L 3389:192.168.1.60:3389 -J [email protected],[email protected] [email protected] -fN

Verification: Use `nmap -sT -p 3389 127.0.0.1` to confirm the RDP port is forwarded.

What Undercode Say:

  • Local port forwarding is a stealthy lateral movement tool – it encrypts all traffic, bypasses many IDS/IPS rules, and leaves minimal logs if the SSH server is poorly monitored. Defenders must disable unused forwarding or strictly audit it.
  • Proactive hardening on SSH servers is critical – setting `AllowTcpForwarding no` by default and using `PermitOpen` whitelists can block most malicious tunnels without breaking legitimate use cases. Combine with egress filtering to prevent SSH on non‑standard ports.

Analysis: While local port forwarding is a legitimate administration feature, red teams exploit it to create encrypted backdoors into internal networks. The rise of cloud environments and zero‑trust models forces defenders to move beyond port‑based blocking and adopt identity‑aware SSH proxies, session recording, and anomaly detection on encrypted traffic patterns. AI‑based systems that profile normal SSH behavior (e.g., typical command lengths, packet sizes) can flag anomalous forwarding requests. However, until such controls are widespread, local port forwarding remains a reliable, low‑noise technique for pivoting and data exfiltration.

Prediction:

As enterprise networks increasingly adopt zero‑trust network access (ZTNA) and micro‑segmentation, traditional SSH local port forwarding may become less effective because services no longer rely on routable IP addresses. Instead, attackers will pivot to tunnelling over HTTPS/3, WebSockets, and encrypted DNS (DoH) to mimic legitimate traffic. AI‑driven defensive systems will evolve to detect anomalous tunnel establishment by analyzing metadata—such as SSH handshake timing, key exchange fingerprints, and session duration—while red teams will respond by embedding tunnelling inside trusted cloud APIs (e.g., AWS SSM, Azure Bastion). The arms race will shift from port forwarding per se to abusing legitimate management protocols themselves, making identity and behavior analytics the last line of defense.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Cybersecurity Ethicalhacking – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: