Choosing The Dig Site & Starting Our Tunnels
Notes from completing this module on Hack The Box Academy (Tier II)
Dynamic Port Forwarding with SSH and Tunneling with SOCKS
Tunneling usually works over the TCP layer. The redirection of the traffic to one port to another can be used to bypass firewalls.
Local Port Forwarding
On this schema, our victim server has port 22 (SSH) and 3306 (MySQL) open. If we want to access the MySQL service on our localhost, we need to perform a port forwarding. We need to forward the traffic from port 1234 of our localhost to the port 3306 of the Ubuntu server.
Since port 22 is open on the target system, we can forward the port locally using SSH. This command will allow us to connect to the MySQL service locally.
It is also possible to forward multiple ports. In that case, the Ubuntu has an Apache server hosted on port 80. We could forward our local port 8080 to the port 80 on the Ubuntu server as well. Similarly than forwarding the MySQL service, in that case, we will be able to access the Apache server on our localhost on port 8080.
Dynamic Port Forwarding with SOCKS and SSH
Below is an schema of how tunneling over SOCKS proxy works. The tool proxychains is used to redirect all our packets on our SOCKS server on our local machine on port 9050. Then, the SSH client, that us turned into a SOCKS server, will redirect all those packets to the targeted network (172.16.5.129/23). We can specify to proxychains which port to use by modifying the/etc/proxychchains.conf
file.
Unlike SOCKS4, SOCKS5 supports UDP and authentication
Proxychains with common tools
nmap
When using nmap with proxychains, the -sT
flag have to be added to the command. Indeed, proxychains only understand full TCP connexions. Sending partial TCP connexion over proxychains will return false results. Note that this methods is scan method is very slow due to the full TCP handshake that is performed.
xfreerdp (to get a RDP session on a remote host)
The metasploit framework
Remote/Reverse Port Forwarding with SSH
In this scenario, we gained an RDP session over the target 172.16.5.19 (Windows A) using dynamic or local port forwarding. However, this is not sufficient for our needs. We would like to get a full shell over the Windows A server. The Windows A server can not connect directly to our attacker host because both systems are not on the same subnet. A pivot host connected both to our attacker host and to the Windows A server is thus needed as an intermediate. To gain the reverse shell over the Windows A server, multiple steps needs to be executed.
Creating the msfvenom payload.
This msfvenom paylod will be executed from the Windows A server and will send a reverse connection to the Ubuntu sever (the pivot). Indeed, the payload can not target directly our attacker machine, since both systems are in a different subnet. That's why we need an intermediate server that could allows connection between the attacker machine and the Windows A server.
As seen in the command below, the payload will connect to the Ubuntu server.
Importing the msfvenom payload on the Windows A server.
The msfvenom payload was uploaded on the Windows A server in two steps. In the first step, we used the scp
utility to transfer the payload from our attack host to the Ubuntu server. Then, we started an HTTP server on the Ubuntu server, and used the Invoke-WebRequest
method from Powershell to transfer the payload from the Ubuntu server to the Windows A target system.
Configuring the msfvenom handler
We configured our msfvenom handler on port 8000. The 0.0.0.0
interface is to specify that all interfaces should be listening on port 8000 for incoming connections.
Configure our remote port forwarding
The command below specified to the Ubuntu server to forward all packets coming on port 8080 on the interface with the IP 172.16.5.129 to our localhost machine on port 8000 where our MSF multi-handler is listening.
Execute the payload from the Windows A server.
The last step is to execute the payload from the Windows A server. Because we created a reverse tunneling, we will be able to get a full reverse shell from Windows A on our localhost machine on port 8000.
Meterpreter Tunneling & Port Forwarding
Meterpreter SOCKS proxy
It is possible to use the capability of Meterpreter to create a tunnel without the use of SSH. The advantage of pivoting using a Meterpreter session is that the MsfVenom framework offers a lot of tools and utilities to perform exploitation and enumeration.
In the following scenario, the objective is to enumerate the network 172.16.5.0/23
from the Ubuntu server, which correspond to the pivot.
Create a msfvenom payload
The command below generates a msfvenom payload aiming at sending a reverse connection back on the multi-handler configured on port 8080 on our attacker machine. We transfered the payload on the Ubuntu server using the scp
utility.
Configure the MSF multi-handler
Then, we configured the msfvenom multi-handler to listen on port 8080 on all interfaces on our attacker machine. Then, when executing the backupjob
script on the Ubuntu server (pivot host), we observed a meterpreter session opening.
Configuring the SOCKS proxy using Metasploit
We can configure a SOCKS proxy using the module server/socks_proxy
from the Metasploit framework. We will set the listener on port 9050. The socks_proxy
will be configured so all the traffic will pass through our Meterpreter session.
We can confirm that the SOCKS proxy is running using the jobs
command.
Configuring proxychains on our host machine
We have to configure proxychains on our attacker machine to redirect the packets sent by Nmap and others tools to the SOCKS proxy server we configured using Metasploit.
Configure the route
We can configure the module post/multi/manage/autoroute
to route all traffics coming to the socks_server through our Meterpreter session to reach the 172.16.5.0/23 network.
An alternative is to create an autoroute running autoroute
from our Meterpreter session.
We can confirm that our routes are set up properly by using the run autoroute -p
command.
Testing Proxy & Routing Functionality
We can perform an nmap scan against the 172.16.5.19 server using proxychains. The nmap packets are routed through our Meterpreter sessions to reach the 172.16.5.19 target on the 172.16.5.0/23 network.
Meterpreter Local Port forwarding
Metasploit can also be used to perform port forwarding using the module portfwd
.
From a Meterpreter session, this command below set a listener on our attacker host machine on port 3300 and forward all traffic coming to this port to the target machine on port 3389. The traffic will be relayed via our Meterpreter session.
Previously, we obtained a Meterpreter session for the Ubuntu server (the pivot). This session can be used to forward our local host port 3300 to port 3389 on the target server.
Then, we can use xfreerdp on localhost:3300 to gain a RDP session.
Meterpreter Reverse Port Forwarding
Meterpreter can also be used to perform remote port forwarding. In these cases, we will listen on a specific port on the compromised target and every traffic going to this port will be forwarded to our attacker host machine.
Having a Meterpreter session for the Ubuntu server (the pivot), we can execute the command below indicating that port 1234 on the pivot is listening for traffic. All traffic coming to this port will be forwarded to our local host machine on port 8081.
To demonstrate remote port forwarding, we created a MSFVenom payload that will be executed from the 172.16.5.19 Windows system. When executed, this payload will send a reverse connection back to the Ubuntu server (the pivot) on port 1234.
We put in background the Meterpreter session 1 on which the port forwarding has been configured, to set up our listener on our attacker host machine for the reverse connection that will comes from the payload.
We have been able to gain a RDP session for the Windows system using local port forwarding and using RDP. This will be used to upload the payload to the Windows system.
To upload the backupscript.exe payload to the Windows system with the IP 172.16.5.19, we proceeded in two steps. We first upload the payload from our localhost to the Ubuntu server (the pivot) using the scp
utility. Then, we started a Python server on the Ubuntu server and used the Invoke-WebRequest Powershell method to upload the payload from the pivot to the Windows System.
Then, we executed the payload backupscript.exe from the Windows system. This sent a connection back to the Ubuntu server on port 1234. Because we specified that every incoming connection to the Ubuntu server (port 1234) should be forward to port 8081 on our attacker machine, a Meterpreter session opened on port 8081.
On HTB Academy, this section had to be completed using the PwnBox. It did not work using OpenVPN.
Last updated