When we implement a Windows Defender Application Control (WDAC) policy, we need to allow or deny different types of executable file. Different methods of creating a policy handle file types differently. This post is an attempt to explain how it works in practice.
The basic challenge is that you need to identify a file sufficiently to know whether it should be allowed to run or not. WDAC has two ways to allow (or deny) a file: by file rule; or by certificate. These are identified in the XML as members of the FileRules or the Signers collection.
File Rules include:
- Hash
- FileName – the internal name of the file, without a path
- FilePath – the fully qualified path and file name
Signers include:
- LeafCertificate – the actual code signing certificate the file is signed with
- Publisher – a combination of the signing certificate and the issuing CA
- PcaCertificate – just the CA that issued the signing certificate
As variations, you can also have combinations of version or filename with certificate; and WHQL signing.
Hash is the most specific file rule. It is also the only method that identifies a file uniquely. FilePath is any file object with the same fully qualified path and name (i.e. you can update the file); and FileName is any file object with the same name (i.e. in any location). The FilePath with wildcard is a special case of FilePath, allowing files with different names in the same path. Similarly, the FileName with wildcard is a special case of FileName, allowing any file at all.
Signers allow different files with the same certificate. They can be different files signed with the same certificate; or different files from the same publisher; or any file from any publisher using the same intermediate certificate. The higher up the chain the certificate is, the more different files (including files not already on the device) will be allowed to run. But conversely, any unsigned file will not be allowed to run. The scan for certificates (in New-CIPolicy) has a –Fallback switch to capture the hash of any unsigned file.
What is less obvious is that the scans at different levels also capture (or skip) different types of file.
| Level | Capture | Skip |
| Signer | Any signed file | Any unsigned file |
| Hash | Any existing file | None |
| FileName | File by internal filename | Any file without an internal filename |
| Filepath+Name | File by path | Any user-writeable file |
| Filepath+* | Files in path | SYS, MSI, PS Scripts. Any user-writeable file |
A scan with a signer level will capture most existing files on the drive. This will work for a file of any type, in any path, signed by a recognised certificate. So probably we want a base policy that allows signed software from all the major legitimate software vendors.
The FilePath policy+wildcard will allow any new EXE and DLL files that we install into Program Files or any other allowed path.
If we merge these two, then we are most of the way towards a working WDAC policy.