Exploit protection is a new security feature of Windows Defender that Microsoft introduced in the operating system's Fall Creators Update.
Exploit protection can best be described as an integrated version of Microsoft's EMET -- Exploit Mitigation Experience Toolkit -- security tool which the company will retire in mid 2018.
Microsoft claimed previously that the company's Windows 10 operating system would make running EMET alongside Windows unnecessary; at least one researcher refuted Microsoft's claim however.
Exploit protection is enabled by default if Windows Defender is enabled. The feature is the only Exploit Guard feature that does not require that real-time protection is enabled in Windows Defender.
The feature can be configured in the Windows Defender Security Center application, via PowerShell commands, or as policies.
You may configure exploit protection in the Windows Defender Security Center application.
The settings are divided into System Settings and Program Settings.
System settings list the available protection mechanisms and their status. The following are available in the Windows 10 Fall Creators Update:
You can change the status of any option to "on by default", "off by default", or "use default".
Program settings give you options to customize the protection for individual programs and applications. This works similarly to how you could add exceptions in Microsoft EMET for particular programs; good if a program misbehaves when certain protective modules are enabled.
Quite a few programs have exceptions by default. This includes svchost.exe, spools.exe, runtimebroker.exe, iexplore.exe and other core Windows programs. Note that you can override these exceptions by selecting the files and clicking on edit.
Click on "add program to customize" to add a program by name or exact file path to the list of exceptions.
You may set the status of all supported protections individually for each program that you have added under program settings. Besides overriding the system default, and forcing it to one or off, there is also an option to set it to "audit only". The latter records events that would have fired if the protection's status would have been on, but will record only the event to the Windows events log.
Program Settings list additional protection options that you cannot configure under system settings because they are configured to run on the application level only.
You may use PowerShell to set, remove or list mitigations. The following commands are available:
To list all mitigations of the specified process: Get-ProcessMitigation -Name processName.exe
To set mitigations: Set-ProcessMitigation -<scope> <app executable> -<action> <mitigation or options>,<mitigation or options>,<mitigation or options>
|Mitigation||Applies to||PowerShell cmdlets||Audit mode cmdlet|
|Control flow guard (CFG)||System and app-level||CFG, StrictCFG, SuppressExports||Audit not available|
|Data Execution Prevention (DEP)||System and app-level||DEP, EmulateAtlThunks||Audit not available|
|Force randomization for images (Mandatory ASLR)||System and app-level||ForceRelocate||Audit not available|
|Randomize memory allocations (Bottom-Up ASLR)||System and app-level||BottomUp, HighEntropy||Audit not available|
|Validate exception chains (SEHOP)||System and app-level||SEHOP, SEHOPTelemetry||Audit not available|
|Validate heap integrity||System and app-level||TerminateOnHeapError||Audit not available|
|Arbitrary code guard (ACG)||App-level only||DynamicCode||AuditDynamicCode|
|Block low integrity images||App-level only||BlockLowLabel||AuditImageLoad|
|Block remote images||App-level only||BlockRemoteImages||Audit not available|
|Block untrusted fonts||App-level only||DisableNonSystemFonts||AuditFont, FontAuditOnly|
|Code integrity guard||App-level only||BlockNonMicrosoftSigned, AllowStoreSigned||AuditMicrosoftSigned, AuditStoreSigned|
|Disable extension points||App-level only||ExtensionPoint||Audit not available|
|Disable Win32k system calls||App-level only||DisableWin32kSystemCalls||AuditSystemCall|
|Do not allow child processes||App-level only||DisallowChildProcessCreation||AuditChildProcess|
|Export address filtering (EAF)||App-level only||EnableExportAddressFilterPlus, EnableExportAddressFilter ||Audit not available|
|Import address filtering (IAF)||App-level only||EnableImportAddressFilter||Audit not available|
|Simulate execution (SimExec)||App-level only||EnableRopSimExec||Audit not available|
|Validate API invocation (CallerCheck)||App-level only||EnableRopCallerCheck||Audit not available|
|Validate handle usage||App-level only||StrictHandle||Audit not available|
|Validate image dependency integrity||App-level only||EnforceModuleDepencySigning||Audit not available|
|Validate stack integrity (StackPivot)||App-level only||EnableRopStackPivot||Audit not available|
Configurations can be imported and exported. You can do so using the Windows Defender exploit protection settings in the Windows Defender Security Center, by using PowerShell, by using policies.
EMET configurations can furthermore be converted so that they can be imported.
You can export configurations in the settings application, but not import them. Exporting adds all system level and app level mitigations.
Just click on the "export settings" link under exploit protection to do so.
Edit filename.xml so that it reflects the save location and filename.
Edit filename.xml so that it points to the location and file name of the configuration XML file.
You can install configuration files using policies.
Change emetFile.xml to the path and location of the EMET configuration file.
Change filename.xml to the path and location that you want the converted configuration file to be saved to.
If you like our content, and would like to help, please consider making a contribution: