The goal of this post is to step through the process of using the WDAC Wizard to create a sample WDAC policy and deploy it to a test Windows 10 or 11 device.
If you’re not familiar with WDAC, or unfamiliar with some of the terms used in this post, refer to my earlier post Application Control with WDAC that introduces application control and provides a summary of WDAC and how it works.
What is the WDAC Wizard?
The WDAC Wizard is a tool that makes creating and maintaining WDAC policies simpler through a user interface, rather than always having to use the Code Integrity PowerShell module (which is built into Windows) or manipulating the XML policy file manually.
Installing the WDAC Wizard
To install the wizard simply go to the WDAC Wizard website, click Download the Installer and follow the installation prompts.
On Windows 11 it appears there is an issue performing the installation using the provided link and it is necessary to download and run the installation package manually using this link: https://webapp-wdac-wizard.azurewebsites.net/packages/WDACWizard.appinstaller
Creating a policy
To keep creating this first policy simple and straight forward, we’ll create a policy with as close to the default settings as possible.
1 – Open the WDAC Wizard and select Policy Creator
2 – At the Select a Policy Type screen leave the default values and click Next
3 – At the Selecting a Base Template for the policy screen you are provided with 3 options for building the base policy – as a brief summary of the policy options:
- Default Windows mode – allows Windows OS components, Microsoft Store applications, Office 365/One Drive/Teams applications and WHQL signed drivers
- Allow Microsoft mode – in addition to Default Windows mode also allows All Microsoft signed applications to run.
- Signed and Reputable mode – in addition to Allow Microsoft Mode software with a known good reputation in the Intelligent Security Graph (ISG) is allowed to run.
In this scenario we’ll use the Signed and Reputable Mode (which is the most permissive policy), accept the default Policy Name and file location then click Next.
4 – At the Configure Policy Template screen we’ll use the default settings. At this stage the Audit Mode flag is the most critical one, when its enabled (like in the screenshot below) the policy is in Audit mode rather than Enforcement mode (which will prevent applications not in the policy from being able to run). Then click Next.
All the rules are defined in the Understanding WDAC policy rules article, and something that we’ll cover in the future.
5 – The File Rules screen is where the rules are configured to allow and deny software, for the time being we’ll keep the default settings as the base policy to start from, and click Next.
Note: As this is the signed and reputable policy, the majority of the file rules allow Microsoft signed software to run.
6 – We’ve now created an audit policy! The WDAC Wizard will confirm where the policy files have been saved, and note that there are two files generated by the Wizard:
- The XML file is the policy configuration file, which should be saved in a source code control solution, and can be edited later using the WDAC Wizard in Policy Editor mode.
- The CIP file is the binary WDAC policy file that gets deployed to Windows devices.
Deploying the policy
The next step is to then deploy the audit policy to a testing machine. There are numerous ways to deploy a WDAC policy within a corporate environment, but for this exercise we’ll perform the deployment manually to a Windows 10/11 device.
Deploying to Windows 11
1 – Open a PowerShell console and then run the following command (replacing the file path with the equivalent policy that was created by the WDAC Wizard).
citool –update-policy ‘C:\users\andrew\Documents\{7F1B11F9-86C5-466E-BA5D-03288D901F05}.cip’
2 – Then run citool –list-policies to confirm the policy has been deployed
Deploying to Windows 10
1 – Copy the CIP file generated by the WDAC Wizard to the directory C:\System32\CodeIntegrity\CIPolicies\Active\
2 – Download the Refresh WDAC Policy tool.
3 – Run the RefreshPolicy executable you have downloaded.
Confirm the policy has been deployed
The steps below can be used to confirm that the policy has been loaded on the device successfully.
1 – Run msinfo32.exe and locate in the System Summary the value for Windows Defender Application Control user mode policy which should now show Audit.
2 – Open Windows Event Viewer (eventvwr) and open the Operational event log under Applications and Services Logs > Microsoft > Windows > Code Integrity.
3 – Look for an event with the Event ID 3099 indicating the policy has been loaded. The event details will include the name of the policy you created and the GUID will match the name of the CIP file deployed.
Testing out the audit policy
The simplest way to test out the policy is to install and run some applications, and because this is an audit policy they any applications you use won’t be blocked. If the applications aren’t allowed by the policy events will be generated that can be reviewed (more on that later).
Also be aware that as this sample policy has the Intelligent Security Graph (ISG) enabled it will likely allow many reputable applications to run (such as Google Chrome) without audit events being generated. Additionally as the reputation of an application can change, the results can also change.
Installing Notepad++
To test out the policy we’ll install Notepad++, here’s the process:
1 – Download the latest version of NotePad++
2 – Complete the installation steps.
3 – Run Notepad++
4 – Now open Windows Event Viewer (eventvwr) and open the Operational event log under Applications and Services Logs > Microsoft > Windows > Code Integrity
5 – For simplicity Filter the current log to display only 3076 events (this is the event that indicates an application would be blocked if this was an enforcement policy).
6 – In this case we can see the event where Notepad++ has been run, and a 3076 event has been generated. This indicates that if this policy was put into enforcement mode the application would be blocked by WDAC and not allowed to execute.
Testing out enforcement mode
Now that we can see that this sample policy wouldn’t allow Notepad++ to execute, lets convert the audit policy to enforcement mode and see what happens.
Note: The steps below aren’t how you’d normally convert a policy from audit mode to enforcement mode. Typically you’d want a different policy GUID, however in this specific scenario we’re keeping the same one for simplicity.
Updating the policy to enforcement mode
1 – Open the WDAC Wizard, and select Policy Editor.
2 – Browse and locate the XML file that was created earlier. In this case we’ll add Enforce to the start of the Policy Name and the new save location file name, then click Next.
3 – At the Configure Policy Template screen turn off the Audit Mode flag, so this will then be an enforcement mode policy. Then click Next.
4 – At the File Rules screen again click Next, which will save an updated set of files.
5 – Complete the Deploying the policy steps again to re-deploy the policy (i.e. the using citool for Windows 11 or the policy refresh tool for Windows 10).
6 – Open msinfo32.exe again and the device should now be in Enforced mode.
7 – Run Notepad++ again and you should see an error similar to the one below. Also in the Code Integrity Operational log you’ll find there should now be at least one 3077 event indicating an application has been blocked by WDAC.
What’s next?
Once you have an audit policy deployed you then need to start installing and using the applications that need to be allowed by the WDAC policy. This testing needs to be thorough to test all the commonly used functions, as for example Microsoft Teams might work but if your audio driver is blocked by WDAC people may not be able to make calls or join meetings.
In the next post in this series we’ll run through the process of modifying the policy to allow Notepad++ to run, which is a digitally signed application.
WDAC Series posts
Below are the links to the posts in this series.