Last Updated on December 2, 2021 by rudyooms

This blog is the fifth part of the Endpoint Security Series and will be about Microsoft Defender Exploit Protection.

Just like always, I need to divide this blog into multiple parts, so we can get a good understanding of what Exploit Protection is and how it works or doesn’t work

1. Information about Exploit Protection
2. First Look at Exploit Protection
3. Deploy it with a Security Baseline?
4. Configure EP in Intune
5. Checking the configuration
6. Event Logging
7. Testing it!
8. Removing EP!
9. KB5005565 and KB5005101 Issues
10. Conclusion

1. Information about Exploit Protection

Exploit protection is a successor of EMET (Enhanced Mitigation Experience Toolkit).EMET support was “killed” on 31 July 2018.

Luckily when EMET was killed, Exploit Protection was already born with the release of Windows version 1709. Just like with EMET, with Exploit Protection you can be sure your devices are protected against malware by enabling attack mitigations.

Some examples of attack mitigations exploit protection uses are, Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP). SEHOP will make sure in case of an existing buffer overflow vulnerability in the application it will try to stop the attacker.

Luckily it’s configured by default in Windows 10 but still, you can still configure or add some mitigations techniques to make sure some apps and your operating system will be protected. Exploit Protection also allows you to block certain applications from creating child processes or executing Win32k system calls.

When you are adding mitigations please make sure you configure them to Audit first.

2.    First look at Exploit Protection

Before I am going to show, how you could implement or configure Exploit Protection with Intune let’s have a look at the settings in the Windows Security Settings Page.

1.System Settings

Now we have opened the Exploit Protection Settings, we are going to take a look at the system settings first. Within the system settings, you can configure different mitigations. It’s important to understand that when an App isn’t individually configured in the program settings it will use the settings configured in the System settings page.

When looking at the default settings, all settings are turned on by default except Force randomization for images (Mandatory ASLR)

Some explanation about the three possibilities, because “use default (on)” doesn’t mean the same as “On by default”

*Use Default (on) –> Application Opt-in

*On by default –> Always on!! Could be safer, but your device could end up in a BSOD

*Off by default –> I guess I don’t have to explain this one

Both options include the words  “on,” and “default”  but if you don’t select “On by default,” you could end up without the protection you thought you had. But again it could break your OS

When we are taking another look at the system settings picture I showed you earlier, you could also create a baseline policy on a specific test device and export the settings from this device to use them on other devices.

Let’s go on to the Program settings Page

2.Program Settings

In the Program settings, you can add individual mitigation settings for each app. These settings will be honoured above the settings that are configured on the system settings page.

For example: block creation of child processes

There is also a cool Matrix available to understand when its enabled and when it’s not.

3. Deploy it with a Security Baseline?

Maybe you were excepting this security feature was a part of the Microsoft Defender for Endpoint baseline, but I have to put you out of that dream.

It’s missing Exploit protection, as it was removed in the MDM security Baseline in December 2020.

Intune security baselines settings for Windows 10 MDM – Microsoft Intune | Microsoft Docs

The main reason could be, that it’s really hard to specify these type of mitigations that apply to everyone. It could do more harm than good! So again my advice, when you want to configure additional settings please Audit first.

4. Configure EP in Intune

Now we know, we can’t use a Intune Security Baseline we are going to take a look on how we can still configure it. We have got 2 options.

Option 1. Device configuration Template –> Endpoint Protection

Option 2. Endpoint Security –> Attack Surface Reduction –> Exploit Protection (Preferred)

