EMET (Enhanced Mitigation Experience Toolkit)

Some confirmation from Google Chrome Security Team developer Justin Schuh regarding Chrome PGO breakage by EMET which I assume would have performance implications.

Link: https://twitter.com/justinschuh/status/771482677757239297?lang=en

PGO = Profile-guided optimization
Link: https://en.wikipedia.org/wiki/Profile-guided_optimization

 

Given the security design of Chrome/Chromium, I would rather not inject code into it.

 

I haven't noticed any issues

 

Spotify - only works under EMET 5.51 when EAT & Caller are unchecked.

There's another issue - upon first run it runs just fine - I listen to some songs etc.
Then when I turn off and ON the program begins installation process - can we handle that somehow?

 

EMET rules to import to prevent some recent application whitelisting bypasses for rundll32.exe and regsvr32.exe
Sourced from: https://github.com/iadgov/Secure-Host-Baseline/tree/master/EMET

The scrobj.dll binary in particular has been discussed quite a bit lately.

Spoiler: Prevent rundll32.exe and regsvr32.exe bypasses

Copy code and save as .xml file. then import into EMET.

Code:

<EMET Version="5.51.6024.23768">
  <EMET_Apps>
    <AppConfig Path="*" Executable="rundll32.exe">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>System.Management.Automation.dll;mshtml.dll;jscript*.dll;scrobj.dll;scrrun.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*" Executable="regsvr32.exe">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>scrobj.dll;scrrun.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
  </EMET_Apps>
</EMET>

Spoiler: Blocking malicious OLE packages in Microsoft Office products

Copy code and save as .xml file. then import into EMET.

Code:

<EMET Version="5.51.6024.23768">
  <EMET_Apps>
    <AppConfig Path="*\OFFICE1*" Executable="EXCEL.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>flash*.ocx;packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*\OFFICE1*" Executable="INFOPATH.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*\OFFICE1*" Executable="MSPUB.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*\OFFICE1*" Executable="OUTLOOK.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*\OFFICE1*" Executable="POWERPNT.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>flash*.ocx;packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*\OFFICE1*" Executable="VISIO.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
    <AppConfig Path="*\OFFICE1*" Executable="WINWORD.EXE">
      <Mitigation Name="DEP" Enabled="true" />
      <Mitigation Name="SEHOP" Enabled="true" />
      <Mitigation Name="NullPage" Enabled="true" />
      <Mitigation Name="HeapSpray" Enabled="true" />
      <Mitigation Name="EAF" Enabled="true" />
      <Mitigation Name="EAF+" Enabled="false" />
      <Mitigation Name="MandatoryASLR" Enabled="true" />
      <Mitigation Name="BottomUpASLR" Enabled="true" />
      <Mitigation Name="LoadLib" Enabled="true" />
      <Mitigation Name="MemProt" Enabled="true" />
      <Mitigation Name="Caller" Enabled="true" />
      <Mitigation Name="SimExecFlow" Enabled="true" />
      <Mitigation Name="StackPivot" Enabled="true" />
      <Mitigation Name="ASR" Enabled="true">
        <asr_modules>flash*.ocx;packager.dll</asr_modules>
      </Mitigation>
      <Mitigation Name="Fonts" Enabled="false" />
    </AppConfig>
  </EMET_Apps>
</EMET>

 

Thanks WildByDesign
So would it be best to import these then do an export as a full backup copy.

 

You're welcome. You could import these and export as a full backup copy, indeed. Or you could also do more compartmentalized backups/imports as well. Or both. I like to have individual exports/backups for specific purposes, such as Microsoft Office, so that I can easily share with others. So you can export in full or export based on selected rules, whichever you prefer.

 

EMET 5.5 and 5.51 causing EAF related crashes on Windows 7 SP1 systems. Microsoft is recommending to disable EAF in those situations for those affected by it.

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

 

About those bypasses, I couldn't figure out what's so special about them. Isn't blocking Powershell from running enough to stop these type of attacks?

 

EMET simply cannot deal with VBA macro's. If you (try to) configure ASR to block certain techniques then there are still a gazillion possible alternative techniques to drop a backdoor.

On top of that, MS doesn't seem to give a bit about fixing EMET bypasses.

 

The Chromium and EMET page has been updated recently regarding the Chrome 53 release, particular to PGO optimized builds of Chrome.

Link: https://www.chromium.org/Home/chromium-security/chromium-and-emet

Spoiler: Details for users protecting Chrome with EMET

Anyway, here is the most important part:

 

You mean you followed a C++ programming class and learned that there always three or four ways of achieving something? Now you looked at the DLL's blocked and could think of at least three more ways to start VBA macro's and you used the primative counting method: one, two, gazillion? It is okay to put things in perspective, you are right this does not closes out everything, but you realy need new glasses when you are seeing a gazillion other options.

 

