Using Windows Defender Application Control to block malicious applications and drivers

WDAC allows security and IT admins to control which applications, drivers and certificates can run on Windows systems.

Ideally, we would lock down our operating systems to allow only those applications we want to have running. For many companies, however, investigating what software is running in their networks takes resources and research that they often don’t have.

A tool built into Windows can provide better control over what runs on your system. Windows Defender Application Control (WDAC), also referred to as Microsoft Defender Application Control (MDAC), was introduced with Windows 10 and allows you to control drivers and applications on your Windows clients. Some WDAC capabilities are available only on specific Windows versions. Cmdlets are available on all SKUs since 1909. An older Microsoft whitelisting technology, AppLocker, is no longer being developed and will receive security fixes but no new features.

You can use Group Policy or cloud services such as Intune to set the policies. While it may be overwhelming to limit applications allowed to run on an operating system given the needs of the business, it probably is not an issue to set a policy to limit what drivers are allowed to run on a system.

Use WDAC to block rogue drivers and certificates

A recent event where attackers stole a software certificate used to sign Nvidia drivers underscores the importance of using WDAC to protect your network from malicious drivers. Kim Oppalfens recently posted about how you can use WDAC to deny any rogue driver or certificate you may want to protect your network from. The only hard part of this process is that you may need to obtain access to the malicious driver or certificate to prepare the rule.

It’s recommended to start the process of deploying WDAC by enabling rules in audit mode so you can determine the impact to your network. Code integrity policies help protect Windows 10 by checking applications based on the attributes of code-signing certificates, reviewing the application binaries, the reputation of the application, and the identity of the process that starts the installation. Typically, an application is launched by the managed installer as well as reviewing the path from which the application is installed.

Review Microsoft’s sample WDAC policies

Start by reviewing the sample base policies that Microsoft has provided. Navigate to C:\Windows\schemas\CodeIntegrity\ExamplePolicies\ and open the xml located at DenyAllAudit.xml.

Microsoft has enabled five rules by default in this sample policy:

  • Unsigned System Integrity Policy “allows the policy to remain unsigned. When this option is removed, the policy must be signed and the certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section.”
  • Audit mode “instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. To enforce the policy rather than just have it log requires removing this option.”
  • Advanced Boot Options Menu “allows the F8 menu to appear to physically present users. This is a handy recovery option but may be a security concern if physical access to the device is available for an attacker.”
  • User-Mode Code Integrity (UMCI) validates user mode executables and scripts.
  • Update Policy No Reboot “allows future WDAC policy updates to apply without requiring a system reboot.”
bradley wdac Susan Bradley

Microsoft's sample WDAC policies

Additional policies include (rule option followed by description):

2 Required: WHQL -- By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified.            

4 Disabled: Flight Signing -- If enabled, WDAC policies will not trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds.       

8 Required: EV Signers -- This rule requires that drivers must be WHQL signed, and have been submitted by a partner with an Extended Verification (EV) certificate. All Windows 10 and Windows 11 drivers will meet this requirement.

10 Enabled: Boot Audit on Failure – Use this when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log.             

11 Disabled: Script Enforcement -- This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to Constrained Language Mode. This option is required to run HTA files, and is supported on 1709, 1803 and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows without the proper update may have unintended results.     

12 Required: Enforce Store Applications -- If this rule option is enabled, WDAC policies will also apply to Universal Windows applications.            

13 Enabled: Managed Installer -- Use this option to automatically allow applications installed by a managed installer.

14 Enabled: Intelligent Security Graph Authorization -- Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG).  

15 Enabled: Invalidate EAs on Reboot -- When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.

17 Enabled: Allow Supplemental Policies -- Use this option on a base policy to allow supplemental policies to expand it. This option is only supported on Windows 10, version 1903 and above.           

18 Disabled: Runtime FilePath Rule Protection -- This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator. This option is only supported on Windows 10, version 1903 and above.            

19 Enabled: Dynamic Code Security – This option enables policy enforcement for .NET applications and dynamically loaded libraries. It is only supported on Windows 10, version 1803 and above.            

20 Enabled: Revoked Expired As Unsigned -- Use this option to treat binaries signed with expired or revoked certificates as "unsigned binaries" for user-mode process/components, under enterprise signing scenarios.

GitHub has documented several recommended ways to deploy WDAC policies ranging from Intune, Endpoint Configuration Manager, Group Policy, and plain old scripting to push out the policies to your network. As they note, start in audit mode first before enforcing. Monitor events to ensure that you will be blocking events you wish to be blocked and not blocking the vice president of sales from accessing the key application that tracks customers. WDAC is an extremely powerful tool that is often overlooked in its ability to protect the network from potential outside attacks as well as internal attacks.

Copyright © 2022 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)