Windows Defender Application Control prevents Windows to boot after second restart (signed policy)

Question

Hy everyone!

I want to lock down some Windows 10 Terminals so that they can only run approved Software but keep the possibility to update this software.

My plan was to make use of the new Feature of Windows 10 1903 that allows the use of Multiple CI Policies (as described here: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies ). To test this, I placed a signed policy under "C:\Windows\System32\CodeIntegrity\CIPolicies\Active\{PolicyID}.cip" in a VMware virtual Machine running Windows 10 1903. After the first boot, the policy gets activated and prevents all applications (except the permited ones) from being executed. However, if I reboot the system again, VMWare fails to boot Windows until I disable Secure Boot. (It seems like the OS is not installed, I land up in the UEFI Configuration) Using the same policy without the signature works fine, but I want to make sure that the administrators on those terminals don't tamper with the policy or delete it, that's why I want to sign the policy.

To sign it, I generated a CodeSigning Certificate as described here: https://blogs.technet.microsoft.com/ukplatforms/2017/05/04/create-code-integrity-signing-certificate/ After that, I added the certificate to the policy using following command:

Add-SignerRule -FilePath .\policy.xml -CertificatePath .\codeSigningCertificate.cer -Update

With the Signer Rule in place, I removed the Option to accept unsigned policies using:

Set-RuleOption -FilePath .\policy.xml -Option 6 -Delete

Then I converted the policy to the binary format using:

ConvertFrom-CIPolicy -XmlFilePath .\policy.xml -BinaryFilePath .\policy.cip

Finally, to sign the Policy, I used the signtool with following parameters:

signtool.exe sign -v /n CodeSigningCertificate -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 .\policy.cip

I copied the resulting "policy.cip.p7" file to a fresh installation under "C:\Windows\System32\CodeIntegrity\CIPolicies\Active\{PolicyID}.cip" and got the described behavior.

Here's some stuff I also tried:

Using "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b" to deploy one policy: That worked fine, but Windows did not care when I deleted the policy. It just got deactivated. My understanding of using a signed policy is, that Windows should throw some kind of error or prevent a boot when someone tampers with it.

Checking if the virtual Machine supports the Device Guard functionality: I used the dgreadiness tool to test if the VM meets the criteria to use device guard. The tool reported the following lines:

PS C:\Users\User\Downloads\dgreadiness_v3.6> .\DG_Readiness_Tool_v3.6.ps1 -Capable
###########################################################################
Readiness Tool Version 3.4 Release.
Tool to check if your device is capable to run Device Guard and Credential Guard.
###########################################################################
###########################################################################
OS and Hardware requirements for enabling Device Guard and Credential Guard
 1. OS SKUs: Available only on these OS Skus - Enterprise, Server, Education, Enterprise IoT, Pro, and Home
 2. Hardware: Recent hardware that supports virtualization extension with SLAT
To learn more please visit: https://aka.ms/dgwhcr
###########################################################################

Checking if the device is DG/CG Capable
 ====================== Step 1 Driver Compat ======================
Driver verifier already enabled
Verifying each module please wait ....
Completed scan. List of Compatible Modules can be found at C:\DGLogs\DeviceGuardCheckLog.txt
No Incompatible Drivers found
 ====================== Step 2 Secure boot present ======================
Secure Boot is present
 ====================== Step 3 MS UEFI HSTI tests ======================
Copying HSTITest.dll
HSTI Duple Count: 0
HSTI Blob size: 0
String:
HSTIStatus: False
HSTI is absent
 ====================== Step 4 OS Architecture ======================
64 bit arch.....
 ====================== Step 5 Supported OS SKU ======================
This PC edition is Supported for DeviceGuard
 ====================== Step 6 Virtualization Firmware ======================
Virtualization firmware check passed
 ====================== Step 7 TPM version ======================
get-tpm : Object was not found. (Exception from HRESULT: 0x80090011)
At C:\Users\User\Downloads\dgreadiness_v3.6\DG_Readiness_Tool_v3.6.ps1:818 char:21
+     $TPMLockout = $(get-tpm).LockoutCount
+                     ~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-Tpm], TpmWmiException
    + FullyQualifiedErrorId : Microsoft.Tpm.Commands.TpmWmiException,Microsoft.Tpm.Commands.GetTpmCommand

TPM is absent or not ready for use
 ====================== Step 8 Secure MOR ======================
Secure MOR is available
 ====================== Step 9 NX Protector ======================
NX Protector is available
 ====================== Step 10 SMM Mitigation ======================
SMM Mitigation is available
 ====================== End Check ======================
 ====================== Summary ======================
Device Guard / Credential Guard can be enabled on this machine.

The following additional qualifications, if present, can enhance the security of Device Guard / Credential Guard on this system:
HSTI is absent
TPM is absent or not ready for use

To learn more about required hardware and software please visit: https://aka.ms/dgwhc

Installing the CA of the code signing certificate as a trusted root certificate to the machines Certificate Store: This did not change anything on the behavior.

Does someone have any suggestions what I can do about this or has some ideas what I did wrong?

Thanks for your Help

Martin

Answer 1

It seems that the use of multiple CI Policies as described here does not fully work yet. In order to solve the windows not booting problem, the base policy has to have the GUID set to {A244370E-44C9-4C06-B551-F6016E563076}. This is als the GUID used in the example Policies found under "C:\Windows\schemas\CodeIntegrity\ExamplePolicies". When using this GUID the policy activates and the signature gets validated correct. As long as no other valid policy with a higher Version number gets deployed, the old policy is active, even if someone deletes the policy file. So the policy is safe from beeing tampered with.

However, there are some functions described in the link that do not work as intended (maybe the feature is not ready to be fully used yet):

• Use multiple Base Policies: With a second base policy in place, Windows would show an error during boot stating, that there was a problem validating a signature.
• Tampering with the supplimental policies: Windows would check the Signature of the supplimental policies but would also be OK if someone removes them or replaces them with an older version.

With those shortcomings, I don't really see a use of the multiple Policy feature for now.

What I will be using instead is one CIPolicy with a rule for an own code signing certificate. That way I can sign security catalogs holding informations about permited programs as suggested by harrymc and described here. This seems to work more stable and easy to use.