November 11, 2014
EMET - The Ultimate Installation and Deployment Guide
Written by
David Kennedy
Penetration Testing
Security Testing & Analysis
The Enhanced Mitigation Experience Toolkit (EMET) is a free tool from Microsoft that incorporates advanced protection from attackers. The concept allows added protection from methods that hackers use to compromise systems through exploitation. If you are new to this, and aren't super tech savvy and are looking to install EMET for your home or personal use (don't worry! it's easy!!!), skim down to the "Installing EMET Step-by-Step" tutorial located just a little bit down in this article.
Otherwise, keep reading on!
Common protection mechanisms such as Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), and Safe Structured Exception Handler (SafeSEH) are protections built inside of Microsoft's newer operating systems. These protections provide a base level of security against known exploit methods. Hackers have gradually increased the sophistication of exploit development and have found ways of circumventing a large portion of these mitigation techniques.
EMET works by injecting an EMET.dll into running executables to provide memory level protections and mitigations against common exploit techniques. Nothing is perfect - several individuals have demonstrated how to circumvent EMET however, it does become much more difficult and has to be built into the exploit. EMET 5.1 was released yesterday (November 10, 2014) by Microsoft which includes their latest iteration of EMET. The folks over at Microsoft continue to move the product forward by including fixes and enhancements each time making it both more compatible with several different products as well as making it more difficult to circumvent and bypass.
EMET 5.1 includes a number of fixes and enhancements which include:
• Several application compatibility issues with Internet Explorer, Adobe Reader, Adobe Flash, and Mozilla Firefox and some of the EMET mitigations have been solved.
• Certain mitigations have been improved and hardened to make them more resilient to attacks and bypasses.
• Added “Local Telemetry” feature that allows to locally save memory dumps when a mitigation is triggered.
For individuals new to EMET, the way it works is you first need to deploy EMET, baseline applications and create a template of what types of applications you want to cover within EMET. The big misconception for large organizations is that by deploying EMET, it will break everything. The truth of the matter is that EMET only protects what is specified, tested, and configured within your configuration profile (xml). You actually have to specify what applications you want to protect under EMET (there are common templates that include basic applications). TrustedSec has done a number of large-scale implementations for Enterprise customers with tens of thousands of assets - as long as the deployment is appropriately tested, EMET is relatively trivial and easy to deploy.
Installing EMET Step-by-Step
First head over to the Microsoft EMET page to download the latest version of EMET. Currently this is version 5.1. Download EMET here. Next, select download.Custom Configurations for EMET
For Enterprise users, and tech savvy folks, you will want to incorporate additional applications for added protection. This is highly recommended and a necessity for enterprise deployments. In the same window as the prior steps, if you look at the lower bottom section, this is the current list of all of the protected applications currently under EMET. Since we haven't made any changes, you can see these are the default applications protected under EMET with the security profile selected. This would include Java, Internet Explorer, Adobe, Office products, and more. If creating a template for your organization as a standard configuration for enterprises, TrustedSec recommends creating two separate templates, one for servers and another for workstations/endpoints. To add a new application, you can simply select "Add Application" and point EMET to an executable you want protected. The way TrustedSec likes to break up protection mechanisms are as follows: 1. Client Side Attacks - applications that can be used against a workstation or server that can be leveraged for remote code execution. These are typically third party applications that are installed that accept some form of input, whether its a file or commands. For example, Foxit Software a PDF reader commonly used as a replacement for Adobe. You would point EMET to the Foxit executable and it would be successfully added. If you test this out, you should notice that when you launch an application added here, it will show up under the "Running EMET" section as green (only when the application is running). 2. Server / Service Attacks - these are categorized as services, ports, and protocols that could be subjective to attack. Here's where it gets a little bit on the cautious side. Microsoft's stance has been to protect mostly client-side attacks from exploitation. However, common services are also frequently attacked. EMET can be deployed on services in order to add additional protection. A common deployment scenario that we typically see is placing EMET over IIS, SMTP (transport), RDP, SMB, RPC, and other commonly attacked services. Please note that this isn't a recommended practice from Microsoft however through our experience, we haven't seen any compatibility issues by placing EMET on these services. Think like an attacker when deploying EMET - we will commonly go after endpoints, and exposed services. Having EMET deployed on these services greatly reduces the ability for zero-day attack angles as well as a temporary mitigation against missing patches. This can be deployed both on workstations/endpoints and servers. We've also done implementations around DameWare, VNC, and other remote control software without issue. Once you've determined what applications to add, there's another section that makes it super simple to configure common services that are already running. Exit out of the apps menu and go back to the original EMET home screen. Under the section "Running Processes" is a list of all processes running on your current system. Skim through the processes and identify what services you want to protect, for example below, we'll cover the IIS (inetinfo) service (executable) under EMET. Simply right click the executable process, and select "Configure Process". This will automatically add EMET to the applications list for protection. Now that this process is now configured, if we do an iisreset from the command line:Enterprise Deployment Strategies
For enterprise users, there are two main deployment methods that work successfully for both small and large organizations. The first is handling configuration changes through your patch management software such as SCCM. You can make the changes to the template, and push the xml to each system through SCCM when changes are needed for compatibility or enhancements. Remember from prior steps, you want to keep two separate configurations, one for servers and others for workstations/endpoints (makes things easier when having to deploy and keep track of changes). You can also manage EMET through group policy however the group policy settings are limited in nature and do not have the same granularity as utilizing the xml deployment methods. A good article on group policy deployment can be found here http://windowsitpro.com/security/control-emet-group-policy. One major catch is also creating a scheduled task to perform a EMET_Conf -refresh upon logon to ensure the latest policies are pushed when a new user logs into their machine. The second method, which is most preferred is by automatically refreshing EMET policies via a scheduled task and a remote file share. In this case, you would configure EMET completely, test it with a pristine XML then export it. You can do this either through the GUI or when inside the EMET directory, you can just run: EMET_Conf.exe --export EMET_Endpoint_Profile.xml The template will now be exported appropriately. Next create a GPO and name it something like "EMET Config Deployment for Endpoints". You should also create a second one for server configurations and follow the same steps for exporting the profile and xml for your server configurations. Select properties on the new GPO and grab the Unique GUID and document the number (looks something like {343423423-32423432-324324-324-32432}). Next, go to the sysvol share on a domain controller and navigate to sysvol\domain\Policies\{new-gpo-guid}. Place the EMET_Endpoint_Profile.xml file under that new group policy object. Now that we have our profile here, whenever we need to make changes replace the xml file located in this location (either for endpoint or server or both). Note that the name must remain the same since we will be creating a scheduled task shortly that calls the specific file. Since this is a sysvol share, anyone that is apart of the domain users group will have access to this group policy object and file in order to import it eventually into EMET. Next we need to create a group policy that runs a scheduled task. There's a few different options you have, the first is by creating a scheduled task upon logon (the most common deployment) or the other option is having it run at certain intervals (say every hour). Under the new group policy you created (in our example Config Deployment for Endpoints" navigate to the computer configuration, preferences, control panel settings, scheduled tasks. Select "New Scheduled Task".