Implementing Windows Defender Application Control (WDAC)–Part 4

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

EKUs

Unfortunately, from this point forward, I can find no ‘official’ definition of the syntax of the WDAC XML file anywhere. Thus, I have done my best to try and decipher the file. However, please keep in mind, this is simply the determination that I can make looking at the file.

What I’ll focus on in this post is the FileRules block. This block is defined in the XML with the following boundaries:

<FileRules>

</FileRules>

The documentation I found about FileRules specifically is here:

Windows Defender Application Control file rule levels

which says:

File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.

Between these headers can be the following definitions:

1. Generic Files

This would typically appear as:

<FileAttrib ID=”ID_FILEATTRIB_F_1_0_1″ FriendlyName=”Microsoft Teams” ProductName=”MICROSOFT TEAMS” />

2. Allow Files

This would typically appears as:

<Allow ID=”ID_ALLOW_A_1B_ONEDRIVE_1_1″ FriendlyName=”C:\Users\user\AppData\Local\Microsoft\OneDrive\21.119.0613.0001\ErrorPage.js Hash Sha1″ Hash=”25D362DEE9A4B04ACDFD0ABBAB7A415AA494DC98″ />

3. Deny files

<Deny ID=”ID_DENY_BASH” FriendlyName=”bash.exe” FileName=”bash.exe” MinimumFileVersion=”65535.65535.65535.65535″/>

Each of these definitions starts off with a ‘ID’ field either: FileAttrib ID, Allow ID or Deny ID. Next, comes a variable that will be used later to refer to the specifics of that file definition. Here those are: ID_FILEATTRIB_F_1_0_1, ID_ALLOW_A_1B_ONEDRIVE_1_1 and ID_DENY_BASH. From what I can determine, these IDs can be any text.

Next, is the FriendlyName field, which again can be any text but typically will be the file name, with or without the path. From what I can determine, this is simply a ‘tagging’ field. If the FileName or is not specified this Friendlyname field will be used as the actual file name.

The next field options are used to actually define the individual file on the system. This can be achieved in a number of different ways specified, including by path and file name, hash, file path, publisher and more as detailed here:

Windows Defender Application Control policy – file rule levels

The most common types of definitions I have found are:

– FileName field, which actually refers to the executable file i.e. bash.exe as shown above.

– FilePath field. which refers to the location of the executables i.e. C:\Program Files\*

– ProductName can be used to identify the file in question. I assume this refers to a product that is registered with the operating system.

– Hash which specifies a unique file hash

It appears that you can also use the field MinimumFileversion when specifying the Fieldname and Productname definitions

These file rule definitions will be utilised by later items in the XML configuration, so they must be present if they are going to referred to.

You can use the

New-CIPolicy

and

New-CIPolicyRule

for drivers

PowerShell command to generate these file rules.

The precedence order of these file rules is defined here:

File rule precedence order

but is basically, deny, then allow, then the rest.

That’s the best I can work out from the documentation and experimenting. I’m sure there is more information somewhere, and if you do find any, please let me know.

Part 5 – Specifying Signers