LinkedInExploit ADHackTheBox

☑️Tunneling & Port Fowarding

Port Forwarding

Port forwarding is a technique that allows us to redirect a communication request from one port to another. Port forwarding uses TCP as the primary communication layer to provide interactive communication for the forwarded port. However, different application layer protocols such as SSH or even SOCKS (non-application layer) can be used to encapsulate the forwarded traffic. This can be effective in bypassing firewalls and using existing services on your compromised host to pivot to other networks.

Lets say there is MySQL service running on a remote server. To access it normally we have to access the server via SSH and then access the service. Or we can bind our localhost and a local port to the remote host and the remote MySQL port in this case port 3306. We can do it with SSH:

ssh -L 1234:localhost:3306 [email protected]

We can also do multiple ports:

ssh -L 1234:localhost:3306 -L 8080:localhost:80 [email protected]

Another example

ssh -L 9999:192.168.226.248:21 -p 54602 [email protected]

Lets say we wanna run a brute force on host with the IP address 192.168.226.248 that has FTP running on port 21. We can access the host via SSH with IP 94.237.59.180 and port 54602. We can run hydra or nedusa against our localhost (127.0.0.1) after we create a tunnel using the above command. It will bind our local port 9999 with the remote hosts (192.168.226.248) port 21.

medusa -h 127.0.0.1 -n 9999 -U jsmith.txt -P passwords.txt -M ftp -t 16

SSH Tunneling via Proxy SOCKS

Lets say we have a compromised Ubuntu machine. This machine is connected to the 172.16.5.0 network. If we want to scan this network through the Ubuntu machine we have to do dynamic port forwarding or pivoting. We can do this by starting a SOCKS listener on our local host and then configure SSH to forward that traffic via SSH to the network (172.16.5.0/23) after connecting to the target host.

This is called SSH tunneling over SOCKS proxy. SOCKS stands for Socket Secure, a protocol that helps communicate with servers where you have firewall restrictions in place. Unlike most cases where you would initiate a connection to connect to a service, in the case of SOCKS, the initial traffic is generated by a SOCKS client, which connects to the SOCKS server controlled by the user who wants to access a service on the client-side. Once the connection is established, network traffic can be routed through the SOCKS server on behalf of the connected client.

This technique is often used to circumvent the restrictions put in place by firewalls, and allow an external entity to bypass the firewall and access a service within the firewalled environment.

This picture shows how we can run nmap and all the packets will be broadcasted to the network 172.16.5.0 using SSH connection. Here's the SSH command to do dynamic port forwarding:

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, which is capable of redirecting TCP connections through TOR, SOCKS, and HTTP/HTTPS proxy servers and also allows us to chain multiple proxy servers together. Using proxychains, we can hide the IP address of the requesting host as well since the receiving host will only see the IP of the pivot host. 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.

Finally, 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.

This part of packing all your Nmap data using proxychains and forwarding it to a remote server is called SOCKS tunneling.

Things To Note

One more important note to remember here is that we can only perform a full TCP connect scan over proxychains. The reason for this is that proxychains cannot understand partial packets. If you send partial packets like half connect scans, it will return incorrect results. 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.

Using Msfconole with Proxychain

Lets say we know RDP is open in one of the hosts. Similar to the Nmap scan, we can also pivot msfconsole via proxychains to perform vulnerable RDP scans using Metasploit auxiliary modules. We can start msfconsole with proxychains.

We can even use xfreerdp using proxychain:

Remote/Reverse SSH Port Forwarding

What happens if we try to gain a reverse shell?

Here,the Windows host does not have any direct connection with the network the attack host is on. In these cases, we would have to find a pivot host, which is a common connection point between our attack host and the Windows server. To gain a Meterpreter shell on Windows, we will create a Meterpreter HTTPS payload using msfvenom, but the configuration of the reverse connection for the payload would be the Ubuntu server's host IP address (172.16.5.129). We will use the port 8080 on the Ubuntu server to forward all of our reverse packets to our attack hosts' 8000 port, where our Metasploit listener is running.

Setting up the multi/handler

Tranfering payload to pivot host

After copying the payload, we will start a python3 HTTP server using the below command on the Ubuntu server in the same directory where we copied our payload.

On the pivot host:

Transfer payload to the target

Now we can download it from our pivot host to the target host:

Once we have our payload downloaded on the Windows host, we will use SSH remote port forwarding to forward connections from the Ubuntu server's port 8080 to our msfconsole's listener service on port 8000. The -R command asks the Ubuntu server to listen on <targetIPaddress>:8080 and forward all incoming connections on port 8080 to our msfconsole listener on 0.0.0.0:8000 of our attack host.

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.

If everything works well we should get a shell that was given by the victim host to the pivot host which forwarded it to our host port thats running the listener.

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

Lets say we have meterpreter shell with the pivot host we saw earlier. We can use it to create tunnels and perform port forwarding without getting involved with SSH.

Creating payload for pivot host

Starting multi/handler

After

Once we have the shell to our pivot machine we can run post exploit modules for example:

This is for ICMP ping sweep (which might not always be successful).

We can try using Nmap scans on an internal network using socks_proxy module for Metasploit.

Confirming that proxy is running

Edit the .conf file

Then of course we have to add a line to the /etc/proxychains.conf file.

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.

We can also run it from a meterpreter session:

As you can see from the output above, the route has been added to the 172.16.5.0/23 network. We will now be able to use proxychains to route our Nmap traffic via our Meterpreter session.

Port Forwarding - Meterpreter

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.

Creating local TCP relay

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.

Looking at netstat:

Reverse Port Forwarding

We can also perform reverse port forwarding using meterpreter:

To configure and run the multi/handler

We can now create a reverse shell payload that will send a connection back to our Ubuntu server on 172.16.5.129:1234 when executed on our Windows host. Once our Ubuntu server receives this connection, it will forward that to attack host's ip:8081 that we configured.

Generating the Windows payload

Once we execute the payload we should get a reverse shell on our machine.

Ping Sweep Commands

Linux

CMD

PowerShell

PreviousIntroductionNextSocat

Last updated