Protecting your Windows PC with Microsoft EMET 3.0
JUNE/18/2013 UPDATE: Microsoft released EMET 4.0 on June 17 2013. You may wish to download that version. Please note that the EMET interface has changed compared to version 3.0 for which this article was written, and new features such as certificate pinning, new mitigations, and early warning program have been added. Note that EMET 4.0 requires .NET Framework 4.
This is a user guide for installing and configuring Microsoft's free Enhanced Mitigation Experience Toolkit (EMET) version 3.0. Using EMET is an extremely easy way to add additional protection mechanisms to a Windows system in order to make successful exploitations of commonly targeted applications (ex: Adobe Reader, Flash, Java, Internet Explorer, Firefox, MS Office suite, etc.) more difficult. Likewise, it can also be used to protect internet-facing services from 0-day vulnerabilities, or to harden legacy applications that are no longer supported by their vendors. EMET is an officially-supported Microsoft product (visit the Microsoft EMET forums for assistance).
For those in a hurry who do not wish to read through the entire guide, the overall process to using EMET is quite simple: Install EMET, then launch either the GUI (Start | Programs | Enhanced Mitigation Experience Toolkit | EMET 3.0) or the command-line (C:\Program Files\EMET\EMET_Conf.exe) and define which process executables you wish to have EMET protect. Once done, restart those applications for the changes to take effect and test them to confirm that they still work properly. And with EMET 3.0 there is an even faster way of quickly protecting a system without having to spend time meddling around: You can either import one of the bundled protection profiles through the GUI (Configure Apps | File | Import | All.xml) or enter the following command from where EMET is installed. Both will produce the same results by adding security mitigations to common applications:
EMET_Conf.exe --import "deployment\protection profiles\all.xml"
The steps above is the simplest, easiest hassle-free way of increasing the security of a Windows system beyond what antivirus, firewall, and patch management can take it. For an eye-opening explanation on why this is important, please read our article that demonstrates how your computer remains at risk of being compromised from an endless barrage of actively exploited 0-day vulnerabilities.
EMET can be used either at home or in an enterprise environment. As always, and as recommended by Microsoft, you should thoroughly test EMET in all target use scenarios before rolling it out to production.
Download and install
Begin by downloading EMET and install it using an account that has administrator privileges. The installer is digitally signed by Microsoft. Below for reference are the hashes for the 3.0 version published on 5/15/2012:MD5: bd146a1e1256ea70442abf7ce92590b1
EMET can be used on both 32 or 64-bit systems. The installer (EMET Setup.msi) is the same for both architectures. On 64-bit systems EMET will be installed in the 32-bit directory C:\Program Files (x86)\, but this does not mean it cannot be used for protecting 64-bit applications.
Note: If you are upgrading EMET from the previous 2.1 version, the installer will prompt you to close any window for applications currently protected by EMET that are in use during the upgrade. Although your previous EMET configuration will be automatically imported, it is recommended to confirm after rebooting your system that your previously protected applications still show the "Running EMET" checkmark within the running processes table of the EMET GUI. If this checkmark is missing, try removing then adding back those application processes within EMET.
The installation is very straightforward with the only setting that you may wish to change being whether or not to install EMET for yourself or for anyone using the computer (all this setting does is define which user accounts will see EMET in the Start menu). Once installed, launch EMET by clicking on Start | Programs | Enhanced Mitigation Experience Toolkit | EMET 3.0
Depending on which Windows version you are using you will immediately see differences in the system status. Below is the EMET GUI after installation on Windows XP SP3:
As you can see, Structured Exception Handler Overwrite Protection (SEHOP) and Address Space Layout Randomization (ASLR) show as unavailable, and these security mechanisms will remain greyed out on Windows XP (and Windows 2003) systems. This does not imply that EMET provides no benefits for systems running those versions of Windows, as will be seen later in this guide. But you can compare the immediate differences between Windows XP and Windows 7 (64-bit):
The following table taken from the Microsoft EMET 3.0 User Guide (located within C:\Program Files\EMET\) summarizes the differences in mitigation options for each Windows system:
Note that not all systems, including virtual machines, support DEP, but the option will remain available even if EMET is being run on a machine that does not support it.
With this aside, we continue to configuring EMET.
There are two main categories of settings that you can configure in EMET: System and Apps. Each category can be set by clicking on the respective button at the right of the main EMET window. Clicking on Configure System brings you to this screen:
The System Configuration section is to configure system-wide (that is, without having to explicitly define which processes to protect) specific mitigations such as DEP, SEHOP and ASLR. On Windows 7, setting the System Configuration to Maximum Security will set DEP to Always On, SEHOP to Application Opt Out, and ASLR to Application Opt In. However the recommended setting for stability is to have these set to Application Opt In. Note that this section has the greatest potential in EMET for causing system instability, as for example setting DEP to Always On could cause any number of applications on your system that are not compatible with DEP to crash. The Application Configuration section which is discussed next allows you to enable mitigations such as DEP per application instead of system wide (which is better from a stability perspective but arguably less secure). In fact, Microsoft has hidden an unsafe option that allows you to set ASLR to Always On, as this setting is known to cause system instability. The EMET User Guide shows which registry key to modify if you wish to override this hidden setting.
If you are using EMET for the first time, you should probably not change the default System Configuration settings and instead make your changes in the Application Configuration section, which is what we discuss next.
Back on the previous screen, click on Configure Apps in order to add protection for specific applications. This is where you will be spending most of your time in EMET.
The list above has already been populated with the entries but by default it will be blank. Click on the Add button in order to drill down and select specific executables to be protected, specifying the path where they are installed. By default all application security mechanisms will be enabled when you add an application, and it is recommended to leave this as-is unless you discover that a specific application does not work properly while running EMET, in which case you could either unselect all of the mechanisms and systematically add them back in one at a time in order to identify the one that is incompatible, or you could visit the EMET forum to search for or report the issue, or ultimately you would remove that specific application from EMET altogether.
New with EMET 3.0 is the inclusion of three default Protection Profiles XML files which are located in the EMET installation directory under Deployment\Protection Profiles\ (the screen capture above shows the configuration included in the profile All.xml. The multiple entries that you can see with the same executable name are for different versions installed in different directories). The profiles can be imported via the EMET GUI (In EMET click on Configure Apps | File | Import) or command line (emet_conf --import <filename.xml>) in order to quickly enable mitigations for common applications.
Many of you likely have an idea of which applications would benefit from having additional protections enabled. Below are some suggestions for Windows desktops:* Any/all web browsers installed on your computer (Internet Explorer, Firefox, Chrome, Opera)
* Entire MS Office suite (Access, Excel, Outlook, PowerPoint, Word)
* Sun (now Oracle) Java
* Any media player (Windows Media Player, VLC, iTunes, RealPlayer, QuickTime, Winamp)
* Any software that waits and listens for a network connection
* Any application that can be automatically invoked by browsing the internet
* Any Adobe product that you see frequently listed within Adobe's Security bulletins and advisories.
And so on. You may wish to make an inventory of which applications you have installed on your computer, and visit exploit-db.com in order to see if those applications are being exploited, and if yes how frequently and how severe. For example, does the exploit result "only" in a denial of service, or in execution of arbitrary code? Although we realize that selecting specific processes to be protected while leaving the rest unprotected has similarities to the "Default Permit" that Marcus Ranum discussed in his security paper Six Dumbest Ideas in Computer Security since this effectively places you "in an endless arms-race with the hackers", the purpose here is taking a reasonable approach to increasing the security of a Windows system by protecting vulnerable applications, especially those that are highly targeted. However it is worth mentioning that nothing prevents you from adding virtually ALL processes to EMET. Note however that the more you add, the more you'll need to test, and some applications are observed to not work properly through EMET, or with trial and error are discovered to only work when a specific EMET application configuration protection such as EAF is disabled.
Those in enterprise environments can get an excellent source of this data by leveraging any vulnerability assessment or auditing tool that they might have, and use this to get an inventory of the software vulnerabilities that exist and the applications that are worth protecting with EMET.
Once you are done adding applications, click on OK and EMET will likely tell you that you need to restart one or more applications. As a quick test close and open one of your protected applications, and click on the refresh button within EMET to see whether a green checkmark appears within the Running EMET column. If no green checkmarks appear, there may be something wrong. If it does work (and it should), it will look something like this:
If you use Windows Sysinternals Process Explorer and view the DLL pane of a process that you have added to EMET, you will notice a new DLL file emet.dll with the description "EMET Shim" for that process (to enable the lower pane DLL view select View | Lower Pane View | DLLs).
Within Process Explorer you will also notice that if you right-click on an EMET-protected process and select Properties | Environment, there will be a variable present called EMET_Settings that lists the mitigations you have enabled for that process.
After you have finished adding processes to EMET, you will want to test your system to confirm that everything still works. At minimum reboot your computer and launch each program that you have added to confirm that they still open properly. Use each application as you normally would and watch for error messages, unresponsiveness, and sudden application exit.
New in EMET 3.0 is the EMET Notifier which resides in the system tray and notifies the user through a pop-up whenever EMET blocks something. If ever this occurs, an event will also be written in the Windows event log. Those who do not wish to have this functionality can disable it through a registry key by creating a new DWORD called NotifierLogLevel under HKLM\SOFTWARE\Microsoft\EMET and setting it to 0.
Using EMET through the command-line
EMET can also be configured from the Windows command line, in order to add, remove, or list applications protected by EMET. Like for the GUI, these commands need to be executed through an account that has administrator privileges (note that in Windows versions past XP and 2003 you will need to run the command line as administrator otherwise you will get the error "Fatal error: Admin privileges are required". To do so click on start, in the search programs and files box type "cmd" (without quotes), then right-click on cmd.exe, select "Run as administrator", and click yes at the UAC prompt):
C:\Program Files\EMET>EMET_Conf.exe Usage: EMET_Conf.exe --list | --set [--force] path\program.exe [(+|-)AppMitigation ...] | --delete path\program.exe | --delete_all | --export file.xml | --import file.xml | --system [--force] SysMitigation=State [SysMitigation=State ...] AppMitigations are: DEP, SEHOP, NullPage, HeapSpray, EAF, MandatoryASLR, BottomUpASLR SysMitigations are: DEP, SEHOP, ASLR Possible states are: Disabled, ApplicationOptIn, ApplicationOptOut, AlwaysOn
Below are some examples of how you would use the command line to protect specific applications.Protect notepad.exe with all application-specific mitigations (the default):
C:\Program Files\EMET>EMET_Conf.exe --set "c:\WINDOWS\system32\notepad.exe"Protect calc.exe with all application-specific mitigations excluding EAF and NullPage:
C:\Program Files\EMET>EMET_Conf.exe --set "c:\WINDOWS\system32\calc.exe" -EAF -NullPageAdd EAF mitigation to the already-protected calc.exe from above which currently has EAF and NullPage excluded:
C:\Program Files\EMET>EMET_Conf.exe --set "c:\WINDOWS\system32\calc.exe" +EAF
For those in enterprise environments, Microsoft has included step-by-step instructions for deploying EMET through SCCM (http://blogs.technet.com/b/configmgrteam/archive/2012/05/15/deploying-and-configuring-the-enhanced-mitigation-experience-toolkit.aspx) as well as through group policy (http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx). Instructions for doing this can also be found in the EMET User Guide.
Recommended applications to add
With EMET 3.0 you can specify either the full path name to the application, or Windows environment variables or wildcards such as * and ? (the latter is new to EMET 3.0). The only restriction is that the wildcard needs to be in the path, not in the filename, so entries such as "*fox.exe" or "C:\Program Files\Mozilla Firefox\*.exe" would not be valid. For example you could specify any of the following to protect firefox.exe:
EMET_conf.exe --set "C:\Program Files\Mozilla Firefox\firefox.exe" EMET_conf.exe --set "*\Mozilla Firefox\firefox.exe" EMET_conf.exe --set "*\firefox.exe" EMET_conf.exe --set "%ProgramFiles%\Mozilla Firefox\firefox.exe" EMET_conf.exe --set "%ProgramFiles%\*\firefox.exe"
In addition, the application does not already need to be installed in order for EMET to accept the parameter (with previous versions of EMET you had to specify the parameter --force to do this). So in an enterprise environment you could define entries for applications that are not currently installed on a system but could be at a future point in time. So when you deploy EMET you could push it out with a large list of applications ahead of time so that you don't need to reconfigure EMET every time you install new software. Also consider using wildcards such as "*\Mozilla Firefox\firefox.exe" instead of "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" if you wish to reduce the duplication of entries or configurations to accommodate mixed 32/64-bit environments.
If ever EMET crashes while you are adding programs through the command line (you get the following error message: "Unhandled Exception: MitigationInterface.ExeNotFoundException") it could be because you are specifying a path without wildcards for an executable that does not exist. For example in the case that the path "c:\example directory\example.exe" does not exist on a system, the following command will generate an error (emet_conf --set "c:\example directory\example.exe") whereas the following won't (emet_conf --set "*\example directory\example.exe"). If however you were to use the --import parameter and import a XML file instead of using --set, you will not experience this problem. It is possible that this is a bug that will be fixed in a future version.
In our previous article on EMET 2.1 we used to keep a list of which applications we recommended our readers to add. However Microsoft has effectively done this work for us in their release of EMET 3.0. Pages 35 to 39 of the EMET User Guide as well as the contents of the All.xml protection profile are an excellent start as to which programs you should add. On top of those you may wish to add (and test) the following additional executables which are not included:
Windows Print Spooler1 %systemroot%\System32\spoolsv.exe Windows LSASS1 %systemroot%\System32\lsass.exe MS Wordpad *\Windows NT\Accessories\wordpad.exe LibreOffice *\LibreOffice 3.5\program\soffice.exe LibreOffice Base *\LibreOffice 3.5\program\sbase.exe LibreOffice Calc *\LibreOffice 3.5\program\scalc.exe LibreOffice Draw *\LibreOffice 3.5\program\sdraw.exe LibreOffice Impress *\LibreOffice 3.5\program\simpress.exe LibreOffice Math *\LibreOffice 3.5\program\smath.exe LibreOffice Writer(Web) *\LibreOffice 3.5\program\sweb.exe LibreOffice Writer *\LibreOffice 3.5\program\swriter.exe OpenOffice.org *\OpenOffice.org 3\program\soffice.exe OpenOffice.org Base *\OpenOffice.org 3\program\sbase.exe OpenOffice.org Calc *\OpenOffice.org 3\program\scalc.exe OpenOffice.org Draw *\OpenOffice.org 3\program\sdraw.exe OpenOffice.org Impress *\OpenOffice.org 3\program\simpress.exe OpenOffice.org Math *\OpenOffice.org 3\program\smath.exe OpenOffice.org Writer *\OpenOffice.org 3\program\swriter.exe Gimp 2.8 *\GIMP 2\bin\gimp-2.8.exe WebEx WRF Player2 *\WebEx\*\AtAuthor.exe WebEx ARF Player2 *\WebEx\*\nbrplay.exe Bonjour Service *\Bonjour\mDNSResponder.exe 1 Test these thoroughly before deploying in an enterprise environment. 2 Double wildcards are recommended as these install in various directories
Note that a common mistake that people would make with EMET was to add Adobe Flash executables such as FlashUtil10k_ActiveX.exe and FlashUtil10k_Plugin.exe. This does not achieve anything. Please see our previous article on EMET 2.1 for more details.
Does EMET make a difference?
The answer to this question spans its own separate article. But to quickly give a few examples, EMET has been demonstrated by Microsoft to successfully block the 0-day vulnerability used in the Operation Aurora attacks against Google (4:30 mark in the following video), and F-Secure has shown it to block the 0-day Adobe Flash exploit that was used against RSA (page 16 of the presentation Making Life Difficult for Malware). The Microsoft TechNet blogs also show a few examples of how EMET is used to block real-life attacks. In his critical analysis of Sophos Antivirus, Tavis Ormandy, a security researcher employed by Google severely criticised the Buffer Overflow Protection component of Sophos Antivirus, then stated "Genuine runtime exploit mitigations exist for older Windows systems. The author recommends you evaluate WehnTrust and EMET" (page 7 of his paper). Adobe in their APSA10-02 security advisory for Adobe Reader and Acrobat has even recommended using EMET as a mitigation to protect against what was then currently unpatched vulnerabilities in their Adobe Reader and Acrobat software.
In Enterprise Environments there can understandably be some concern or hesitation in deploying EMET. The IT department might not feel comfortable with deploying software that has the ability to affect mission critical software such as MS Office, Internet Explorer, Adobe Reader, etc. In all honesty the best thing to do is deploy it to a test group and see if it "breaks" anything, and if it doesn't begin rolling it out across your organization. If your concern is "Well, my applications work fine with EMET today, but what about when there's a new version or patch for that application in the future -- isn't there the potential that EMET might break it then?" The answer to that is "yes" but the solution is simple: You should already be testing our your patches and upgrades in a development environment before rolling them out anyway, so it is simply a question of making sure that your development environment has EMET installed. As a precaution you should prepare and test a process that allows you to reconfigure EMET post-deployment in the event that you ever do need to remove a specific application from being protected by EMET. But what you should be equally concerned with if not more so is the very real possibility of criminal organizations, industrial spies, hacktivists, or in some cases even nation-states managing to infiltrate your network by sending an employee an email with a file attachment or link that delivers an exploit against a zero day or recently patched vulnerability. If somebody were to send a malicious PDF file disguised as a resume to your HR department, or a sales order to your sales department, or something related to salary increases or performance bonuses to anybody within the organization, how likely do you think it is they would open it?
In addition there has recently been the emergence of an industry geared towards developing 0-day exploits that are sold to interested parties in which the vendor of the affected software is never notified of the vulnerability so that it can be fixed. Depending on the nature of the vulnerability, this can, and should, be defeated by using EMET.
Now EMET is by no means a magic bullet that can make a computer completely secure, however it does block many exploits and should be seen as a defense-in-depth strategy to be used in addition to standard security best practices, especially given its negligible performance impact (unlike antivirus), its minimal tuning and maintenance (unlike host/network intrusion prevention and firewall), its lack of obstructiveness to the user experience (unlike a least-privilege permission model) and its deployment simplicity (unlike reputational filtering and whitelisting). Microsoft probably best summarized the purpose and limitations of EMET in their FAQ for Microsoft Security Advisory (2458511) - Vulnerability in Internet Explorer Could Allow Remote Code Execution - in which they write: "[The] security mitigation technologies [of EMET] do not guarantee that vulnerabilities cannot be exploited, but work to make exploitation as difficult to accomplish as possible. In many instances, a fully functional exploit that can bypass EMET may never be developed.
If you are using BitLocker and modify the system setting for DEP, BitLocker will ask you for the recovery key when you reboot. BitLocker users who wish to modify the system settings for DEP should make sure to read the FAQ section of the EMET User Guide for information on how to address this issue.
If you decide that you no longer want EMET, you can easily uninstall it through Add/Remove programs. EMET is light-weight (the installer is 6.0 MB) and so uninstalls very easily.