EMET (Enhanced Mitigation Experience Toolkit)

You install it. You select what profile you wish to use; or just use the default one. That's all there is to it.

The only part that needs manual configuration is certificate pinning and only if you chose to use that feature. Only when you get into "tweaking" it as Wild Bill has done is when things get a bit complex and dicey.

 

Well, they made it look complex, I didn't like the GUI.

 

Luckily, quite a bit of EMET's mitigations can already be enforced via GPO on Windows 10 (some on Windows 8.x as well):
https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088(v=vs.85).aspx
https://technet.microsoft.com/en-us...ion-options-for-app-related-security-policies

 

Link: https://support.microsoft.com/en-us/kb/2458544

 

Why is this? , does Windows 10 comes by default with the same security than EMET or it can be configured to provide the same protection ? How?

 

As a potential FYI for home version user, you can directly edit registry to enable those mitigation, HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel!MitigationOptions for system wide setting, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options for per app setting.

 

I believe for non-sandboxed (out of AppContainer) apps EMET still makes sense and win10 does not protect them by the way EMET does.
It's not very good for us users, but EMET is free tool and Microsoft is a company...

 

Some key takeaway points here are the fact that Microsoft is extending EMET support by an additional 18 months. However, that does not necessarily rule out another release because EMET releases generally add an additional 12 months of support for major version release and I believe 6 months of support for minor version.

But anyway, one of the big takeaway points for me is that EMET will not support the next upgrade to Windows 10 which they are supposedly referring to as Creators Update or something along those lines. So this makes me wonder what might be coming along next with regard to security in Windows 10. Are they adding more security mitigations into the root of the operating system which would cause conflicts with EMET? Are they making changes to the way in which EMET shimming is done (via App Compatability shim engine) that would cause EMET to not work anymore? I've heard some bits and pieces recently that some shimming (not EMET related) stopped working in Windows 10 Anniversary Update and that there may be signatures added to verify the shim databases, but I don't think that this has been entirely clarified yet by the security heavyweights.

Windows 10 includes much (if not all) of the system-wide security mitigations that EMET provides, the only thing is that EMET provides a simple UI to modify those changes. Windows 10 also has the ability to do many of the per-process mitigations as well, to force in, exclude, etc. But that is all done via registry and/or group policy. This could be a hint for some open source developers to make a handy UI with easy access to all of these great Windows 10 built-in mitigations. However, not all EMET mitigations are in Windows 10.

Another aspect is that nearly all Windows processes in Windows 10 are compiled and protected by Control Flow Guard (CFG) by default, and therefore on 64-bit machines for example have a 2TB virtual memory size. So far, the updated iteration of CFG built into Anniversary Update has not yet been defeated. Windows 10 has much more security protection built-in and is a decent step up from Windows 8.1, and a rather large step up for Windows 7. EMET would definitely be missed by Windows 7 users.

Some processes, at least thinking of the user-mode font driver processes, are contained within an AppContainer restricted sandbox. So I can envision Microsoft protecting more processes over time with AppContainer sandbox when possible.

But as for why Microsoft is going to EOL EMET, as for everything in life, certainly money is likely the deciding factor. I am still a bit surprised because many large organizations have adopted EMET over the past few years (including governments, mandated) and Microsoft even has paid support for those customers. I believe that it has more to do with Microsoft wanting to push Windows 10 more and more, whereas a lot of this large organizations are likely hanging onto Windows 7 (with a little help from EMET to harden security) and holding off on the migration to Windows 10. EMET is that fine line that some organizations may be using to hang onto. Microsoft pulls that line away and those organizations are going to think much harder into Windows 10 migration and essentially forced to do so, assuming those organizations value security, no doubt. That is my take on it.

Microsoft: Please open-source the code for EMET toolkit before the 18 months is up!

 

I agree with that entirely regarding protecting AppContainer processes, not much benefit there and even the possibility to make that AppContainer sandbox slightly less secure by shimming with EMET. AppContainer processes seem to be injected by EMET but I don't believe that EMET is able to communicate properly back to it's injected DLL or vice versa.

Lately, my biggest use of EMET has simply been the ease-of-use for applying the system-wide mitigations. I don't worry so much about the per-process mitigations lately and therefore avoid the need for DLL injection which slows down the startup of those processes.



So from the screenshot above, this is what I do for Windows 10 users. I disable the Certificate Trust (Pinning) because it is not used by Chromium and therefore avoids entirely the injection of EMET_CE.dll / EMET_CE64.dll into the chrome.exe process. This was occurring before regardless of adding chrome.exe process. Therefore disabling Cert Trust setting stops the injection which was unneeded at least in my case. So no need to have a DLL injected which could potentially cause slower startup or any potentially unknown security issue.

