Automated Penetration Testing with the Metasploit Framework

Filed under Penetration Testing

<%image(20080320-metasploit.gif|287|49|Metasploit Framework Rocks!)%>

Last night I did a talk on “Automated Penetration Testing with the Metasploit Framework” to a local information security group in Cleveland, Ohio. This was the last talk in a two part series on automated penetration testing tools. Last month I spoke about CORE IMPACT by Core Security Technologies which is a commercial penetration testing tool.

What is Metasploit and autopwn?
Metasploit is a free, open source tool for developing and executing exploit code against a remote target machine. In regards to automated penetration testing, starting with version 3, Metasploit offers a module called “autopwn” which can automate the exploitation phase of a penetration test. While autopwn is far from perfect, it does a decent job of exploiting multiple hosts. With 269 exploits (as of the latest update) you have lots of options (especially with Windows targets) for gaining a basic bind shell with autopwn.

Some of the strengths of autopwn include the ability to import vulnerability data from Nessus NBE files and to pull in Nmap XML output. Nice feature that works well. In addition, you can run Nmap from within the Metasploit console and it will put the results in the database. Finally, you can launch exploits based on ports, services or vulnerabilities from your imported data.

Limitations of autopwn
Autopwn has some limitations worth mentioning. Autopwn requires either a MySQL, Sqlite or Postgres database. Some pre-configuration required which may be a daunting task for some users. RubyGems, active record (part of ruby on rails), and getting the database configured to work with autopwn are all required. In terms of payloads you are pretty limited as well. Unfortunately with the current version you can only use a basic bind shell as your payload.

If you are looking for fancy reports with your vulnerability data you will have to do that on your own as there is no automated reporting in autopwn. On that same note…decent logging within Metasploit is limited to the debug modes. I recommend you run the “script” command from a shell before you start up the msfconsole so everything is logged to a file. Not much you can do if you use the GUI or web consoles for Metasploit except for screen shots.

Finally, if you are exploiting large numbers (several hundred) or wanting to import a ton of Nessus are going to take a performance hit. Autopwn seems to choke on lots of data. This will probably be fixed as it gets tweaked and tuned in future versions.

More information
HD Moore wrote up a very good autopwn tutorial which you can check out on the official Metasploit blog.

If you really want to quickly test out the features of autopwn without a lot of setup work, I recommend that you download one of the Backtrack disks. Backtrack 2 has autopwn ready to go once you launch the ninja script. Backtrack 3 beta has it installed but you need to update everything first on the disk by using the script which is included. Fast-track is a very useful script if you are a regular user of Backtrack…the creator of this script (Dave Kennedy from SecureState) was actually at the meeting last night and I got to chat with him about some cool stuff coming soon to the fast-track script and some new “to be announced” modules for Metasploit.

You can download the Metasploit presentation I did here. I plan on putting together a tutorial on autopwn installation in the near future. If you were at the talk last night, thanks for all the nice comments and for coming out!


  1. Tom,

    Nice post! I have attempted to download the .PDF of your presentation and keep getting "file damaged and can’t be repaired errors". I seem to be able to open up other .PDF files just fine. Can you please verify your file?



  2. Tom says:

    Sorry about that. Please try downloading the file again.

  3. CG says:

    I have the same comment about db_autopwn that i did about Core RPT. limited usefulness IMO, especially on a pentest.

    running that also lends a bit towards irresponsibility as well. if a tester doesnt have the skill to scan, enumerate, and pick exploits in a methodological manner, that "should" work based on version identification then i’m not sure i’d want them on a team with me.

    not to say that it isnt "neat" that tools can do that.

    pulled down the slides, looks like you are talking about good things in that local security group

  4. Tom says:

    CG, thanks for the comments. Totally agree with you that running any automated tool like Core and autopwn can lead to irresponsibility by a pen tester. I have used autopwn only on a limited number of hosts and only to verify that these hosts could be exploited…mostly to supplement the manual testing that was also being done. Unfortunately we are sometimes limited with the time (and staff) we have to verify hosts that can be exploited. Tools like Core and autopwn can assist with this. I always mention in my talks that automated testing should never replace manual, detailed testing….use these tools sparingly to supplement your toolkit! 🙂

Post a Comment

Your email is never published nor shared. Required fields are marked *