Both of them need an XML (I used this one from the defender ATP test ground

https://demo.wd.microsoft.com/Content/ProcessMitigation.xml

After the policy arrives at the device, you will notice you can’t change anything because you blocked the possibility to edit it.

5. Checking the configuration

When we have configured the XML in Intune and it’s deployed to your test device and we have seen we can’t do anything with it in the security settings, we need to take a closer look at all the settings.  The easiest way is just to open PowerShell and launch this command: get-processmitigation It will show you all the configured settings available

You will notice there are some settings that are configured as NOTSET. What does this mean?

You have seen it in the Windows Security Settings Page there are Program Mitigations and System Mitigations, let’s take a closer look at those two.

1.      Program Mitigations

Program/Application Mitigations are configured via a registry entry for each program that you configure protections for. These settings are stored in the MitigationOptions registry entry for each program.

(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion \Image File Execution Options\ImageFileName\ MitigationOptions).

When you are adding an app with mitigations, the mitigations will only take effect when you restart the program and/but will remain effective until you change them and restart the program again.

If you configure exploit protection mitigations using an XML configuration file, as I did with Intune (You can also do this with PowerShell or the GPO), all of the individual registry settings, as shown above, will be configured for you.

2.      System mitigations

Just like with program mitigation there are also system mitigations. One example of a system mitigations you could deploy is to block untrusted fonts. As shown earlier you could also change this by a GPO setting.

When you configured this setting the mitigation options registry key will be created in the registry for you.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\

And to top it off with PowerShell: set-processmitigation -system

Each system mitigation option has its own unique hexadecimal value, when you enable DEP and bottumup this will be ADDED to the mitigationoptions key:

hex: 01,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

But if you choose to only disable dep, the first 01, will be changed to 02 (disabled) and other 01 responsible for bottumup will still be configured

hex: 02,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

This picture below lists all the policies and how to configure them with a registry key.

But beware, configuring to many settings in the past could gave you a BSOD.

When you have a nice BSOD, just delete the mitigation option key mentioned earlier from the registry.

6. Event Logging

It’s always good to know you could use the event log to troubleshoot Exploit Protection settings. But where to look? You will find all the events in the Security-Mitigations (of course…) event log

There are a huge of events that can occur, I am not going to show you all of these but if you want to know all types of events that can occur please visit this page:

exploitguard/README.md at master · palantir/exploitguard · GitHub

7. Testing It!

Of course, now we have seen what exploit protection is and how to configure, deploy and troubleshoot it, you will need to know how you could test your setup. I really hoped there was a simple method to test exploit protection just like with controlled folder access but the Microsoft Defender Test ground isn’t giving us any examples to test with.

Exploit Protection – Microsoft Defender Testground

It only shows us 2 scenarios, but not a method to start some tests…

UPDATE 15-07-2021:

If you want to test exploit protection and how it works, just add onedrive.exe to exploit protection and enable all program settings!

Like mentioned earlier, just close Onedrive.exe and try to reopen it. It will be blocked, that is for sure!

All the security mitigations block events will also be visible in the event log.

8. Removing EP!

Like told earlier… exploit protection is removed from the baseline because each company has their own needs and their own settings needed.

So If you end up with problems with applications like excel or other third-party apps you could disable exploit protection. But beware you can’t just disable the Intune policy, you will need to make sure you deploy the XML (provided by Microsoft as part of the windows security baselines) to reset the exploit protection settings.

9. KB5005565 and KB5005101 Issues

Please beware when using Exploit Protection and Export Address Filtering (EAF) you could end up with some issues after the last September updates.

Luckily Microsoft has already rolled out a fix using the Known Issue Rollback (KIR) feature, it will be distributed to your personal Windows 10 devices using Windows Update. But waiting is not always fun or nice when all of your users start complaining. When you want to fix it now, the only thing you will need to do is adding a registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 2767781516 /t REG_DWORD /d 0 /f

Or if you are more into Proactive Remediations… No problem!

Detection Script

$regPath = "HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides"
$regName = "2767781516"
$regValue = 0

try {
    $registry = Get-ItemProperty -Path $regPath -Name $regName -ErrorAction Stop | Select-Object -ExpandProperty $regName
    if ($registry -eq $regValue){
        Write-Output "Problem already fixed"
        exit 0
    }
    else { 
        Write-Warning "Problem still exists"
        exit 1
    }
} 
catch {
    Write-Output "Problem still exist the $regName does not exist"
    exit 1
}

Remediation Script

$regPath = "HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides"
$regName = "2767781516"
$regType = "DWORD"
$regValue = 0

try {
    New-Item -Path $regPath -Force
    New-ItemProperty -Path $regPath -Name $regName -Type $regType -Value $regValue -Force -ErrorAction Stop
}
catch {
    Write-Output "Failed to change the $regName to $regValue"
}

UPDATE 12-10-2021

Luckily Microsoft was aware of these kinds of problems and when installing this nice new Patch KB5006670 it should all be resolved

Conclusion

As part of the Endpoint Security Protection in Intune, I  guess I needed to write a blog about it. It was fun doing so, but in my opinion… the default options are pretty solid…I am wondering why they need adjustment?

Please make sure when you are implementing Exploit protection, make sure you test it first… Because you don’t want to end up in a situation where Onedrive can’t be opened anymore!

If you want to read more parts of the Endpoint Security Series:

Endpoint Security Series – Call4Cloud 

*The fourth part about WDAC/MDAC

MDAC or (the Unexpected Virtue of Ignorance) – Call4Cloud