So first of all, why should you deploy Microsoft EMET? EMET stands for Enhanced Mitigation Experience Toolkit. By itself, that doesn't sound like much. What EMET actually is is a toolkit that mitigates different exploitation techniques and enables security features on your operating systems and applications. So what we're trying to do with Microsoft EMET is we're going to try to make it much harder for a bad actor, and you can see he's definitely evil because he's wearing a hat, exploiting a system. So on a system without EMET, he will be able to exploit a vulnerability really easily. And on a system with EMET, it's going to be much more complicated.
So Microsoft EMET has over 12 different mitigations. Some of them are real mitigations, such as enabling that execution prevention on applications that did not support it. Some other ones are simply ways to block well–known exploitation techniques. And there's also attack surface reduction mitigations that EMET includes.
Microsoft EMET does not cost anything if you already have Windows, so it's a really cost-effective way to reduce the number of compromised systems in your environment. And it is actually really configurable, and you can deploy it in a staggered manner to avoid any problems with compatibility of unstability. But the important thing to do when you're deploying EMET is you need to target some applications first. You can't do everything at once. So great applications to target first with Microsoft EMET are Microsoft Office, your browsers, and also the browser plugins that you're using. Microsoft already has templates for most of these applications that you can deploy to your workstations.
So when I said Microsoft EMET has more than twelve mitigations, that means you can enable or disable them for every application you are going to protect with EMET. This is typically done using group policies so you don't have to do it on every single system. And you can publish different policies with exceptions based on groups or the location of systems in your active directory.
So first, start by protecting these applications on your workstations. You can set EMET to simply observe on systems, or you can set EMET to block attacks. Maybe you want to set it in a mode where it won't prevent anything from being executed, and then you can look at what's happening before you push a configuration that will block activity.
Once EMET gets triggered, it's going to shut down the application where a mitigation was triggered. This generates information in your Windows security logs, which you can use for troubleshooting, but also to be notified of any potential attack going on. So if many of your users are receiving a link that tries to exploit a vulnerability in Internet Explorer, Internet Explorer will close, and EMET will log this information, allowing you to detect a potentially dangerous situation before the attacker can make a customized version of his exploit to attack your vulnerability.
Most exploits that are in the wild will not work against a computer that has Microsoft EMET protecting this specific application. That doesn't mean that it's impossible to exploit the vulnerability. Someone could always bypass EMET. And it's been done in the past. But most off-the-shelf, easy-to-obtain exploits will not be able to attack this system. This means that you can buy yourself some time while you try to patch these systems for the specific vulnerability that people are using.
Once you've deployed this on your workstations, you should look at servers. Servers can also be protected by EMET. And typically, servers are running fewer different processes on them. So look at your domain controllers, which are extremely sensitive systems that control authentication to all of your systems. By protecting them with EMET, the next time there is a vulnerability affecting a server that's running on it, you might be able to patch it before it gets exploited. And that doesn't cost you anything because Microsoft EMET is freely available.
Once you've used EMET to protect these really common applications and the system services, you can then use EMET specifically to protect any application that you cannot patch. So for example, legacy applications that you know you will be replacing soon and for which there is no support available. When you do this, Microsoft obviously cannot provide a template telling you what mitigation is safe to use or not on these applications. So it is important that you test it well. So you can start by enabling some of the mitigations, testing to see if the stability is effective or not and then enabling more of them. And in some cases, you'll see that a specific mitigation is causing an issue with an application, but you'll still be able to enable EMET with all the other mitigations.
The last thing you should look at with EMET is certificate pinning for Internet Explorer, which can be found in the attack surface reduction, which will allow you to specify what certificate should be expected for, let's say, your internet or your SharePoint servers, preventing any man-in-the-middle attack using a trusted but malicious certificate.
That's it for this week's Whiteboard Wednesday. We'll see you next week. Thank you.
