Windows 10 exploit protection

Windows 10 exploit protection - Tutorial

Updated: December 20, 2017

With the release of Windows 10 Fall Creators Update (Build 1709), the most superb and elegant Enhanced Mitigation Experience Toolkit (EMET) is no longer available or can be installed on this operating system. Instead, these mitigations are now an integral part of Windows 10.

Since I'm a huge fan of EMET, and I'm using it on all my Windows machines, I decided to write a detailed, practical and real-life use guide on how to deploy and tweak the new mitigations in Windows 10. Please follow me.

Teaser

Introduction & preliminary reading
Windows 10 exploit protection
1. System settings
2. Program settings
Export and import configuration
Real-life usage and examples
Additional reading
Conclusion

Introduction & preliminary reading

If you have stumbled upon this article by accident, which is unlikely given the niche and nerdy nature of this topic, then let me just briefly introduce EMET. This utility is a set of system and program mechanisms that prevent bad code from running. This way it can potentially stop and block exploits in running programs.

Microsoft released EMET as a standalone tool many years ago, and you could manually deploy it on any which system. It is still available in the previous two versions of Windows as well as Windows 10 until Build 1709.

EMET works by restricting what type of instructions and memory access running programs can execute. The beauty of this idea is that it does NOT differentiate between what we call good programs and malware. It only differentiates between compliant, so-called legal code and non-compliant, so-called illegal code. So even if you have a perfectly legitimate program like say Chrome or Powerpoint, and they are encapsulated and protected by the EMET libraries, if they misbehave due to some illegal instruction - most likely introduced by mistake and sloppy programming practices or legacy constraints - then EMET will block the execution and terminate the program.

This makes EMET ideas as a security tool - once properly configured, it is a fire-and-forget solution. It is lightweight, non-intrusive, extremely efficient, and smart. The concept of looking at software from its execution quality perspective is much wiser than trying to blacklist bad programs.

EMET also works in conjunction with system-level security mechanisms available in Windows, including DEP, SEHOP, ASLR, and others. Very neat, very handy, and supremely useful.

I have written a detailed tutorial on how to use EMET. It was made with version 4 of the program, but the guidelines are 100% true and correct for later versions, with my last review of the mitigation toolkit being on version 5.5. Please read those so you can familiarize yourselves with the various concepts and protections.

GUI

App mitigations

No longer installable, though:

EMET cannot install anymore

Windows 10 exploit protection

The functionality of EMET is now available inside Windows 10 Build 1709 as a built-in capability. You can access the relevant UI through the Windows Defender Security Center. On the left, in the sidebar, click on the second-to-last icon, scroll down to the end of the list, and then click Exploit protection settings.

Exploits protection

The new UI is simplified compared to EMET - and also more difficult to use, as you have less visibility into what you currently have enabled. You also do not have the full matrix-style view of your apps and enabled mitigations. But let's leave the ergonomic considerations aside. Let's only focus on the raw functionality. We will touch on how the actual interface can and should be improved later.

System settings

The default view lists System settings. Like older operating systems, Windows 10 comes with several low-level mechanisms to prevent malicious (read incorrect/illegal) execution of code. Again, we are not specifically talking malware, we're talking any code that may potentially cause system crashes, instability and alike.

System settings

The six available protections that come with Windows 10 include: CFG, DEP, Mandatory ASLR, Bottom-up ASLR, SEHOP, and heap integrity. These are roughly equivalent to what Windows had before, but there's no exact 1:1 translation, as there have been some changed in the underlying kernel structures. By default, all these protections are ON.

Program settings

If you click on the second category, this will expand the list of individual programs currently covered by the exploit protection mechanism. Only programs with overrides are listed. If a program has a configuration that matches the system defaults, it will not be added.

Programs

Windows 10 comes with several applications already listed, including specific overrides. At the moment, we should leave those alone, as they have been configured by Microsoft for optimal security versus compatibility.

You can add new programs, either by path or by name. The latter is better as it allows you to protect any version of the specific application matching the particular executable name, regardless of where it is installed on your disk.

Add program

Once you add a program, a new windows will pop up, allowing you to customize its exploit protection configuration, with a long and somewhat confusing list of available mitigations. You can now individually turn mitigations on and off. You will notice that some of these protections are Off by default - and others are on, usually matching the system configuration mentioned earlier. So you can override the defaults.

Edit program configuration

There are 15 mitigations available - and if you enable them, they will take precedence over the system defaults. You also have the option to allow auditing - basically if an exception is encountered, the system will notify you, and you will need to manually close or terminate the program. Otherwise, the system will terminate programs with illegal instructions that match mitigations.

Export and import configuration

Now, the interesting and tricky part. Since the new mechanism comes with a more cumbersome interface, configuring programs becomes a pain - we're talking say 20-30 programs with up to 15 mitigations each, and this takes a lot of mouse clicks to sort out.

