Implementing Windows Defender Application Control (WDAC)–Part 2

This post is part of a series focused on Windows Defender Application Control (WDAC). The previous article can be found here:


In this article I’m going to start looking at the XML you use to create policies.

WDAC policies are composed using XML format. You can view a number of example policies on any Windows 10 device by navigating to:


and looking at the file I’ll be starting is process with:



The first item I want to examine is the Rules block contained within the tags <Rule></Rule> and everything in between as shown above.

Information about the available rules is contained here:

Policy rule options

As a best practice, I would suggest the following rule options should be set:

0 Enabled:UMCI – Enabling this rule option validates user mode executables and scripts.

2 Required:WHQL – 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 – 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. That will come later in our process, so no now we’ll only be logging results of the policy/

4 Disabled:Flight Signing –  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. In short, we don’t to support Windows Insider builds with our policy.

6 Enabled: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.

8 Required:EV Signers – This rule requires that drivers must be WHQL (Windows Hardware Quality Labs) 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.

9 Enabled:Advanced Boot Options Menu – Setting this rule option 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.

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 load.

12 Required:Enforce Store Applications –  WDAC policies will also apply to Universal Windows applications.

13 Enabled:Managed Installer – 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 – 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 (above)  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.

16 Enabled:Update Policy No Reboot – allow future WDAC policy updates to apply without requiring a system reboot.

Since we are going to be modifying the WDAC policy, best practice is to take a copy of the example start point XML file and modify that. Thus, take a copy of:


and use this going forward.

There are two methods of adjusting this new policy. You can directly edit the XML file or you can make the modifications using PowerShell.

To add a policy rule option add the appropriate rule setting encapsulated by <Rule></Rule> and <Option></Option> tags within the <Rules></Rules> global tag like so:



  <Option>Enabled:Audit Mode</Option>




and like what is shown above.

You can also make the same updates using PowerShell. The new, copied XML prior to modification appears like:


with five rules. To add the additional rules detailed above use the following:

Set-RuleOption -FilePath “.\newaudit.xml” -Option 0
Set-RuleOption -FilePath “.\newaudit.xml” -Option 2
Set-RuleOption -FilePath “.\newaudit.xml” -Option 3
Set-RuleOption -FilePath “.\newaudit.xml” -Option 4
Set-RuleOption -FilePath “.\newaudit.xml” -Option 6
Set-RuleOption -FilePath “.\newaudit.xml” -Option 8
Set-RuleOption -FilePath “.\newaudit.xml” -Option 10
Set-RuleOption -FilePath “.\newaudit.xml” -Option 12
Set-RuleOption -FilePath “.\newaudit.xml” -Option 13
Set-RuleOption -FilePath “.\newaudit.xml” -Option 14
Set-RuleOption -FilePath “.\newaudit.xml” -Option 15
Set-RuleOption -FilePath “.\newaudit.xml” -Option 16

where newaudit.xml is the policy file being built. The numbers for each option correspond to the:

Policy rule options


If you open the XML policy file you should now see all the rule options have been added as shown above (13 in all).

In summary then, we have taken an example policy provided by Microsoft and started to modify it to suit our needs. This modification can either be done by directly editing the XML file or using PowerShell commands. I’d suggest PowerShell is a better way because you can save all the commands together in a script and re-run it if you wish.

With this first modification of the policy complete we’ll next look at how to work with the EKU area in the XML file.

Part 3 – Understanding EKUs

Implementing Windows Defender Application Control (WDAC)–Part 1

Windows Defender Application Control (WDAC) is a technology that is built into Windows 10 that allows control of what applications execute on the device.


WDAC also allows you to control which drivers are allowed to run and is thus, a very powerful security measure that many should consider implementing. A typical WDAC blocking message is shown above.

Microsoft also has an older application white listing technology known as AppLocker. Here is the recommendation from Microsoft when choosing between the two technologies:

“Generally, it is recommended that customers, who are able to implement application control using WDAC rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.”

You can deploy AppLocker and WDAC together if your wish, and thus the best practice recommendation from Microsoft is:

“As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.”

This is also a good side by side feature comparison here:

Windows Defender Application Control and AppLocker feature availability

So, WDAC it is!

WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:

– Attributes of the codesigning certificate(s) used to sign an app and its binaries

– Attributes of the app’s binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file

– The reputation of the app as determined by Microsoft’s

– Intelligent Security Graph

The identity of the process that initiated the installation of the app and its binaries (managed installer)

– The path from which the app or file is launched (beginning with Windows 10 version 1903)

– The process that launched the app or binary

WDAC policies are composed using XML. You can view a number of example policies on any Windows 10 device by navigating to:


and looking at the file I’ll be starting is process with:


and building from there.

Before we get too much further along I need to give you this warning. Application whitelisting is a lot of work to implement and maintain. The more variations (i.e. third party software) you have floating around the environment, the more challenging it is to implement. Also, remember that application whitelisting of ANY form is placing restrictions on user productivity. The things you do with tools like WDAC have the potential to severely restrict users ability to do their job. This can result in the ‘local villages’ pitching up to your door with burning effigies, sharp weapons, menacing looks and foul language if you are not careful. I’ll give you my best practices for reducing the pain and suffering but be prepared for this to be a journey rather than a set and forget update.

