Implementing Windows Defender Application Control (WDAC)–Part 3

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

Understanding Policy Rules

In this article I’ll continue looking at the XML used to create WDAC policies. Specifically, I’ll focus on the EKU block.

If you open up the XML policy file that we have been working through so far, you’ll effectively find just a placeholder for EKUs as shown above.

If you look at another, more complete, WDAC policy, you’ll see that the EKU block is populated as shown above. The block reads like:

I am no expert, but in essence this is telling the WDAC policy about trusted Microsoft certificates for the environment.

To simplify let’s look at:

<EKUID=”ID_EKU_WINDOWS “Value=”010A2B0601040182370A0306 “FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″/>

From what I understand, this refers to capability with PKI style certificate. Trusted certificates are used to sign each file on a Windows 10 device to ensure it is original and untampered with.

The Object Identifier (ODI) number, 1.3.6.1.4.1.311.10.3.6, helps identify who the certificate is from. If you look at this article:

Object Identifiers (OID) in PKI

you’ll learn that a certificate that starts with 1.3.6.1.4.311 is from Microsoft and that the specific certificate 1.3.6.1.4.311.10.3.6 OID is for the Windows System Component Verification.

If we now dig into a typical Windows system file that we want to ensure is secure:

c:\windows\system32\kernel32.dll

and examine that files’ properties, Digital Certificates, Details, View Certificate as shown above, we see that this certificate can be used for:

– Ensuring the software came from the software publisher

– Protects the software from alteration after publication

Which is exactly what functionality we are after.

If we now look at the certificate Details, then select the field Enhanced Key Usage (EKU) as shown above we see:

Windows System Component Verification (1.3.6.1.4.1.311.10.3.6) which matches what we found in the EKU block in the WDAC policy in the lower box.

I will say that I am no expert on how certificates and how they exactly interact with file verification but all we need to know, in essence, is that the EKUs in the WDAC XML file tell the policy which certificates to trust when evaluating whether to trust a file. If the file in question is signed with a certificate that is in the EKU list, then that file will be trusted. This makes it easy to trust a large number of files from Microsoft, which is good as we need to trust Windows system files to boot.

<EKUID=”ID_EKU_WINDOWS “Value=”010A2B0601040182370A0306 “FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″/>

Returning to the EKU line in question from the WDAC policy file, we note that:

Value=”010A2B0601040182370A0306”

This is, as I again understand it, the internal Microsoft identification for the certificate in question. EKU instances have a “Value” attribute consisting of an encoded OID. The process for this Object Identifier (OID) encoding is detailed here:

Object Identifier

which, I must say, is very complex. Luckily, I found this PowerShell function:

https://gist.github.com/mattifestation/5bdcdbadfc4070f9191705853c5481da

which you can use to convert. Now for reasons I can’t yet determine, you need to change the leading 01 to an 06. Thus, to view all the Object IDs using the PowerShell function above you can use the following code:

Which provides the following result:

Note: 1.3.6.1.4.1.311.76.11.1 = AntiMalware EKU

You can select which EKUs you wish to include in the WDAC XML file, but in this case I will include them all.

The best way to add these to the policy, from what I have found so far, is simply to edit the XML and add it. After you do this the modified policy XML file will appear like shown above.

Most of WDAC relies on certificates and verification of signing. I will readily admit that I don’t have a full appreciate for how the world of certificates work, but I hope you, like me, are satisfied enough with what I have detailed here.

So, in summary, the EKU block in the WDAC policy, specifies known certificates from Microsoft that are used to sign Windows system files that we want to trust on the device. Thus, by trusting those certificates we can trust files signed by those certificates. Using the EKU block in the policy allow us to do this for many Microsoft system files quickly and easily and is why, as a best practice, we should include it in the policy.

The next block in the XML policy to focus on will be covered in the next article in the series:

Part 4 – Specifying File Rule