EMET (Enhanced Mitigation Experience Toolkit)

There's one thing that still bothers me until now. I know what the manual says, but if I enabled all mitigations in the additional protection and the programs don't show any strange behaviors, can I still do that? Thank you.

 

Yes, the manual clearly stated which mitigations aren't compatible with popular software. The less popular ones may need some personal tests, but the examples of popular software might be usable. But we've been suggested to disable certain mitigations if the program misbehaved. If I don't encounter it then would it be okay to let them all on?

 

Help needed. I added mspaint.exe to EMET with all exploit mitigation checked. When I ran Malwarebytes I got this message. Is it a false positive ? I checked that registry key and it looks like its part of EMET. Can someone pls confirm ? Should I be concerned about this alert or its part of EMET ?

 

I guess you're right. I'll just let them all on and see how it goes. For now, I don't see the need to disable any of the mitigations. Thanks.

In my experience MBAM loves to detect any alterations of the OS. It will give you a similar threat warning if you disabled the system restore. I suggest to scan it with other scanners as well. And if you wanted to, remove MSPaint from EMET's protection and do a scan again with MBAM. See if it still detects it. If yes, maybe that's because there's a registry key left in (if I'm not being mistaken) HKLM/Software/Microsoft/EMET which is the rule for MSPaint. It's rather dangerous IMO, but you will need to delete that key. I'm not going to take any responsibility in case if something went wrong.

 

This registry location is used in different ways. It is used for debugging software. It's used to set SEHOP IFEO flags on software. I also know it is used to redirect normal software executions to malicious files. Instead of MSPAINT.EXE it'll launch instead ThisTrojan.exe file ... for instance.

I don't know if EMET uses this area. Running w/ Windows 7 x64 and adding MSPAINT to EMET filtering and visiting this registry area, MSPAINT key hasn't been created for me. Simply try adding something else that you haven't added before and checking for that key creation in this reg location. While your there make sure that the MSPAINT executable isn't being redirected by having a look inside this reg location.

Also... It is pointless to be adding MSPAINT (Microsoft Paint) application to EMET filtering anyways. Want to focus on adding anything with client, and server capabilities.

 

Thanks Graffy and Phantom.. I do see lot of entries that are added in EMET in this registry location. Recently I read about Microsoft TIFF exploit, so I added mspaint to EMET.

 

Everything that I read about it makes me believe that it has to be opened / viewed from a client application like Email, browser, or Office Word.

 

If I am not wrong, TIFF can be opened with windows photo viewer. Just as a precaution I added mspaint, so in future even if I open TIFF with paint it can protect

 

I sent an email to chromium security id and I am posting the conversation here. I want inputs from you guys to understand that whether chrome should be kept in EMET's list or not?

 

I had everything checked for my media player (Zoom Player) but it kept hanging and I'd have to kill it with task manager. I ended up unchecking all protection except for DEP, SEHOP and heap spray. Is this setting ok for protection or should there be more with a media player?

 

I think It was mentioned in EMET 4.0 User's Guide.pdf that Windows Media Player don't support Mandatory ASLR and EAF

 

I don't see any reason for chromium security to lie, if they say it's all covered ... must be. Here few days ago I applied the latest Chrome portable version to EMET filter. Everything set and not experienced any problems surfing about. I thought well maybe I need to add a plugin or two, and I still couldn't experience a problems running Chrome.

 

Thank you for the Chromium response, harshisthere.

 

Sigh, whenever I see "it may conflict with" kind of statement it makes me worry so much even if I don't experience any problems. Maybe I should drop Chrome and start using IE. Not to mention certificate trust is unusable by web browsers other than IE.

 

Chromium already implements the most important features of EMET. Certain features, like EAF, may not even work - or at least not for certain areas. I would be very wary about using the Anti-ROP mitigation techniques with Chrome as well, I would not recommend that.

Overall, it's just not worth it.

 

Or maybe I should drop EMET because I have no idea if my weirdo apps will be compatible with those additional mitigations. Is there a way to enable SEHOP and force ASLR in Windows 8/8.1 without EMET? The "SEHOP fix it" patch didn't work and the registry placements seem to be changed here and there.

 

It does, check page 40 in EMET User's Guide.pdf.

 

After the enabling I have only Disabled, Opt In, Always On. How to make "Opt Out" ASLR available? Mine OS is Win 7 Ult 64.

 

To enforce system wide ASLR or force ASLR as you call it open registry editor and navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel right click and create a QWORD and name it MitigationOptions and hit enter, now double click on the QWORD and delete the default value of zero and enter a new value of 555 and click ok now reboot your computer, that is it

Note: Setting ASLR to "Always On" using EMET's interface or manually as I have described above seems to only enforce ASLR on dlls but not on the main exe processes as claimed in the EMET user manual as evident from process explorer or atleast it seems so

 

"Opt Out" is only available on Win 8 and 8.1

 

Where is this documented...? AFAIK it's the MoveImages value in a key named Memory Manager or something...

Going by what in Process Explorer? I think the ASLR column may only indicate if the image (exe or DLL) is flagged as ASLR enabled. To see if Windows is really moving it, simply compare Base and Image Base in the lower pane -- if they're different, it's been relocated (you can also enable highlighting of those instances).

 

Re: post 386

This is a definitive response from Chrome support. I was wondering why Chrome was not in the preferred list from EMET. I guess we can assume that the developers tested Chrome under EMET and found that under certain criteria the browser would break. They would have the dumps and the expertise to analyse the source of the failures. Having these two powerful apps compete for the same task is not good. I have decided to let Chrome do its own mitigation tasks and have removed it from EMET, totally.

 

Oh, thank you.

Then EMET can be used to determine Win 8.x editions.