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 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 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.
First head over to the Microsoft EMET page to download the latest version of EMET. Currently this is version 5.1.
Next, select download.
Then select the msi to download.
Run the MSI file, select next.
Use the default installation path – for added security against automated attacks, you can change this path directory for attackers that may look for the hardcoded EMET.dll. Note that most memory oriented attacks will simply identify if the EMET.dll is loaded, not actually check the path of EMET.
Select “I Agree” and hit next.
This is where the installation takes place, select next to begin the installation phase.
Select “Use Recommended Settings” – we will be changing this shortly.
Select Finish to complete the installation.
Once the installation is complete, you should notice an icon on the bottom right hand side that looks like a lock.
Double click the lock icon, and you will get the default interface for EMET 5.1.
A couple items for explanation, the lower half section of “Running Processes” is the applications that are currently protected by EMET. Notice that in this screenshot we have not configured anything to be protected by EMET. By default, EMET will protect common applications such as Java, Adobe, and Internet Explorer. It does not however protect anything you do not specify other than the common applications. Since we previously specified “Use Recommended Settings” it will select the default applications just mentioned (Java/Adobe/Internet Explorer). We will want to change this shortly. Note that a protected application would have a green check mark under “Running EMET” on the lower right hand side.
Since EMET works by injecting a DLL into the executables memory space, whenever we configure any new process to be protected by EMET, it will require us to close the application and restart it (or service). It does not require a full restart, just the services or applications themselves to be restarted.
In the “System Status” section of EMET, ensure that DEP is set to “Always On”, SEHOP to “Always On”, and ASLR to “Application Opt In”. The next is certificate trust pinning which checks certificate security. This setting can be troublesome when deployed to common workstations and endpoints due to the fact that the certificate management field in most of the Internet is extremely messed up. This will typically trigger alerts for the end user and cause confusion. For endpoints, TrustedSec recommends potentially disabling this feature.
On the top middle, there is a “Quick Profile Name:” field – we recommend configuring the settings to the “Maximum Security Settings” – while we will be doing some additional changes here shortly, the maximum security settings incorporate additional stringent security policies and protections.
Next, select the “Apps” button on the top middle left to open the application window:
On the top left section, ensure that “Deep Hooks”, “Anti Detours”, and “Banned Functions” are selected. These should all be highlighted as these are default configurations of EMET 5.x. Also ensure “Stop on exploit” is selected. The only time when you may want to deploy “Audit only” is when you are doing initial testing and are experiencing application crashes. EMET will notify you upon a time when it would traditionally block something from running vs. actually stopping it from running and you can fine tune EMET’s protections to not block a certain protection for normal application functionality.
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 onworkstations/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:
We should now see the application fully protected under “Running EMET” on the right hand side, indicated by a green check mark.
That’s it! You are now protected. Walk through each of the processes and applications that you want protected to create your baseline.
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 . 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”.
Next, select a name, in this case we use “EMET Update”, navigate to the EMET 5.1 program files directory and select the “EMET_Conf.exe” executable. For arguments use the –import flag with EMET which will import the xml file for us and select our domain controller to pull the group policy from. In this case we use the example of “serverdc1” and provide the path to our new policy we created in group policy and point to our xml that we recently copied over “EMET_Endpoint_Profile.xml”.
We can also specify when to run this xml, upon logon, daily, hourly, weekly, whatever your personal preferences are.
That’s it! Phew. You should now have a scheduled task and whenever you replace the xml file located in that group policy, it will automatically refresh to your user population without the need to deploy additional packages company wide through something like SCCM.
Client Operating Systems • Windows Vista Service Pack 2 • Windows 7 Service Pack 1 • Windows 8 • Windows 8.1
Server Operation Systems • Windows Server 2003 Service Pack 2 • Windows Server 2008 Service Pack 2 • Windows Server 2008 R2 Service Pack 1 • Windows Server 2012 • Windows Server 2012 R2
Wrapping things up – EMET is a powerful and free tool that needs to be seriously considered by both home deployment and enterprises. It is obtainable and easy if you understand how EMET works and how to deploy it within a large environment. TrustedSec has seen countless numbers of organizations moving towards EMET and as long as they are appropriately tested and planned out, the issues are minimal or non-existent. EMET 5.1 continues along the lines of a great product line from Microsoft and should be commended on the additional protection mechanisms that are introduced by having EMET in place.
This article was written by David Kennedy – CEO of TrustedSec