Under the term exploit protection, Microsoft brings together several technologies intended to protect against malware attacks. Among them are well-known features such as DEP, which has been around for a long time. While most mechanisms are active by default at the system level, you should still tune the settings for individual apps.

The key components of exploit protection include:

  • Control Flow Guard (CFG)
  • Data Execution Prevention (DEP)
  • Force randomization for images
  • Randomize memory allocations
  • Validate exception chains
  • Validate heap integrity

In addition, exploit protection comprises numerous settings that can be applied to harden applications. They complement the measures you can take for programs to reduce the attack surface. For example, you can prevent applications from starting child processes, block untrusted fonts, disable Win32k system calls, or prevent DLLs not signed by Microsoft from loading.

System versus app level

These mechanisms can be enabled at the system level so that they can then take effect automatically for all applications. However, configuring a setting for specific apps overrides system-wide defaults.

As a rule, it is better to protect individual applications, since global defaults can have unforeseen effects, especially on older programs. An audit mode that can be used to examine the potential side effects of certain protection mechanisms is only available for a few settings.

Check the event log

Before you distribute the settings from a reference PC to other computers, you should test the configuration extensively. The entries in the event log are helpful here. You can find them in the Event Viewer under Application and Service Logs > Microsoft > Windows > Security Mitigations > Kernel Mode.

Entries for exploit protection in the event log

Entries for exploit protection in the event log

Alternatively, you can display the log with PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-Security-Mitigations/KernelMode' |

Show current settings

The exploit prevention settings can be configured interactively in the Security app under App and browser Control > Exploit protection. There, you will find a tab for the system and program settings.

Exploit protection options in the security settings app

Exploit protection options in the security settings app

However, PowerShell is better suited for targeted queries. The system-wide standards for exploit protection can be displayed like this:

Get-ProcessMitigation -System
Query system defaults for exploit protection

Query system defaults for exploit protection

The individual settings are summarized under the respective protection mechanisms, and the output is often very extensive, especially for applications. If you want to display only the settings for Address space layout randomization (ASLR), for example, you can add the following filter to the command above:

Get-ProcessMitigation -System | select -ExpandProperty ASLR

The specific settings for programs can also be retrieved with this cmdlet:

Get-ProcessMitigation -Name chrome.exe

If you want to examine a program's running processes, then you would need to add the RunningProcesses switch.

Configure settings with PowerShell

Most of the settings for exploit protection can be adjusted using the GUI. If you decide to use PowerShell instead, then the Set-ProcessMitigation cmdlet is responsible for this.

Here, too, you can use the System or Name parameters to address either the global settings or those for individual apps. One or more settings are then activated or deactivated via Enable or Disable:

Set-ProcessMitigation -System -Enable DisableNonSystemFonts
Disable the use of untrusted fonts by system default

Disable the use of untrusted fonts by system default

This example generally disables the loading of untrusted fonts unless you specifically allow them for certain applications. Refer to Microsoft’s documentation for the names of the settings to use with Enable and Disable.

Exporting settings for exploit protection

Once you have configured the desired settings for exploit protection on a reference PC, you can distribute them to the other computers in the network.

The first step is to export the configuration from the source PC. This is done in the app, where you can customize the exploit protection as described above. The export is in XML format, and it writes both the system and app settings to a file.

Export the settings for exploit protection from the reference PC

Export the settings for exploit protection from the reference PC

Distribute configuration in the network

Next, you can import the exported configuration to another computer using PowerShell:

Set-ProcessMitigation -PolicyFilePath settings.xml

In most environments, however, group policies will be used for this purpose. To do this, place the file with the exported configuration in a shared folder, where it can be accessed by all clients. Now, create a GPO that distributes these settings in the network.

The Use general policy for exploit protection policy is responsible for this. It can be found under Computer Configuration > Policies > Administrative Templates > Windows Components > Microsoft Defender Exploit Guard > Exploit Protection.

Distributing the reference configuration using group policies.

Distributing the reference configuration using group policies.

If you activate the setting, you can store the path to the XML file in the corresponding input field.

If you want to return to the defaults, it is not enough to simply disable the GPO. You have to actively reset the configuration. To do so, either use the export from a freshly installed Windows or the EP-reset.xml file from the Windows Security Baseline.


Exploit protection brings together a number of mechanisms that harden Windows against malicious programs and attacks. Some of these are enabled by default, but a tailored configuration for critical applications can further enhance security.

Subscribe to 4sysops newsletter!

In managed environments, you'll want to test such a custom configuration on a reference system before exporting it and distributing it across the network via a GPO. Unfortunately, only a few settings support audit mode, so you should ensure the compatibility of applications with stricter rules for exploit protection.

1 Comment
  1. Avatar
    Bo Geitz (Rank 2) 1 year ago

    Thanks for using Get-WinEvent instead of Get-EventLog. 👍

Leave a reply

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account