The other important part this is following the EMET manual documentation and forcing the (supposedly unsafe) ASLR Always On option. So this now, on a system-wide basis, is forcing ASLR module relocation on all processes whether they opt-in or not. This used to be an unsafe option back in like 2012/2013 specifically with AMD/ATI graphics drivers which would cause BSOD on startup. That was fixed with AMD/ATI drivers since that time. My main system is all Intel drivers and zero issues. Do be careful and know your way into Safe Mode to undo the registry change for this just in case you do run into BSOD so that you can revert this change if needed.

 

I have EMET installed again solely for the ASR feature, I am not using any memory mitigations so no conflict with HMPA.

I am going to refresh here what I posted about 18 months back but censored on request of EMET dev's but since they never fixed it I am posting again.

On both windows 8 and windows 10 if you adjust the DEP setting or SEHOP setting using EMET, it breaks DEP, this happens because EMET writes an incorrect registry value. Those values should not be touched in EMET, and instead use bcdedit to set DEP to the correct mode you want for your system. EMET will report the wrong value so you can verify what is set with bcdedit.

 

@WildByDesign If you want to use cert pinning on Chromium, you can add chrome.exe (I thought Chromium's exe file is chrome.exe, but correct me if wrong.) to HKLM\Software\Microsoft\EMET!EMET_CE like "iexplore.exe;chrome.exe" as Chrome/Chromium also use Windows CryptAPI.
However, it doesn't make sense unless you manually add custom rules for cert pinning, as Chrome (maybe Chromium too, but need confirmation) comes w/ default HPKP rule set which has broader coverage than EMET's pre-defined rule. You can even add custome HPKP rule as command line switch, tho not handy at all.
I once added all SSL sites I often use, only to find managing them is quite a hassle, while benefit is limited (it can't detect all MitM nor compromised cert since it only checks root).

 

Chrome has native cert pinning as does firefox.

 

One guy througly investigated that problem and here's his result. Tho it is about Win8/8.1, probably 10 is not different.
There're 3 major problem in EMET's DEP/SEHOP setting or kernel!MitigationOptions key (0x0F & 0x0F0).
1. If you set DEP to OptIn from other state, automatic DEP by /NXCOMPAT won't work and DEP can't be enabled by SetProcessDEPPolicy.
2. If you set DEP to OptOut, exclusion via DEP system setting won't work and ATL thank emuration won't be enabled for non-NXCOMPAT process. Also DEP can't be disabled by SetProcessDEPPolicy.
3. If you change SEHOP setting while keeping DEP setting to default OptIn, it affects DEP setting too (see above link for details).
Workaround: Delete HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel!MitigationOptions registry value and use bcdedit for DEP and DisableExceptionChainValidation for SEHOP. Or if you use EMET system setting or MitigationOptions, only use AlwaysOn and never change.

 

Yes, mentioned in #1312.

 

I dont mean to sound dumb here, but i'f most of Emets protection are in Windows 10 now and more to come.
Doesn't it make it obselete using it in Windows 10 Home.

 

no - there's no UI to modify the settings easily

 

Ok thanks rm22

 

Well if they pull the plug on EMET the migration to a different OS is approaching faster than I thought.

 

Here are some (slightly outdated) fantastic open-source Reporting tools for EMET created by a Microsoft Dev from the EMET team previously.
Link: https://github.com/kurtfalde/EMET-Reporting

Some pretty interesting stuff there to create beautiful graphs and such. Not so exciting for a home user, I suppose, but great for organizations who are utilizing EMET on a larger scale. I recall seeing the details and graphs from these reporting tools a while back on a Channel 9 video but, at the time, did not realize that he had released these tools on Github.

ASR is something that would surely be missed if EMET were to be gone. Hopefully Microsoft developers will listen to suggestions for adding that ASR mitigation potentials to Windows 10 at least sometime down the road. ASR is something that has increasingly become more and more useful these days since you can specify certain modules, although it does have limits on modules.

You are right, Chromium does use CryptoAPI and therefore that is why EMET automatically injects EMET_CE.dll into chrome.exe as long as Cert Pinning is enabled. Although my experience with web site certificates and pinning in general is quite limited. A while back, I did try that method to add chrome.exe onto that registry key exactly as suggested from the manual and subsequently tried purposefully messing up all of the various cert pinning rules within EMET as an attempt to trigger those block rules. But unfortunately I was unable to trigger those cert pinning rules for chrome.exe and eventually gave up on that effort.

 

Wow, those are some big posts, you guys are really into EMET.

 

Bear in mind when EMET stops been supported it doesnt mean it has to be uninstalled.

For windows 8 and 7 it will probably work forever, the issue is with windows 10 which has major updates.

 

Moving Beyond EMET
EMET – Then and Now
Link: https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/

 

so in short they are dropping EMET to try to push people onto windows 10.

 

EMET also have some ROP mitigation which Win10 don't offer unless a protected program has CFG enabled.

Ah, I remembered there was an issue about cert pinning on Win8+.

 

Rest in peace EMET.