Using Microsoft's Enhanced Mitigation Experience Toolkit 5.0

EMET enforces security measures.

security awareness lock data finger touch point up

Sometimes we need someone to have our back. Applications, believe it or not, are the same way. Applications don't always behave as we expect them to, and though Windows has built-in protections for program misbehavior and exploitation, it can sometimes be difficult to tell if those protections are active and what exactly they are defending.

Enter EMET. Here's what it is, how it works and what's new in version 5.

What is EMET?

The Enhanced Mitigation Experience Toolkit, or EMET, is basically a shield or a shell that runs over Windows applications and forces them, regardless of how those applications were coded by their original developer, to take advantage of security defenses that are built into the Windows operating system.

EMET is supported on Windows XP Service Pack 3 and later, Windows Vista Service Pack 1 and later, all levels of Windows 7 and Windows 8 on the client side. From the server operating system perspective, EMET is supported on Windows Server 2003 Service Pack 1 and later, all levels of Windows Server 2008, all levels of Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.

EMET is a wrapper that enables and enforces a set of protections that, when used together, significantly enhance the security posture of a machine and greatly reduce the chance that exploits can run against it and cause any harm. Most will simply fail to execute completely. It is particularly helpful in protecting against exploits that have not yet been patched by a software developer, making it a key tool that should be in your security arsenal.

EMET in its newest version, 5.0, relies on six main defenses to offer its protection, and these are based on the following security technologies:

Data execution prevention, or DEP, which was introduced in Windows XP Service Pack 2 and has remained in Windows ever since. Essentially, DEP checks applications that are loaded in memory and identifies pages in memory that are explicitly marked as executable. If a piece of code attempts to run from a place within memory that is not explicitly designated as application space, Windows will disable the code from running on systems with compatible CPUs. (All modern CPUs from 2005 onward support this feature.) DEP is always enabled on 64-bit versions of Windows and for 64-bit applications themselves, so there's nothing to configure and no added benefit from EMET. But 32-bit applications running on either 32-bit or 64-bit versions of Windows have the potential to misbehave; DEP combined with other protections included in EMET can help prevent that nefarious behavior.

Address space layout randomization, or ASLR, a technique primarily designed to prevent the tried-but-true buffer overflow attack. ASLR basically scrambles up the locations of an application's base executable, the stack, heap and associated application libraries, across all of the address space available to the operating system. The goal of ASLR -- and this has proven to be a valuable protection in production -- is that if an exploit is actually loaded into memory, a cracker cannot access it by simply overflowing from one buffer and jumping into the next space. The attacker basically has to guess where the vulnerable code is living in memory, and that location is different each time the application is loaded. In addition, the application usually is not written to handle the guessing and will crash, further thwarting the attacker's exploit.

Structured exception handler overwrite protection, or SEHOP, which defends against exploits that overwrite a return address on a thread's stack and point to bogus code that does bad things. This happens, among other times, with buffer overflows. The software's exception handling will perform some functions that can let an attacker point the exception dispatcher to an address that will run malware. SEHOP makes sure the list of exception handlers is valid before an application can call them. SEHOP works with the aforementioned ASLR technology to basically prevent structured exception handling overwrites. (This is a pretty detailed developer-oriented technology, and I have tried to simplify it here but still explain the overall attack and what is done to defend against it. For a great technical explanation of SEHOP if you have the chops, check out this Technet post.)

Certificate trust. Sometimes called "pinning," certificate trust is new to this EMET version. Basically, EMET's certificate trust lets you create rules that specify the certificates and root certificate authorities that your systems should trust. By doing this, you can prevent funny business with certificates from man-in-the-middle attacks that use untrusted certificates to impersonate legitimate services, from illegitimate certificates issued improperly by trusted certification authorities that have experienced a breach or from a misexecuted protocol. For example, a fake antivirus program in circulation uses at least a dozen stolen digital code-signing certificates, indicating cybercriminals are increasingly breaching the networks of software developers. More recently, Google has blocked several digital certificates issued in India that could have been used to make bogus websites appear to be run by the Web giant. EMET's certificate pinning feature lets you take matters more fully into your own hands and decide specifically what certificates and which issuers you trust. Unfortunately, it is only useful if you primarily use Internet Explorer, as you cannot pin certificates from sites in Firefox, Google Chrome or any other Internet browser.

Attack surface reduction, or ASR, helps to prevent outdated or vulnerable plug-ins or other subcomponents of applications from being loaded, depending on whether an internal resource or an external resource is being requested. For those of us who despise the Java runtime environment (JRE) browser plug-ins and are perpetually three versions behind the current release because of a dependency on internal trusted software, ASR provides an opportunity to secure the plug-in from external vulnerabilities without breaking compatibility with our internal applications that depend upon a certain outdated release of the JRE.

Finally, export address table filtering plus, or EAF+, guards against a couple of new attack vectors that read around memory and modules stored in memory, including checking the integrity of stack registers and stack limits as well as preventing memory reads in certain situations. These mitigations help prevent attack surfing, or return-oriented programming, where tools try to surf around and discover vulnerabilities and then immediately attempt to execute code when they find a tender area of the system.

One happy family

As it happens, the weaknesses in each of these technologies offset one another -- where DEP is weak, ASLR is not, and so on. DEP acts as a kind of front door on attacks, making it harder to get them to execute, and ASLR backstops it by making a scrambled mess (from the point of view of the exploiter) out of the memory space a vulnerable application uses so that attackers have a harder time carrying out their malfeasance.

