Skip navigation
All Places > Metasploit > Blog > 2016 > December

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we’re highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them.




Towards the end of November, the Tor community was shaken up by the revelation of an previously unknown vulnerability being actively exploited against pedo^H^H^H^H Tor Browser users. Some further drama unfolded regarding who the source for the exploit may be, and I received questions from several reporters who wanted every single detail I could give them. While I did not participate in commenting at the time, I'll say everything I will ever say about it now:


- Yes, I'm aware of a very similar exploit which targeted Firefox

- No, I didn't write it


Largely lost among all the noise are the nuances of the vulnerability and the exploit itself, which I know the author put his heart and soul into. If anonymous entrants are ever retroactively awarded Pwnies, I'd like to put his unsaid name into the hat. In this part of the 12 Days of HaXmas, I wanted to offer a high level overview to some of the more interesting parts of both the vulnerability--which in my opinion doesn't fit cleanly into any classic category--and the exploit. I'm not going to dive into all of the gory details for a couple of reasons. Firstly, timing. Had this been leaked earlier in the year, I might have been able to do the analysis part some justice. Second, while verbose technical expositions certainly have their place, a blog is not the right spot. The content might take take another 12 days to cover, and for those seeking to learn from it, I feel your own analysis of the exploit coupled with lots of dirty work in a debugger would be your best option. In that case, hopefully this can offer you some direction along the way.


The Discovery


It would be remiss of me if I didn't begin by pointing out that no fuzzer was used in the discovery of this vulnerability. The only tools employed were the Woboq Code Browser (Woboq Code Browser - Explore C++ code on the web), WinDBG, a sharp mind, and exhaustive effort. The era of low-hanging fruit is largely over in my opinion. Don't be the gorilla, be the lemur, climb that tree.


The Vulnerability


