Wdac Windows

[Ophelia Gurin]

Tryinga few different combinations of applying the wdac policy in intune resulted in different registry paths within applocker but no success. Funny thing though, a M365 subscription comes with support so I opened a case.

WDAC policies can only be created on computers beginning with Windows 10 Enterprise or Professional editions or Windows Server 2016. They can be applied to computers running any edition of Windows 10 or Windows Server 2016 and managed via Mobile Device Management (MDM), such as Microsoft Intune. Group Policy or Intune can be used to distribute WDAC policies.

I left the endpoint control profile setting for WDAC to "Not Configured", since Deploy WDAC policies using Mobile Device Management (MDM) (Windows) - Windows security Microsoft D... says the built-in policies use the AppLocker CSP and pre-1903 settings. (I did have it set to Audit Only" previously though).

Figured it out.

I used wbemtest to browse the WMI Bridge to see whether I could find instances of the CI policies.

I found 4, two of which were mine. A third was related to driver integrity, and the 4th was the policy that was getting my way.

I deleted the offtending instance direclty from wbemtest, and now everything works as expected, or at least the CI event log is showing things I expected.

This is somewhat documented here: -us/windows/security/threat-protection/windows-defender-application-con...

Where it mentions that pre-1903 policies must be deleted by script or overridden. Because I had used the intune builtin policy, I fell under this category, even though I was using a 21H2 machine.

I'm trying to disable my device guard policy, what I have done is: windows + R --> gpedit.msc --> Local Computer Policy --> Computer configuration --> Administrative templates --> System --> Device guard --> Deploy Windows Defender Application Control --> Set to not configured as shown on image

I have followed the signing guide exactly as it was written at -us/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering

I have tried what this person had suggested Windows Defender Application Control prevents Windows to boot after second restart (signed policy). I changed the policy GUIDs to those. I still didn't get it to boot after the second reboot

I just created a complete guide about successfully creating, signing and deploying a signed WDAC - Windows Defender Application Control policy, on my Github. the complete version of the guide is on there but I will try to post as much of it as possible in my answer here. I need at least 10 points to be able to post pictures and more than 8 links so I will update my post If i get 10 points.

By deploying a Signed Windows Defender Application Control policy, a system will be secure and resistant to any form of tampering (if coupled with Bitlocker and other built-in security features), in a way that even the system administrator can't tamper or disable this security policy.

That's essentially everything we have to do. So, if you are already familiar with the concepts, you can go straight to the bottom of this page and use the resources section to refer to Microsoft guides to create and deploy the Signed WDAC policy.

But if you aren't familiar, keep reading as I've thoroughly explained every step to set up Windows Server, generate signing certificate and sign the WDAC policy. It takes about 20 minutes for me (as you can see in the video) and depending on the hardware, it can even take less time.

It can be anything, even Bing.com, but for our usage let's use CAServer.com. On the next step, set a password for DSRM (Directory Services Restore Mode), It needs to have uppercase, lowercase and numbers (e.g., Bing6969), write this password down somewhere, like in Sticky notes app on your host.

Next, choose a NetBIOS domain name, the default one will be OK. Confirm and proceed with the rest of the steps by selecting Next and at the end select Install. Wait for the installation to finish. It will restart the Server once the Installation is finished.

From Server Manager => Add Roles and Features => Role-based or feature-based installation => Select the current server we are on => Select Active Directory Certification Service => Select Next for the rest of the steps and finally select install.

After installation is over, open the notifications in the Server Manager, (there will probably be a yellow icon on it), Select "Configure Active Directory Certificate Service on the destination server".

Select Enterprise CA (because Standalone CA does not support certificate templates that we are going to use) and select Next. On the CA Type section select Root CA. On the Private Key section select Create a new private key.

On the Cryptography section, for Cryptographic Provider choose RSA#Microsoft Software Key Storage Provider, for Key length choose 4096, for Hash Algorithm choose SHA512 and select Next. On the CA name section select next. On the Validity Period section set validity period to something like 50 Years. Select next for the rest of the sections and finally select Configure.

Now open Certification Authority, you can do so by searching for it in Windows search or from Server Manager => Tools.Once you open it, you can follow the official guide from Microsoft to create the certificate template for WDAC policy signing and then request and create a certificate.

The guide suggests using a client computer to request and create the certificate but since we are going to use the certificate for non-domain-joined computers and don't need to use the Active Directory, we can perform all of the steps on the same Windows Server VM.

As the Microsoft's guide suggests, you need to go to security tab to verify account access of the user(s) requesting the certificate, but since we are requesting and creating our certificate on the same CA server, we don't need to change anything there.

Once we have the certificate in the User Certificates store of either the Windows Server or a client machine, Right-click on it => All tasks => Export. Export the Private key and export all the Extended Properties, set a password for the certificate and set Encryption to AES256-SHA256. Select a location to export and it will create a .pfx file.

You also need to export the certificate without private key, in DER encoded binary X.509 format which will create a .cer certificate file. We need this certificate to sign the WDAC policy.

It is important to keep these 2 files, specially .pfx that contains the private key, in a safe place, such as Azure Key Vault Managed HSM or OneDrive Personal Vault, so that if you delete all the VMs you created, you will be able to continue using the same certificate to sign further WDAC policies and supplemental policies, at least for the next 22 years, before it needs a renewal. As you can see, all of that setup must be done just once every few decades.

The Personal Information Exchange (.pfx) file has great importance because it contains the Public key and Private key of the certificate so anyone who has access to this file can disable the deployed Signed WDAC policy. It should never be shared with anyone outside your circle of trust. It is a password-protected file by nature.

Run it and only select Windows SDK Signing Tools for Desktop Apps to install. After that signtool.exe will be placed at C:\Program Files (x86)\Windows Kits\10\bin and the WDACConfig module will automatically detect and use it for signing. You can even copy the executable to another location for later usage on another system where SDK is not installed and then use the optional -SignToolPath parameter of WDACConfig module to browse for executable.

After the signed WDAC policy binary .cip is copied to the EFI partition as part of the deployment process, and system is restarted oncee, we can see in System Information that WDAC user-mode is being enforced and when you try to install an application not permitted by the deployed policy, it will be successfully blocked. At this point, since we are using UEFI Secure Boot, the Anti Tampering protection of the Signed WDAC kicks in and starts protecting WDAC policy against any tampering. We need to reboot the system one more time, to verify everything and make sure there is no boot failure.

Deploying a Signed WDAC policy without restarting is the same as deploying Unsigned policies, because the Signed policy can be easily removed just like an Unsigned policy. So always make sure you restart at least once after deploying a Signed WDAC policy.

Deleting the .cip policy file from C:\Windows\System32\CodeIntegrity\CiPolicies\Active and then restarting the system multiple times won't have any effect at all on the status of WDAC. It will continue to work, and enforcement status will be shown in System Information. This is how it protects itself against rogue administrators.

Deleting the .cip policy file from the EFI partition located at \EFI\Microsoft\Boot\CIPolicies\Active and restarting the device will result in a boot failure. Before system restart, nothing happens and it will remain active. This is another self-protection method of a Signed WDAC policy. To recover from this state, the person will need to disable Secure Boot in the UEFI firmware settings. There are only 3 scenarios at this point:

3a8082e126