Update: 12th September 2017:
Versions 1703 and 1709 of Windows 10 will block the installation of EMET. This makes sense for version 1709 since it includes a replacement for EMET while 1703 (to the best of my knowledge does not).
Update: 11th July 2017:
As noted in a new blog post, an upcoming update to Windows 10 will contain some features of EMET. Further details are available in the above mentioned blog post.
Update: 13th December 2016:
Shortly after publishing this blog post, I received a response (apologies for not posting this update sooner) from the Microsoft EMET team to some questions that I had asked with regard to how to harden applications that do not incorporate security mitigations be default on Windows 10 once EMET has reached it’s end of support. These can be used with any applications, not just legacy applications.
They suggested using the Process Mitigation Options GPO which is described in the link provided by them below. This can be used to apply mitigations such as DEP, SEHOP, Mandatory/Force ASLR, and Bottom-up ASLR to a process without using EMET. They also mentioned this GPO should be receiving further usability improvements in the future.
While the above mitigations don’t provide the same level of protection that EMET offered, they offer an improvement over not using them. From their message there appears to be a possibility that further mitigations will be available in later updates to Windows 10.
I have provided the text of their message below.
Thank you for your support and for providing this helpful feedback! We will consider these suggestions as we develop our documentation and continue to evolve our security and mitigation features in future releases of Windows 10.
Today, the Process Mitigation Options GPO documented below can be used to configure certain in-box Windows 10 mitigations for particular processes.
These mitigations include DEP, SEHOP, Mandatory/Force ASLR, and Bottom-up ASLR. Though we’re aware that this GPO presents some UX challenges, we’re actively working to improve our mitigation management experience for future releases.
Once again shortly after publishing this post, I came across this blog post from the CERT/CC team of Carnegie-Mellon University. They recommend using EMET on Windows 10 after the end of support deadline in July 2018 to protect applications that do not incorporate security mitigations.
This is of course assuming that future builds/versions of Windows 10 allow EMET to continue to function. If this is not the case, the alternatives discussed above could be considered.
The CERT blog post also provides the steps to enable system-wide DEP an ASLR if EMET (or the alternatives) cannot be used. That post also provides a comparison table of Windows 7 and Windows 10 with and without EMET to better display the benefits EMET offers.
How the CERT/CC team align to the US CERT team is mentioned in this Sophos blog post.
I hope that you find this additional information useful. Thank you.
Early last week Microsoft extended the support deadline of their exploit mitigation tool, Enhanced Mitigation Experience Toolkit (EMET). The final support deadline is now the 31st of July 2018 (originally 27th January 2017).
Why Should This Announcement Be Considered Important?
At this time there are known bypasses for EMET e.g. this and this. While a competitor to EMET, SurfRight HitmanPro.Alert mitigated the WoW64 bypass, Microsoft never incorporated such changes (or at least never documented such improvements). In addition in their most recent blog post concerning EMET; Microsoft states that EMET’s effectiveness against modern exploit kits (defined) has not been proven and were not designed to be a long term solution just a “stop gap” to add extra protection to older versions of Windows without necessitating upgrading to a newer version of Windows.
In addition, Microsoft mentioned that EMET can reduce the performance of the applications that it protects. Moreover it can impact their reliability since it hooks into the operating system at a low level in order to add its protection to the applications chosen by a system administrator or individual user.
You recommend EMET a lot on this blog; is that going to change?
In the short term, no. In the long-term, yes. While EMET is still supported I will recommend its use but will note that its end of support date is approaching.
I still believe that EMET can provide value by adding mitigations to commonly used applications both for enterprise/business users and individual user applications when those applications don’t include mitigations such as DEP or ASLR etc. by default after installing them. I don’t agree with Microsoft’s decision to end support for EMET for this reason.
I believe that they were overly critical of EMET in their most recent blog post. Yes it can cause performance issues (usually disabling one or both EAF and EAF+ mitigations resolves this) and can cause compatibility issues. In general, this depended on the set up of your individual applications. E.g. if you don’t install add-ons into Microsoft Word, Excel etc. they are far more likely to work with EMET without any changes. In many business and enterprise environments I realise this isn’t an option.
In my experience, accepting the defaults of the EMET configuration and adding all but EAF and EAF+ to custom applications would almost always work. Adding EAF and/or EAF+ was appropriate if they didn’t cause performance issues. A further reference regarding EMETs mitigations and another application compatibility list is available here.
I always believed that if you were going to deploy EMET across an organisation that you had to extensively test it. This could possibly involve testing it on hardware and software that mostly (or exactly if possible) emulates each type of server and workstation in use across each team in your organisation. Using just one configuration across your organisation would not work or if it did, it would be sub-optimal since you would likely have to disable many more mitigations to make it work smoothly across all systems in use.
How secure non-best practice applications (namely that they don’t include mitigations such as DEP or ASLR) are when installed on Windows 10 is uncertain. However given the continuing work that Microsoft is doing with Windows 10 and their recent publishing of details concerning the new mitigations available in Windows 10 (the original security benefits are discussed in a previous blog post) Windows 10 in the long term is the way forward. Overall however the Windows 10 without any additions is more secure by default than Windows 7 or Windows 8.1. Just one example would be the disabling of LDR Hotpatching which mitigates the issues caused by abusing its functionality discussed here and here.
If I can’t upgrade to Windows Server 2016 or Windows 10 before the support for EMET ends, what would you recommend?
If your business applications already include security mitigations such as DEP and ASLR, you may not need EMET and can simply ignore it. EMET and indeed the competitors to EMET are only necessary if the applications you use need hardening.
For business, enterprises and individuals Alternatives to EMET are Malwarebytes Anti-Exploit (Business and Personal editions) and HitmanPro.Alert. Malwarebytes Anti-Exploit can be used to protect custom applications and thus can take that role over from EMET. I am currently testing Malwarebytes Anti-Exploit and HitmanPro.Alert and will comment on their resource usage and any drawbacks they may have. I will update this post when I have completed this testing.
Alternatively try to contact the developers of the custom business applications that you are using and request that they enable some security mitigations e.g. DEP and ASLR. Visual Studio 2015 is required for adding CFG but DEP and ASLR can be added using compilers like Mono and mingw (example 2 and example 3).
I contacted the developer of a 64 bit open source tool and he mentioned that since he still supports Windows XP migrating to a newer version of Visual Studio is not an option right now but would consider it for the future. Another small but commercial application developer (a 64 bit utility for Windows) was very enthusiastic about a new version of Visual Studio offering extra mitigations and promised to add these to the next major release of his product which is currently in beta and moving towards a release candidate.