In the following snippet from nsSMILTimeContainer.cpp, the pointer p is initialized to the beginning of the mMilestoneEntries array.


  // Called when the container time is changed with respect to the document
  // time. When this happens time dependencies in other time containers need to
  // re-resolve their times because begin and end times are stored in container
  // time.
  // To get the list of timed elements with dependencies we simply re-use the
  // milestone elements. This is because any timed element with dependents and
  // with significant transitions yet to fire should have their next milestone
  // registered. Other timed elements don't matter.
  const MilestoneEntry* p = mMilestoneEntries.Elements();
  uint32_t queueLength = mMilestoneEntries.Length();
  while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) {
    mozilla::dom::SVGAnimationElement* elem = p->mTimebase.get();
    MOZ_ASSERT(queueLength == mMilestoneEntries.Length(),
               "Call to HandleContainerTimeChange resulted in a change to the "
               "queue of milestones");


Now, consider the following two examples:


Exhibit One

  Exhibit One
    <svg id='foo'>
        <animate id='A' begin='1s' end='10s' />
        <animate begin='A.end + 5s' dur='15s' />


Exhibit Two

  Exhibit Two
    <svg id='foo'>
        <animate id='A' begin='1s' end='10s' />
    <svg id='bar'>
        <animate begin='A.end + 5s' dur='15s' /> 


In these examples, for each <svg> element that uses <animate>, an nsSMILTimeContainer object is assigned to it in order to perform time book keeping for the animations (<animateTransform> or <animateMotion> will also have the same behavior).  The epoch of each container is the time since the creation of the <svg> element it is assigned to relative to the creation of the page.  The nsSMILTimeContainer organizes each singular event in an animation with an entry for each in the mMilestoneEntries member array. See: nsSMILTimeContainer.h - DXR


In Exhibit One, the mMilestoneEntries array will contain four entries: one for both the beginning and ending of 'A', in addition to another two, one being relative to A's completion (A.end + 5s), and the other demarcating the end of the animation, in this case 30 seconds (A.end + 5s + 15s).


In Exhibit Two we see two independent <svg> elements.  In this example, two separate nsSMILTimeContainer objects will be created, each of course having it's own mMilestoneEntries array.


The exploit makes a single call to the function pauseAnimation(), which in turn triggers entry into the NotifyTimeChange() method.  nsSMILTimeContainer::NotifyTimeChange() proceeds to iterate through all entries in the mMilestoneEntries array, retrieving each individual entries nsSMILTimedElement object, after which it calls the object's HandleContainerTimeChange() method.  After some time, this method will end up making a call to the NotifyChangedInterval() method of of the nsSMILTimedElement object.  In NotifyChangedInterval(), HandleChangedInterval() will be entered if the animation being processed has a milestone relative to another animation.  In Exhibit Two, bar's beginning is relative to the element A belonging to foo, so HandleChangedInterval() will be called.


Within HandleChangedInterval(), a call to nsSMILTimeValueSpec::HandleChangedInstanceTime() will inevitably be made.  This method determines if the current animation element and the one it has a dependency on are contained within the same nsSMILTimeContainer object.  If so, as is the case with Exibit One, the pauseAnimations() function basically lives up to it's name and pauses them.  In Exhibit Two, the animations do not share the same nsSMILTimeContainer object, so additional bookkeeping is required in order to maintain synchronization.  This occurs, with subsequent calls to nsSMILTimedElement::UpdateInstanceTime() and nsSMILTimedElement::UpdateCurrentInterval() being made, and nothing too interesting is to be seen, though we will be revisiting it very shortly.


Deeper down the rabbit hole ...


What about the case of three or more animation elements with relative dependencies? Looking at the exploit, we see four animations split unequally among two containers.  We can modify Exhibit Two using details gleaned from the exploit to arrive at the following example.


Exhibit Three

  Exhibit Three
     var foo = document.getElementById('foo');
    <svg id='foo'>
        <animate id='A' begin='1s' end='5s' />
        <animate id='B' begin='10s' end='C.end' dur='5s' />
    <svg id='bar'>
        <animate id='C' begin='0s' end='A.end/> 


In this example, C's ending is relative to A's end, so we end up in nsSMILTimedElement::UpdateCurrentInterval() again, except that a different branch is followed based on the example's milestones:


if (mElementState == STATE_ACTIVE) {
  // The interval is active so we can't just delete it, instead trim it so
  // that begin==end.
  if (!mCurrentInterval->End()->SameTimeAndBase(*mCurrentInterval->Begin()))
    NotifyChangedInterval(mCurrentInterval, false, true);
  // The transition to the postactive state will take place on the next
  // sample (along with firing end events, clearing intervals etc.)


NotifyChangedInterval() is called to resolve any milestones relative to other animations for C.  Within foo, B has milestones relative to C in bar.  This results in a recursive branch along the same code path which ultimately hits UpdateCurrentInterval(), which in turn sets the state of the nsSMILTimedElement.  mElementState can be one of four possible values:




all of which perfectly describes their own respective meanings.  In Exhibit Three, B's beginning is set to occur after it's ending is set (C.end == A.end == 5s).  Since it will never start, the code marks it as STATUS_POSTACTIVE.  This results in the following code within the UpdateCurrentInterval() method creating a new interval and setting it as current.


if (GetNextInterval(GetPreviousInterval(), mCurrentInterval,
                    beginTime, updatedInterval)) {

  if (mElementState == STATE_POSTACTIVE) {

               "In postactive state but the interval has been set");
    mCurrentInterval = new nsSMILInterval(updatedInterval);
    mElementState = STATE_WAITING;


With this occurring, UpdateCurrentInterval() now makes a call to the RegisterMilestone() method.  This was not the case in Exhibit Two.  With a new interval having been created, the method will add a new entry in the mMilestoneEntries array of containerA's nsSMILTimeContainer object, resulting in the array being freed and reallocated elsewhere, leaving the pointer p from nsSMILTimeContainer::NotifyTimeChange() referencing invalid memory.


Exploitation Overview


Just because the pointer p in NotifyTimeChange() can be forced to point to free memory doesn't mean it's all over.  Firefox overwrites freed memory with 0x5a5a5a5a, which effectively mitigates a lot of classic UaF scenarios.  Secondly, there is no way to allocate memory in the freed region after the milestone array is relocated.  Given these conditions, it's becoming clear that the vulnerability cannot be exploited like a classic use-after-free bug.  If you forced me to categorize it and come up with a new buzz word as people are so apt to in this industry, I might call it a dangling index, or an iterator run-off.  Regardless of silly names, the exploit utilizes some artful trickery to overcome the hurdles inherent in the vulnerability.  As I mentioned at the offset, for the sake of brevity, I'm going to be glossing over a lot of the details with regards to heap determinism (the terms "heap grooming" and "heap massaging" irritate me more than the word "moist").


In the first step, the exploit defragments the heap by spraying 0x80 byte blocks of ArrayBuffers, and another 0x80 of milestone arrays.  Each of the milestone arrays is filled to capacity, and then one additional element is added to each.  This causes the arrays to be reallocated elsewhere, leaving 0x80 holes.  After filling these holes with vulnerable milestone arrays, assuming the <b>last element</b> of the array is the one that triggers the vulnerability, there is now a high probability that the next iteration of the NotifyTimeChange() loop will point within one of the 0x80 ArrayBuffer's that were allocated first.  It is important that the last element be the one to trigger the bug, as otherwise, the memory would be freed and overwritten before an attacker could take advantage of it.


The next obstacle in the process is bypassing the object reference count which, under normal circumstances, would cause the loop to exit.  Even if this were a full technical exposition, I'd leave this part as an exercise to the reader because of reasons.  I invite you to figure it out on your own, because it's both quite clever and critical to the success of the exploit.  Those pesky reasons though.  Seasoned exploitation engineers will see it quickly, and astute students will have truly learned when they unravel the knot.


I'd like to think that this is a good hint, but the only certainty is that it comes up on my 3 AM debugging session playlist a lot


In any case, after the exploit does it's thing, the exit condition of the loop


while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) 


will never be reached, and instead the loop will continue to iterate infinitely.  While this is great news, it also means that an attacker is unable to continue executing code.  The solution to this is one of the more brilliant aspects of this exploit, that being the use of a Javascript worker thread.


  var worker = new Worker('cssbanner.js');


With the worker thread, Javascript can continue being executed while the infinite loop within the main thread keeps spinning.  In fact, it's used to keep tabs on a lot of magical heap manipulation happening in the background, and to selectively exit the loop when need be.  From here, the exploit leverages a series of heap corruptions into a r/w primitive, and bypasses ASLR by obtaining the base address of xul.dll from said corruptions by parsing the files DOS header in memory.  This, along with resolving imports, is the main purpose of the PE(b,a) function in the leaked exploit.


With ASLR defeated, all that lies ahead is defeating Data Execution Prevention, as the Tor browser doesn't feature any sort of sandbox technology.  The exploit handles this beautifully by implementing an automatic ROP chain generation function, which can locate the addresses of required gadgets amongst multiple versions of Firefox/Tor browser.  After constructing the chain, the following shellcode is appended (I've converted all addresses to base 16 for readability and added comments):


ropChain[i++] = 0xc4819090;   // add esp, 800h
ropChain[i++] = 0x0800;
ropChain[i++] = 0x5050c031;   // xor eax, eax ; push eax ; push eax
ropChain[i++] = 0x5b21eb50;   // push eax ; jmp eip+0x23 ; pop ebx
ropChain[i++] = 0xb8505053;   // push ebx ; push eax ; push eax
ropChain[i++] = CreateThread; // mov eax, kernel32!CreateThread
ropChain[i++] = 0xb890d0ff;   // call eax
ropChain[i++] = arrBase + 0x2040;   // mov eax, arrBase+0x2040
ropChain[i++] = 0x5f58208b;   // mov esp, dword ptr [eax] ; pop eax ; pop edi
ropChain[i++] = 0xbe905d58;   // pop eax ; pop ebp
ropChain[i++] = 0xffffff00;   // mov esi, 0xffffff00
ropChain[i++] = 0x000cc2c9;   // ret 0x0c
ropChain[i++] = 0xffffdae8;   // call eip+0x21
ropChain[i++] = 0x909090ff;   // placeholder for payload address


The shellcode basically allocates stack space and makes a call to CreateThread with the address of the final payload, which is obtained via the jmp eip+x023 ; pop ebx line, as it's argument.  It next performs stack cleanup and exits the current infinite NotifyTimeChange() loop to ensure clean process continuation.  At least, it's supposed to.  Initial findings I've read from other researchers seem to indicate that it does not continue cleanly when used against Tor browser.  I need to investigate this myself at the first lull in the holiday festivities.


"I hope I managed to prove that exploiting buffer overflows should be an art"

                                                                                         - Solar Designer


That wraps this up for now. Check back for updates in the future as I continue analysis on it. If you have questions about anything, feel free to ask either here or find me on Twitter @iamwilliamwebb. Happy holidays!




Original leaked exploit: [tor-talk] Javascript exploit


Weekly Metasploit Wrapup

Posted by egypt Employee Dec 16, 2016

Taking Care of Universal Business: the Handler's Tale


With a few exceptions, payloads have to have a handler. That's the guy who waits with the car while your exploit runs into the liquor store.


To run an exploit module, we have to select and configure a payload first. In some cases, Metasploit can do this for you automatically, by just guessing that you probably wanted the best payload for the target platform and architecture. Once the payload is set up, we have to have a way to talk to it -- that's the handler. For a reverse style payload like windows/meterpreter/reverse_tcp, Metasploit will open a listening socket on the attacker machine and wait for connections from the payload. For bind, style where the payload listens on the victim machine, Metasploit starts a loop attempting to connect to that listener. (When we talk about Metasploit payloads, we always call the payload the server and msfconsole the client, regardless of which direction the TCP session is going.)


Once the connection is established, two things can happen. First, if the handler is expecting a stageless payload, msfconsole sets up an interactive session that you can use to control the payload, whether that's a socket <-> terminal passthrough like a raw shell connection or the full-fledged client that meterpreter needs. If, on the other hand, the payload is staged, the handler needs to transmit more code for the first stage to read and run. When that's done, everything proceeds the same as for a stageless payload.


Either way, it is very important that the payload and the handler have matching settings. If a staged payload expects x86 shellcode and the handler thinks it is talking to a MIPS payload, the second stage will crash and you'll lose your shell despite having successfully achieved code execution. Similarly, if the payload is staged and the handler is stageless, the server will either a) wait forever for shellcode that will never come or b) it will take whatever you type into the console as shellcode, which will certainly fail unless your binary typing skills are significantly better than mine.


You usually don't have to worry too much about any of this, because everything is taken care of for you automatically when you type run. Where it gets complicated is when you need to have multiple payloads or run multiple exploits using the same listener port. To accomplish that, it is often useful to have a handler independent of an exploit. Metasploit has exploit/multi/handler, which is a special exploit module that isn't really an exploit, for exactly this purpose. All it does is allow you to configure a payload and run the handler for it.


This week's update introduces a new command, handler, which does all the same work as multi/handler (and in fact runs multi/handler in the background) all from a single command. This means you no longer have to move away from the context of the exploit you're working in to set up a handler.


Having independent handlers is also super useful for when you want create a payload outside of the current msfconsole.


The perfect example here is when using something like veil to generate executables that bypass antivirus for manual delivery. When the payload is not associated with an exploit, you have to tell Metasploit the details that it would normally have from the exploit's settings.


Unfortunately, there are a couple of disadvantages with this. First, it's error-prone. If the settings in your payload and handler don't match, like I mentioned above, things will crash and you'll be missing out on shells. Second, it requires multiple listening ports if you want to be able to handle multiple platforms or architectures. Sometimes that's not a big deal, but when you're dealing with organizations that have strong egress filtering, it can become an insurmountable hassle.


This week's update makes all reverse HTTP handlers use a single handler. This means you can run multi/handler (or the new handler command) to set up a single HTTP handler on port 443, with a real CA-signed certificate, and point staged and/or stageless meterpreters for any of the supported platforms all at the same place.


This isn't perfect yet. Native Linux Meterpreter and its up and coming replacement, Mettle, don't yet support HTTP, so they can't yet take advantage of the new handler. TCP payloads can theoretically do something similar, but the implementation will require changing the way stagers work, which is always challenging because of the extreme space restrictions they have to operate under and the fact that changing the staging protocol will make all existing stagers stop working. If you have ideas for how to accomplish that without breaking everyone's existing payloads, I'd love to hear them.


New Modules


Auxiliary and post modules (1 new)


Get it


As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:


To install fresh, check out the open-source-only Nightly Installers, or the binary installers which also include the commercial editions.

The Metasploitable3 Capture The Flag Competition has been underway for about a week now and the submissions have been pouring in!  We're very excited to see so many great submissions. We're reviewing as fast as we can so if you don't hear back from us right away, don't worry, you will.  For all valid submissions we will update this blog post and subsequent ones with the leaderboard. For any questions submitted we will get back with you as fast as we can, and for any invalid solutions submitted we will write back and let you know the reason. Got a question? Send it to capturetheflag [at] rapid7 [dot] com.


Some of the flags are a little bit tricky and have been causing the most questions, so we wanted to add a little clarity.


Firstly, all flags will be in the same design. If you see a flag that looks different than others, it's probably not a flag.  Additionally, all the real flags are .PNGs.


There is also one flag where we lost some of the data, if you find one half flag, it counts. And don't forget, flags found in C:\Vagrant or the virtual box console don't count.


Now that some housekeeping is out of the way, let's get on with the current results!!


So far we have had 155 submissions from 31 individuals!  One rock-star submitter went BONKERS over the weekend and found 11 flags in 2 days.There's definitely still time to get submissions in and take over the leaderboard though!


The Joker is the most common flag found and the Ace of Hearts has been the most tricky flag to find with 10 invalid submissions


Top Submitters



Card Counts



Great stuff everyone! Keep those submissions coming in!


Metasploit Wrapup

Posted by egypt Employee Dec 9, 2016

Finding stuff


For a very long time, msfconsole's search command has used a union of the results of all search terms. This means that if you do something like search linux firefox, you'll get a list of all modules that mention linux, regardless of the application they target, and all modules that mention firefox, regardless of their platform. Most people are probably expecting the intersection, i.e. you probably wanted to see only the modules that target Firefox on Linux. So now that's what happens.


The exception is when you have two or more of a single keyword operator, like search arch:x86 arch:mips. That will still get you the union of those two, since arguably it makes more sense to see results for both in this case.


Stealing stuff


This release brings a new post module from Geckom: post/osx/gather/enum_messages, a module for gathering messages from the Messages app in OS X. With the ability to connect your phone to the Messages app, this module provides an easy way to steal 2FA tokens and other goodies from a connected phone, assuming you have an active session on the target machine.


The module supports a few operations: DBFILE for grabbing the SQLite DB directly, READABLE for collecting messages in a human readable format, LATEST for collecting only the latest message, and ALL for doing all of the above.

Here's an example of what to expect:

msf > use post/osx/gather/enum_messages
msf post(enum_messages) > set session -1
session => -1
msf post(enum_messages) > run

[+] [redacted]:56791 - Messages DB found: /Users/[redacted]/Library/Messages/chat.db
[+] [redacted]:56791 - Found Messages file: /Users/[redacted]/Library/Messages/chat.db
[*] [redacted]:56791 - Looting /Users/[redacted]/Library/Messages/chat.db database
[*] [redacted]:56791 - Generating readable format
[*] [redacted]:56791 - Retrieving latest messages
[+] [redacted]:56791 - Latest messages:

[+] [redacted]:56791 - messages.db stored as: /Users/[redacted]/.msf4/loot/20161207151127_default_[redacted]_messages.db_947304.db
[+] [redacted]:56791 - messages.txt stored as: /Users/[redacted]/.msf4/loot/20161207151127_default_[redacted]_messages.txt_801211.txt
[+] [redacted]:56791 - latest.txt stored as: /Users/[redacted]/.msf4/loot/20161207151127_default_[redacted]_latest.txt_986021.txt
[*] Post module execution completed
msf post(enum_messages) >


That's all there is to it! You can change the user to retrieve messages from by setting the USER option, or you can let the module work against the current user. If you want to retrieve more than three messages, you can change that with MSGCOUNT.


New Modules


Exploit modules (2 new)

Auxiliary and post modules (2 new)


Get it


As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:


To install fresh, check out the open-source-only Nightly Installers, or the binary installers which also include the commercial editions.

UPDATE: Leaderboard can be found on this new post! Plus, some notes that may be helpful.


Exciting news! Rapid7 is hosting a month-long, world-wide capture the flag(s) competition!


Rapid7 recently released Metasploitable3, the latest version of our attackable, vulnerable environment designed to help security professionals, students, and researchers alike hone their skills and practice their craft. If you are unfamiliar with Metasploitable3, you can get up to speed with this blog post announcing its release. For an additional challenge in Metasploitable3, we’ve hidden several flags in the virtual machine that penetration testers can find to demonstrate their prowess.


To honor the release of this new tool – and to have a little fun – we’re hosting a month-long competition to see who can find the most Metasploitable flags! The competition will be very simple, and easy for anyone to participate in. For our leaderboard winners, we’ll be giving out some great prizes as well as some Metasploit T-Shirts for others who submit a captured flag.


Here’s how it works.

  1. Download and install Metasploitable3.
  2. Dig in! Find those flags!
  3. Complete a simple write-up (see format below or template here), providing proof you’ve found one and you’ll be added to the leaderboard. (Note: We may ask your permission to publish the write-up after the competition closes.)
  4. We’ll keep a running tally of the leaderboard at the bottom of this blog post.
  5. On December 31st we’ll announce the winners!



There are currently 15 flags hidden in Metasploitable3, with more being added. When you find a flag, take a screenshot of it.  Put it in a doc with the following information:

  • How did you get access to the machine?
  • How did you spot the file?
  • How did you extract the file?

Note: In some cases, the files are easy to find so please describe the extraction process. A template can be found here.


Please note: in the spirit of friendly competition, please only submit flags that have been found from a running metasploitable3 instance, not the vagrant folders used to build the instance


Then email capturetheflag [at] and we’ll review and add you to the leader board.  At the end of the month the top 3 people with the most submitted flags accepted will receive prizes. In the case of a tie, a set of subjective measures will be used to select the winners. The measure will be: creativity of methods used to obtain the flags and strength of the write-up. We reserve the right to award bonus prizes. And one note for our beloved Rapid7 employees: You are welcome to play along, but standings will be tracked separately and awarded accordingly.



1st Place: Hak5 Pineapple

2nd Place: LAN Turtle or Lock Pick Set

3rd Place: LAN Turtle or Lock Pick Set


The first 25 to submit a flag will get a Metasploit T-Shirt! We reserve the right to award bonus prizes.


Any questions? Feel free to comment below or email community [at] and we’ll get back to you. Happy Hunting!



Get all the updates here: Metasploitable3 CTF Competition: Update and Leaderboard!





Official Rules: Terms & Conditions


The Metasploitable3 Capture the Flags competition is open to anyone. No purchase is necessary to participate. Eligibility is dependent on following the entry rules outlined in this guide.


To Enter: Locate and screenshot flags found in Metasploitable3 and send a written submission detailing 1) how you got access to the machine; 2) how you spotted the file; 3) how you extracted the file, to capturetheflag [at]