Before anything else, I would suggest that you should be conducting a software audit in your environment. You should know what applications are being run by users, however, I’ll guarantee that you won’t know them all. This should not preclude you from at least making an attempt to catalogue what you have. Doing so will save you a lot of pain in the long run.

Next, you’ll create start creating a default WDAC policy in audit mode to see what is actually happening and what issues may be faced. This policy will then be adjusted along the way to accommodate any required inclusions (typically third party software). Once that stage has been completed, the policy will then be flipped from audit to enforcement mode to actually start preventing unknown applications from running.

That’s the plan for these upcoming series of WDAC articles and I hope you’ll follow along and with the knowledge I share look to implement WDAC in your own environment.

Part 2 – Understanding a basic WDAC policy

Need to Know podcast–Episode 274

In this episode I speak with George Farah from Ingram Micro Cloud about the changes in the partner economics brought about by the move to the Microsoft Cloud over the years. The discussion provides a great opportunity to pause and reflect on your business focus in today’s IT environment.

I also cover off the latest Microsoft Cloud news to bring you right up and update.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Brought to you by

Take a listen and let us know what you think –

You can listen directly to this episode at:

Subscribe via iTunes at:

The podcast is also available on Stitcher at:

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.


George Farah – Linkedin, Email –

Basic Authentication and Exchange Online – September 2021 Update

New minimum Outlook for Windows version requirements for Microsoft 365

Analyzing attacks that exploit the CVE-2021-40444 MSHTML vulnerability

A deep-dive into the SolarWinds Serv-U SSH vulnerability

Hunting for OMI Vulnerability Exploitation with Azure Sentinel

Introducing new Surface products, built for Windows 11

Viva Connections public preview is now available!

The passwordless future is here for your Microsoft account

Announcing General Availability of Azure AD-joined VMs support

Microsoft Teams Public Preview indicator “P” on avatar

Restricting user file downloads in SharePoint Online

There are situations with SharePoint Online where businesses wish to restrict users from downloading files. Unfortunately, this can’t be done at a document library level but I can be done at a user level provided you have licenses for Conditional Access.

Conditional Access is a features of Azure AD P1 and is included in SKUs like Microsoft 365 Business Premium. The above video takes you through the steps of configuring an appropriate Conditional Access policy in your environments to prevent downloads. The policy can be targeted at specific users and expanded to include other Microsoft 365 cloud services if desired.

Allow contribute with no delete in SharePoint

By default, users in SharePoint can created, modify and delete file. This deletion capability also extends to files that they may not have created. This is the default nature of collaboration.

However, there are times when businesses may want an environment that allows collaboration but prevents user deletion of a file from say, a document library.

In this video:

I’ll show you how to set that up. In essence, an administrator needs to create a new custom permission level in SharePoint that excludes the delete capability. They then need to assign that new permissions to the location and users where they wish to apply this. The great thing is that once it is set up, it can be used across the whole site collection.

Testing for CVE-2021-40444 vulnerability

There are current concerns around:

Microsoft MSHTML Remote Code Execution Vulnerability

which is yet to have a patch made available.

I found this excellent article:


which provide some PowerShell scripts to create Word documents that can be used to test for the vulnerability.

I have run these scripts to create the actual Word documents and uploaded them for you here:

Office365/example at master · directorcia/Office365 (


In both cases, when you open these documents, you should NOT be able to get CALC.EXE to execute on your system unlike what you see above and below.


I have also added these tests to my security testing script which you can download from my GitHub repo here:

Office365/sec-test.ps1 at master · directorcia/Office365 (


When I opened these documents in my production environment, the vulnerability was largely blocked thanks to Windows ASR which I have detailed previously:

Attack surface reduction for Windows 10

You can use the follow KQL query as I did above to view the result of this blocking if you are using something like Azure Sentinel like I am:

Another great security add on for Microsoft 365


| where ActionType startswith ‘Asr’

Need to Know podcast–Episode 273

Listen along as I speak with IT business owner David Nicholls from Solve Business Services on his journey to becoming a ‘modern’ cloud IT Professional. David shares the successful processes and approaches he has taken to ‘transform’ his business to be providing cloud support services.

Also, plenty of news and updates from the Microsoft Cloud, including the announcement date for Windows 11. so tune in to stay up to date.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Brought to you by

Take a listen and let us know what you think –

You can listen directly to this episode at:

Episode 273 – David Nicholls (

Subscribe via iTunes at:

The podcast is also available on Stitcher at:

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.


David Nicholls – Web, Linkedin

Windows 11 available on October 5

Windows 11 preview is now available on Azure Virtual Desktop

Introducing Microsoft Defender for Endpoint Plan 1

Get free DMARC visibility with Valimail Authenticate and Microsoft Office 365

Announcing Apple M1 native support for Microsoft Defender for Endpoint

Simplifying the Quarantine Experience

Securing your Windows 365 Cloud PCs

Troubleshoot Windows 365 Business Cloud PC setup issues