Let's talk about EMET. Enhanced Mitigation Experience Toolkit. Version 4.1 is the latest update, out just last month. It's free. You can find it here. When you download it, make sure you also download the user guide PDF that comes with it, as it's actually pretty good quality documentation for a free tool.
The thing about EMET, is that it is not antivirus. It's not signature-based, the way that traditional AV is. EMET is behavior based. It monitors the system in real time and watches all running processes for signs of malicious behavior and attempts to prevent them. It also applies a set of overall system-wide hardening policies that make many types of exploits more difficult or impossible to pull off. The upshot of this approach is that EMET can theoretically thwart 0-days and other malware/exploits that antivirus is oblivious to. It also allows us to protect legacy applications that may not have been originally written with today's security features in mind.
The world of computer security is all about measure and countermeasure. The attackers come up with a new attack, then the defenders devise a defense against it, then the attackers come up with a way to get around that defense, ad nauseum, forever. But anything you can do to raise the bar for the attackers - to make their jobs harder - should be done.
Here's what the EMET application and system tray icon look like once it's installed:
From that screenshot, you get an idea of some of the malicious behavior that EMET is trying to guard against. You can turn on mandatory DEP for all processes, even ones that weren't compiled for it. Data Execution Prevention has been around for a long time, and is basically a mechanism to prevent the execution of code that resides in areas of memory marked as non-executable. (I.e. where only data, not code, should be.) With DEP on, heaps and stacks will be marked as non-executable and attempts to run code from those areas in memory will fail. Most CPUs these days have the technology baked right into the hardware, so there's no subverting it. (Knock on wood.)
You can turn on mandatory ASLR for all processes on the system, again, even for processes that were not compiled with it. Address Space Layout Randomization is a technique whereby a process loads modules into "random" memory addresses, whereas in the days before ASLR processes always loaded modules into the same, predictable memory locations. Imagine what an advantage it would be for an attacker to always know exactly where to find modules loaded in any process on any machine.
Then you have your heapspray mitigation. A "heap spray" is an attack technique where the attacker places copies of malicious code in as many locations within the heap as possible, increasing the odds of success that it will be executed once the instruction pointer is manipulated. This is a technique that attackers came up with to aid them against ASLR, since they could no longer rely on predictable memory addresses. By allocating some commonly-used memory pages within processes ahead of time, we can keep the heap sprayer's odds of success low.
Those are only a few of the mitigations that EMET is capable of. Read that user guide that I mentioned before for much more info.
Oh, and one last thing: Is it possible that EMET could cause certain applications to malfunction? Absolutely! So always test thoroughly before deploying to production. And just like with enterprise-grade antivirus software, EMET also requires a good bit of configuring until you come up with a good policy that suits your environment and gives you the best mix of protection versus application compatibility.
Let's get into how EMET can be deployed across an enterprise and configured via Group Policy. Once you've installed it on one computer, you will notice a Deployment folder in with the program files. In the Deployment folder you will find the Group Policy template files you need to configure EMET across your enterprise via GPO. First, create your Group Policy Central Store if you haven't already:
Copy the EMET.ADMX file into the PolicyDefinitions folder, and EMET.ADML file into the EN-US subfolder. If all goes well, you will notice a new Administrative Template now when you go to create a new GPO:
Now you may notice that while I do have the EMET administrative template... all my other admin templates have disappeared! That's because I forgot to copy all of the other admin templates from one of the domain controllers into Sysvol before I took the screen shot. So don't forget to copy over all the other *.admx and *.adml files from one of your DCs before continuing.
Now you can control how EMET is configured in a centralized, consistent, enforceable way on all the computers in your organization.
The next part is deploying the software. The EMET user guide describes using System Center Configuration Manager to deploy the software, and while I agree that SCCM is boss when it comes to deploying software, I don't have it installed here in my lab, so I'm going to just do it via GPO as well. In fact, I'll do it in the same EMET GPO that defines the application settings too.
Copy the installer to a network share that can be accessed by all the domain members that you intend to deploy the software to:
Then create a new GPO with a software package to deploy that MSI from the network location. Make sure the software is assigned to the computer, not the user. And lastly, you'll likely rip less of your hair out if you turn off asynchronous policy processing like so:
+ Administrative Templates
+ Always wait for the network at computer startup and logon: Enabled
And software deployment across an entire organization, that simple. Luckily I didn't even have to apply a transform to that MSI, which is good, because that is something I didn't feel like doing this evening.
Until next time, stay safe, and if you still want to hear more about EMET, watch this cool talk from Neil Sikka about it from Defcon 21!