Gentoo Wiki


Please format this article according to the guidelines and Wikification suggestions, then remove this notice {{Wikify}} from the article

Well quite simply I'm going to assume you know the basics of the Gentoo portage.

emerge metasploit -v
emerge activerecord -v
emerge ruby-postgres -v

From Metasploit pages, just follow the rest of this.

Check to make sure ruby modules are good, if no error on this command:

$ ruby -e 'require "rubygems"; require_gem "postgres";' 

Once the prerequisites are in place, you need to create a PostgreSQL instance. If you already have a PostgreSQL server running, you can skip this step. To create a new database instance, run the following commands:

$ initdb ~/metasploitdb
$ pg_ctl -D ~/metasploitdb start

Finally, you need to grab the latest copy of the Metasploit Framework source from the public Subversion tree:

$ svn checkout framework3

To obtain the latest updates in the future, just change into the framework3 directory and execute svn update.

Change into the framework3 directory and execute ./msfconsole. You may see a few warning messages about broken modules that you can safely ignore, but eventually you should be looking at a msf> prompt. Load the PostgreSQL driver plugin using the following command:

msf > load db_postgres

Once the plugin loads, type the help command and look at the new options listed under the Postgres Database section. Since we do not have an existing database, we want to use the db_create command. If you created the PostgreSQL instance using the commands above, this should result in various NOTICE and ERROR messages as it loads the schema into the default database name (metasploit3). If you are using an existing PostgreSQL instance, you will need to pass the appropriate parameters to the db_create command (see the help output for more information).

Now that the console is connected to a new database instance, a new set of console commands become available. These are listed in the help output under the Database Backend section. To verify that the database connection is valid, execute the db_hosts command. If everything worked, there should be no results and no errors listed. If you receive a error message and a backtrace, use the db_disconnect command and try executing db_create again with different parameters.

The console is connected to the database, the schema is in place, you are now ready to import vulnerability data. The current version of the framework supports Nessus NBE output files, Nmap XML output files, and a wrapper command (db_nmap) that will launch the nmap port scanner and record the results into the attached database.

Before you start loading data, take a quick look at the db_autopwn command. If you run this command without any parameters, it should result in a blob of text like the following:

msf > db_autopwn
[*] Usage: db_autopwn [options]
-t Show all matching exploit modules
-x Select modules based on vulnerability references
-p Select modules based on open ports
-e Launch exploits against all matched targets
-r Use a reverse connect shell
-b Use a bind shell on a random port
-h Display this help text

The db_autopwn command is where the exploitation magic happens. This command will scan through the database tables and create a list of modules that match up to specific vulnerabilities. This matching process can happen in two different ways. The first method involves analyzing the list of vulnerability references for every exploit and matching them up with the references in every imported vulnerability record. This cross-referencing method is fairly accurate and depends on standard identifiers, such as OSVDB, Bugtraq, and CVE to match exploits with their targets. The second method uses the default port associated with each exploit module to locate targets running the same service. While this will work in most cases, it can cause a fair amount of collateral damage and is likely to miss vulnerabile services running on non-default ports.

At this point, you have a few options. You can either import an existing Nessus NBE file using the db_import_nessus_nbe command, import an existing Nmap XML output file using the db_import_nmap_xml command, or use the db_nmap command to populate the database. The benefit of using a Nessus NBE file is that it provides data for the cross-referencing mode (-x) of db_autopwn. The benefit of using Nmap data is that you can quickly attack a large group of systems without having to run a complete vulnerability scan, but you will miss vulnerabilities that are not on the default port of the associated Metasploit module.

Please keep in mind is that the db_autopwn command will treat ALL of the records in the database as potential targets. Future versions of the framework will include the ability to limit the targets to a specific set of the entire database. Until this change occurs, be really careful about what data you feed to the framework. Do NOT import anything into the database that you are not allowed to exploit.

For the first attempt, try using the db_nmap command to identify all Windows 2000 and Windows XP systems on the local network that expose the SMB service.

msf > db_nmap -p 445 [target]

Replace the [target] string with the network block of your local subnet or the IP address of a target system that you want to test. This command will use the Nmap port scanner to find systems with port 445 exposed. Once this command completes, use the db_services command to view the results. If no hosts were found with port 445 open, no results will be displayed by the db_services command.

Assuming that you found at least one system with port 445 open, its time to run the db_autopwn command and see what modules it will launch. Execute the following command from the console prompt:

msf > db_autopwn -p -t

The -t flag tells the command to display all the match results and the -p flag indicates that port-based matching should be used to locate potential targets. This command should show a handful of exploits and one or two auxiliary modules for every system that was found with port 445 open. Don't worry about the auxiliary modules for now, as they are disabled by default and need to be manually enabled. This is your last chance to verify that every host in the target list is valid and that exploiting (or crashing) these systems won't result in your incarceration or lack of employment.

Time for the fun part! Execute the db_autopwn command again, this time adding the -e flag. This will result in every one of those modules being launched against their specified target. The default payload is a generic bind shell, using a randomized port number for each attempt. Wait for this command to complete and then execute the sessions -l command to view the results. If any of those target systems were vulnerable, you should see at least one command shell. To interact with these shells, use the sessions -i [ID]. To detach from a shell, use control+Z, and to kill a shell, use control+C.

Thats it for the basics. To expand the scope of the test, widen the port range for the db_nmap command or import a Nessus NBE file. If the command finishes, but exploits are still running, you can use the jobs command to kill off any stragglers.

The log below is a result of my own testing against a local network full of vulnerable virtual machines.


Retrieved from ""

Last modified: Mon, 08 Sep 2008 19:38:00 +0000 Hits: 3,360