Microsoft Enhanced Mitigation Experience Toolkit (EMET) v5 security technology which I outlined in a previous post has several protection methods which will be detailed here. According to my sources at Microsoft 😉, EMET can be installed on workstations and servers (testing is always highly recommended before placing in production). Given the tremendous security improvements when installed, it is recommended for all Windows systems on the network.

Other EMET Comments:

• If you are still running Windows XP, you should definitely consider installing EMET (v5).
• Additional information on EMET 5 from the Microsoft Security Research and Defense Blog post & EMET mitigations guidelines
• An online video giving a more thorough overview of the mitigations can be seen here.
• TrustedSec has a walk-through for installing EMET 4 which is very similar to EMET 5.

It’s a good thing that EMET v5 is out now since several of the protections in EMET v4 have been bypassed.

The 4 recommendations from the Bromium whitepaper (Bypassing EMET 4.1):

1. Hook NtProtectVirtualMemory by default.
2. Create a new EAF protection scheme.
3. Check more than one CALL deep to see if code was RETed into.
4. Expand the ROP mitigations to cover 64 bit code.

It seems like Microsoft has incorporated fixes in EMET 5 to mitigate the issues discovered with version 4.1.

EMET 5 Improvements Overview:

Attack Surface Reduction (ASR)
The ASR is a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET 5.0 to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET 5.0 to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.

During the preview period we have performed several tests and collected your feedback to finalize the default configuration for this mitigation. We aimed at having a configuration that provided security, and at the same time, did not limit the user experience with the applications protected by EMET 5.0. By default, EMET 5.0 is configured to block some modules and plug-ins from being loaded by Internet Explorer while navigating to websites belonging to the Internet Zone, and to also block the Adobe Flash plug-in from being loaded by Microsoft Word, Excel, and PowerPoint. We have chosen modules that are commonly used in certain exploitation scenarios, but like all EMET features and mitigations, the ASR is completely configurable to satisfy everybody’s needs and to be tailored to specific systems’ requirements.

Export Address Table Filtering Plus (EAF+)
The EAF+ starts by the same concept as the existing Export Address Table Filtering (EAF) mitigation, but it amplifies its scope and robustness. During the Technical Preview, we have presented the EAF+ as an extension to the EAF. During the last couple of months we have made several improvements to it, and we decided that it should be a new mitigation on its own.

As already mentioned in the Technical Preview blog post, when EAF+ is enabled it adds the following additional safeguards:

• Perform additional integrity checks on stack registers and stack limits when export tables are read from certain lower-level modules
• Prevent memory read operations on the PE header, sections, import/export table pointers of selected modules when they originate from suspicious code that may reveal memory corruption bugs used as “read primitives” for memory probing

These improvements help detect and disrupt some current techniques used to dynamically discover ROP (Return Oriented Programming) gadgets and reliably execute code when a vulnerability is exploited.

64-bit Return Oriented Processing (ROP) mitigations
Many ROP mitigations are now available also for 64-bit processes: Deep Hooks, Stack Pivot, Load Library, and MemProt. Although we have not yet detected exploits that use ROP techniques to exploit 64-bit applications, we decided to extend the anti-ROP mitigations to this architecture to be ready when the time comes.

Strict checks for Certificate Trust rules
The Certificate Trust’s pinning rules can now be configured with a more aggressive “blocking” mode (not enabled by default), so that EMET 5.0 can force Internet Explorer to terminate the SSL connection without sending session data instead of just detecting the untrusted certificate.

EMET Service
We have added a new service, called EMET Service, which is taking in charge many duties that EMET Agent used to do in previous versions. The EMET Service, among other things, takes care of evaluating the Certificate Trust rules, appropriately dispatching EMET Agents in every user’s instance, and automatically applying Group Policy settings pushed through the network. Also, a service offers more resiliency and better ability to being monitored.

Hardening and better application compatibility
We have seen a technique to potentially bypass some of the EMET 4 mitigations. This technique is possible when a memory corruption within an EMET-protected application can be abused to overwrite selected memory areas and corrupt data belonging to EMET itself. We have also seen techniques aiming at disabling the EAF mitigation by invoking some specific API calls. In EMET 5.0 we worked to harden against potential bypass techniques.
We also refactored many components of the EMET 5.0 engine, in order to maximize application compatibility, also with some popular anti-malware products, and reduce potential false-positives.

The first screenshot includes the following protection methods:

• Data Execution Prevention (DEP) – Implemented by default on Windows 8.1, so this is greyed out.

In a previous blog post series we went into detail on what DEP is and how it works[part 1, part 2].  In summary, the purpose of DEP is to prevent attackers from being able to execute data as if it were code.  This stops an attacker from being able to directly execute code from the stack, heap, and other non-code memory regions.  As such, exploitation techniques like heap spraying (of shellcode) or returning into the stack are not immediately possible.

The effectiveness of DEP hinges on the attacker not being able to 1) leverage code that is already executable or 2) make the attacker’s data become executable (and thus appear to be code).  On platforms without ASLR (that is, versions of Windows prior to Windows Vista), it is often straightforward for an attacker to find and leverage code that exists in modules (DLLs and EXEs) that have been loaded at predictable locations in the address space of a process.  Return-oriented programming (ROP) is perhaps the most extensive example of how an attacker can use code from loaded modules in place of (or as a stepping stone to) their shellcode [3,1].  In addition to loaded modules, certain facilities (such as Just-In-Time compilers) can allow an attacker to generate executable code with partially controlled content which enables them to embed shellcode in otherwise legitimate instruction streams (“JIT spraying”)[2].

