Monday, March 28, 2016

Understanding and Deploying EMET

Hey everyone - Last week, we talked about a few defense measures you can employ on your computer or in your organization.  One of those tools was EMET: Microsoft's Enhanced Mitigation Experience Toolkit.  Today, we will talk about EMET, why you might want to use it, and how to deploy it.  Let's do this!

What is EMET?

EMET is a tool Microsoft developed to help mitigate memory corruption vulnerabilities that are common exploit vectors when deploying malware.  You can download it here.  Memory corruption vulnerabilities include heap sprays and return-oriented-programming (ROP).  Many of the vulnerabilities that EMET protects against are ROP attacks.  We will talk briefly about ROP so that you can get a sense of some of the attacks that EMET tries to mitigate.

Return-Oriented-Programming (ROP)

In a nutshell, ROP attacks utilize common bits of code to take control of the flow of a program.  These common bits of code, or 'gadgets', are chained together to achieve execution.  Gadgets typically come from shared libraries (like kernel32.dll that takes care of input/output operations, memory management, and process creation) or the vulnerable executable itself.  ROP evolved from bugs in programs that allowed for things like buffer overflows.  Before we get into ROP, we should take a moment to talk about buffer overflows in case you are not familiar with them.

Buffer overflows

When a programmer wants to initialize a buffer for an operation like user input, they will allocate a certain number of bytes for how much space they expect that input to take.  Take a look at the following C code:

#include <stdio.h>

void Dangerous()
    char nameInput[10]; // No one has a name longer than 10 characters, right? :P
    printf('What is your name? ');
    gets(nameInput); // This is really dangerous

    printf('It is nice to meet you %s! I have to go now.  Good bye!', nameInput);

int main(void)
     return 0;

This is a contrived example, but the lesson is still valid.  The issue here is with the call to gets(...).  We do not check that we only get 10 characters so that we do not overflow the buffer.  Why is overflowing the buffer bad though?

To understand that, we need to understand how memory is allocated when a program is run.  Memory essentially comes in two flavors when it comes to program execution: heaps and stacks.  The heap is for the dynamic allocation of memory as it is needed by the program.  It is good if you need to allocate a lot of memory for something because it is an unstructured pool.  You can take and release as necessary.  The stack is much more rigid.   It contains things that are less likely to change and are of a known size.  When a program is executed, structures like addresses and variables of a known size are put on the stack (if they are not too big - there is a limit to the size of the stack defined by the OS).  It is called a stack because variables are allocated in a top to bottom structure as opposed to the heap which is unstructured.

In our example above, the character array nameInput will be put on the stack because its size is known at compile time and it is small.  Also on the stack are several registers that contain memory addresses.  Registers are small amounts of storage used by CPU for various purposes.

The ones that are important here are the extended stack pointer (ESP) and the extended instruction pointer (EIP).  We are going to talk about x86 for this example because that is common and easier to demonstrate.  Extended refers to the fact that when 32-bit x86 was first introduced, it could have longer (or extended) memory addresses than 16-bit x86.  With the introduction of x64, the 64-bit registers start with an R (RIP, RSP).  From here forward, I will talk about RIP and RSP because the example I am going to use is run on a 64-bit system.

In the x86 architecture, the stack grows down.  This means as variables are created and stack frames are allocated, they are added to the stack at lower and lower addresses.  So when the program starts, it starts at the top of the stack for the program.  If a function is called as the first instruction in the program, it is allocated a frame.  That frame is allocated on the stack and the base pointer (RBP, another register) is set to that address.  As things like other functions are called and local variables are allocated in the first function, RSP will move around to help the CPU keep track of where it currently is in the stack.

To know where it needs to go next during execution, the CPU references the RIP.  At the end of the called function, RIP would point back to the calling function right after the instruction to execute the called function (the address of which is in RSP by the time the function is ready to return).

Problems can arise when RSP is overridden during the course of the function and the address that the CPU goes to is not what the programmer intended.  For example, if the attacker places shellcode (assembly instructions) in the stack and then is able to overwrite RSP with the start of those instructions, the attacker could execute arbitrary code.  Modern systems prevent this with a number of different mechanisms including marking certain parts of memory non-executable.  So, even if executable code makes it into an area marked non-executable, it will not be allowed to run.

Let's take a look at what overwriting RSP looks like during execution using the code above.  I am going to use a Linux system to do this, but the principle is the same on Windows and other operating systems.

