If you follow this blog at all, you're familiar with Christian Kirsch's round up of the most searched modules in our exploit database. These stats are gathered roughly monthly from the Metasploit exploit database backend, and tend to have a pretty strong recency bias -- modules that recently got a lot of press or Twitter buzz tend to shoot up to the top of the list.
Of course, that's the point of "Exploit Trends" exercise -- we and our readers want to know what's recently interesting. But we sometimes ask ourselves, what are the "most popular" exploits that we ship with Metasploit? How could we tell?
Tracking module usage is one way to determine popularity. We've kicked around the idea of instrumenting things like on_session_open() to gather stats and periodically let us know what modules are effective, but of course this kind of tracking would need to be carefully controlled to ensure that we're not leaking vulnerability data on your behalf, it would necessarily need to be opt-in, and that kind of usage tracking tends to make security people more than a little squirmy, so we don't do that.
So, I had an idea a while back on how to get at a popularity index without spying on our end users. Instead of measuring runtime use, what if we just measured the number of times a module got fixed, enhanced, or otherwise changed?
Git makes this kind of thing pretty straightforward to measure, since I can pull a commit history of all our modules, dating back to 2005, and each time someone touches a module, that event is recorded in that module's commit history. So, if you just count the number of commits across all modules, and sort them from high to low, you should get a pretty decent picture of what Metasploit modules are at least attracting the attention of code maintainers, and maybe that's a good proxy for user popularity.
Well, that turned out to be a pretty insightful guess. I showed the initial output to one of our full-time penetration testers here, Leon @sho_luv Johnson, who responded with, "Wow, this is my checklist, in order, for every engagement I'm on." It's spooky how accurate this top ten list is in terms of what real pentesters do when they're first on-site and have Metasploit loaded up:
modules/exploits/windows/smb/psexec.rb 61 modules/exploits/windows/smb/ms08_067_netapi.rb 56 modules/exploits/multi/http/tomcat_mgr_deploy.rb 52 modules/exploits/multi/http/jboss_maindeployer.rb 42 modules/exploits/multi/browser/java_signed_applet.rb 39 modules/exploits/windows/browser/ms03_020_ie_objecttype.rb 37 modules/exploits/windows/iis/ms03_007_ntdll_webdav.rb 36 modules/exploits/unix/webapp/php_include.rb 34 modules/exploits/windows/browser/ie_createobject.rb 34 modules/exploits/windows/smb/ms05_039_pnp.rb 33
I'll get to more detailed analysis of these results in a later blog post, I promise. For now, I want to talk about the advantages for measuring commits, rather than actual usage, which is applicable to not only Metasploit, but really any software project with easily discernible atoms of content.
This measurement is totally non-invasive. By going over a module's commit history, I can certainly tell who made changes to a module, and for very popular modules like psexec and MS08-067, there's a fair number of non-Rapid7 committers listed, but everyone on that list went way out of their way to create a GitHub (or old SVN) account, make a change, and land it. It doesn't tell me anything about where they used it or what they were using it for.
It doesn't just measure buggy modules. Commits not only represent bug fixes, but also measure feature addons. If a module starts off being pretty useful, it's not long until someone says, "Hey, it'd be great if this module cleaned up after itself," or "here's another target for this exploit," or "This module can report something new in the database about the target," other any other feature enhancement. Therefore, useful modules tend to get more useful over time, especially as people use them in different environments, contexts, and situations.
It reverses recency bias. Recent, hot modules still need to get a fair amount of real use in the field in order to start hitting a top 10 or top 50 list. For example, the recent java_jre17_exec exploit, which is really useful right now, only has 13 commits on it. That puts it in the top 40% of all modules by commit counts, but it's a long way off from the top 10% (modules with 20 or more commits). Therefore, older, more established exploits will tend to dominate the top of the list.
Using our new module_commits.rb script in particular module trees allows for ranking different sets of modules to against each other. For example, if I wanted to know about just the browser exploits, I could just run:
$ ./tools/module_commits.rb modules/exploits/windows/browser/ | tee browser-exploits.txt
Reading browser-exploits.txt to gives me the top ten Windows-based browser exploits:
modules/exploits/windows/browser/ms03_020_ie_objecttype.rb 37 modules/exploits/windows/browser/ie_createobject.rb 34 modules/exploits/windows/browser/ms06_001_wmf_setabortproc.rb 29 modules/exploits/windows/browser/ms06_067_keyframe.rb 29 modules/exploits/windows/browser/adobe_flash_mp4_cprt.rb 28 modules/exploits/windows/browser/aim_goaway.rb 27 modules/exploits/windows/browser/winamp_playlist_unc.rb 26 modules/exploits/windows/browser/winzip_fileview.rb 23 modules/exploits/windows/browser/mcafee_mcsubmgr_vsprintf.rb 23 modules/exploits/windows/browser/macrovision_unsafe.rb 23
So, with that feature in mind, here are some more top ten lists. People love top ten lists.
Top ten auxiliary modules
These are modules that don't open a session, but are nonetheless useful for information gathering, server spoofing, cracking passwords, and pretty much any non-memory corruption / command injection activity.
modules/auxiliary/server/browser_autopwn.rb 78 modules/auxiliary/scanner/smb/smb_login.rb 71 modules/auxiliary/scanner/ssh/ssh_login.rb 51 modules/auxiliary/scanner/http/tomcat_mgr_login.rb 50 modules/auxiliary/server/capture/smb.rb 47 modules/auxiliary/server/capture/http.rb 45 modules/auxiliary/scanner/telnet/telnet_login.rb 44 modules/auxiliary/scanner/http/http_login.rb 39 modules/auxiliary/scanner/mssql/mssql_login.rb 38 modules/auxiliary/spoof/dns/bailiwicked_host.rb 36
Top ten post modules
Post modules are what a pentester will run once a machine is compromised. These are tasks like looting stored credentials, escalating local privilege, launching a keystroke logger, activities like that. Now that we can tell what modules are getting attention, we can say confidently that what people are most interested is extending access through the domain and other machines through stolen credentials.
modules/post/windows/gather/credentials/gpp.rb 55 modules/post/windows/gather/enum_chrome.rb 26 modules/post/multi/gather/firefox_creds.rb 24 modules/post/multi/gather/pidgin_cred.rb 24 modules/post/windows/escalate/service_permissions.rb 23 modules/post/osx/gather/enum_osx.rb 22 modules/post/windows/gather/credentials/filezilla_server.rb 22 modules/post/multi/gather/ssh_creds.rb 21 modules/post/windows/gather/smart_hashdump.rb 21 modules/post/windows/gather/cachedump.rb 21
Top ten exploit payloads
Payloads are the chunks of code that gets run immediately after the vulnerability is exploited. Most of the time, payloads establish a remote a shell into the target over a command prompt, a Meterpreter session, a VNC session, something along those lines.
modules/payloads/stages/windows/shell.rb 35 modules/payloads/stages/windows/meterpreter.rb 34 modules/payloads/stagers/windows/reverse_tcp.rb 34 modules/payloads/stages/windows/vncinject.rb 25 modules/payloads/singles/php/reverse_php.rb 25 modules/payloads/stages/windows/upexec.rb 24 modules/payloads/stagers/windows/bind_tcp.rb 23 modules/payloads/stages/windows/dllinject.rb 21 modules/payloads/singles/linux/x86/shell_reverse_tcp.rb 21 modules/payloads/singles/windows/adduser.rb 20
Top ten Rex protocols
Oh, you don't need to limit to just content. We're constantly poking at Rex, the Ruby Exploitation library, so here's a top ten survey of protocols that we've touched a lot over Metasploit's life:
lib/rex/proto/http/client.rb 109 lib/rex/proto/smb/client.rb 84 lib/rex/proto/http/packet.rb 36 lib/rex/proto/http/server.rb 35 lib/rex/proto/dcerpc/client.rb 29 lib/rex/proto/smb/constants.rb 27 lib/rex/proto/smb/simpleclient.rb 27 lib/rex/proto/smb/utils.rb 25 lib/rex/proto/http/request.rb 24 lib/rex/proto/dhcp/server.rb 23
Yep, it looks like HTTP and SMB is where it's at in network-based exploitation. That's not surprising, but it's always nice to get some programmatic confirmation of where my intuition is.
The script I've been using isn't very user friendly or configurable, but it gets me the data in a more-or-less useful format. I'd like to be able to break ties a little better using a few different criteria, or output in a format that's actually machine-parsable (XML or JSON or something), or limit to a particular date range... my wish list goes on and on. I have a pull request open with it included as is right now, but even us core Metasploit developers have to wait in line to get our pull requests landed. (: If you have your own ideas, feel free to jump in on hacking Metasploit yourself and drop a pull request on us when you have something presentable.