On a Windows Defender Application Control (WDAC) project one issue you may encounter is driver .dll or .sys files that are digitally signed, but the certificate has now expired. The software is valid and in most cases safe to use, and it can be seen that the DLL was signed during the validity period of the signing certificate, however WDAC sees such libraries and executables as un-trusted and prevents their execution.
When files such as these are blocked (or audited), you will get two code integrity error codes in the Code Integrity Event Log. If the device is in Audit mode you will get a 3034 and 3076, whereas if the device is in Enforcement mode the error codes will be 3033 and 3077.
The work-around
The WDAC documentation for the 3033/3034 error gives two instructions for resolving the issue:
- Try using option
20 Enabled:Revoked Expired As Unsignedin your policy – this one is very straight forward. - Use a non-signature rule (for example, hash) to address issues with revoked or expired certs.
Part 2 of that seems very straight forward, for example based on that instruction you would think it would be possible to use a File Path rule. For example add a rule trusting all files in C:\Windows\drivers.
Unfortunately however it appears WDAC ignores File Path rules for such files and the only option for the policy to allow such files is by using a File Hash rule. Using the file hashes certainly works, however has all the drawbacks associated with attempting to whitelist files using file hashes.
Be aware when generating policies
If you are using the PowerShell cmdlet New-CIPolicy to generate a WDAC policy from event logs on a device be aware. Generally you want to generate the policy using publisher certificates by default (using the parameter value -Level Publisher).
Be aware if you are faced with the scenario of a dll with an expired signature, the PowerShell cmdlet generates the policy using the expired Publisher Certificate – the file is still going to be blocked and at a cursory glance it looks like the policy is perfectly valid and should allow the file to execute.
In these scenarios it appears the only solution is to then generate (or build) a policy for these files using a file hash.