Luckily, you can use XML configurations files to more quickly update your protections. You add and remove programs to and from your list, you can tweak specific mitigations, and perform the needed setup much more quickly and efficiently. To do so, you need to understand the basic format of the configuration file.

In the main interface, click Export settings and save an XML file somewhere on the disk. Open it inside a text editor, and let's briefly look at the configuration, and what different directives and values mean.

Configuration file format

Let us review:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<SystemConfig>
<ASLR Enable="true" ForceRelocateImages="false"
OverrideForceRelocateImages="false"></ASLR>
</SystemConfig>
<AppConfig Executable="DevicesFlow.exe">
<ExtensionPoints DisableExtensionPoints="true"
OverrideExtensionPoint="false"></ExtensionPoints>
</AppConfig>
...

These are the first few lines of an actual configuration; the indentation is there to help visually distinguish where things start and where they stop, like pretty much any other language. You have the XML declaration at the top. Then, you have the root section, which basically defines the block inside which you will have system and application configurations.

System configurations are declared by SystemConfig. Applications are declared by AppConfig. Application names are declared by the variable Executable. Then we have different types of mitigations, like ExtensionPoints, Fonts, Payloads, DynamicCode, and others. For instance, the almost full list for an added application will include something like:

Ignore the actual values for the time being. Let's understand three important variables:

Value - can be true/false, defines if a mitigation is enabled or not.

Override - contrary to what you think, this does NOT tell you if the value specified overrides system defaults. Nope. That's already by design. If this variable is set to true, it means you CANNOT edit the settings through the UI. This is rather confusing, especially since false, means you have control through the Defender Security Center, and true means you do not. Best ignore this variable.

Override disabled

Audit - whether the program runs in audit mode or full enforced mode.

So we have the basics ready. Now, let's actually create a configuration file, and then import it into the exploits list. And we will do that by actually importing an old EMET configuration, as we do not want to lose all the hard work we've done.

Use old EMET configuration

We will now actually use Powershell command line to do some of the tasks. Namely, we will convert an EMET config file to the new format and then import it. These commands do not currently have a GUI equivalent. You need Powershell and administrator access. Anyway, an EMET file will look something like this:

I think this is a much cleaner and nicer format. But never mind. Let's now convert this configuration file. If we read the online documentation on how to do this, we need the following command:

ConvertTo-ProcessMitigationPolicy -EMETFilePath emetconfig.xml -OutputFilePath newconfig.xml

I got a bunch of errors:

Error: Should read Win10 setting for some reason?: PinRuleMember
Error: Should read Win10 setting for some reason?: Active
Error: Should read Win10 setting for some reason?: PinnedSite
Error: Should read Win10 setting for some reason?: Domain
Error: Should read Win10 setting for some reason?: PinRuleMember
Error: Should read Win10 setting for some reason?: Active

Apparently, all the pinned rules for certificates in pre-Windows 10 rules are not compatible with the new format. If you're trying to import such a configuration, it will fail. You will need to clean up the XML before doing the conversion again.

<Pinning>
    <PinRules>
      <PinRule>
        <ID>{392c02ca-a7dd-49e3-888f-7fb505de9333}</ID>
        <Name>FacebookCA</Name>
...

Note: There is no exact 1:1 match between EMET and the new exploit protection mechanism, and especially if you move across multiple operating systems. My recommendation would be to use the old config as an advisory only.

So, the converted file will look something like this - in terms of app mitigations:

Application template

Most of the mitigations imported from EMET will be set to false unfortunately - and the system ones will no longer fully match. So my recommendation is as follows: the six system mitigations cover the basics. You can also enabled an additional six mitigations that seem to match 1:1 between EMET and new protection mechanism, including: EAF, EAF+, IAF, StackPivot, CallerCheck, and SimExec. Therefore our basic template for applications, based on previous usage becomes:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<AppConfig Executable="executable.exe">
<Payload EnableExportAddressFilter="true"
EnableExportAddressFilterPlus="true"
EnableImportAddressFilter="true"
EnableRopStackPivot="true"
EnableRopCallerCheck="true"
EnableRopSimExec="true">
</Payload>
</AppConfig>
</root>

We can extend this with fonts protection (the text is formatted for visual clarity):

<?xml version="1.0" encoding="UTF-8"?>
<root>
<AppConfig Executable="executable.exe">
<Fonts DisableNonSystemFonts="true"
AuditOnly="false"
OverrideFontDisable="false"
Audit="false">
</Fonts>
<Payload EnableExportAddressFilter="true"
EnableExportAddressFilterPlus="true"
EnableImportAddressFilter="true"
EnableRopStackPivot="true"
EnableRopCallerCheck="true"
EnableRopSimExec="true">
</Payload>
</AppConfig>
</root>

