Dear IT Pros,
Today we discuss about All things about WDAC – Windows Defender Application Control.
WDAC was introduced with Windows 10 and could be applied to Windows server 2016 and later, its older name is Configurable Code Integrity (CCI). WDAC allows organizations to control which drivers and applications are allowed to run on devices.
WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:
Beginning with Windows 10 version 1903, Windows server 2022, WDAC supports up to 32 active policies on a device at once. The following scenarios are supported:
Implementing application control can have unintended consequences, plan your deployment carefully.
The creation of an WDAC Policy depends on the level of restriction you may want to apply to your target devices. You could start with a pre-built template of Windows 10:
Level of Restriction |
Template to be used (C:\Windows\schemas\CodeIntegrity\ExamplePolicies) |
Allowed All Applications |
AllowAll.xml |
Allowed All Enabled HVCI |
AllowAll_EnableHVCI.xml (Enable Hypervisor-Code-Integrity in Memory) |
Allowed All Microsoft Applications |
AllowMicrosoft.xml |
Allowed All Microsoft and Good Reputation Applications |
DefaultWindows_Enforced.xml or DefaultWindows_Audit.xml |
Deny All Applications but the one you choose |
DenyAllAudit.xml |
Other pre-built .xml template for Application or Script Control |
|
Allowed Application deployed by Microsoft Endpoint Configuration Manager (MECM). |
WDAC Policy deployed to Clients at directory location: %OSDrive%\Windows\CCM\DeviceGuard
|
Device Guard Signing Service (DGSS) DefaultPolicy.xml |
Including the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS version 2 |
> Set-RuleOption -FilePath InitialCIPolicy -Option 9
> Set-RuleOption -FilePath InitialCIPolicy -Option 10
> copy InitialCIPolicy.xml EnforcedCIPolicy.xml
> Set-RuleOption -FilePath EnforcedCIPolicy.xml -Option 3 -Delete
Note
To enforce a WDAC policy, you delete option 3, the Audit Mode Enabled option. There is no “enforced” option in a WDAC policy.
> ConvertFrom-CIPolicy EnforcedCIPolicy.xml EnforcedCIPolicy.bin
WDAC - policy rule options |
|
|
Rule option |
Description |
WDAC Wizard Icon |
0 Enabled:UMCI |
WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
|
1 Enabled:Boot Menu Protection |
This option is not currently supported. |
|
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. |
|
3 Enabled:Audit Mode (Default) |
Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. |
|
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. |
|
5 Enabled:Inherit Default Policy |
This option is reserved for future use and currently has no effect. |
|
6 Enabled:Unsigned System Integrity Policy (Default) |
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. |
|
7 Allowed:Debug Policy Augmented |
This option is not currently supported. |
|
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 later drivers will meet this requirement. |
|
9 Enabled:Advanced Boot Options Menu |
The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. |
|
10 Enabled:Boot Audit on Failure |
Used 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 be able to load at boot. |
|
11 Disabled:Script Enforcement |
This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to Constrained Language Mode. NOTE: This option 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 10 without the proper update may have unintended results. |
|
12 Required:Enforce Store Applications |
WDAC policies will also apply to Universal Windows applications. (Microsoft Store App) |
|
13 Enabled:Managed Installer |
Use this option to automatically allow applications installed by a managed installer. For more information, see Authorize apps deployed with a WDAC 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 upon Windows reboot. |
|
16 Enabled:Update Policy No Reboot |
Use this option to allow future WDAC policy updates to apply without requiring a system reboot. NOTE: This option is only supported on Windows 10, version 1709, and above. |
|
17 Enabled:Allow Supplemental Policies |
Use this option on a base policy to allow supplemental policies to expand it. NOTE: 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. NOTE: This option is only supported on Windows 10, version 1903, and above. |
|
19 Enabled:Dynamic Code Security |
Enables policy enforcement for .NET applications and dynamically loaded libraries. NOTE: This option is only supported on Windows 10, version 1803, and above. |
|
Steps to proceed with creating the WDAC Policy by Wizard:
The WDAC Wizard has 3 options for creating, modifying or merge 2 WDAC policies as shown here:
You could create single base policy or multiple base policy or supplemental policies.
Hash:
- Custom Rule by Publisher:
Enter the executable file of the related Publisher for the Wizard to collect the Publisher Sign in Code:
- Custom Rule by File Attribute
Checking the box “Use Custom Values” and Use the glider to choose the attribute as shown here
- Custom Rule by Package App (UWP)
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity.
* To get a list of packaged apps run on a device, run command:
> Get-AppxPackage | ft
> Typing the Package Name to the Wizard under “Package Name” and click Search button as shown:
- Custom Rule by File Hash
You could add multiple file hash separated by comma with Custom rule or use the browser button and specify the file:
- Custom Rule by Folder Path or File Path:
> ConvertFrom-CIPolicy .\SignedReputable052621.xml SignedReputable052621.bin
While a WDAC policy is running in audit mode, any application that runs but are supposed to be denied according to WDAC Audit Policy, is logged in the
Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational event log. Script and MSI are logged in the
Applications and Services Logs\Microsoft\Windows\AppLocker\MSI and Script event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
You must have already deployed a WDAC audit mode policy to use this process.
PowerShell
$PolicyName= "Lamna_FullyManagedClients_Audit"
$LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
PowerShell
> New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback Hash –UserPEs -Mul
More detail here.
There are 4 ways to deploy WDAC:
To activate the WDAC Policy binary file to WMI repository.
Group Policy-based deployment of WDAC policies only supports single-policy format WDAC policies. To deploy multiple policy for Windows 10 version 1903 and later, you will need to use other deploying mechanisms.
You can copy the WDAC policies to a file share to which all computer accounts have access, e.g: \\NYCCL1\WDAC\AllowMSAppEnforcedV3.bin:
Deploying WDAC Policy by MECM (SCCM) for Device Collection.
An Example is shown here:
> Adding File or Folder path as shown here:
> Next and Close.
Deploy WDAC Policy by MDM (Intune)
Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI.
An Example:
After the first reboot to apply the WDAC Policy, then, only Office 365 applications, and Allowed Applications ( Acrobat DC) are able to run. Others (like Chrome) will be blocked as shown here:
Also, you could download and install applications but you could not run it as shown here:
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events are generated under two locations:
Event ID |
Explanation |
3076 |
Audit executable/dll file |
3077 |
Block executable/dll file |
3089 |
Signing information event correlated with either a 3076 or 3077 event. One 3089 event is generated for each signature of a file. Contains the total number of signatures on a file and an index as to which signature it is. |
3099 |
Indicates that a policy has been loaded |
Event ID |
Explanation |
|
8028 |
Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the scripthosts themselves. Note: there is no WDAC enforcement on 3rd party scripthosts. |
|
8029 |
Block script/MSI file |
|
8038 |
Signing information event correlated with either a 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Unsigned script files will generate a single 8038 event with TotalSignatureCount 0. |
Event ID |
Explanation |
3090 |
Allow executable/dll file |
3091 |
Audit executable/dll file |
3092 |
Block executable/dll file |
o reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300
To apply the policy immediately,
> copy the {Policy GUID}.cip binary policy created by the WDAC Wizard location to the CodeIntergrity Active Foder in :
Windows\System32\CodeIntegrity\CIPolicies\Active folder
> Reboot device after copying policy to the above folder.
Detailed steps as in Microsoft document “Configure a WDAC managed installer (Windows 10)”
The denied rule of WDAC Policy related to system driver may cause a loss of OS on testing device.
In WDAC Wizard’ Settings, please make sure to enable “Boot Audit on Failure” feature, it will automatically switch policy mode from enforcement to audit if the system drivers failed to load due to denied rule of Policy. This will save OS from loss because of driver failure in boot procedure.
To prevent loss of OS :
> Click to turn on “Boot Audit on Failure”
> Next and close the Wizard.
> In Windows\System32\CodeIntegrity\CIPolicies\Active folder, replace the old .cip policy with new cip policy and reboot the device to apply new WDAC policy.
> Run WDAC Wizard and Create a Custom Rule based on package App as shown here:
> Type a word related name of package e.g: F5
> Search (button)
> Create Rule
To view the name of your package if you do not know the exact name of WUA
> Go to C:\Program Files\WindowsApps
> View your WUA apps ID
I hope the information is useful for your WDAC deployment. Then, until next time.
Disclaimer
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.