The fact that modules load at predictable addresses without ASLR also makes it possible to turn the attacker’s data into executable code.  There are a variety of ways in which this can be accomplished, but the basic approach is to use code from loaded modules to invoke system functions like VirtualAlloc or VirtualProtect which can be used to make the attacker’s data become executable.

Summary: DEP breaks exploitation techniques that attackers have traditionally relied upon, but DEP without ASLR is not robust enough to prevent arbitrary code execution in most cases.
Source: Microsoft Security Research and Defense Blog

• Structured Exception Handler Overwrite Protection – Implemented by default on Windows 8.1, so this is greyed out.

This mitigation performs Structured Exception Handler (SEH) chain validation and breaks SEH overwrite exploitation techniques.  Take a look at the following SRD blog post for more information on what these exploits are and how they are blocked. View post here. [Implemented in Windows since Windows Vista SP1]
Source: What’s EMET and How Can You Benefit (Windows Blog)

• Null Page Protection
  

  This blocks attackers from being able to take advantage of NULL dereferences in user mode.  It functions by allocating the first page of memory before the program starts.
  Source: What’s EMET and How Can You Benefit (Windows Blog)
  

• Heap Spray Protection
  

  Heap spraying is an attack technique that involves filling a process’ heap with specially crafted content to aid in exploitation.  Right now, many attackers rely on their content being placed at a common set of memory addresses.  This mitigation is designed to pre-allocate those memory addresses and thus block these common attacks.  Please note that it only aims to break current exploit that take advantage of these common addresses.  It is not a general mitigation for the larger heap spraying attack.  That said, if attackers do change the addresses they use, EMET users can change the addresses that are blocked.
  Source: What’s EMET and How Can You Benefit (Windows Blog)
  

• Export Address Table Access Filtering
  

  In order to do something useful an exploit generally needs to call functions exposed by Windows. However, in order to call one of these functions, the exploit must first find where it is loaded. This mitigation blocks the most common approach used by exploits to look up the location of a function which involves scanning the export address table of loaded libraries. It is highly effective at blocking exploits currently being used.
  Source: What’s EMET and How Can You Benefit (Windows Blog)

• Mandatory Address Space Layout Randomization
  

  ASLR randomizes the addresses where modules are loaded to help prevent an attacker from leveraging data at predictable locations. The problem with this is that all modules have to use a compile time flag to opt into this. Mandatory ASLR forces all modules to be loaded at randomized addresses regardless of what flags they were compiled with. Exploits relying on data at fixed addresses will fail.
  Source: What’s EMET and How Can You Benefit (Windows Blog)

• Bottom-Up Address Space Layout Randomization
  

  This mitigation randomizes (8 bits of entropy) the base address of bottom-up allocations (including heaps, stacks, and other memory allocations) once EMET has enabled this mitigation but not for previous allocations.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

• Load Library Protection
  

  EMET monitors all calls to the LoadLibrary API and prevents loading libraries from UNC paths (i.e. \\evilsite\bad.dll). It is possible to disable this option if a program is known to legitimately load DLLs from UNC paths or remote servers. This mitigation is available for 32 and 64 bit processes.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

• Memory Protection
  

  EMET disallows making the stack area executable. Such activity is usually used by shellcode or ROP gadgets. This mitigation is available for 32 and 64 bit processes.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

• ROP Caller Check
  

  EMET makes sure that when a critical function is reached, it is reached via a CALL instruction rather than a RET instruction. This is a very useful mitigation and breaks many ROP gadgets. This mitigation may be incompatible with some applications. This mitigation is available for 32 bit processes.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

• ROP Simulate Execution Flow
  

  This feature tries to detect ROP gadgets following a call to a critical function. Like the “Caller checks”, this feature may not be compatible with some applications. This mitigation is available for 32 bit processes.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

• Stack Pivot
  

  This mitigation is used to detect if the stack has been pivoted. This mitigation also validates the stack register present in the context structure of certain APIs. It is compatible with most programs. This mitigation is available for 32 and 64 bit processes.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

•  Attack Surface Reduction
  

  The Attack Surface Reduction (ASR) helps reduce the exposure of applications at risk for attacks by blocking the usage of specific modules or plugins within the target application. For example, EMET can be configured to prevent Microsoft Word from loading the Adobe Flash plugin, or, with the support of Security Zones, can be configured to prevent Internet Explorer from loading the Oracle Java plugin on a website in the Internet Zone while continuing to allow Java on Intranet Zone websites. The mechanism simply prevents DLL loading on a per-process base, and it essentially adds the benefit to “killbit” specific modules in specific applications.
  Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

Additional mitigations:

• Advanced Mitigations for ROP

EMET offers additional mitigation options that apply to all configured software. The currently available additional mitigations are related to the ROP mitigations, and when enabled or disabled they affects all the programs that have any of the ROP mitigations configured.

Following is a summary of what these advanced mitigations are:

Requires ROP
Deep hooks: EMET protects critical APIs and the subsequent lower level APIs used by the top level critical API. For example, EMET not only hooks and protects kernel32!VirtualAlloc but also the related lower level functions, kernelbase!VirtualAlloc and ntdll!NtAllocateVirtualMemory.

Anti detours: Some exploits attempt to evade the hooks by executing a copy of the hooked function prologue and then jump to the function past the prologue. With “Anti detours” option enabled, common shellcode using this technique are not effective.

Banned functions: By enabling this option, additional APIs, configured in a list, will be blocked when used. In this version only ntdll!LdrHotPatchRoutine is configured to mitigate potential exploits abusing this API.

Source: Enhanced Mitigation Experience Toolkit 5.0 User Guide [PDF]

EMET logs to the Application Event Log in Windows for activity review.