- SystoLOCK in review: Logging in to Active Directory with multi-factor authentication without passwords - Tue, Dec 5 2023
- New Group Policy settings in Windows 11 23H2 - Mon, Nov 20 2023
- Windows Server 2025 will support SMB over QUIC in all editions - Fri, Nov 17 2023
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.
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.
However, PowerShell is better suited for targeted queries. The system-wide standards for exploit protection can be displayed like this:
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
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.
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.
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.