Tweaking Metasploit Modules To Bypass EMET – Part 1

Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is designed to increase the protection of your system against exploitation. It can render current Metasploit modules useless, as they’re currently not designed to bypass it. We discuss ways to tweak Metasploit modules in as much a generic way as possible, so they can work against targets utilizing EMET.

EMET has several modules that are designed to (further) protect your computer from exploitation, providing protection even for legacy applications and operating systems that don’t inherently support advanced defense mechanisms. EMET’s modules provide, among other things, support for data execution prevention (DEP), mandatory address space layout randomization (ASLR), and export address table filtering (EAF).

There are two main areas we need to concern ourselves with when trying to bypass EMET: the exploit and the Metasploit payload. Obviously, the exploit needs to be crafted so as to bypass EMET. This cannot be generic – we can’t find a solution that will automatically work for all exploits, as the intrinsic details of the exploit are important to accomplish successful bypassing. It might be a different story when we consider the Metasploit payloads. Sure, we may be able to tweak each payload to bypass EMET, but that’s really missing the point. We would like to have a generic solution that enables all unmodified payloads to work for a specific exploit.

To sum it all up, we’re going to need to know the specifics of the exploit, and then tweak it to bypass EMET regardless of the Metasploit payload used.

For this example we select a very simple configuration: the Poison Ivy exploit, and Windows XP SP3 with EMET v3.0.0.0 (the latest version at the time of writing). Here’s what we know:

  • The vulnerable executable is not compiled with any exploit mitigation technique.
  • The exploit takes advantage of a stack-based buffer overflow vulnerability to put the payload on the stack and run it from there.
  • The exploit uses address 0×401000 (and a little bit onwards) as a place to write data to (such addresses were needed during exploitation). I.e., we can use this set of addresses as destination for our data, without really doing more “damage” than the original exploit does.
  • There are no characters we need to avoid. Not even null bytes.

What Are We Up Against?

In order to bypass something, it’s always good to know where you’re being stopped. Let’s try EMET with different configurations, and see what’s bothering it. Here’s the first configuration:

As we said, this is a simple exploit on a simple system, so this configuration of EMET doesn’t even bother it:

Next, we enable DEP:

Without even trying the exploit, we run Poison Ivy’s C&C server and get:

Apparently, PI’s unpacker conflicts with DEP. This shouldn’t come as a surprise, as the comments at the end of the official Metasploit module say so. So we can’t enable EMET’s DEP feature. Let’s check what happens when we enable EAF:

We run the exploit and get:

Clearly, the exploit failed. This is what EMET shows:

So basically, for this specific exploit, we only need to overcome EAF. This means that there’s no need to modify the exploitation method, as the problem manifests itself only when the Metasploit payload is run, i.e., after a successful exploitation of the vulnerability. Metasploit modules use the export address table to find addresses of API functions needed by the payload, and that’s where EMET stops them.

Bypassing EMET’s EAF Using Structured Exception Handling (SEH)

It’s a known fact that EMET uses hardware debug registers to intercept instructions that access the EAT through the PEB/TEB. EMET’s code checks that the code traversing the EAT linked list originates from a module’s code section. If that check fails, EMET terminates the application. Naturally, since Metasploit payloads traverse the linked list, and our payload resides on the stack, we’re guaranteed a glorious failure.

All is not lost, though, as all we need to do is find a way to zero the debug registers before letting our payload run. Unfortunately, direct access to the debug registers is restricted to ring 0 code, and most exploits never go past user-land. You might want to let the OS zero the debug registers for you, but that would require getting the address of the appropriate exported functions… Hmmm… Chicken and egg? Maybe not. We will revisit this idea later.

Lucky for us, there is a way to manipulate the debug registers from user space without needing any exported function, and that’s through the use of structured exception handling (SEH). Utilizing SEH to modify the debug registers is rather easy. When an exception is raised, the thread’s context is saved on the stack, and so we can install a custom exception handler that will modify the saved debug registers on the stack, and pass execution back to the program.

Since our payload is on the stack, but we can’t have an exception handler on the stack, we first need to put our exception handler somewhere else. The executable’s code section is marked RWX, and we can put our code there. Normally, we would try to find a place that we can (almost) be certain we can overwrite without causing the program any harm. For this PoC, as mentioned before, we choose 0×401000 as the destination address.

Moreover, in this PoC, 68 bytes are copied to the executable. This is hardly optimized. Not only could we cut down on the code size, but we could also just copy the handler to the code section, leaving the code that triggers the exception on the stack. I leave the optimization as an exercise for you, as the best way to really learn these techniques is by having hands-on experience.

Here’s the PoC, which is a tweak to the original code:

So here’s the do_exploit function from Metasploit’s official Poison Ivy module:

And here’s the modified version that bypasses EMET’s EAF:

Let’s test it:

You can use this example of bypassing EMET’s EAF to try and modify other Metasploit modules and see if you can get them to bypass EMET. In the coming parts we’ll deal with other techniques and different configurations.

Go to part 2.


Be Sociable, Share!

4 thoughts on “Tweaking Metasploit Modules To Bypass EMET – Part 1

  1. Interested to see where this goes though it’s worth noting a few things.

    1) Software DEP is actually SafeSEH (that’s what you’re forcing I believe.)

    2) EAF is bypassed most easily through ROP

    3) ASLR does not work with XP even with EMET

    • 1) This is not software DEP, but hardware DEP. Hardware DEP is available since XP SP2.

      2) And what is it that you do, exactly? You do remember that you’re not allowed to change the payload, right?

      3) I don’t know how much value it has when the executable doesn’t support it anyway.


      • That’s interesting. I really wasn’t sure about the hardware DEP being forced but I’ll take your word for it.

        As for ASLR it doesn’t have much value for XP. Mandatory ASLR is more for a program that supports ASLR but gets loaded with non-ASLR modules (like loading Firefox with Norton Toolbar.)

        I just wanted to point it out – that’s all.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>