To compile the code, I am using GCC (the GNU C Compiler), and I am turning off stack protections with the -fno-stack-protector flag and enabling debugging symbols (which allow us to debug the program easier) with -g:

Even gcc is telling us we are being dangerous.  But we are living life on the edge, so we are going to press on.

So we can see what is happening while the code is executing, we will use the GNU DeBugger (gdb).  To keep things tidy on the screen, we will suppress the intro messages with -q.  First, we will diassemble main() to see the flow of the program using the disas (disassemble) command:

We can see that the base pointer (RBP) is pushed onto the stack, and the stack pointer (RSP) is set to the value in RBP.  Since the function Dangerous does not have any arguments, we do not need to move anything onto EAX to supply to Dangerous.  After Dangerous is done, the program is pretty much done, and it will return (exit).

We are interested in the Dangerous function, so let's see what that looks like with disas:

We see the three function calls we made in the source code (printf, gets, and another printf).  We will do two runs of the program.  One that does not overflow the buffer and one that does to see the differences.  For each run, we will look at the stack pointer and the instruction pointer when the function is done.  To stop the program before it returns, we need to set a break point.  The break point will be at the retq call (address 0x4005c6 in this example).  To do this, we tell gdb to break at memory address (denoted by *) 0x4005c6 with the command break *0x4005c6 and run the program with run.

We will look at the contents of each register with the x (eXamine) command.  For RIP, we want to see the instruction, so we will use x/i which tells gdb to tell us the memory interpreted as an instruction.  For RSP, we want to see the contents of the memory as a 64-bit hex value so we can see what address it will return to, so we will use x/gx (g for 64-bit, x for hex).

Let's take a look:

So we input the name Bob, and looking at RIP, it will return to the address specified in RSP.  In this case, we can see it is 0x4005d5, and if we look at the disassembly of main above, we can see that 0x4005d5 is the instruction after the call to Dangerous.  If we let the function continue (using the c command), it exits normally:

Awesome.  Now, let's see what happens if we overflow the buffer.  To make things easier to see, I will overflow it with the capital letter A which in hexadecimal is 0x41.  If we re-run the program with r and put in a bunch of As, let's see what the registers look like:

So we can see the RIP will still execute the return function, retq, but RSP is now filled with As.  If we try to continue, the program crashes because that address is not valid:

Evolving from the Simple Buffer Overflow

As you saw above, I had to disable stack protections to make this work.  Buffer overflows have been around a long time, so there are a number of defenses against them.  Since exploits and countermeasures are a big cat and mouse game, ROP was created.  Instead of using shellcode, ROP chains existing code together in libraries that the program loads or in parts of the program itself.  The functions could be something like exec() which is part of the standard C library and is loaded by a large number of programs (at least on Linux, though a similar call exists in Windows).

To meet that threat, EMET deploys a number of countermeasures to help mitigate this.

Is EMET the silver bullet?

No.  While EMET is really good, it has been bypassed in the past.  However, just because EMET has been bypassed, it is not useless.  In order to bypass EMET, exploit developers have to step up their game.  Also, in order to bypass all of EMET's protections, the exploit would have to be quite complex, and in trying to bypass EMET, it could flag other defense measures, like your host-based IDS.

EMET should be deployed as part of a layered defense plan, including network intrusion monitoring, user education, patching, and all of the good practices we have talked about in the past.  I think that EMET is worthwhile, so we are going to learn how to use it.  Then, I will show you how to deploy it across a network using Group Policy.

A Tour of EMET