I was talking about these bypasses (see links), it seems like they can be stopped easily by simply monitoring rundll32.exe and regsvr32.exe. It seems they can both be used to execute Powershell scripts, so monitoring powershell.exe isn't enough, I misunderstood. But anyway, what I'm trying to say is that anti-exploit should always be combined with anti-executable or a sandbox. It's very unlikely that malware will be able to bypass multiple layers.

http://subt0x10.blogspot.nl/2016/04/bypass-application-whitelisting-script.html
http://www.labofapenetrationtester....use-of-javascript-and-com-for-pentesting.html

 

I just came across a fantastic article on EMET today that goes over how the different component of EMET work within Windows OS and also contains many great links to other highly detailed EMET articles and previous bypasses. A wealth of information and well written.

Diving into EMET (by Timo Schmid)
Link: https://www.insinuator.net/2016/09/diving-into-emet/

 

@WildByDesign Thanks good read

 

Nice find @WildByDesign

 

Who needs 20 skins... I'm skipping this upgrade ^^

 

On W7, I found that the workaround described in KB3175024 for EMET did not work with Mozilla Firefox, but it did work with other programs, so it is a bit inconsistent. I used the group edit method for the EAF issue. FF would not update even with this set after the windows update was installed. There is another windows update rollup that has the same problem with EMET. Fortunately these two monthly rollups are not cumulative, so no big deal on that front.

When I removed Firefox totally from EMET, it immediately updated to the latest release.

I am going to hold off updating EMET until they fix this problem with the windows update monthly rollups. Hopefully the EMET Team will not have the fix wrapped up in the non-security monthly bundle in October (or afterwards).

 

i wonder why they use devexpress thats make it too heavy loading
please somebody email them about it,so they try use Microsoft dll in Microsoft software!

DevExpress.BonusSkins.v15.1.dll
DevExpress.Data.v15.1.dll
DevExpress.Images.v15.1.dll
DevExpress.Utils.v15.1.dll
DevExpress.XtraBars.v15.1.dll
DevExpress.XtraEditors.v15.1.dll
DevExpress.XtraLayout.v15.1.dll
DevExpress.XtraTreeList.v15.1.dll

 

There has been some recent rumours (so far just rumours, hopefully) that EMET may be going EOL in January and that 5.51 may very well be the last version of EMET. Some have said that the EMET team has been disbanded, etc. However, keep in mind that these are just rumours at the moment. I am hoping that EMET will stay around and continue to evolve and be supported.

However (and this is a rather important "however"), if Microsoft were to discontinue EMET, I would be crossing my fingers and hoping that they release the source code on Github. Similar to how they have done with .NET, Powershell, and other programs. Open-sourcing EMET would be phenomenal.

Anyway, I have been told by a member within the EMET team that they will be updating their public documentation within the coming weeks. That was the only information that I was able to get out of them. They said that their internal documentation is up-to-date but that their external (public) facing documentation is outdated and therefore they will update their support article and other documentation sometime within the next few weeks. So for now, we can really only speculate.


Regarding skins:

For anyone that does not care for the additional skins, you can safely delete the DevExpress.BonusSkins.v15.1.dll file, restart EMET service, and they will be removed from the UI without any errors or issues. Removing any of the other DevExpress DLL's, on the other hand, does cause many errors within Event Viewer and causes the EMET UI to not load at all. But you can safely delete the BonusSkins DLL.

 

@WildByDesign

I wouldn't be surprised if MS would stop the development of EMET. In the past year I have reported multiple bypass techniques for versions 5.2 and 5.5 and I received zero response. So I guess they stopped caring about EMET.

 

Can you explain why you think EMET is cool? I believe HMPA and MBAE are a bit more advanced and are much more user friendly.

 

Sure, absolutely. And I would agree with you that HMPA and MBAE are likely a bit more advanced and are both more user-friendly. The reason why I like EMET is because it's entirely free and because it integrates well into the operating system and I also find the appcompat/shim functionality to be interesting. Also, it has increasing enterprise adoption in recent years and has published baseline rules (https://github.com/iadgov/Secure-Host-Baseline/tree/master/EMET) to follow, among others. I also like the fact that it can be manage through GPO.

But on the other hand, EMET has been increasingly defeated. So the EMET dev team would need to put a lot of effort into new techniques and tricks to remain solid and relevant. So I suppose that is the big question right now, whether or not Microsoft is willing to continue putting money and time into that effort.

 

I had this feeling that EMET being a free tool did have something to do with it.

But seriously, I was never into EMET. It looked too complex for me, I think MS could have done a better job.