[FIXED] Windows Defender Application Control does not work with Secure Launch
PLEASE NOTE THAT THIS ISSUE HAS NOW BEEN FIXED BY THE MICROSOFT PRODUCT GROUP. THIS BLOG IS NOW INFORMATIONAL ONLY.
I’ve been working with Windows Defender Application Control (WDAC) a lot recently and have come across a few undocumented bugs that might be worth knowing about. This is the second of two bugs that I wanted to share on the blog. Microsoft are currently working on both issues in the Product Group, so these blogs may soon be struck down and rendered irrelevant, but until then, I’d like to describe the issues and the workarounds to save fellow engineers the grief.
Symptoms
You can apply and enforce a WDAC policy using a Unified Endpoint Management product (or manually) but it won’t stay enforced upon a reboot (apps no longer being blocked),
Upon reviewing the CodeIntegrity Event Log (Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational) you only see the following event:
“Code Integrity will enable WHQL driver enforcement for this boot session. Settings 0x0. Exemption 1." (Event ID 3084)
When the WDAC policy is applied and enforced in the user session, the machine blue screens within 60 minutes.
When I was investigating this issue I found the symptoms to be paralysing - you could not feasibly implement and maintain a WDAC policy if it couldn’t keep itself enabled, and was likely to cause bluescreening.
Diagnostic hell
In a similar fashion to the other blog (Windows Defender Application Control can cause bluescreening (currently)) I was having to investigate reasonably deeply to find out what was causing these issues, though some observations stood out to me:
The machine only blue screened when WDAC was enabled (often using the refresh policy tool while testing),
Only a few models of laptop were having these issues - it was not consistent across our pool of test devices,
It did not seem to be connected to the known issue identified by Microsoft with WDAC Option 16
<Option> Enabled: Update Policy No Reboot </Option>.
Having provided a full memory dump to a senior Microsoft engineer, the problem was linked to a second known issue related to the configuration and enforcement of the System Guard Secure Launch feature alongside WDAC.
It appears that while Secure Launch is enabled, the operating system cannot read the WDAC configuration file from the EFI partition at boot time. This explains how a simple reboot can deactivate application control, though it doesn’t perfectly explain the bluescreening, which may just be a symptom of the same issue.
The reason that these issues only affected some of our test devices was related to the generation of processor on board each of the machines. Later generations of processor support hardware based virtualised security features, and some of our devices processors were not new enough to support the Secure Launch feature.
Turning off System Guard Secure Launch - not as easy as it sounds
While the issue is being worked on in the Product Group it may come down to your local security to make a decision on whether you choose WDAC over Secure Launch. It may even become the straw that broke the camels back for your implementation of application control (temporarily, I hope!) as it stands, as these are not the only two complexities and bugs affecting the product.
Turning off Secure Launch would be an easy fix, if it was as easy as simply unconfiguring it. We found that you could not unenforce, or even reverse, the Secure Launch configuration because of how Credential Guard UEFI locks behave. Long story short…
“The "Enabled with UEFI lock" option ensures that Virtualization Based Protection of Code Integrity cannot be disabled remotely. In order to disable the feature, you must set the Group Policy to "Disabled" as well as remove the security functionality from each computer, with a physically present user, in order to clear configuration persisted in UEFI.”
If you have UEFI locks configured, and Secure Launch was switched on, you need to clear the keys in the BIOS, including some user interaction. Yikes - not going to happen!
You can see this happening yourself on a test system by configuring UEFI locks and Secure Launch, then unconfiguring Secure Launch using your UEM solution. You’ll find that within MSINFO32 the “Virtualisation-based security services configured” will drop Secure Launch, but “Virtualisation-based security services running” will retain it, meaning it is still switched on.
Though this makes sense from a security point of view, it’s another complication for remote administrators to have to work around.
Fortunately there’s another way that we can remotely “fix” the issue, at least on systems that use IntelTXT. By turning off IntelTXT in the BIOS you can quietly break Secure Launch, whilst leaving your configuration policies untouched.
You’ll be configuring Secure Launch but Secure Launch won’t be able to start any more, kind of like how WDAC couldn’t start…
If you are happy to make this trade, you should be able to find a similar temporary solution for AMD machines.
You should be able to resolve it by configuring, testing, and releasing a BIOS configuration change using remote BIOS management tools and your UEM solution. Keep a note of what you’ve done, as you will want to invert the settings later on when Microsoft have fixed this bug!