A template can be found here or by searching for “Metasploitable3 CTF” on Partial or incomplete submissions WILL NOT BE ACCEPTED as an entry and shall not be eligible for any prize. All submissions will be reviewed by Rapid7 for adherence to these Official Rules. Rapid7 may ask for permission to publish written submissions after the contest close.


The leaderboard competition will open on Wednesday, December 7, 2016 at 12:00:01 ET and close on Saturday, December 31, 2016 at 11:59:59 ET. Entries submitted after this time may be eligible for additional prizes determined by Rapid7. In the event of a tie, Rapid7 will evaluate submissions to select the first place winner. A set of subjective measures will include 1) creativity of methods used to obtain the flags and 2) strength of the written submission. Rapid7 reserves the right to award bonus prizes.


The leaderboard will be updated regularly with the final submissions being added by Tuesday, January 3, 2017 at 11:59:59 ET.


Prizes/Odds of Winning: Only the prizes listed below will be awarded in the competition. Odds of winning depend on the number of eligible entries submitted by the close date. Prize is not transferable or redeemable for cash. Rapid7 reserves the right to make equivalent substitutions as necessary, due to circumstances not under its control. Please allow 3-4 weeks for delivery of any prize.


Leaderboard Prizes


Three (3) Prizes


Leaderboard Position


