When planning your organization’s security strategy, there are a number of different tools available.  Once such tool is Microsoft’s Enhanced Mitigation Toolkit (EMET) to protect applications from new and emerging threats. In this article, I’ll cover EMET’s protections, system requirements, and other useful information about the tool. 

The Enhanced Mitigation Experience Toolkit, or EMET for short, is a free security tool from Microsoft that is designed to protect software from undiscovered or zero-day exploits that may not have security fixes yet and/or are able to slip past other system protections. EMET, like other tools, can’t protect against 100% of threats, but gives IT departments another tool to protect against attacks and protect corporate networks. When implementing your endpoint security plan, you should definitely consider adding EMET to supplement tools like regular/scheduled patching, antivirus, AppLocker, and other security tools.

Enhanced Mitigation Experience Toolkit 5.5 on Windows 10

Enhanced Mitigation Experience Toolkit 5.5 on Windows 10

EMET Mitigations

EMET is compatible with most third-party applications on both client and server versions of Windows as well as built-in Windows applications. Here are the security mitigations available in EMET 5.5 with brief explanations. If you’re looking for more technical explanations of the mitigations, they are available in the EMET User Guide.

  • Attack Surface Reduction (ASR) Mitigation – This mitigation blocks the usage of specific modules and plugins in target applications.
  • Data Execution Prevention (DEP) Security Mitigation – This mitigation prevents an attacker from placing executable code in certain areas of memory. Applications must be compiled with a special flag to include Data Access Prevention; using EMET, you can force applications compiled without the flag to also use DEP.
  • Structured Execution Handling Overwrite Protection (SEHOP) Security Mitigation – This mitigation protects against one of the most common attack vectors for exploiting stack overflows in Windows.
  • Heapspray Allocation Security Mitigation – This mitigation prevents shellcode from being placed into commonly used memory pages.
  • NullPage Security Mitigation – Similar to a heapspray allocation; this mitigation is designed to prevent potential null deference issues in user mode.
  • Export Address Table Filtering (EAF) Security Mitigation – This mitigation filters accesses to the Export Address Table based on the calling code origination.
  • Export Address Table Filtering (EAF+) Security Mitigation – This mitigation is an extension of EAF and can be used with or without EAF.
  • Mandatory Address Space Layout Randomization (ASLR) Security Mitigation – This mitigation randomizes the addresses where modules are loaded to prevent an attacker from using predictable memory locations.
  • Bottom Up ASLR Security Mitigation – This mitigation randomizes the base address of bottom-up allocations.
  • Load Library Check [Return-Oriented Programming (ROP) Security Mitigation] – This mitigation prevents .dll files from being loaded from UNC paths.
  • Memory Protection Check [Return-Oriented Programming (ROP) Security Mitigation] – This mitigation disallows making the stack area executable.
  • Caller Checks – [Return-Oriented Programming (ROP) Security Mitigation – 32-bit processes only] – This mitigation ensures critical functions are reached via a CALL instruction rather than RET.
  • Simulate Execution Flow – [Return-Oriented Programming (ROP) Security Mitigation – 32-bit processes only] – This mitigation, following a call to a critical function, tries to detect ROP gadgets.
  • Stack Pivot [Return-Oriented Programming (ROP) Security Mitigation] – This mitigation detects if the stack is pivoted and validates the stack register present in certain APIs.
  • Windows 10 untrusted fonts – This mitigation protects systems from untrusted fonts that are installed outside of the C:\Windows\Fonts directory.
  • Certificate Trust – This feature adds additional checks to certificate trust validation to protect systems from man-in-the-middle attacks.

EMET 5.5

Released in late January 2016, EMET 5.5 is the latest version of the tool as of the writing of this article. This version includes support for Windows 10, along with a number of other new features:

  • Protects Windows 10 from untrusted fonts
  • Certificate pinning based on root CA thumbprints
  • Improved Group Policy management
  • Improved writing of mitigations to the Registry; improves management using existing tools like Group Policy
  • New command line syntax and options
  • EAF/EAF+ pseudo-mitigation performance improvements

System requirements for EMET

To run the latest version EMET, you must have the .NET Framework 4.0 installed.  If you’re still running IE 10 and Windows 2012 (which I hope you aren’t), you’ll need to have KB2790907 installed.

Are there risks using EMET?

Yes, some applications may use functions that are explicitly blocked in mitigation rules that you’ve created in EMET, which will lead to applications closing unexpectedly. You’ll definitely want to test applications with any new mitigations you’ve configured before mass deployments of new rules to ensure that applications don’t break once new EMET rules are applied.

Does Windows 10 need EMET?

The short answer is, it depends.  The EMET Team at Microsoft recently discussed the built-in mitigations in Windows 10. EMET can be used for providing CFG (Control Flow Guard) protections for third-party applications that are not compiled with that feature enabled. CFG analyzes and discovers indirect-call instructions within applications.  A check runs before indirect calls within an app, and closes the app if the code tries to run an unexpected indirect call. If you have apps that were compiled without CFG – which many of us do – EMET allows you to provide that functionality to the app without your developers having to recompile the app or complicated conversations with your app vendors.

Windows 10 also has additional protections like AppLocker and Device Guard that can be used to protect computers from running untrusted applications and to control which trusted applications are allowed to run.

Microsoft Edge, the new web browser for Windows 10, includes improved sandboxing and memory management. Because of these improvements, EMET mitigations are not necessary for Microsoft Edge.

Subscribe to 4sysops newsletter!

In my next post I will describe how you can install EMET.

  1. Brian G 7 years ago

    IE 10 is the last and supported browser on Server 2012.  On Server 2012 R2, the supported browser is IE 11.

    • Author

      Thanks! I tweaked the wording so it would sound better. If you’re still running Server 2012, you should really be looking for a way to upgrade to 2012 R2.

Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account