mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-22 05:43:41 +00:00
Merge branch 'master' into security-acrolinx-updates
This commit is contained in:
Beth Levin
@ -857,12 +857,12 @@
|
||||
},
|
||||
{
|
||||
"source_path": "windows/threat-protection/windows-defender-exploit-guard/emet-exploit-protection-exploit-guard.md",
|
||||
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/emet-exploit-protection",
|
||||
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/exploit-protection",
|
||||
"redirect_document_id": true
|
||||
},
|
||||
{
|
||||
"source_path": "windows/security/threat-protection/microsoft-defender-atp/emet-exploit-protection.md",
|
||||
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/exploit-protection-exploit-guard",
|
||||
"redirect_url": "https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/exploit-protection",
|
||||
"redirect_document_id": true
|
||||
},
|
||||
{
|
||||
|
||||
@ -145,8 +145,8 @@ To set up a test account through Windows Configuration Designer, follow these st
|
||||
- username@tenant.com
|
||||
|
||||
4. Under **Runtime settings**, go to **TakeATest** and configure the following settings:
|
||||
1. In **LaunchURI**, enter the assessment URL.
|
||||
2. In **TesterAccount**, enter the test account you entered in step 3.
|
||||
- In **LaunchURI**, enter the assessment URL.
|
||||
- In **TesterAccount**, enter the test account you entered in step 3.
|
||||
|
||||
3. Follow the steps to [build a package](https://technet.microsoft.com/itpro/windows/configure/provisioning-create-package#build-package).
|
||||
|
||||
@ -166,9 +166,9 @@ This sample PowerShell script configures the tester account and the assessment U
|
||||
- Use your tester account for **-UserName**
|
||||
|
||||
>[!NOTE]
|
||||
>The account that you specify for the tester account must already exist on the device.
|
||||
>The account that you specify for the tester account must already exist on the device. For steps to create the tester account, see [Set up a dedicated test account](https://docs.microsoft.com/education/windows/take-a-test-single-pc#set-up-a-dedicated-test-account).
|
||||
|
||||
```
|
||||
```powershell
|
||||
$obj = get-wmiobject -namespace root/cimv2/mdm/dmmap -class MDM_SecureAssessment -filter "InstanceID='SecureAssessment' AND ParentID='./Vendor/MSFT'";
|
||||
$obj.LaunchURI='https://www.foo.com';
|
||||
$obj.TesterAccount='TestAccount';
|
||||
@ -232,7 +232,7 @@ One of the ways you can present content in a locked down manner is by embedding
|
||||
|
||||
1. Embed a link or create a desktop shortcut with:
|
||||
|
||||
```
|
||||
```http
|
||||
ms-edu-secureassessment:<URL>#enforceLockdown
|
||||
```
|
||||
|
||||
|
||||
@ -17,6 +17,23 @@ ms.date: 10/17/2017
|
||||
|
||||
# Add unsigned app to code integrity policy
|
||||
|
||||
> [!IMPORTANT]
|
||||
> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) will be available for consumption starting mid-September 2020, and you will have until the end of December 2020 to transition to DGSS v2. At the end of December 2020, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service between September and December 2020.
|
||||
>
|
||||
> Following are the major changes we are making to the service:
|
||||
> - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets will be available as a NuGet download.
|
||||
> - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it).
|
||||
> - DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download). Note that the certificate used to sign a file can be easily extracted from the signed file itself. As a result, after DGSS v1 is retired at the end of December 2020, you will no longer be able to download the leaf certificates used to sign your files.
|
||||
>
|
||||
> The following functionality will be available via these PowerShell cmdlets:
|
||||
> - Get a CI policy
|
||||
> - Sign a CI policy
|
||||
> - Sign a catalog
|
||||
> - Download root cert
|
||||
> - Download history of your signing operations
|
||||
>
|
||||
> We will share detailed instructions and NuGet location before mid-September 2020. For any questions, please contact us at DGSSMigration@microsoft.com for more information on migration.
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
|
||||
@ -17,6 +17,23 @@ ms.date: 10/17/2017
|
||||
|
||||
# Device Guard signing
|
||||
|
||||
> [!IMPORTANT]
|
||||
> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) will be available for consumption starting mid-September 2020, and you will have until the end of December 2020 to transition to DGSS v2. At the end of December 2020, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service between September and December 2020.
|
||||
>
|
||||
> Following are the major changes we are making to the service:
|
||||
> - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets will be available as a NuGet download.
|
||||
> - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it).
|
||||
> - DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download). Note that the certificate used to sign a file can be easily extracted from the signed file itself. As a result, after DGSS v1 is retired at the end of December 2020, you will no longer be able to download the leaf certificates used to sign your files.
|
||||
>
|
||||
> The following functionality will be available via these PowerShell cmdlets:
|
||||
> - Get a CI policy
|
||||
> - Sign a CI policy
|
||||
> - Sign a catalog
|
||||
> - Download root cert
|
||||
> - Download history of your signing operations
|
||||
>
|
||||
> We will share detailed instructions and NuGet location before mid-September 2020. For any questions, please contact us at DGSSMigration@microsoft.com for more information on migration.
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
|
||||
@ -17,6 +17,24 @@ ms.date: 10/17/2017
|
||||
|
||||
# Sign code integrity policy with Device Guard signing
|
||||
|
||||
> [!IMPORTANT]
|
||||
> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) will be available for consumption starting mid-September 2020, and you will have until the end of December 2020 to transition to DGSS v2. At the end of December 2020, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service between September and December 2020.
|
||||
>
|
||||
> Following are the major changes we are making to the service:
|
||||
> - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets will be available as a NuGet download.
|
||||
> - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it).
|
||||
> - DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download). Note that the certificate used to sign a file can be easily extracted from the signed file itself. As a result, after DGSS v1 is retired at the end of December 2020, you will no longer be able to download the leaf certificates used to sign your files.
|
||||
>
|
||||
> The following functionality will be available via these PowerShell cmdlets:
|
||||
> - Get a CI policy
|
||||
> - Sign a CI policy
|
||||
> - Sign a catalog
|
||||
> - Download root cert
|
||||
> - Download history of your signing operations
|
||||
>
|
||||
> We will share detailed instructions and NuGet location before mid-September 2020. For any questions, please contact us at DGSSMigration@microsoft.com for more information on migration.
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
@ -27,7 +27,7 @@ The following features and functionalities have been removed from the installed
|
||||
|
||||
|Feature | Details and mitigation | Removed in version |
|
||||
| ----------- | --------------------- | ------ |
|
||||
| Connect app | The [Connect app](https://docs.microsoft.com/windows-hardware/design/device-experiences/wireless-projection-understanding) for wireless projection using Miracast is no longer installed by default, but is available as an optional feature. To install the app, click on **Settings** > **Apps** > **Optional features** > **Add a feature** and then install the **Wireless Display** app. | 2004 |
|
||||
| Connect app | The **Connect** app for wireless projection using Miracast is no longer installed by default, but is available as an optional feature. To install the app, click on **Settings** > **Apps** > **Optional features** > **Add a feature** and then install the **Wireless Display** app. | 2004 |
|
||||
| Rinna and Japanese Address suggestion | The Rinna and Japanese Address suggestion service for Microsoft Japanese Input Method Editor (IME) ended on August 13th, 2020. For more information, see [Rinna and Japanese Address suggestion will no longer be offered](https://support.microsoft.com/help/4576767/windows-10-rinna-and-japanese-address-suggestion) | 2004 |
|
||||
| Cortana | Cortana has been updated and enhanced in the Windows 10 May 2020 Update. With [these changes](https://docs.microsoft.com/windows/whats-new/whats-new-windows-10-version-2004#cortana), some previously available consumer skills such as music, connected home, and other non-Microsoft skills are no longer available. | 2004 |
|
||||
| Windows To Go | Windows To Go was announced as deprecated in Windows 10, version 1903 and is removed in this release. | 2004 |
|
||||
|
||||
@ -49,7 +49,7 @@ To enable KMS functionality, a KMS key is installed on a KMS host; then, the hos
|
||||
|
||||
To activate , use the slmgr.vbs command. Open an elevated command prompt and run one of the following commands:
|
||||
- To install the KMS key, type `slmgr.vbs /ipk <KmsKey>`.
|
||||
- To activate online, type `slmgr.vbs/ato`.
|
||||
- To activate online, type `slmgr.vbs /ato`.
|
||||
- To activate by telephone , follow these steps:
|
||||
1. Run `slmgr.vbs /dti` and confirm the installation ID.
|
||||
2. Call [Microsoft Licensing Activation Centers worldwide telephone numbers](https://www.microsoft.com/licensing/existing-customer/activation-centers) and follow the voice prompts to enter the installation ID that you obtained in step 1 on your telephone.
|
||||
|
||||
@ -40,7 +40,7 @@ Transparency is an important part of the data collection process in Windows 10.
|
||||
|
||||
### 1.1 Device set up experience and support for layered transparency
|
||||
|
||||
When setting up a device, a user can configure their privacy settings. Those privacy settings are key in determining the amount of personal data collected. For each privacy setting, the user is provided information about the setting along with the links to supporting information. This information explains what data is collected, how the data is used, and how to manage the setting after the device setup is complete. When connected to the network during this portion of setup, the user can also review the privacy statement. A brief overview of the set up experience for privacy settings is described in [this blog](https://blogs.windows.com/windowsexperience/2018/03/06/windows-insiders-get-first-look-new-privacy-screen-settings-layout-coming-windows-10/#uCC2bKYP8M5BqrDP.97).
|
||||
When setting up a device, a user can configure their privacy settings. Those privacy settings are key in determining the amount of personal data collected. For each privacy setting, the user is provided information about the setting along with the links to supporting information. This information explains what data is collected, how the data is used, and how to manage the setting after the device setup is complete. When connected to the network during this portion of setup, the user can also review the privacy statement. A brief overview of the set up experience for privacy settings is described in [Windows Insiders get first look at new privacy screen settings layout coming to Windows 10](https://blogs.windows.com/windowsexperience/2018/03/06/windows-insiders-get-first-look-new-privacy-screen-settings-layout-coming-windows-10/#uCC2bKYP8M5BqrDP.97), a blog entry on Windows Blogs.
|
||||
|
||||
The following table provides an overview of the Windows 10 privacy settings presented during the device setup experience that involve processing personal data and where to find additional information.
|
||||
|
||||
@ -168,7 +168,7 @@ If a user signs in to a Windows experience or app on their device with their Mic
|
||||
|
||||
## 4. Cross-border data transfers
|
||||
|
||||
Microsoft complies with the EU-U.S. Privacy Shield Framework and Swiss-U.S. Privacy Shield Framework as set forth by the U.S. Department of Commerce regarding the collection, use, and retention of personal information transferred from the European Union, the United Kingdom, and Switzerland to the United States.
|
||||
Microsoft complies with applicable law regarding the collection, use, and retention of personal information, including its transfer across borders
|
||||
|
||||
Microsoft’s [Privacy Statement](https://privacy.microsoft.com/privacystatement#mainwherewestoreandprocessdatamodule) provides details on how we store and process personal data.
|
||||
|
||||
|
||||
@ -93,6 +93,8 @@ The following methodology was used to derive the network endpoints:
|
||||
|www.bing.com|HTTPS/TLS v1.2|Cortana and Live Tiles
|
||||
|www.msftconnecttest.com|HTTP|Network Connection Status Indicator (NCSI)
|
||||
|wdcp.microsoft.com|HTTPS|Used for Windows Defender when Cloud-based Protection is enabled
|
||||
|activity.windows.com|TLSV1.2|Used by Activity Feed Service which enables multiple cross-device data roaming scenarios on Windows
|
||||
|adl.windows.com|HTTP|Used for compatibility database updates for Windows
|
||||
|
||||
## Windows 10 Pro
|
||||
|
||||
@ -155,6 +157,8 @@ The following methodology was used to derive the network endpoints:
|
||||
|storage.live.com|HTTP/TLS v1.2|OneDrive
|
||||
|skydrivesync.policies.live.net|TLS v1.2|OneDrive
|
||||
|windows.policies.live.net|HTTP|OneDrive
|
||||
|activity.windows.com|TLSV1.2|Used by Activity Feed Service which enables multiple cross-device data roaming scenarios on Windows
|
||||
|adl.windows.com|HTTP|Used for compatibility database updates for Windows
|
||||
|
||||
## Windows 10 Education
|
||||
|
||||
@ -203,3 +207,4 @@ The following methodology was used to derive the network endpoints:
|
||||
|outlook.office365.com|HTTP|Microsoft Office
|
||||
|www.bing.com|TLS v1.2|Used for updates for Cortana, apps, and Live Tiles
|
||||
|www.msftconnecttest.com|HTTP|Network Connection (NCSI)
|
||||
|adl.windows.com|HTTP|Used for compatibility database updates for Windows
|
||||
|
||||
@ -86,7 +86,7 @@
|
||||
##### [Enable exploit protection](microsoft-defender-atp/enable-exploit-protection.md)
|
||||
##### [Customize exploit protection](microsoft-defender-atp/customize-exploit-protection.md)
|
||||
##### [Import, export, and deploy exploit protection configurations](microsoft-defender-atp/import-export-exploit-protection-emet-xml.md)
|
||||
|
||||
##### [Exploit protection reference](microsoft-defender-atp/exploit-protection-reference.md )
|
||||
|
||||
#### [Network protection]()
|
||||
##### [Protect your network](microsoft-defender-atp/network-protection.md)
|
||||
|
||||
@ -20,7 +20,7 @@ ms.custom: nextgen
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- [Windows Defender Advanced Threat Protection (Windows Defender ATP)](https://go.microsoft.com/fwlink/p/?linkid=2069559)
|
||||
- [Microsoft Defender Advanced Threat Protection (Windows Defender ATP)](https://go.microsoft.com/fwlink/p/?linkid=2069559)
|
||||
|
||||
## Microsoft Defender Antivirus: Your next-generation protection
|
||||
|
||||
|
||||
@ -31,28 +31,30 @@ ms.topic: article
|
||||
|
||||
You can also manually onboard individual devices to Microsoft Defender ATP. You might want to do this first when testing the service before you commit to onboarding all devices in your network.
|
||||
|
||||
> [!NOTE]
|
||||
> The script has been optimized to be used on a limited number of devices (1-10 devices). To deploy to scale, use other deployment options. For more information on using other deployment options, see [Onboard Window 10 devices](configure-endpoints.md).
|
||||
> [!IMPORTANT]
|
||||
> This script has been optimized for use on up to 10 devices.
|
||||
>
|
||||
> To deploy at scale, use [other deployment options](configure-endpoints.md). For example, you can deploy an onboarding script to more than 10 devices in production with the script available in [Onboard Windows 10 devices using Group Policy](configure-endpoints-gp.md).
|
||||
|
||||
## Onboard devices
|
||||
1. Open the GP configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from [Microsoft Defender Security Center](https://securitycenter.windows.com/):
|
||||
|
||||
a. In the navigation pane, select **Settings** > **Onboarding**.
|
||||
1. In the navigation pane, select **Settings** > **Onboarding**.
|
||||
|
||||
b. Select Windows 10 as the operating system.
|
||||
1. Select Windows 10 as the operating system.
|
||||
|
||||
c. In the **Deployment method** field, select **Local Script**.
|
||||
1. In the **Deployment method** field, select **Local Script**.
|
||||
|
||||
d. Click **Download package** and save the .zip file.
|
||||
1. Click **Download package** and save the .zip file.
|
||||
|
||||
|
||||
2. Extract the contents of the configuration package to a location on the device you want to onboard (for example, the Desktop). You should have a file named *WindowsDefenderATPOnboardingScript.cmd*.
|
||||
|
||||
3. Open an elevated command-line prompt on the device and run the script:
|
||||
|
||||
a. Go to **Start** and type **cmd**.
|
||||
1. Go to **Start** and type **cmd**.
|
||||
|
||||
b. Right-click **Command prompt** and select **Run as administrator**.
|
||||
1. Right-click **Command prompt** and select **Run as administrator**.
|
||||
|
||||
|
||||
|
||||
@ -73,7 +75,7 @@ You can manually configure the sample sharing setting on the device by using *re
|
||||
|
||||
The configuration is set through the following registry key entry:
|
||||
|
||||
```
|
||||
```console
|
||||
Path: “HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection”
|
||||
Name: "AllowSampleCollection"
|
||||
Value: 0 or 1
|
||||
@ -95,21 +97,21 @@ For security reasons, the package used to Offboard devices will expire 30 days a
|
||||
|
||||
1. Get the offboarding package from [Microsoft Defender Security Center](https://securitycenter.windows.com/):
|
||||
|
||||
a. In the navigation pane, select **Settings** > **Offboarding**.
|
||||
1. In the navigation pane, select **Settings** > **Offboarding**.
|
||||
|
||||
b. Select Windows 10 as the operating system.
|
||||
1. Select Windows 10 as the operating system.
|
||||
|
||||
c. In the **Deployment method** field, select **Local Script**.
|
||||
1. In the **Deployment method** field, select **Local Script**.
|
||||
|
||||
d. Click **Download package** and save the .zip file.
|
||||
1. Click **Download package** and save the .zip file.
|
||||
|
||||
2. Extract the contents of the .zip file to a shared, read-only location that can be accessed by the devices. You should have a file named *WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd*.
|
||||
|
||||
3. Open an elevated command-line prompt on the device and run the script:
|
||||
|
||||
a. Go to **Start** and type **cmd**.
|
||||
1. Go to **Start** and type **cmd**.
|
||||
|
||||
b. Right-click **Command prompt** and select **Run as administrator**.
|
||||
1. Right-click **Command prompt** and select **Run as administrator**.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -252,7 +252,6 @@ For more information about customizing the notification when a rule is triggered
|
||||
## See also
|
||||
|
||||
* [Protect devices from exploits](exploit-protection.md)
|
||||
* [Comparison with Enhanced Mitigation Experience Toolkit](emet-exploit-protection.md)
|
||||
* [Evaluate exploit protection](evaluate-exploit-protection.md)
|
||||
* [Enable exploit protection](enable-exploit-protection.md)
|
||||
* [Import, export, and deploy exploit protection configurations](import-export-exploit-protection-emet-xml.md)
|
||||
|
||||
@ -242,7 +242,6 @@ See the [Windows Security](../windows-defender-security-center/windows-defender-
|
||||
|
||||
## Related topics
|
||||
|
||||
* [Comparison with Enhanced Mitigation Experience Toolkit](emet-exploit-protection.md)
|
||||
* [Evaluate exploit protection](evaluate-exploit-protection.md)
|
||||
* [Configure and audit exploit protection mitigations](customize-exploit-protection.md)
|
||||
* [Import, export, and deploy exploit protection configurations](import-export-exploit-protection-emet-xml.md)
|
||||
|
||||
@ -11,7 +11,7 @@ ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
author: denisebmsft
|
||||
ms.author: deniseb
|
||||
ms.date: 10/21/2019
|
||||
ms.date: 08/28/2020
|
||||
ms.reviewer:
|
||||
manager: dansimp
|
||||
---
|
||||
@ -22,7 +22,7 @@ manager: dansimp
|
||||
|
||||
* [Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP)](https://go.microsoft.com/fwlink/p/?linkid=2069559)
|
||||
|
||||
[Exploit protection](exploit-protection.md) helps protect devices from malware that uses exploits to spread and infect other devices. Mitigation can be applied to either the operating system or to an individual app. Many of the features that were part of the [Enhanced Mitigation Experience Toolkit (EMET)](emet-exploit-protection.md) are included in exploit protection.
|
||||
[Exploit protection](exploit-protection.md) helps protect devices from malware that uses exploits to spread and infect other devices. Mitigation can be applied to either the operating system or to an individual app. Many of the features that were part of the Enhanced Mitigation Experience Toolkit (EMET) are included in exploit protection. (The EMET has reached its end of support.)
|
||||
|
||||
This article helps you enable exploit protection in audit mode and review related events in Event Viewer. You can enable audit mode to see how mitigation works for certain apps in a test environment. By auditing exploit protection, you can see what *would* have happened if you had enabled exploit protection in your production environment. This way, you can help ensure exploit protection doesn't adversely affect your line-of-business apps, and you can see which suspicious or malicious events occur.
|
||||
|
||||
@ -72,12 +72,12 @@ Where:
|
||||
|
||||
|Mitigation | Audit mode cmdlet |
|
||||
|---|---|
|
||||
|Arbitrary code guard (ACG) | AuditDynamicCode |
|
||||
|Block low integrity images | AuditImageLoad
|
||||
|Block untrusted fonts | AuditFont, FontAuditOnly |
|
||||
|Code integrity guard | AuditMicrosoftSigned, AuditStoreSigned |
|
||||
|Disable Win32k system calls | AuditSystemCall |
|
||||
|Do not allow child processes | AuditChildProcess |
|
||||
|Arbitrary code guard (ACG) | `AuditDynamicCode` |
|
||||
|Block low integrity images | `AuditImageLoad`
|
||||
|Block untrusted fonts | `AuditFont`, `FontAuditOnly` |
|
||||
|Code integrity guard | `AuditMicrosoftSigned`, `AuditStoreSigned` |
|
||||
|Disable Win32k system calls | `AuditSystemCall` |
|
||||
|Do not allow child processes | `AuditChildProcess` |
|
||||
|
||||
For example, to enable Arbitrary Code Guard (ACG) in audit mode for an app named *testing.exe*, run the following command:
|
||||
|
||||
@ -100,13 +100,9 @@ To review which apps would have been blocked, open Event Viewer and filter for t
|
||||
|Exploit protection | Security-Mitigations (Kernel Mode/User Mode) | 9 | Disable win32k system calls audit |
|
||||
|Exploit protection | Security-Mitigations (Kernel Mode/User Mode) | 11 | Code integrity guard audit |
|
||||
|
||||
## Related topics
|
||||
## See also
|
||||
|
||||
* [Comparison with Enhanced Mitigation Experience Toolkit](emet-exploit-protection.md)
|
||||
* [Enable exploit protection](enable-exploit-protection.md)
|
||||
* [Configure and audit exploit protection mitigations](customize-exploit-protection.md)
|
||||
* [Import, export, and deploy exploit protection configurations](import-export-exploit-protection-emet-xml.md)
|
||||
* [Troubleshoot exploit protection](troubleshoot-exploit-protection-mitigations.md)
|
||||
* [Enable network protection](enable-network-protection.md)
|
||||
* [Enable controlled folder access](enable-controlled-folders.md)
|
||||
* [Enable attack surface reduction](enable-attack-surface-reduction.md)
|
||||
- [Enable exploit protection](enable-exploit-protection.md)
|
||||
- [Configure and audit exploit protection mitigations](customize-exploit-protection.md)
|
||||
- [Import, export, and deploy exploit protection configurations](import-export-exploit-protection-emet-xml.md)
|
||||
- [Troubleshoot exploit protection](troubleshoot-exploit-protection-mitigations.md)
|
||||
|
||||
@ -0,0 +1,717 @@
|
||||
---
|
||||
title: Exploit Protection Reference
|
||||
keywords: mitigations, vulnerabilities, vulnerability, mitigation, exploit, exploits, emet
|
||||
description: Details on how the Exploit Protection feature works in Windows 10
|
||||
search.product: eADQiWindows 10XVcnh
|
||||
ms.pagetype: security
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: manage
|
||||
ms.sitesec: library
|
||||
ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
author: appcompatguy
|
||||
ms.author: cjacks
|
||||
ms.date: 07/20/2020
|
||||
ms.reviewer:
|
||||
manager: saudm
|
||||
ms.custom: asr
|
||||
---
|
||||
|
||||
# Exploit Protection Reference
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- [Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP)](https://go.microsoft.com/fwlink/p/?linkid=2069559)
|
||||
|
||||
Exploit Protection provides advanced protections for applications which the IT Pro can apply after the developer has compiled and distributed the software.
|
||||
|
||||
This article helps you understand how Exploit Protection works, both at the policy level and at the individual mitigation level, to help you successfully build and apply Exploit Protection policies.
|
||||
|
||||
## How mitigations are applied
|
||||
|
||||
Exploit Protection mitigations are applied per 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**). They take effect when you restart the program and remain effective until you change them and restart the program again.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Image File Execution Options only allows you to specify a file name or path, and not a version number, architecture, or any other differentiator. Be careful to target mitigations to apps which have unique names or paths, applying them only on devices where you have tested that version and that architecture of the application.
|
||||
|
||||
If you configure Exploit Protection mitigations using an XML configuration file, either via PowerShell, Group Policy, or MDM, when processing this XML configuration file, individual registry settings will be configured for you.
|
||||
|
||||
When the policy distributing the XML file is no longer enforced, settings deployed by this XML configuration file will not be automatically removed. To remove Exploit Protection settings, export the XML configuration from a clean Windows 10 device, and deploy this new XML file. Alternately, Microsoft provides an XML file as part of the Windows Security Baselines for resetting Exploit Protection settings.
|
||||
|
||||
To reset Exploit Protection settings using PowerShell, you could use the following command:
|
||||
|
||||
```powershell
|
||||
Set-ProcessMitigation -PolicyFilePath EP-reset.xml
|
||||
```
|
||||
Following is the EP-reset.xml distributed with the Windows Security Baselines:
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<MitigationPolicy>
|
||||
<AppConfig Executable="ONEDRIVE.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR OverrideRelocateImages="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
<ImageLoad OverrideBlockRemoteImages="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="firefox.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="fltldr.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
<ImageLoad OverrideBlockRemoteImages="false" />
|
||||
<ChildProcess OverrideChildProcess="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="GROOVE.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
<ImageLoad OverrideBlockRemoteImages="false" />
|
||||
<ChildProcess OverrideChildProcess="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="Acrobat.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="AcroRd32.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="chrome.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="EXCEL.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="iexplore.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="INFOPATH.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="java.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="javaw.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="javaws.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="LYNC.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="MSACCESS.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="MSPUB.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="OIS.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="OUTLOOK.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="plugin-container.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="POWERPNT.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="PPTVIEW.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="VISIO.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="VPREVIEW.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="WINWORD.EXE">
|
||||
<DEP OverrideDEP="false" />
|
||||
<ASLR ForceRelocateImages="true" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="wmplayer.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
<AppConfig Executable="wordpad.exe">
|
||||
<DEP OverrideDEP="false" />
|
||||
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
|
||||
</AppConfig>
|
||||
</MitigationPolicy>
|
||||
```
|
||||
|
||||
## Mitigation Reference
|
||||
|
||||
The below sections detail the protections provided by each Exploit Protection mitigation, the compatibility considerations for the mitigation, and the configuration options available.
|
||||
|
||||
## Arbitrary code guard
|
||||
|
||||
### Description
|
||||
|
||||
Arbitrary Code Guard helps protect against a malicious attacker loading the code of their choice into memory through a memory safety vulnerability and being able to execute that code.
|
||||
|
||||
Arbitrary Code Guard protects an application from executing dynamically generated code (code that is not loaded, for example, from the exe itself or a dll). Arbitrary Code Guard works by preventing memory from being marked as executable. When an application attempts to [allocate memory](https://docs.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc), we check the protection flags. (Memory can be allocated with read, write, and/or execute protection flags.) If the allocation attempts to include the [*execute*](https://docs.microsoft.com/windows/win32/memory/memory-protection-constants) protection flag, then the memory allocation fails and returns an error code (STATUS_DYNAMIC_CODE_BLOCKED). Similarly, if an application attempts to [change the protection flags of memory](https://docs.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect) that has already been allocated and includes the [*execute*](https://docs.microsoft.com/windows/win32/memory/memory-protection-constants) protection flag, then the permission change fails and returns an error code (STATUS_DYNAMIC_CODE_BLOCKED).
|
||||
|
||||
By preventing the *execute* flag from being set, the Data Execution Prevention feature of Windows 10 can then protect against the instruction pointer being set to that memory and running that code.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Arbitrary Code Guard prevents allocating any memory as executable, which presents a compatibility issue with approaches such as Just-in-Time (JIT) compilers. Most modern browsers, for example, will compile JavaScript into native code in order to optimize performance. In order to support this mitigation, they will need to be rearchitected to move the JIT compilation outside of the protected process. Other applications whose design dynamically generates code from scripts or other intermediate languages will be similarly incompatible with this mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Allow thread opt-out** - You can configure the mitigation to allow an individual thread to opt-out of this protection. The developer must have written the application with awareness of this mitigation, and have called the [**SetThreadInformation**](https://docs.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadinformation) API with the *ThreadInformation* parameter set to **ThreadDynamicCodePolicy** in order to be allowed to execute dynamic code on this thread.
|
||||
|
||||
**Audit only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Block low integrity images
|
||||
|
||||
### Description
|
||||
|
||||
Block low integrity images prevents the application from loading files which are untrusted, typically because they have been downloaded from the internet from a sandboxed browser.
|
||||
|
||||
This mitigation will block image loads if the image has an Access Control Entry (ACE) which grants access to Low IL processes and which does not have a trust label ACE. It is implemented by the memory manager, which blocks the file from being mapped into memory. If an application attempts to map a low integrity image, it will trigger a STATUS_ACCESS_DENIED error. For details on how integrity levels work, see [Mandatory Integrity Control](https://docs.microsoft.com/windows/win32/secauthz/mandatory-integrity-control).
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Block low integrity images will prevent the application from loading files which were downloaded from the internet. If your application workflow requires loading images which are downloaded, you will want to ensure that they are downloaded from a higher-trust process, or are explicitly relabeled in order to apply this mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Block remote images
|
||||
|
||||
### Description
|
||||
|
||||
Block remote images will prevent the application from loading files which are hosted on a remote device, such as a UNC share. This helps protect against loading binaries into memory which are on an external device controlled by the attacker.
|
||||
|
||||
This mitigation will block image loads if the image is determined to be on a remote device. It is implemented by the memory manager, which blocks the file from being mapped into memory. If an application attempts to map a remote file, it will trigger a STATUS_ACCESS_DENIED error.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Block remote images will prevent the application from loading images from remote devices. If your application loads files or plug-ins from remote devices, then it will not be compatible with this mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Block untrusted fonts
|
||||
|
||||
### Description
|
||||
|
||||
Block untrusted fonts mitigates the risk of a flaw in font parsing leading to the attacker being able to run code on the device. Only fonts which are installed into the windows\fonts directory will be loaded for processing by GDI.
|
||||
|
||||
This mitigation is implemented within GDI, which validates the location of the file. If the file is not in the system fonts directory, the font will not be loaded for parsing and that call will fail.
|
||||
|
||||
Note that this mitigation is in addition to the built-in mitigation provided in Windows 10 1607 and later, which moves font parsing out of the kernel and into a user-mode app container. Any exploit based on font parsing, as a result, happens in a sandboxed and isolated context, which reduces the risk significantly. For details on this mitigation, see the blog [Hardening Windows 10 with zero-day exploit mitigations](https://www.microsoft.com/security/blog/2017/01/13/hardening-windows-10-with-zero-day-exploit-mitigations/).
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
The most common use of fonts outside of the system fonts directory is with [web fonts](https://docs.microsoft.com/typography/fonts/font-faq#web). Modern browsers, such as Microsoft Edge, use DirectWrite instead of GDI, and are not impacted. However, legacy browsers, such as Internet Explorer 11 (and IE mode in the new Microsoft Edge) can be impacted, particularly with applications such as Office 365 which use font glyphs to display UI.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Code integrity guard
|
||||
|
||||
### Description
|
||||
|
||||
Code integrity guard ensures that all binaries loaded into a process are digitally signed by Microsoft. This includes [WHQL](https://docs.microsoft.com/windows-hardware/drivers/install/whql-release-signature) (Windows Hardware Quality Labs) signatures, which will allow WHQL-approved drivers to run within the process.
|
||||
|
||||
This mitigation is implemented within the memory manager, which blocks the binary from being mapped into memory. If you attempt to load a binary which is not signed by Microsoft, the memory manger will return the error STATUS_INVALID_IMAGE_HASH. By blocking at the memory manager level, this prevents both binaries loaded by the process and binaries injected into the process.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
This mitigation specifically blocks any binary which is not signed by Microsoft. As such, it will be incompatible with most third party software, unless that software is distributed by (and digitally signed by) the Microsoft Store, and the option to allow loading of images signed by the Microsoft Store is selected.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Also allow loading of images signed by Microsoft Store** - Applications which are distributed by the Microsoft Store will be digitally signed by the Microsoft Store, and adding this configuration will allow binaries which have gone through the store certification process to be loaded by the application.
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Control flow guard (CFG)
|
||||
|
||||
### Description
|
||||
|
||||
Control flow guard (CFG) mitigates the risk of attackers leveraging memory corruption vulnerabilities by protecting indirect function calls. For example, an attacker may user a buffer overflow vulnerability to overwrite memory containing a function pointer, and replace that function pointer with a pointer to executable code of their choice (which may also have been injected into the program).
|
||||
|
||||
This mitigation is provided by injecting an additional check at compile time. Before each indirect function call, additional instructions are added which verify that the target is a valid call target before it is called. If the target is not a valid call target, then the application is terminated. As such, only applications which are compiled with CFG support can benefit from this mitigation.
|
||||
|
||||
The check for a valid target is provided by the Windows kernel. When executable files are loaded, the metadata for indirect call targets is extracted at load time and marked as valid call targets. Additionally, when memory is allocated and marked as executable (such as for generated code), these memory locations are also marked as valid call targets, to support mechanisms such as JIT compilation.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Since applications must be compiled to support CFG, they implicitly declare their compatibility with it. Most applications, therefore, should work with this mitigation enabled. Because these checks are compiled into the binary, the configuration you can apply is merely to disable checks within the Windows kernel. In other words, the mitigation is on by default, but you can configure the Windows kernel to always return "yes" if you later determine that there is a compatibility issue that the application developer did not discover in their testing, which should be rare.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Use strict CFG** - In strict mode, all binaries loaded into the process must be compiled for Control Flow Guard (or have no executable code in them - such as resource dlls) in order to be loaded.
|
||||
|
||||
> [!Note]
|
||||
> **Control flow guard** has no audit mode. Binaries are compiled with this mitigation enabled.
|
||||
|
||||
## Data Execution Prevention (DEP)
|
||||
|
||||
### Description
|
||||
|
||||
Data Execution Prevention (DEP) prevents memory which was not explicitly allocated as executable from being executed. This helps protect against an attacker injecting malicious code into the process, such as through a buffer overflow, and then executing that code.
|
||||
|
||||
If you attempt to set the instruction pointer to a memory address not marked as executable, the processor will throw an exception (general-protection violation), causing the application to crash.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
All x64, ARM, and ARM-64 executables have DEP enabled by default, and it cannot be disabled. Since an application will have never been executed without DEP, compatibility is generally assumed.
|
||||
|
||||
All x86 (32-bit) binaries will have DEP enabled by default, but it can be disabled per process. Some very old legacy applications, typically applications developed prior to Windows XP SP2, may not be compatible with DEP. These are typically applications that dynamically generate code (e.g. JIT compiling) or link to older libraries (such as older versions of ATL) which dynamically generate code.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Enable ATL Thunk emulation** - This configuration option disables ATL Thunk emulation. ATL, the ActiveX Template Library, is designed to be as small and fast as possible. In order to reduce binary size, it would use a technique called thunking. Thunking is typically thought of for interacting between 32-bit and 16-bit applications, but there are no 16-bit components to ATL here. Rather, in order to optimize for binary size, ATL will store machine code in memory which is not word-aligned (creating a smaller binary), and then invoke that code directly. ATL components compiled with Visual Studio 7.1 or earlier (Visual Studio 2003) do not allocate this memory as executable - thunk emulation resolves that compatibility issue. Applications which have a binary extension model (such as Internet Explorer 11) will often need to have ATL Thunk emulation enabled.
|
||||
|
||||
## Disable extension points
|
||||
|
||||
### Description
|
||||
|
||||
This mitigation disables various extension points for an application, which might be used to establish persistence or elevate privileges of malicious content.
|
||||
|
||||
This includes:
|
||||
|
||||
- **AppInit DLLs** - Whenever a process starts, the system will load the specified DLL into to context of the newly started process before calling its entry point function. [Details on AppInit DLLs can be found here](https://docs.microsoft.com/windows/win32/winmsg/about-window-classes#application-global-classes). With this mitigation applied, AppInit DLLs are not loaded. Note that, beginning with Windows 7, AppInit DLLs need to be digitally signed, [as described here](https://docs.microsoft.com/windows/win32/win7appqual/appinit-dlls-in-windows-7-and-windows-server-2008-r2). Additionally, beginning with Windows 8, AppInit DLLs will not be loaded if SecureBoot is enabled, [as described here](https://docs.microsoft.com/windows/win32/dlls/secure-boot-and-appinit-dlls).
|
||||
- **Legacy IMEs** - An Input Method Editor (IME) allows a user to type text in a language that has more characters than can be represented on a keyboard. Third parties are able to create IMEs. A malicious IME might obtain credentials or other sensitive information from this input capture. Some IMEs, referred to as Legacy IMEs, will only work on Windows Desktop apps, and not UWP apps. This mitigation will also prevent this legacy IME from loading into the specified Windows Desktop app.
|
||||
- **Windows Event Hooks** - An application can call the [SetWinEventHook API](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-setwineventhook) to register interest in an event taking place. A DLL is specified and can be injected into the process. This mitigation forces the hook to be posted to the registering process rather than running in-process through an injected DLL.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Most of these extension points are relatively infrequently used, so compatibility impact is typically small, particularly at an individual application level. The one consideration is if users are using 3rd party Legacy IMEs which will not work with the protected application.
|
||||
|
||||
### Configuration options
|
||||
|
||||
There are no configuration options for this mitigation.
|
||||
|
||||
> [!Note]
|
||||
> **Disable extension points** has no audit mode.
|
||||
|
||||
## Disable Win32k system calls
|
||||
|
||||
### Description
|
||||
|
||||
Win32k.sys provides a broad attack surface for an attacker. As a kernel-mode component, it is frequently targeted as an escape vector for applications that are sandboxed. This mitigation prevents calls into win32k.sys by blocking a thread from converting itself into a GUI thread, which is then given access to invoke Win32k functions. A thread is non-GUI when created, but converted on first call to win32k.sys, or through an API call to [IsGuiThread](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-isguithread).
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
This mitigation is designed for processes which are dedicated non-UI processes. For example, many modern browsers will leverage process isolation and incorporate non-UI processes. Any application which displays a GUI using a single process will be impacted by this mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Do not allow child processes
|
||||
|
||||
### Description
|
||||
|
||||
This mitigation prevents an application from creating new child applications. A common technique used by adversaries is to initiate a trusted process on the device with malicious input (a "living off the land" attack), which often requires launching another application on the device. If there are no legitimate reasons why an application would launch a child process, this mitigation mitigates that potential attack vector. The mitigation is applied by setting a property on the process token, which blocks creating a token for the child process with the error message STATUS_CHILD_PROCESS_BLOCKED.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
If your application launches child applications for any reason, such as supporting hyperlinks which launch a browser or an external browser, or which launch other utilities on the computer, this functionality will be broken with this mitigation applied.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Export address filtering
|
||||
|
||||
### Description
|
||||
|
||||
Export address filtering (EAF) mitigates the risk of malicious code looking at the export address table of all loaded modules to find modules that contain useful APIs for their attack. This is a common tactic used by shellcode. In order to mitigate the risk of such an attack, this mitigation protects 3 commonly attacked modules:
|
||||
|
||||
- ntdll.dll
|
||||
- kernelbase.dll
|
||||
- kernel32.dll
|
||||
|
||||
The mitigation protects the memory page in the [export directory](https://docs.microsoft.com/windows/win32/debug/pe-format#export-directory-table) which points to the [export address table](https://docs.microsoft.com/windows/win32/debug/pe-format#export-address-table). This memory page will have the [PAGE_GUARD](https://docs.microsoft.com/windows/win32/memory/creating-guard-pages) protection applied to it. When someone tries to access this memory, it will generate a STATUS_GUARD_PAGE_VIOLATION. The mitigation handles this exception, and if the accessing instruction doesn't pass validation, the process will be terminated.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
This mitigation is primarily an issue for applications such as debuggers, sandboxed applications, applications using DRM, or applications that implement anti-debugging technology.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Validate access for modules that are commonly abused by exploits** - This option, also known as EAF+, adds protections for additional commonly attacked modules:
|
||||
|
||||
- mshtml.dll
|
||||
- flash*.ocx
|
||||
- jscript*.ocx
|
||||
- vbscript.dll
|
||||
- vgx.dll
|
||||
- mozjs.dll
|
||||
- xul.dll
|
||||
- acrord32.dll
|
||||
- acrofx32.dll
|
||||
- acroform.api
|
||||
|
||||
Additionally, by enabling EAF+, this mitigation adds the PAGE_GUARD protection to the page containing the "MZ" header, the first two bytes of the [DOS header in a PE file](https://docs.microsoft.com/windows/win32/debug/pe-format#ms-dos-stub-image-only), which is another aspect of known memory content which shellcode can look for to identify modules potentially of interest in memory.
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Force randomization for images (Mandatory ASLR)
|
||||
|
||||
### Description
|
||||
|
||||
Address Space Layout Randomization (ASLR) mitigates the risk of an attacker using their knowledge of the memory layout of the system in order to execute code that is already present in process memory and already marked as executable. This can mitigate the risk of an attacker leveraging techniques such as return-to-libc attacks, where the adversary sets the context and then modifies the return address to execute existing code with context that suits the adversary's purpose.
|
||||
|
||||
Mandatory ASLR forces a rebase of all DLLs within the process. A developer can enable ASLR using the [/DYNAMICBASE](https://docs.microsoft.com/cpp/build/reference/dynamicbase-use-address-space-layout-randomization?view=vs-2019) linker option, and this mitigation has the same effect.
|
||||
|
||||
When the memory manager is mapping in the image into the process, Mandatory ASLR will forcibly rebase DLLs and EXEs that have not opted in to ASLR. Note, however, that this rebasing has no entropy, and can therefore be placed at a predictable location in memory. For rebased and randomized location of binaries, this mitigation should be paired with [Randomize memory allocations (Bottom-up ASLR)](#randomize-memory-allocations-bottom-up-aslr).
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
This compatibility impact of ASLR is typically constrained to older applications which were built using compilers which made assumptions about the base address of a binary file or have stripped out base relocation information. This can lead to unpredictable errors as the execution flow attempts to jump to the expected, rather than the actual, location in memory.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Do not allow stripped images** - This option blocks the loading of images that have had relocation information stripped. The Windows PE file format contains absolute addresses, and the compiler also generates a [base relocation table](https://docs.microsoft.com/windows/win32/debug/pe-format#the-reloc-section-image-only) which the loader can use to find all relative memory references and their offset, so they can be updated if the binary does not load at its preferred base address. Some older applications strip out this information in production builds, and therefore these binaries cannot be rebased. This mitigation blocks such binaries from being loaded (instead of allowing them to load at their preferred base address).
|
||||
|
||||
> [!Note]
|
||||
> **Force randomization for images (Mandatory ASLR)** has no audit mode.
|
||||
|
||||
## Import address filtering (IAF)
|
||||
|
||||
### Description
|
||||
|
||||
The Import address filtering (IAF) mitigation helps mitigate the risk of an adversary changing the control flow of an application by modifying the import address table (IAT) to redirect to arbitrary code of the attacker's choice when that function is called. An attacker could use this approach to hijack control, or to intercept, inspect, and potentially block calls to sensitive APIs.
|
||||
|
||||
The memory pages for all protected APIs will have the [PAGE_GUARD](https://docs.microsoft.com/windows/win32/memory/creating-guard-pages) protection applied to them. When someone tries to access this memory, it will generate a STATUS_GUARD_PAGE_VIOLATION. The mitigation handles this exception, and if the accessing instruction doesn't pass validation, the process will be terminated.
|
||||
|
||||
This mitigation protects the following Windows APIs:
|
||||
|
||||
- GetProcAddress
|
||||
- GetProcAddressForCaller
|
||||
- LoadLibraryA
|
||||
- LoadLibraryExA
|
||||
- LoadLibraryW
|
||||
- LoadLibraryExW
|
||||
- LdrGetProcedureAddress
|
||||
- LdrGetProcedureAddressEx
|
||||
- LdrGetProcedureAddressForCaller
|
||||
- LdrLoadDll
|
||||
- VirtualProtect
|
||||
- VirtualProtectEx
|
||||
- VirtualAlloc
|
||||
- VirtualAllocEx
|
||||
- NtAllocateVirtualMemory
|
||||
- NtProtectVirtualMemory
|
||||
- CreateProcessA
|
||||
- CreateProcessW
|
||||
- WinExec
|
||||
- CreateProcessAsUserA
|
||||
- CreateProcessAsUserW
|
||||
- GetModuleHandleA
|
||||
- GetModuleHandleW
|
||||
- RtlDecodePointer
|
||||
- DecodePointer
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Legitimate applications which perform API interception may be detected by this mitigation and cause some applications to crash. Examples include security software and application compatibility shims.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Randomize memory allocations (Bottom-up ASLR)
|
||||
|
||||
### Description
|
||||
|
||||
Randomize memory allocations (Bottom-up ASLR) adds entropy to relocations, so their location is randomized and therefore less predictable. This mitigation requires Mandatory ASLR to take effect.
|
||||
|
||||
Note that the size of the 32-bit address space places practical constraints on the entropy that can be added, and therefore 64-bit applications make it significantly more difficult for an attacker to guess a location in memory.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Most applications which are compatible with Mandatory ASLR (rebasing) will also be compatible with the additional entropy of Bottom-up ASLR. Some applications may have pointer-truncation issues if they are saving local pointers in 32-bit variables (expecting a base address below 4GB), and thus will be incompatible with the high entropy option (which can be disabled).
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Don't use high entropy** - this option disables the use of high-entropy ASLR, which adds 24 bits of entropy (1TB of variance) into the bottom-up allocation for 64-bit applications.
|
||||
|
||||
> [!Note]
|
||||
> **Randomize memory allocations (Bottom-up ASLR)** has no audit mode.
|
||||
|
||||
## Simulate execution (SimExec)
|
||||
|
||||
### Description
|
||||
|
||||
Simulate execution (SimExec) is a mitigation for 32-bit applications only which helps validate that calls to sensitive APIs will return to legitimate caller functions. It does this by intercepting calls into sensitive APIs, and then simulating the execution of those APIs by walking through the encoded assembly language instructions looking for the RET instruction, which should return to the caller. It then inspects that function and walks backwards in memory to find the preceding CALL instruction to compare if the two match and that the RET hasn't been intercepted.
|
||||
|
||||
The APIs intercepted by this mitigation are:
|
||||
|
||||
- LoadLibraryA
|
||||
- LoadLibraryW
|
||||
- LoadLibraryExA
|
||||
- LoadLibraryExW
|
||||
- LdrLoadDll
|
||||
- VirtualAlloc
|
||||
- VirtualAllocEx
|
||||
- NtAllocateVirtualMemory
|
||||
- VirtualProtect
|
||||
- VirtualProtectEx
|
||||
- NtProtectVirtualMemory
|
||||
- HeapCreate
|
||||
- RtlCreateHeap
|
||||
- CreateProcessA
|
||||
- CreateProcessW
|
||||
- CreateProcessInternalA
|
||||
- CreateProcessInternalW
|
||||
- NtCreateUserProcess
|
||||
- NtCreateProcess
|
||||
- NtCreateProcessEx
|
||||
- CreateRemoteThread
|
||||
- CreateRemoteThreadEx
|
||||
- NtCreateThreadEx
|
||||
- WriteProcessMemory
|
||||
- NtWriteVirtualMemory
|
||||
- WinExec
|
||||
- CreateFileMappingA
|
||||
- CreateFileMappingW
|
||||
- CreateFileMappingNumaW
|
||||
- NtCreateSection
|
||||
- MapViewOfFile
|
||||
- MapViewOfFileEx
|
||||
- MapViewOfFileFromApp
|
||||
- LdrGetProcedureAddressForCaller
|
||||
|
||||
If a ROP gadget is detected, the process is terminated.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Applications which perform API interception, particularly security software, can cause compatibility problems with this mitigation.
|
||||
|
||||
This mitigation is incompatible with the Arbitrary Code Guard mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Validate API invocation (CallerCheck)
|
||||
|
||||
### Description
|
||||
|
||||
Validate API invocation (CallerCheck) is a mitigation for return oriented programming (ROP) techniques which validates that sensitive APIs were called from a valid caller. This mitigation inspects the passed return address, and then heuristically disassembles backwards to find a call above the return address to determine if the call target matches the parameter passed into the function.
|
||||
|
||||
The APIs intercepted by this mitigation are:
|
||||
|
||||
- LoadLibraryA
|
||||
- LoadLibraryW
|
||||
- LoadLibraryExA
|
||||
- LoadLibraryExW
|
||||
- LdrLoadDll
|
||||
- VirtualAlloc
|
||||
- VirtualAllocEx
|
||||
- NtAllocateVirtualMemory
|
||||
- VirtualProtect
|
||||
- VirtualProtectEx
|
||||
- NtProtectVirtualMemory
|
||||
- HeapCreate
|
||||
- RtlCreateHeap
|
||||
- CreateProcessA
|
||||
- CreateProcessW
|
||||
- CreateProcessInternalA
|
||||
- CreateProcessInternalW
|
||||
- NtCreateUserProcess
|
||||
- NtCreateProcess
|
||||
- NtCreateProcessEx
|
||||
- CreateRemoteThread
|
||||
- CreateRemoteThreadEx
|
||||
- NtCreateThreadEx
|
||||
- WriteProcessMemory
|
||||
- NtWriteVirtualMemory
|
||||
- WinExec
|
||||
- CreateFileMappingA
|
||||
- CreateFileMappingW
|
||||
- CreateFileMappingNumaW
|
||||
- NtCreateSection
|
||||
- MapViewOfFile
|
||||
- MapViewOfFileEx
|
||||
- MapViewOfFileFromApp
|
||||
- LdrGetProcedureAddressForCaller
|
||||
|
||||
If a ROP gadget is detected, the process is terminated.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Applications which perform API interception, particularly security software, can cause compatibility problems with this mitigation.
|
||||
|
||||
This mitigation is incompatible with the Arbitrary Code Guard mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Validate exception chains (SEHOP)
|
||||
|
||||
### Description
|
||||
|
||||
Validate exception chains (SEHOP) is a mitigation against the *Structured Exception Handler (SEH) overwrite* exploitation technique. [Structured Exception Handling](https://docs.microsoft.com/windows/win32/debug/structured-exception-handling) is the process by which an application can ask to handle a particular exception. Exception handlers are chained together, so that if one exception handler chooses not to handle a particular exception, it can be passed on to the next exception handler in the chain until one decides to handle it. Because the list of handler is dynamic, it is stored on the stack. An attacker can leverage a stack overflow vulnerability to then overwrite the exception handler with a pointer to the code of the attacker's choice.
|
||||
|
||||
This mitigation relies on the design of SEH, where each SEH entry contains both a pointer to the exception handler, as well as a pointer to the next handler in the exception chain. This mitigation is called by the exception dispatcher, which validates the SEH chain when an exception is invoked. It verifies that:
|
||||
|
||||
- All exception chain records are within the stack boundaries
|
||||
- All exception records are aligned
|
||||
- No exception handler pointers are pointing to the stack
|
||||
- There are no backward pointers
|
||||
- The exception chain ends at a known final exception handler
|
||||
|
||||
If these validations fail, then exception handling is aborted, and the exception will not be handled.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Compatibility issues with SEHOP are relatively rare. It's uncommon for an application to take a dependency on corrupting the exception chain. However, some applications are impacted by the subtle changes in timing, which may manifest as a race condition that reveals a latent multi-threading bug in the application.
|
||||
|
||||
### Configuration options
|
||||
|
||||
> [!Note]
|
||||
> **Validate exception chains (SEHOP)** has no audit mode.
|
||||
|
||||
## Validate handle usage
|
||||
|
||||
### Description
|
||||
|
||||
*Validate handle usage* is a mitigation which helps protect against an attacker leveraging an existing handle to access a protected object. A [handle](https://docs.microsoft.com/windows/win32/sysinfo/handles-and-objects) is a reference to a protected object. If application code is referencing an invalid handle, that could indicate that an adversary is attempting to use a handle it has previously recorded (but which application reference counting wouldn't be aware of). If the application attempts to use an invalid object, instead of simply returning null, the application will raise an exception (STATUS_INVALID_HANDLE).
|
||||
|
||||
This mitigation is automatically applied to Windows Store applications.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Applications which were not accurately tracking handle references, and which were not wrapping these operations in exception handlers, will potentially be impacted by this mitigation.
|
||||
|
||||
### Configuration options
|
||||
|
||||
> [!Note]
|
||||
> **Validate handle usage** has no audit mode.
|
||||
|
||||
## Validate heap integrity
|
||||
|
||||
### Description
|
||||
|
||||
The *validate heap integrity* mitigation increases the protection level of heap mitigations in Windows, by causing the application to terminate if a heap corruption is detected. The mitigations include:
|
||||
|
||||
- Preventing a HEAP handle from being freed
|
||||
- Performing additional validation on extended block headers for heap allocations
|
||||
- Verifying that heap allocations are not already flagged as in-use
|
||||
- Adding guard pages to large allocations, heap segments, and subsegments above a minimum size
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
This mitigation is already applied by default for 64-bit applications and for 32-bit applications targeting Windows Vista or later. Legacy applications from Windows XP or earlier are most at-risk, though compatibility issues are rare.
|
||||
|
||||
### Configuration options
|
||||
|
||||
> [!Note]
|
||||
> **Validate heap integrity** has no audit mode.
|
||||
|
||||
## Validate image dependency integrity
|
||||
|
||||
### Description
|
||||
|
||||
The *validate image dependency* mitigation helps protect against attacks which attempt to substitute code for dlls which are statically linked by Windows binaries. The technique of DLL planting abuses the loader's search mechanism to inject malicious code, which can be used to get malicious code running in an elevated context. When the loader is loading a Windows signed binary, and then loads up any dlls that the binary depends on, these binaries will be verified to ensure that they are also digitally signed as a Windows binary. If they fail the signature check, the dll will not be loaded, and will throw an exception, returning a status of STATUS_INVALID_IMAGE_HASH.
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Compatibility issues are uncommon. Applications which depend on replacing Windows binaries with local private versions will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
|
||||
## Validate stack integrity (StackPivot)
|
||||
|
||||
### Description
|
||||
|
||||
The *validate stack integrity (StackPivot) mitigation helps protect against the Stack Pivot attack, a ROP attack where an attacker creates a fake stack in heap memory, and then tricks the application into returning into the fake stack which controls the flow of execution.
|
||||
|
||||
This mitigation intercepts a number of Windows APIs, and inspects the value of the stack pointer. If the address of the stack pointer does not fall between the bottom and the top of the stack, then an event is recorded and, if not in audit mode, the process will be terminated.
|
||||
|
||||
The APIs intercepted by this mitigation are:
|
||||
|
||||
- LoadLibraryA
|
||||
- LoadLibraryW
|
||||
- LoadLibraryExA
|
||||
- LoadLibraryExW
|
||||
- LdrLoadDll
|
||||
- VirtualAlloc
|
||||
- VirtualAllocEx
|
||||
- NtAllocateVirtualMemory
|
||||
- VirtualProtect
|
||||
- VirtualProtectEx
|
||||
- NtProtectVirtualMemory
|
||||
- HeapCreate
|
||||
- RtlCreateHeap
|
||||
- CreateProcessA
|
||||
- CreateProcessW
|
||||
- CreateProcessInternalA
|
||||
- CreateProcessInternalW
|
||||
- NtCreateUserProcess
|
||||
- NtCreateProcess
|
||||
- NtCreateProcessEx
|
||||
- CreateRemoteThread
|
||||
- CreateRemoteThreadEx
|
||||
- NtCreateThreadEx
|
||||
- WriteProcessMemory
|
||||
- NtWriteVirtualMemory
|
||||
- WinExec
|
||||
- CreateFileMappingA
|
||||
- CreateFileMappingW
|
||||
- CreateFileMappingNumaW
|
||||
- NtCreateSection
|
||||
- MapViewOfFile
|
||||
- MapViewOfFileEx
|
||||
- MapViewOfFileFromApp
|
||||
- LdrGetProcedureAddressForCaller
|
||||
|
||||
### Compatibility considerations
|
||||
|
||||
Compatibility issues are uncommon. Applications which are leveraging fake stacks will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications.
|
||||
|
||||
### Configuration options
|
||||
|
||||
**Audit Only** - You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in [Microsoft Defender ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
|
||||
@ -36,10 +36,10 @@ When a mitigation is encountered on the device, a notification will be displayed
|
||||
|
||||
You can also use [audit mode](evaluate-exploit-protection.md) to evaluate how exploit protection would impact your organization if it were enabled.
|
||||
|
||||
Many of the features in the [Enhanced Mitigation Experience Toolkit (EMET)](https://technet.microsoft.com/security/jj653751) have been included in Exploit protection, and you can convert and import existing EMET configuration profiles into Exploit protection. See [Comparison between Enhanced Mitigation Experience Toolkit and Exploit protection](emet-exploit-protection.md) for more information on how Exploit protection supersedes EMET and what the benefits are when considering moving to exploit protection on Windows 10.
|
||||
Many of the features in the [Enhanced Mitigation Experience Toolkit (EMET)](https://technet.microsoft.com/security/jj653751) are included in exploit protection. In fact, you can convert and import existing your EMET configuration profiles into exploit protection. To learn more, see [Import, export, and deploy exploit protection configurations](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/import-export-exploit-protection-emet-xml).
|
||||
|
||||
> [!IMPORTANT]
|
||||
> If you are currently using EMET you should be aware that [EMET reached end of support on July 31, 2018](https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/). You should consider replacing EMET with exploit protection in Windows 10.
|
||||
> If you are currently using EMET you should be aware that [EMET reached end of support on July 31, 2018](https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/). Consider replacing EMET with exploit protection in Windows 10.
|
||||
|
||||
> [!WARNING]
|
||||
> Some security mitigation technologies may have compatibility issues with some applications. You should test exploit protection in all target use scenarios by using [audit mode](audit-windows-defender.md) before deploying the configuration across a production environment or the rest of your network.
|
||||
@ -61,34 +61,34 @@ DeviceEvents
|
||||
|
||||
You can review the Windows event log to see events that are created when exploit protection blocks (or audits) an app:
|
||||
|
||||
Provider/source | Event ID | Description
|
||||
-|-|-
|
||||
Security-Mitigations | 1 | ACG audit
|
||||
Security-Mitigations | 2 | ACG enforce
|
||||
Security-Mitigations | 3 | Do not allow child processes audit
|
||||
Security-Mitigations | 4 | Do not allow child processes block
|
||||
Security-Mitigations | 5 | Block low integrity images audit
|
||||
Security-Mitigations | 6 | Block low integrity images block
|
||||
Security-Mitigations | 7 | Block remote images audit
|
||||
Security-Mitigations | 8 | Block remote images block
|
||||
Security-Mitigations | 9 | Disable win32k system calls audit
|
||||
Security-Mitigations | 10 | Disable win32k system calls block
|
||||
Security-Mitigations | 11 | Code integrity guard audit
|
||||
Security-Mitigations | 12 | Code integrity guard block
|
||||
Security-Mitigations | 13 | EAF audit
|
||||
Security-Mitigations | 14 | EAF enforce
|
||||
Security-Mitigations | 15 | EAF+ audit
|
||||
Security-Mitigations | 16 | EAF+ enforce
|
||||
Security-Mitigations | 17 | IAF audit
|
||||
Security-Mitigations | 18 | IAF enforce
|
||||
Security-Mitigations | 19 | ROP StackPivot audit
|
||||
Security-Mitigations | 20 | ROP StackPivot enforce
|
||||
Security-Mitigations | 21 | ROP CallerCheck audit
|
||||
Security-Mitigations | 22 | ROP CallerCheck enforce
|
||||
Security-Mitigations | 23 | ROP SimExec audit
|
||||
Security-Mitigations | 24 | ROP SimExec enforce
|
||||
WER-Diagnostics | 5 | CFG Block
|
||||
Win32K | 260 | Untrusted Font
|
||||
|Provider/source | Event ID | Description|
|
||||
|---|---|---|
|
||||
|Security-Mitigations | 1 | ACG audit |
|
||||
|Security-Mitigations | 2 | ACG enforce |
|
||||
|Security-Mitigations | 3 | Do not allow child processes audit |
|
||||
|Security-Mitigations | 4 | Do not allow child processes block |
|
||||
|Security-Mitigations | 5 | Block low integrity images audit |
|
||||
|Security-Mitigations | 6 | Block low integrity images block |
|
||||
|Security-Mitigations | 7 | Block remote images audit |
|
||||
|Security-Mitigations | 8 | Block remote images block |
|
||||
|Security-Mitigations | 9 | Disable win32k system calls audit |
|
||||
|Security-Mitigations | 10 | Disable win32k system calls block |
|
||||
|Security-Mitigations | 11 | Code integrity guard audit |
|
||||
|Security-Mitigations | 12 | Code integrity guard block |
|
||||
|Security-Mitigations | 13 | EAF audit |
|
||||
|Security-Mitigations | 14 | EAF enforce |
|
||||
|Security-Mitigations | 15 | EAF+ audit |
|
||||
|Security-Mitigations | 16 | EAF+ enforce |
|
||||
|Security-Mitigations | 17 | IAF audit |
|
||||
|Security-Mitigations | 18 | IAF enforce |
|
||||
|Security-Mitigations | 19 | ROP StackPivot audit |
|
||||
|Security-Mitigations | 20 | ROP StackPivot enforce |
|
||||
|Security-Mitigations | 21 | ROP CallerCheck audit |
|
||||
|Security-Mitigations | 22 | ROP CallerCheck enforce |
|
||||
|Security-Mitigations | 23 | ROP SimExec audit |
|
||||
|Security-Mitigations | 24 | ROP SimExec enforce |
|
||||
|WER-Diagnostics | 5 | CFG Block |
|
||||
|Win32K | 260 | Untrusted Font |
|
||||
|
||||
## Mitigation comparison
|
||||
|
||||
@ -96,38 +96,36 @@ The mitigations available in EMET are included natively in Windows 10 (starting
|
||||
|
||||
The table in this section indicates the availability and support of native mitigations between EMET and exploit protection.
|
||||
|
||||
Mitigation | Available under Exploit protection | Available in EMET
|
||||
-|-|-
|
||||
Arbitrary code guard (ACG) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]<br />As "Memory Protection Check"
|
||||
Block remote images | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]<br/>As "Load Library Check"
|
||||
Block untrusted fonts | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Data Execution Prevention (DEP) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Export address filtering (EAF) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Force randomization for images (Mandatory ASLR) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
NullPage Security Mitigation | [!include[Check mark yes](../images/svg/check-yes.svg)]<br />Included natively in Windows 10<br/>See [Mitigate threats by using Windows 10 security features](../overview-of-threat-mitigations-in-windows-10.md#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) for more information | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Randomize memory allocations (Bottom-Up ASLR) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Simulate execution (SimExec) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Validate API invocation (CallerCheck) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Validate exception chains (SEHOP) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Validate stack integrity (StackPivot) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Certificate trust (configurable certificate pinning) | Windows 10 provides enterprise certificate pinning | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Heap spray allocation | Ineffective against newer browser-based exploits; newer mitigations provide better protection<br/>See [Mitigate threats by using Windows 10 security features](../overview-of-threat-mitigations-in-windows-10.md#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) for more information | [!include[Check mark yes](../images/svg/check-yes.svg)]
|
||||
Block low integrity images | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Code integrity guard | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Disable extension points | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Disable Win32k system calls | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Do not allow child processes | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Import address filtering (IAF) | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Validate handle usage | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Validate heap integrity | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
Validate image dependency integrity | [!include[Check mark yes](../images/svg/check-yes.svg)] | [!include[Check mark no](../images/svg/check-no.svg)]
|
||||
|Mitigation | Available under exploit protection | Available in EMET |
|
||||
|---|---|---|
|
||||
|Arbitrary code guard (ACG) | yes | yes<br />As "Memory Protection Check" |
|
||||
|Block remote images | yes | yes<br/>As "Load Library Check" |
|
||||
|Block untrusted fonts | yes | yes |
|
||||
|Data Execution Prevention (DEP) | yes | yes |
|
||||
|Export address filtering (EAF) | yes | yes |
|
||||
|Force randomization for images (Mandatory ASLR) | yes | yes |
|
||||
|NullPage Security Mitigation | yes<br />Included natively in Windows 10<br/>See [Mitigate threats by using Windows 10 security features](../overview-of-threat-mitigations-in-windows-10.md#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) for more information | yes |
|
||||
|Randomize memory allocations (Bottom-Up ASLR) | yes | yes |
|
||||
|Simulate execution (SimExec) | yes | yes |
|
||||
|Validate API invocation (CallerCheck) | yes | yes |
|
||||
|Validate exception chains (SEHOP) | yes | yes |
|
||||
|Validate stack integrity (StackPivot) | yes | yes |
|
||||
|Certificate trust (configurable certificate pinning) | Windows 10 provides enterprise certificate pinning | yes |
|
||||
|Heap spray allocation | Ineffective against newer browser-based exploits; newer mitigations provide better protection<br/>See [Mitigate threats by using Windows 10 security features](../overview-of-threat-mitigations-in-windows-10.md#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) for more information | yes |
|
||||
|Block low integrity images | yes | no |
|
||||
|Code integrity guard | yes | no |
|
||||
|Disable extension points | yes | no |
|
||||
|Disable Win32k system calls | yes | no |
|
||||
|Do not allow child processes | yes | no |
|
||||
|Import address filtering (IAF) | yes | no |
|
||||
|Validate handle usage | yes | no |
|
||||
|Validate heap integrity | yes | no |
|
||||
|Validate image dependency integrity | yes | no |
|
||||
|
||||
> [!NOTE]
|
||||
> The Advanced ROP mitigations that are available in EMET are superseded by ACG in Windows 10, which other EMET advanced settings are enabled by default, as part of enabling the anti-ROP mitigations for a process.
|
||||
>
|
||||
> See the [Mitigation threats by using Windows 10 security features](../overview-of-threat-mitigations-in-windows-10.md#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) for more information on how Windows 10 employs existing EMET technology.
|
||||
> The Advanced ROP mitigations that are available in EMET are superseded by ACG in Windows 10, which other EMET advanced settings are enabled by default, as part of enabling the anti-ROP mitigations for a process. See the [Mitigation threats by using Windows 10 security features](../overview-of-threat-mitigations-in-windows-10.md#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) for more information on how Windows 10 employs existing EMET technology.
|
||||
|
||||
## Related articles
|
||||
## See also
|
||||
|
||||
- [Protect devices from exploits](exploit-protection.md)
|
||||
- [Evaluate exploit protection](evaluate-exploit-protection.md)
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 29 KiB |
@ -64,7 +64,7 @@ When you've configured exploit protection to your desired state (including both
|
||||
|
||||
Example command:
|
||||
|
||||
**Get-ProcessMitigation -RegistryConfigFilePath C:\ExploitConfigfile.xml**
|
||||
`Get-ProcessMitigation -RegistryConfigFilePath C:\ExploitConfigfile.xml`
|
||||
|
||||
> [!IMPORTANT]
|
||||
> When you deploy the configuration using Group Policy, all devices that will use the configuration must be able to access the configuration file. Ensure you place the file in a shared location.
|
||||
@ -88,7 +88,7 @@ After importing, the settings will be instantly applied and can be reviewed in t
|
||||
|
||||
Example command:
|
||||
|
||||
**Set-ProcessMitigation -PolicyFilePath C:\ExploitConfigfile.xml**
|
||||
`Set-ProcessMitigation -PolicyFilePath C:\ExploitConfigfile.xml`
|
||||
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
@ -115,16 +115,16 @@ You can use Group Policy to deploy the configuration you've created to multiple
|
||||
|
||||
5. In the **Options:** section, enter the location and file name of the Exploit protection configuration file that you want to use, such as in the following examples:
|
||||
|
||||
* C:\MitigationSettings\Config.XML
|
||||
* \\\Server\Share\Config.xml
|
||||
* https://localhost:8080/Config.xml
|
||||
* C:\ExploitConfigfile.xml
|
||||
* `C:\MitigationSettings\Config.XML`
|
||||
* `\\Server\Share\Config.xml`
|
||||
* `https://localhost:8080/Config.xml`
|
||||
* `C:\ExploitConfigfile.xml`
|
||||
|
||||
6. Select **OK** and [Deploy the updated GPO as you normally do](https://docs.microsoft.com/windows/win32/srvnodes/group-policy).
|
||||
|
||||
## Related topics
|
||||
## See also
|
||||
|
||||
* [Protect devices from exploits](exploit-protection.md)
|
||||
* [Evaluate exploit protection](evaluate-exploit-protection.md)
|
||||
* [Enable exploit protection](enable-exploit-protection.md)
|
||||
* [Configure and audit exploit protection mitigations](customize-exploit-protection.md)
|
||||
- [Protect devices from exploits](exploit-protection.md)
|
||||
- [Evaluate exploit protection](evaluate-exploit-protection.md)
|
||||
- [Enable exploit protection](enable-exploit-protection.md)
|
||||
- [Configure and audit exploit protection mitigations](customize-exploit-protection.md)
|
||||
|
||||
@ -19,6 +19,10 @@ ms.topic: conceptual
|
||||
|
||||
# What's new in Microsoft Defender Advanced Threat Protection for Linux
|
||||
|
||||
## 101.04.76
|
||||
|
||||
- Bug fixes
|
||||
|
||||
## 101.03.48
|
||||
|
||||
- Bug fixes
|
||||
|
||||
@ -196,7 +196,6 @@ If you haven’t already, it's a good idea to download and use the [Windows Secu
|
||||
## Related topics
|
||||
|
||||
* [Protect devices from exploits](exploit-protection.md)
|
||||
* [Comparison with Enhanced Mitigation Experience Toolkit](emet-exploit-protection.md)
|
||||
* [Evaluate exploit protection](evaluate-exploit-protection.md)
|
||||
* [Enable exploit protection](enable-exploit-protection.md)
|
||||
* [Configure and audit exploit protection mitigations](customize-exploit-protection.md)
|
||||
|
||||
@ -28,7 +28,7 @@ After designing and deploying your Windows Defender Application Control (WDAC) p
|
||||
|
||||
## WDAC Events Overview
|
||||
|
||||
WDAC generates and logs events when a policy is loaded as well as when a binary attempts to execute and is blocked. These events include information that identifies the policy and gives more details about the block. Generally, WDAC does not generate events when a binary is allowed; however, there is the option to enable allow events when Managed Installer and/or the Intelligent Security Graph (ISG) is configured.
|
||||
WDAC generates and logs events when a policy is loaded as well as when a binary attempts to execute and is blocked. These events include information that identifies the policy and gives more details about the block. Generally, WDAC does not generate events when a binary is allowed; however, there is the option to enable events when Managed Installer and/or the Intelligent Security Graph (ISG) is configured.
|
||||
|
||||
WDAC events are generated under two locations:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user