Approx. Value

1st place

Hak5 Pineapple (Nano Basic)


2nd place            

LAN Turtle OR Lock Pick Set


3rd place

LAN Turtle OR Lock Pick Set




Additional Prizes


Twenty-five (25) Prizes

The first 25 people to submit a flag will get a Metasploit T-Shirt (approx. value: $10) available from the online Rapid7 Retail Store. Rapid7 reserves the right to award additional T-shirt prizes.



Competition host is Rapid7 LLC, 100 Summer St, Boston, MA 02110.


By entering the competition, you agree to these terms and conditions. Employees and the immediate families of Rapid7 may not participate.


If you have any concerns or questions related to these terms and conditions, please email capturetheflag [at]


Metasploit Weekly Wrapup

Posted by egypt Employee Dec 2, 2016

Terminal velocity


The terminal/shell interface has been around for decades and has a rich and storied history. Readline is the main library for shells like msfconsole to deal with that interface, but it's also possible for commandline tools to print ANSI escape sequences that the terminal treats specially.


When a shell like msfconsole has asynchronous output going to the terminal at unpredictable times, such as when a new session connects, that output can clobber the current prompt. That makes it hard to tell what you're typing and slows you down.


These short videos, created by @jennamagius, the contributor who submitted this patch, illustrate the issue and the new behavior:






The old behavior has annoyed me for a long time and I'm super glad to see that typing into a prompt can still be usable when you have a ton of shells flying in.


New Modules


Exploit modules (4 new)


Auxiliary and post modules (1 new)


Get it


As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:


To install fresh, check out the open-source-only Nightly Installers, or the binary installers which also include the commercial editions.

Filter Blog

By date: By tag: