After we looked at patch management optimization last month, this month’s topic is Credential Guard. Since there are already numerous articles (Link, Link, Link) on the technology as such, we would like to focus on the implementation of the technology in an existing infrastructure.

If you read Microsoft’s documentation, you realize that all you have to do is configure a Group Policy and the rollout is done. So why this blog post? The reasoning lies in the way Credential Guard works and the implications of it.

Backgroung

The original idea in the design of Windows (and in many much older operating systems as well) is a separation between a kernel mode and a user mode. The Windows kernel runs in a privileged processor mode with full access to system data and hardware, while other parts of Windows and all applications run in user mode with limited access to system data and no direct access to hardware. However, it is also within kernel mode that most device drivers are run, and many of these come from third-party companies. Microsoft states that there are a million unique hashes of drivers in the telemetry data – every month! Credential Guard uses “Virtualization Based Security” to provide its own protected environment with a separate kernel where credentials are stored. To enable this virtualization, there are some prerequisites to be met:

 

• • Support for Virtualization-based security (required)
  • Secure boot (required)
  • Trusted Platform Module (TPM, preferred – provides binding to hardware) versions 1.2 and 2.0 are supported, either discrete or firmware
  • UEFI lock (preferred – prevents attacker from disabling with a simple registry key change)

 

The “virtualization-based security” needs:

• • 64-bit CPU
  • CPU virtualization extensions plus extended page tables
  • Windows hypervisor (does not require Hyper-V Windows Feature to be installed)

 

Credential Guard is also supported in VMs, for which the following requirements are necessary:

• • The Hyper-V host must have an IOMMU, and run at least Windows Server 2016 or Windows 10 version 1607.
  • The Hyper-V virtual machine must be Generation 2, have an enabled virtual TPM, and be running at least Windows Server 2016 or Windows 10.
  • TPM is not a requirement, but we recommend that you implement TPM.

 

It doesn’t sound like much in 2021, but how does it work in practice?

Hardware

From the list of requirements we can see that two things are necessary:

• • A 64 bit processor, which can virtualization extensions and extended page tables
  • A TPM (min. 1.2) chip or a processor that implements the TPM in the firmware.

The virtualization extensions were introduced around 2006, the extended page tables around 2009. The TPM 1.2 specification was published in 2011.

As a rule, the hardware in the current lifecycle supports Credential Guard.

Unfortunately, exceptions prove the rule. Just recently, we found a productive Windows 3.11 PC during an assessment. It is certainly not running on compatible hardware. It is also possible that client hardware from the consumer product lines is in use and therefore does not meet all the necessary requirements.

The good news is that if Credential Guard is enabled via GPO on a system that does not meet the prerequisites, nothing will happen except that Credential Guard will not run. The bad news is that Credential Guard does not run. You may think you are safe, but you are not protected.

BIOS Settings

It is not enough that the hardware supports the necessary features, they also have to be enabled in the BIOS. Unfortunately, every manufacturer names the functions a bit differently, which is why we won’t mention the specific settings here.

Current hardware is often delivered in such a way that Credential Guard can be used directly. A few years ago, however, this was not the case. At first glance, the problem sounds smaller than it is. To illustrate, here is a real-life scenario:

A pan-European company with about 20,000 clients. There are about 20 different notebook and desktop models from one manufacturer in circulation. The refueling infrastructure is provided centrally, but the devices are provisioned regionally.

The first question is whether all clients have the necessary BIOS settings set. After all, no one thought about Credential Guard (up to) 3 or 5 years ago. Fortunately, the BIOS settings can be read out centrally using SCCM. Result: The BIOS settings are not consistent, several thousand clients do not have the necessary settings activated ☹️.

How can you solve the problem? Well, most hardware manufacturers offer tools to configure BIOS settings centrally. The catch is that you need the BIOS password for this. Surely no problem, the company has a standardized deployment process after all…

In the test lab, we noticed that only upper case can be used in some models. On one model, it was not possible to enter @. Stupidly, the default password contains both lowercase letters and the @ character. Too bad.

In the end, a coordinated effort with the regional support forces was necessary to configure the correct BIOS settings everywhere.

Readiness Tool

To check the requirements described so far, Microsoft provides the so-called “Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool”. However, the “tool” is “only” a Powershell script.

Unfortunately, the tool must be executed with admin rights and requires a reboot. The result is then saved in a text file. In our opinion, it is therefore only suitable to a limited extent for carrying out large-scale and automated checks.

Virtualization

“Windows hypervisor (does not require Hyper-V Windows Feature to be installed)”.
Any operating system that supports Credential Guard comes with Hyper-V, so no problem there.

Really?

Almost. Hyper-V is always included, but what happens if you want to use other virtualization solutions, such as VMWare Server or Desktop or VirtualBox? For several years, sharing Credential Guard and other virtualization technologies was not possible (Windows 10 was released in July 2015).

For VMWare Server, this has been possible since the release of vSphere 6.7 (April 2018).

VMWare Desktop supports it only from version 15.5.6 in conjunction with Windows 10 20H1 build 19041.264 (June 2020).

VirtualBox has supported it experimentally since version 6.0 (December 2018), and the feature is still experimental in the current version 6.1.

Rollout

With all the topics interacting here, it is advisable to do the rollout in waves, especially since we definitely had a bluescreen on one of our test machines. Afterwards, it was necessary to enter the Bitlocker recovery key. Wouldn’t it be stupid if this happened at the CIO…

We now have everything meticulously prepared, hardware, BIOS and 3rd party software tested and updated if necessary, finally we link the GPO at the first OU. But how do we know if we did everything right and Credential Guard actually protects our credentials?

Out of the box, not at all.

To remedy this, we wrote a small script that collects the necessary information and saves it to a ZIP file. Of course, this procedure is only intended for the pilot phase. During the actual rollout, the information must be collected fully automatically via the respective systems management tool.

Microsoft’s Endpoint Configuration Manager, for example, offers the option of collecting extensive inventory information from the managed clients. A template can be used to configure which WMI classes and attributes can be collected. Registry entries can be indirectly mapped into the WMI namespace via the WMI Registry Provider and thus also retrieved from the client via inventory. Inventory information is stored in a SQL Server database and web-based reports can be retrieved using the browser to provide a centralized configuration overview.

We have made the PowerShell script and MOF templates for Microsoft Endpoint Configuration Manager available for you on Github: https://github.com/teal-technology-consulting/Test-CredentialGuardConfiguration