EMET works by injecting code (a dynamically linked library or DLL) into processes you choose.  When you execute a program that is protected by EMET, EMET looks for code trying to use common exploit techniques and terminates the process before the "bad" code has a chance to execute.  I will very briefly cover each of the techniques that EMET tries to mitigate against, but if you want more detail, check out the user guide for EMET available here.  I wanted to add a bit more information than what is in the user guide.  These are current as of EMET 5.5.
  • Attack Surface Reduction (ASR): This allows an administrator to tell EMET to block certain applications from using certain plugins.  For example, you can disallow Firefox from using Java.  Of course, you can do this without EMET, but EMET allows you to define security zones.  When you define a zone, you can say that certain plugins are allowed to run when the site is in a given zone, but otherwise it is disabled. 
  • Bottom-up Randomization: EMET will randomize the base address of things like stack pointers, heap pointers, and others.  This is similar to ASLR (see below), but is for certain types of memory spaces.
  • Certificate Pinning: When an SSL / TLS certificate is issued, it could be signed by a number of intermediate Certificate Authorities (CAs) and those certificates are then signed by a Root CA.  If you are being targeted with a man-in-the-middle attack, you might not know it because the certificate has been signed by "trusted" CAs even if those CAs have been compromised or a root CA that has been added to your trusted certificate store without your knowledge.  Certificate pinning tells a browser to skip verifying the chain and only use certain certificates for a given domain.  The accepted certificates can be loaded into the software (like a browser) or when the certificate is first seen.  For example, Google ships accepted certificates for with Chrome.  EMET can enforce pinning for Microsoft and other Microsoft services (like Skype) for Internet Explorer.
  • Data Execution Prevention (DEP):  Data Execution Prevention has been around in Windows since Windows XP SP2.  In programs that opt-in to DEP, memory will be marked as executable or not.  For example, parts of memory used to store stack variables will be marked as non-executable, and any code that happens to be put there by an attacker will not execute.  We turned off stack protections to get our example C code to work.  The key with DEP is that a program has to be compiled with DEP turned on.  Not all programs are.  EMET allows an administrator to opt-in a program that was not compiled with DEP enabled.
  • Export Address Table Access Filtering (EAF) / EAF+: When a program uses a library, it does not know where the addresses for desired functions are.  For example, if a program needs a function out of kernel32.dll (which is very common), it will look in the export address table for kernel32.dll to find where the desired function lives.  Shellcode is similar.  In order for it to do what it needs to do, it usually needs something from the Windows API (Application Programming Interface) from libraries like kernel32.dll and ntdll.dll.  An application programming interface is a set of functions that are exposed by a library to other programs that need the functionality.  If EMET determines that shellcode is trying to call one or more of the addresses in the export address tables, it will block those calls.  EAF+ performs additional mitigations and can be loaded independently or with EAF.
  • Heapspray Allocation: You saw in our example above that a malicious person has to put his code in a certain place to get it to work.  Sometimes, they will try to put their code in as many places as possible on the heap so their chance of success will be greater.  This is called a heap spray.  EMET reserves some of the more common places for itself so that if some malicious code tries to jump into those places, it will fail.
  • Mandatory Address Space Layout Randomization (ASLR): If you ran our example program above multiple times on the same computer, all of the memory addresses will be the same without ASLR.  An attacker could then write their exploit against the same memory addresses. ASLR randomizes where different sections of memory live, so an exploit writer would have to do more work to figure out where they need to place their exploit code.  Like DEP, a programmer must compile support for ASLR into the program.  EMET allows a program to be opted-in after it is compiled.
  • Null Page Allocation: When a programmer declares a variable, the variable will not point to anywhere in memory (a null location) until the program allocates memory for that variable and points it at that memory.  If a programmer makes an error and tries to do something with that variable before it is allocated, it can cause an error.  In theory, an attacker can take advantage of this to crash the program.  Depending on how the crash is handled, the attacker could glean information about the program that could be useful for other attack techniques they want to try.  They could also be trying to deny the user access to the program by intentionally crashing it.  EMET tries to stop an attacker from being able to do something useful after they crash a program this way.
  • ROP Mitigations
    • Anti-detours: Shellcode can call copies of the EMET-hooked API functions and jump to the real function.  EMET mitigates this.
    • Banned Functions: Certain API functions are blocked if a program tries to call them.  Obviously, this can break some things, so you will have to test if your application will not work with this protection enabled.
    • Caller Checks (32-bit only): If a critical Windows API is called with a retr (return) statement and not a call instruction, the call is denied.  This can break some things, so you might have to turn this one off.
    • Deep Hooks: EMET will hook into certain common API functions that are used by ROP attacks and try to protect them.  It will also hook lower level functions that are called by those top-level API functions.
    • Load Library Paths (32/64-bit): If a program tries to load libraries from a network path, EMET will deny it.
    • Memory Protection Checks (32/64-bit): EMET will stop any attempts to make the stack executable.  This is similar to DEP.
    • Simulate Execution Flow (32-bit only): EMET will try to follow the call for certain Windows API functions, and if it detects ROP gadgets, it will terminate the call.
    • Stack Pivot (32/64-bit): Stack pivoting is when the stack pointer (ESP) is pointed to a part of memory that the attacker controls.  EMET can detect this and try to stop it.
  • Structured Exception Handler Overwrite Protection (SEHOP): When an error occurs in a program, an exception may be thrown by the program that it can handle itself or rely on an external handler to take of.  In order to deal with an exception, the program calls an exception handler which is some code defined by the programmer that will take any necessary actions to deal with the exception.  For example, if an exception is thrown, the associated exception handler may print a friendly error message.  In vulnerable programs, an attacker may overwrite the address of an exception handler with the address of malicious code.  If EMET detects that an exception is going to be handled by a handler that was not previously defined, it terminates the program.
  • Untrusted Font Mitigation (Available in Windows 10+): If a program tries to use a font that is not installed in the default location (the Fonts folder in the Windows directory), the attempt is blocked.  This can be enabled on an application by application basis or system-wide.