For its part, SEHOP works with ASLR to prevent random code from executing in specific address spaces the attacker wants. (Certificate pinning is a new feature not really related to the other technologies, but it still offers a security-posture improvement over plain-vanilla Windows.) EAF+ is an improvement on techniques that have been in previous versions of EMET for a long time, but Microsoft decided in version 5.0 to break it out and call it a separate mitigation strategy all on its own.

EMET 5.0 enables a pre-configured wrapper of protection for some default applications with known deficiencies and vulnerabilities, like Adobe Acrobat and the Java runtime, as well as common Microsoft applications like Office and Internet Explorer. This preconfigured protection is optional and you can configure custom protection on your own if you like, but the new defaults are a quick way to deploy some defenses sooner rather than later while you ramp up your custom deployment of the tool.

EMET is good if you use IE most of the time and use Firefox or other browsers sometimes. It's much better if you use IE all the time, but we try not to let the perfect be the enemy of the good -- EMET is still useful even if you use other browsers simply because it does protect some of the time.

Setting up EMET

You can download the latest version from the Microsoft website. Once you have downloaded the tool and run the simple MSI installation, just like any other Windows application, load the program. You will see a window much like the screenshot below.

EMET

The main screen from EMET.

In the System Status area, you can see whether the overall protections of DEP, ASLR, SEHOP and certificate trusts are enabled and active -- or not.

You can see at the top of the window the Quick Profile Name area, and a dropdown list where you can choose from various profiles that are already set up. Since you are just starting out, go ahead and choose the Maximum Security Settings profile so you can get a sense of the defenses. Once you select this, you will be prompted for a reboot; do not do that yet.

Instead, open a command prompt with administrative privileges and activate the default profiles.

From the command prompt, type:

cd "C:\Program Files (x86)\EMET 5.0"

Type the following command:

EMET_Conf.exe -- import "Deployment\Protection Profiles\Recommended Software.xml"

You will see confirmation messages like the following:

  • EMET is importing configuration, please wait...
  • Processed 86 entries
  • The changes you have made may require restarting one or more applications

That is your signal the profiles are installed and are working.

Now you need to tell EMET what applications you typically use. You do this through the EMET graphical user interface. Keep in mind, though, that since we just imported some default profiles through the command line, there will already be some existing entries in the interface.

To continue setting up and adding applications:

  1. Open the EMET GUI from the Start menu.
  2. In the ribbon, within the Configuration section, click Apps.
  3. The Application Configuration screen appears. In the ribbon, within the Add/Remove section, click Add Application.
  4. A standard browse box appears. Browse to the location of the program you want to add, and then click Open.
  5. The application will be added to the list on the Application Configuration screen. Each of the columns represents the defense technology and protection that should be applied to that particular executable: DEP, SEHOP and so on. Start out with all of the protections enabled when you add executables.
  6. Launch the program. You may need to restart your computer first if this is the initial load of EMET on that particular system.

Fine-tuning EMET

Since EMET acts as a shell around an application, said application's creator might not have anticipated some of the methods EMET uses. This means that you will likely run into some compatibility issues as you start rolling out EMET across your organization. Some observations:

Begin with Internet-facing applications. These applications are the ones most likely to contain exploits and those most likely to cause damage by spreading. Also, your users probably spend a lot of time in these applications. You will get the most protection bang for your buck here and, as a bonus, you can weed out terribly programmed Internet apps. Conversely, your custom line- of-business applications and other kinds of software you wrote for your business in-house are unlikely to be exploited. Little value would be derived from trying to make them work with EMET if they don't by default, so I would not advise wasting your time.

Understand ahead of time which applications are not likely to work well with EMET. Google Chrome is one that comes to mind immediately -- I have had little success in running EMET with Chrome unless the EAF+ defense is disabled. (EAF is the fifth column from the left in the Application Configuration section of the EMET GUI.) Skype, which I used to use on a daily basis, is another application that needs EAF turned off. But essentially, as everyone uses a different set of programs with different risk profiles, you will need to play around and test to figure out exactly which security postures work for your organization. Start by disabling different threat protectors within the tool for programs that are acting wonky; only disable EMET as a whole for that particular application as a last resort.

Deploy EMET and manage it using Group Policy. Look inside the EMET folder after it is installed, find the EMET.ADMX and EMET.ADML files, and copy them into the \Windows\PolicyDefinitions and \Windows\PolicyDefinitions\en-US folders on a domain-joined system. (But do NOT place these folders on a domain controller.) This copying will add settings to control the EMET tool to the Group Policy central store, so all you have to do is roll out the Microsoft installer, or MSI, file to your workstations and let Group Policy handle the configuration for you.

The last word

The Microsoft Enhanced Mitigation Experience Toolkit is a complex but useful tool to protect the integrity of your desktop and laptop machines -- in other words, computers traditionally used by employees. I recommend it in that context.

It has the potential to cause more trouble than its protection is worth in server contexts and on computers where IT pros and power users who are less likely to download and activate malware are the primary users, so proceed with caution in those scenarios. But overall EMET provides an effective additional layer of defense against potentially enterprise-crippling malware. You should evaluate it today.

Copyright © 2014 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon