Windows Defender Exploit Guard – Controlled Folder Access

In this post, we’ll see how we can configure Windows Defender Exploit Guard’s other features Controlled Folder Access, Network Protection and Exploit Protection using Microsoft Intune.

Existing setup done:

  1. Two Local users created
  2. Azure AD Connect configured
  3. Seamless Single Sign-On (IE) configured
  4. Seamless Single Sign-On (Firefox) configured
  5. Hybrid Azure AD Join configured
  6. Intune enrollment – Domain Joined Windows 10 devices
  7. Azure AD Join
  8. Office 365 Pro Plus Application
  9. Sample SharePoint Team Site
  10. OneDrive Known Folder Migration and SharePoint library sync
  11. Copy necessary files (Win32 App)
  12. Set Desktop Background, Lock Screen and Screensaver
  13. Adding applications to StartUp folder
  14. Adding some 3rd Party applications (Browsers)
  15. Microsoft Store for Business configuration and integration and Store Apps.
  16. Windows Defender Application Guard configuration
  17. Extend Application Guard to Mozilla Firefox and Google Chrome
  18. Configure Windows Defender Antivirus
  19. Windows Defender Credential Guard
  20. Windows Defender Exploit Guard – Attack Surface Reduction

Existing setup:

  1. SkyDC: Machine with ADDS, DNS, DHCP role
  2. SkyCON: Machine where we will install Azure AD Connect
  3. SkyCM: Machine with Configuration Manager Current Branch
  4. SkyTEN1: Domain Joined Windows 10 machine
  5. SkyTEN2: Domain Joined Windows 10 machine
  6. SkyTEN3i: Domain Joined Windows 10 machine (Intune Managed)
  7. SkyTEN4i: Domain Joined Windows 10 machine (Intune Managed)
  8. SkyTEN5i: Azure AD Joined Windows 10 (Intune Managed)
  9. SkyTEN6i: Azure AD Joined Windows 10 (Intune Managed)
  10. SkyTEN7i: Azure AD Joined Windows 10 (Cloud User, Intune Managed)
  11. SkyTEN8i: Azure AD Joined Windows 10 (Cloud User, Intune Managed)

 

Controlled Folder Access

Controlled folder access helps you protect valuable data from malicious apps and threats, such as ransomware. Controlled Folder Access makes sure that protected folders are not modified by such malicious apps.

Navigate to Intune -> Device configuration -> Profiles. Click on earlier created WDEG policy.

Navigate to Settings -> Microsoft Defender Exploit Guard -> Controlled folder access.

There are multiple options available which you might select depending on requirement. We are going to select Enable option.

Options:

Enable: Enables Controlled Folder Access in enforce mode

Audit: Enables Controlled Folder Access in Audit mode

Block disk modification: Allows Controlled folder access to be enabled for boot sectors only and does not enable the protection of specific folders or the default protected folders.

Audit disk modification: Allows Controlled folder access to be enabled in Audit mode for boot sectors only and does not enable the protection of specific folders or the default protected folders.

Ref: https://docs.microsoft.com/en-us/configmgr/protect/deploy-use/create-deploy-exploit-guard-policy

In Folder protection, select Enable.

If you have any applications that you want them to access the protected folders, add them in the Apps section.

If you want to protect any additional folders, add them in the Folders section. We are going to add C:\Demo folder in the protected folder list.

In Folders section, enter C:\Demo and click on Add.

Click OK.

Click OK.

Click OK.

Click Save.

In Client machine:

Sync the machine

Copy the testing files from URL: https://demo.wd.microsoft.com/?ocid=cx-wddocs-testground

You can see that I have copied the CFAtool.exe to the root of C Drive.

I faced some issues while testing the tool when copied to Lab folder.

Open the CFATool by double clicking on it.

Enter appropriate file name.

Select the appropriate folder and click Create file.

We can see an Unauthorized changes Blocked notification.

We can close the CFATool now.

Open Event Viewer and navigate to Custom Views -> Controlled Folder Access view.

Check the warning event generated.

Network Filtering

Network protection or Network Filtering helps to prevent employees from using any application to access dangerous domains that may host phishing scams, exploits, and other malicious content on the Internet. When enabled, it will block all outbound connection from any application to low reputation IP/Domain.

Navigate to Intune -> Device configuration -> Profiles. Click on earlier created WDEG policy.

Navigate to Settings -> Microsoft Defender Exploit Guard -> Network filtering.

In Network protection, select Enable.

Click OK.

Click OK.

Click OK.

Click Save.

Deploy 3rd party browsers to the group where the policy is deployed

You can see that I have deployed Google Chrome to the target device group.

In Client machine

Sync the device

Start Google Chrome.

Enter below URL for Network Protection:

https://smartscreentestratings2.net/

You can see that the connection is blocked.

Open Event Viewer and check the warning message.

Exploit Protection

Exploit protection helps protect against malware that uses exploits to infect devices and spread. It consists of a number of mitigations that can be applied to either the operating system or individual apps.

Some information on Exploit Protection mitigations:

Control Flow Guard:

Control Flow Guard (CFG) is a highly-optimized platform security feature that was created to combat memory corruption vulnerabilities. By placing tight restrictions on where an application can execute code from, it makes it much harder for exploits to execute arbitrary code through vulnerabilities such as buffer overflows.

Data Execution Prevention:

Data Execution Prevention (DEP) is a system-level memory protection feature that is built into the operating system starting with Windows XP and Windows Server 2003. DEP enables the system to mark one or more pages of memory as non-executable. Marking memory regions as non-executable means that code cannot be run from that region of memory, which makes it harder for the exploitation of buffer overruns.

DEP prevents code from being run from data pages such as the default heap, stacks, and memory pools. If an application attempts to run code from a data page that is protected, a memory access violation exception occurs, and if the exception is not handled, the calling process is terminated.

ASLR:

Attackers often make assumptions about the address space layout of a process when developing an exploit. For example, attackers will generally assume that a module will be loaded at a predictable address or that readable/writable memory will exist at a specific address on all PCs. Attackers can also use various address space spraying techniques (such as heap spraying or JIT spraying) to place code or data at a predictable location in the address space. ASLR is designed to break these assumptions by making the address space layout of a process unknown to an attacker who does not have local access to the machine. This prevents an attacker from being able to directly and reliably leverage code in loaded modules.

Randomization of EXEs/DLLs is opt-in. EXEs/DLLs tell the operating system they are compatible with ASLR by linking with the /DYNAMICBASE flag. This flag has been enabled by default since Visual Studio 2010.

Mandatory ASLR can be used to forcibly rebase EXEs/DLLs that have not opted in. In Windows 8, we introduced operating system support for forcing EXEs/DLLs to be rebased at runtime if they did not opt-in to ASLR. This mitigation can be enabled system-wide or on a per-process basis. It works by forcing a base address conflict at the time that a non-ASLR EXE/DLL is mapped. When this occurs, the new base address of the EXE/DLL is selected by searching for a free region starting from the bottom of the address space.

Bottom-up randomization provides entropy for bottom-up allocations. In Windows 8, we also introduced opt-in support for bottom-up randomization which adds entropy to the base address selected for allocations that search for a free region starting from the bottom of the address space (e.g. EXEs/DLLs rebased due to mandatory ASLR). This provides implicit biasing of all bottom-up allocations and can be enabled system-wide or on a per-process basis.

Bottom-up randomization is enabled by default only if the process EXE opts in to ASLR. This is for compatibility reasons as applications whose EXE did not opt-in to ASLR (via /DYNAMICBASE) do not necessarily expect their address space layout to change from one execution to the next.

SEHOP:

In Windows Server 2008 and Windows Vista SP1, Microsoft released support for a new platform mitigation known as Structured Exception Handler Overwrite Protection (SEHOP). The purpose of the SEHOP mitigation is to prevent an attacker from being able to make use of the Structured Exception Handler (SEH) overwrite exploitation technique. At a high-level, the SEH overwrite technique uses a software vulnerability to execute arbitrary code by abusing the 32-bit exception dispatching facilities provided by Windows.

Force Randomization for images (Mandatory ASLR):

This forces relocation of images not compiled with /DYNAMICBASE. Can optionally fail loading images that don’t have relocation information.

Randomize memory allocations (Bottom-Up ASLR):

Randomizes locations for virtual memory allocations including those for system structures heaps, stacks, TEBs, and PEBs. Can optionally use a wider randomization variance for 64-bit processes.

High-entropy ASLR:

Increase variability when using Randomize memory allocations (Bottom-up ASLR)

Validate exception chains (SEHOP):

Ensures the integrity of an exception chain during exception dispatch. Only configurable for 32-bit (x86) applications.

Validate heap integrity:

Terminates a process when heap corruption is detected.

Ref:

https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard

https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/customize-exploit-protection

https://msrc-blog.microsoft.com/2010/12/08/on-the-effectiveness-of-dep-and-aslr/

https://msrc-blog.microsoft.com/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/

https://msrc-blog.microsoft.com/2009/02/02/preventing-the-exploitation-of-structured-exception-handler-seh-overwrites-with-sehop/

https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/customize-exploit-protection

Take a gold machine where you can configure Exploit Protection and then export the settings.

On the Gold machine:

Open Windows Defender Security Center app and click on App & browser control.

Scroll down and click on Exploit protection settings.

In Exploit protection page, select System settings and configure the settings accordingly.

Click on Program settings, and configure the settings for any program accordingly.

Click on Export settings.

Save the XML file.

In Portal:

Navigate to Intune -> Device configuration -> Profiles. Click on earlier created Win 10 WDEG policy.

Navigate to Settings -> Microsoft Defender Exploit Guard -> Exploit protection.

In Upload XML, Click on folder icon and select the XML exported earlier.

In User editing of exploit protection interface, select the appropriate option. In my case, I have selected Block.

Click OK.

Click OK.

Click OK.

Click Save.

In Client machine

Sync the policy

Open Microsoft Defender Security Center.

Navigate to App & browser control -> Exploit protection settings.

You can see the message that the setting is managed by administrator.

Done.

Leave a comment

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