We have done a lot of talking about how EMET works, but now we should talk about actually installing and using EMET.

Deploying EMET on a Single Machine (Or Multiple Machines Without a Domain)

If you want to use EMET on a single computer or on several computers without a domain, you can simply download EMET from Microsoft's website and install it.  We will talk about deploying it in a domain a little later.  Before we get started, I want to mention that because EMET injects itself into a process, that could cause a given process to misbehave.  Before deploying this to a large number of computers, it would be wise to test the applications your organization relies on with EMET's protections so that you do not break anything.

When you install EMET, it will ask if you want to use the recommended settings or if you want to start from scratch.  We will start with the recommended settings and build up from there.  The recommended settings add protections for IE, WordPad, Office, Java, Adobe Acrobat, and Flash.  Those are good places to start.  After it is done installing, there will be a system tray icon that looks like a little lock.  If you right click that, you can choose Open EMET.  Once you do, you will be presented with the main EMET screen:


Along the top, you have options to save and load configurations, fine tune your current configuration, and other options related to reporting and help.  In the middle, you can change system wide options for a few of the mitigations we talked about above.  This is the first place where we will change some options.  As we talked about above, DEP must be enabled when a programmer compiles the program.  We can tell EMET to force DEP for all programs, regardless if DEP was enabled or not at compile time.  To do this, hit the arrow next to Application Opt In for DEP and change it to Always On:

I recommend doing the same for SEHOP.  Unfortunately, ASLR cannot be forced for applications that are not compiled with that protection, so we will leave the ASLR setting at Application Opt In.  We will keep Certificate Pinning enabled.

At the bottom, you can see a list of running processes and whether or not they are protected by EMET.  If you look through the list, you can see that no application is currently protected by EMET.  That is because we are not running anything covered under the default rules fot the recommended configuration (things like Internet Explorer, Office, Java, et cetera).  We will configure some rules in a bit that apply to other programs.

Since we need to reboot the computer to have the DEP and SEHOP changes apply, we will reboot the computer now.

When the computer comes back up, we can see that DEP and SEHOP are always enabled.  Now we can apply EMET to other applications.  To get started, hit the Apps button in the main EMET GUI.  You should get a window that looks like this:

You can see all of the different mitigations we talked about above all of the check boxes.  Another useful function is the Default Action at the top.  If you are testing EMET for use in your environment, you can tell EMET to work in Audit Only mode.  Instead of stopping a program when it detects something funny, EMET will log it in the Event Log.  You can use this as a sort of learning mode to see if EMET will have unintended side effects in your environment.  When you are ready to have EMET employ its mitigations, you can change this setting back to the default (Stop on Exploit).

If you click the Show All Settings button, you will get a little more information about the various mitigations:

If you would like to see the full path of the executables protected by EMET, hit the Show Full Path button.  Feel free to add or remove mitigations that are set up by default.  For purposes of this post, we will go with the defaults.  Let's apply what we have talked about so far and configure another application.

We will configure Firefox with all available mitigations.  I downloaded and installed Firefox earlier.   You can substitute whatever application you wish.  To begin, click the Add Application button.  The first window that will pop up will ask you to find the application you want to add to EMET's configuration:

Firefox lives in C:\Program Files (x86)\Mozilla Firefox, so navigate there and choose firefox.exe.  Once you do, you will be back at the Application Configuration screen.

Generally, I enable all of the available protections, turn on audit mode, and use the application normally.  If the application crashes, I will disable the mitigation that caused the issue.  If I can find a way to keep the mitigation and still perform the task I want, I will look for those routes, but they are not always available.  As with anything security related, you have to balance security and usability.