And this is a template section you can use as your baseline:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<AppConfig Executable="executable.exe">
<Fonts DisableNonSystemFonts="true" AuditOnly="false" OverrideFontDisable="false" Audit="false"></Fonts>
<Payload EnableExportAddressFilter="true" EnableExportAddressFilterPlus="true" EnableImportAddressFilter="true" EnableRopStackPivot="true" EnableRopCallerCheck="true" EnableRopSimExec="true"></Payload>
</AppConfig>
</root>

Real-life usage and examples

All right, so far, we have covered the new UI, system and program settings, overview of new exploit mitigations, how to export configuration files, how to convert old EMET settings, and now we will import our app templates and use them.

We will use our app template from above to quickly and elegantly add new applications into the system list, bearing in mind that system settings are best left at their defaults, and they already cover a great deal, plus there are six other mitigations that closely match past configurations, and are likely to work well. This is the MAIN reason why I have chosen this baseline, plus the fonts, which make simple sense, and also go hand in hand with past vulnerabilities on this issue.

There are other mitigations that we could potentially enable, but unless you fully understand what you're doing, you may cripple your programs. In some cases, even the developers of software will NOT know what their applications are doing wrong, so it is quite possible you won't find an easy answer.

ACG, low integrity and remote images - should be okay.
Code integrity guard - unless signed by Microsoft, images won't run - this is basically Windows 10 S. Not recommended.
Extension points - very likely to cause problems in how software runs.
Disable system calls - highly likely to cause problems.
Child processes - will definitely cripple programs.
Handle usage - likely to cause problems with sloppily designed software.

The rest we already have covered - six basics, six old mitigations, fonts, and potentially three written in the first bullet, with the rest best left alone.

Import new configuration

This is done as follows, again from Powershell, and with admin credentials:

Set-ProcessMitigation -PolicyFilePath .\config.xml

Configuration file contents

Based on our template, we can add the applications inside the file. You can either create a single configuration with several programs listed inside and then import it once, or make an per-app template and perform multiple imports. It makes no difference.

What you need to take into account is: 1) you can do with the Security Center running, but it will NOT show the changes on the fly; the config is loaded once and/or whenever you make changes through the UI 2) old app settings will be removed with the new ones.

Running and using exploit protection

I tested with the following programs: Firefox, LibreOffice, VLC, IrfanView, Notepad++, and these run without any problems, including updates. Google Chrome would not run with ANY mitigation enabled except the fonts - both the pages and extensions kept crashing. This is in contrast to EMET behavior. Like I said, there's no GOLDEN list on what works and what does not, but I believe you can have 7/15 and maybe even 10/15 mitigations enabled, with code signing, child processes and system calls disabling really being unnecessary. That leaves only two mitigations that might need closer look: extension points and handle usage. Pretty good, I'd say.

Page crash

Extension crash

Edit and tweak configuration

You can always go back and make changes - also through GUI after you've imported the bulk of your configuration, and now you just need fine tuning. If things do not work, you can always remove an entry and start fresh.

Edit app

Overzealous protection

If you go wild, and I tried, just to see what gives, you may completely cripple your programs, and they won't run. It's all too easy to do this, so please be utterly careful, and make sure you understand what you're doing. This is a long-term investment. Do it well once and you won't have problems down the road.

Firefox cannot launch

Firefox cannot start

Additional reading

You may also want to check these official Microsoft articles:

Apply mitigations to help prevent attacks through vulnerabilities

Customize exploit protection

Conclusion

There you go. A very thorough, hands-on, real-life guide on how to use the new exploit protection mechanism in Windows 10. We didn't just blindly look at the list and wonder what magic happens behind the scene, we went behind the scene, and got ourselves autographs on our chests.

On a more technical note, we learned about the exploit mechanism, the new UI, system and program settings, types of exploits and what they roughly do, how to export and import XML configuration files, we created our work template, we converted and used our old EMET settings, we tried to match the level of protection that EMET gave us while still maintaining sane and practical functionality with most programs and most mitigations. We have about 80-90% coverage without breaking things. There are no guarantees in this process, but it's so much ahead of any conventional security software.

The mitigation protection remains Microsoft's best product by far, and hopefully, they will improve the workflow so it is more accessible to advanced users. For the time being, you have this guide, and hopefully, it will make your journey into the post-EMET world of mitigations simpler and faster. And your apps will still work! See you.

If you like this tutorial, then give some love back, support Dedoimedo. Right?

Cheers.

Table of Contents

Introduction & preliminary reading

Windows 10 exploit protection

System settings

Program settings

Export and import configuration

Configuration file format

Use old EMET configuration

Application template

Real-life usage and examples

Import new configuration

Configuration file contents

Running and using exploit protection

Edit and tweak configuration

Overzealous protection

Additional reading

Conclusion