Once you hit OK, you will get a message saying that some applications may need to restart applications to enable EMET's protection for that application.  Remember that is because EMET injects itself into the process and can only do that as it is being launched.

When EMET is protecting your chosen application, you will see a green check mark next to the application, like this:

That is all there is to it.  You can also use the Trust button to configure certificate pinning.  We are not going to do that in this post, but it is something to explore if you need that protection.

You can also Export your configuration and deploy it across multiple computers if they are not managed by a domain.  Simply use the Export button under Application Configuration.

If you want to be able to configure EMET without the GUI, there is a command line executable (EMET_Conf.exe) that you can use.  Please note that as of version 5.5, it does not support all configuration options for EMET.  However, it does support some important ones.  For example, you can import the configuration (saved as XML) from another instance of EMET using the --import option.  You can also configure all protections for a given application using EMET_Conf.exe --set <path to executable>.  A complete list of options is available by typing EMET_Conf.exe --help from the command line.

What Applications Should I Protect with EMET?

This section serves as a general guideline, not as gospel.  The exact configuration you will need for any defensive tools depends on your environment.  With that being said, I would look at the following applications:
  • Anything that is known to be particularly vulnerable.  The default settings cover things like Acrobat and Java, but there are other applications such as Adobe Air and Apple Quicktime (those are just examples).  You can look at CVEs to see which products may be particularly vulnerable at a site like this (
  • Anything that touches an untrusted network.  Web browsers, media players, and other applications fall into this category.  Firefox and Chrome are examples.
  • You could also deploy EMET on your server.  Server services (like IIS, MS SQL, or SMB) are popular targets for exploitation, and you could point EMET at the service executables for these services.

Deploying EMET Using Group Policy

In order to deploy EMET via Group Policy, we need to put the setup file in a place that the computers in the network can see it.  We created the deployment folder in the root of our C: drive when we set up the domain for this purpose, so copy the "EMET Setup.msi" to this folder.

Then, we will use Group Policy to configure it.  We will deploy EMET for computers in our Workstations OU that we created when we set up the domain.  Open the Group Policy Management snap-in (Start > Run > gpmc.msc).  Then right click the Workstations OU and click "Create a New GPO in this Domain and Link it Here"

 We will name it Deploy EMET.  The new GPO will show up under Workstations.  We could also link this GPO to other OUs if we wanted to use it on other machines in our network (like servers).

Right click the new GPO and choose Edit.  The Group Policy Management Editor will pop up:

Expand Policies > Software Settings and click Software Installation.  Then right click anywhere in the right pane and choose New > Package:

Navigate to a place where every computer in the network can see.  I set up a file server called

Click Assigned in the window that pops up:

After this is done, right click the GPO under the Workstations OU and choose Enforced.  Then, restart the client computer (or run gpupdate /force /boot which will reboot the computer).  When you restart, you should see the EMET icon in your system tray.  EMET is deployed.

Now, we need to push a configuration to it.

EMET Configuration Through Group Policy

There are two ways you can use Group Policy to manage EMET configurations.  One way is via the EMET GUI, and the other way is through the normal Group Policy tools (like Group Policy Management Editor).  We will configure EMET through normal Group Policy tools for the most part, but we will start things off using the EMET GUI.  Not all of the group policy configuration options are available through the EMET GUI.  Please note that if you choose to enable the default protections through Group Policy, they will not be exposed through the GUI on the individual workstations.  They will still work, but you will not see them in the GUI. If you want to have the default protections visible through the GUI or you want the ability to easily push an XML configuration into Group Policy, you should install the EMET GUI on the machine you are managing Group Policy from.

To get started, you will need the ADMX and ADML (Group Policy Template) files for EMET.  They come with every EMET install, so you can either install EMET on your server, grab the files from another EMET install, or use the EMET installer to extract all EMET files.  To use the EMET installer to get the files without actually installing EMET, issue the following command from the command line:

msiexec.exe /a <path to EMET installer>

Whichever way you choose, the files we need are available in the Deployment folder wherever EMET is installed or extracted.  In the Group Policy Files folder, there should be two files: EMET.admx and EMET.adml.

EMET.admx needs to be moved to %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\ (create this folder if it does not exist).  The path for our example domain is \\WIN-J5OF2U1H36S\sysvol\windows.local\policies\PolicyDefinitions and EMET.adml needs to be moved to %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\en-US (create this folder if it does not exist).  You should substitute en-US for whatever your locale is.  en-US is United States English.

Back in Group Policy Management (gpmc.msc), we will create a new GPO for the EMET configuration for our workstations.  Right click the Workstations OU and create a new GPO and link.  You can name it whatever you like.  I chose EMET Configuration - Workstations.

Once you have named it, find the new GPO, right click it and choose Edit.

The Group Policy Management Editor will pop up.  The EMET settings we will look at are located in two places.  They manage the system-wide settings and user configuration.  The system-wide settings are available in Computer Configuration > Policies > Administrative Templates > EMET.  Per-user configuration is in User Configuration > Policies > Administrative Templates > EMET.  Close this window if you are going to use the GUI for initial set up.  If not, skip the next section.

Using the EMET GUI for Initial Group Policy Configuration

If you want to use the EMET GUI to do the initial set up we can tweak later, open the EMET GUI and click the Group Policy button.  EMET will ask you to choose your GPO object.  In this case, we will choose our newly created GPO object "EMET Configuration - Workstations"

The EMET Group Policy Window pops up.

We will start with the familiar system-wide options (DEP, SEHOP,  ASLR, and Certificate Pinning).  For our example, we will set all of these to always on except ASLR.  ASLR will be set to application opt-in.  If you force this on, it could cause instability.  In the best case, an application that is not ASLR aware will crash.  In the worst case, the system will not boot.  If through your testing that you found that you needed different settings, use those.

With that done, we will move on to Application Configuration.  If you click the Apps button, you will see there is nothing there because we have not made any configuration changes.  Configuration changes made here will populate the Application Configuration key under the Group Policy settings.

We will start with the defaults.  Click the Import button and navigate to the Deployment folder we got the admx and adml files from.  There will be another folder in there called Protection Profiles.

Click CertTrust and then click Open.  Do the same for the other two files.

Now if we check our configuration, we can see that there are lots of applications loaded now:

If we look at the certificate pinning rules, we can see they are populated too:

Using the Group Policy Management Editor to Edit EMET Settings

If we go back to the Group Policy Management Editor, we can see that the options we changed have changed in here as well:

If you want to tweak application settings later, you can use the Application Configuration key here to do so.  You can tweak certificate pinning settings as well using the Certificate Pinning Configuration key.  If you double click Application Configuration, it will look blank, but you can use the Show button to see what we have configured through the GUI.

If you want to add something here, the bottom right pane shows you the syntax to use.  It is very similar to the command line tool.  For example, if you wanted to enable all default protection for myapp.exe, hit the Show button, go all the way to the bottom, and type myapp.exe in the left box.

That will enable protections for any application called myapp.exe no matter where it is on the hard drive.  If you leave the right box blank, that will enable all protections.  You can specify protections you do not want by putting a hyphen in front of the protection name.  I am not going to add anything for my example, but feel free to if you like.

Once you are done, click OK until you are back at the Group Policy Management Editor.  If you are all done, then close Group Policy Management Editor.  We are done editing the group policy.  To enforce it, right click the group policy object, and choose Enforced, then say OK.

On the client machine, you can run gpupdate /force from a command prompt or simply restart the computer.

If you cannot open EMET on the client, there is a workaround you can employ.  I had this problem on some of the test machines I was playing with.  It seems that the EMET installer does not always create all of the needed registry keys when deployed through Group Policy.  To fix this, run Registry Editor (regedit.exe) as the Administrator you are going to administer EMET with and create HKEY_CURRENT_USER\Microsoft\EMET (it is a key).  The GUI is separate from the service that actually does the mitigations, so you do not strictly need it.  However, if you open the GUI, go to Apps then click Show Group Policy Apps, you will see all the configuration we loaded into Group Policy:

That is it for configuring EMET through Group Policy.


Conclusion and Final Thoughts

We took a look at buffer overflows, mitigations that EMET performs, and deploying EMET.  EMET is not going to stop all threats all the time.  With that being said, it should make things just a bit more difficult for someone to successfully exploit your system.  EMET is a layer in a good network defense strategy.  Hopefully, it will help the attacker make moves that get his activity noticed by your IDS / IPS, your users, or other network defenses.

Do you use EMET?  Why or why not?  I am interested to hear your thoughts.  Thanks for reading!


EMET 5.5 User Guide

Further Reading

Deploying EMET Configuration Without Using Templates (ADMX)
Deploying EMET via WSUS