Windows 10: Windows 10 Device Guard and Credential Guard Demystified

/u/Wireless_Life · Jan 29, 2021

submitted by /u/Wireless_Life
[link] [comments]

:)

Brink · Jan 29, 2021

Windows 10 Device Guard and Credential Guard Demystified

While helping Windows Enterprise customers deploy and realize the benefits of Windows 10, I've observed there's still a lot of confusion regarding the security features of the operating system. This is a shame since some of the key benefits of Windows 10 involve these deep security features. This post serves to detail the Device Guard and Credential Guard feature sets, and their relationship to each other.

First, let's set the foundation by thinking about the purpose of each feature:

Device Guard is a group of key features, designed to harden a computer system against malware. Its focus is preventing malicious code from running by ensuring only known good code can run.

Credential Guard is a specific feature that is not part of Device Guard that aims to isolate and harden key system and user secrets against compromise, helping to minimize the impact and breadth of a Pass the Hash style attack in the event that malicious code is already running via a local or network based vector.

The two are different, but complimentary as they offer different protections against different types of threats. Let's dive in and take a logical approach to understanding each.

It’s worth noting here that these are enterprise features, and as such are included only in the Windows Enterprise client.

Virtual Secure Mode

The first technology you'll need to understand before we can really dig into either Device Guard or Credential Guard, is Virtual Secure Mode (VSM). VSM is a feature that leverages the virtualization extensions of the CPU to provide added security of data in memory. We call this class of technology Virtualization Based Security (VBS), and you may have heard that term used elsewhere. Anytime we’re using virtualization extensions to provide security, we're essentially talking about a VBS feature.

VSM leverages the on chip virtualization extensions of the CPU to sequester critical processes and their memory against tampering from malicious entities.

The way this works is the Hyper-V hypervisor is installed - the same way it gets added in when you install the Hyper-V role. Only the hypervisor itself is required, the Hyper-V services (that handle shared networking and the management of VMs themselves) and management tools aren't required, but are optional if you’re using the machine for ‘real’ Hyper-V duties. As part of boot, the hypervisor loads and later calls the real 'guest' OS loaders.
The diagram below illustrates the relationship of the hypervisor with the installed operating system (usually referred to as the host operating system)

The difference between this and a traditional architecture is that the hypervisor sits directly on top of the hardware, rather than the host OS (Windows) directly interacting at that layer. The hypervisor serves to abstract the host OS (and any guest OS or processes) from the underlying hardware itself, providing control and scheduling functions that allow the hardware to be shared.

In VSM, we’re able to extend this by tagging specific processes and their associated memory as actually belonging to a separate operating system, creating a ‘bubble’ sitting on top of the hypervisor where security sensitive operations can occur, independent of the host OS:

In this way, the VSM instance is segregated from the normal operating system functions and is protected by attempts to read information in that mode. The protections are hardware assisted, since the hypervisor is requesting the hardware treat those memory pages differently. This is the same way to two virtual machines on the same host cannot interact with each other; their memory is independent and hardware regulated to ensure each VM can only access it’s own data.

From here, we now have a protected mode where we can run security sensitive operations. At the time of writing, we support three capabilities that can reside here: the Local Security Authority (LSA), and Code Integrity control functions in the form of Kernel Mode Code Integrity (KMCI) and the hypervisor code integrity control itself, which is called Hypervisor Code Integrity (HVCI).

Each of these capabilities (called Trustlets) are illustrated below:

When these capabilities are handled by Trustlets in VSM, the Host OS simply communicates with them through standard channels and capabilities inside of the OS. While this Trustlet-specific communication is allowed, having malicious code or users in the Host OS attempt to read or manipulate the data in VSM will be significantly harder than on a system without this configured, providing the security benefit.

Running LSA in VSM, causes the LSA process itself (LSASS) to remain in the Host OS, and a special, additional instance of LSA (called LSAIso – which stands for LSA Isolated) is created. This is to allow all of the standard calls to LSA to still succeed, offering excellent legacy and backwards compatibility, even for services or capabilities that require direct communication with LSA. In this respect, you can think of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’ instance that simply communicates with the isolated version in prescribed ways.

Deploying VSM is fairly straightforward. You simply need to verify you have the appropriate hardware configuration, install certain Windows features, and configure VSM via Group Policy.

Step One: Configure Hardware

In order to use VSM, you’ll need a number of hardware features to be present and enabled in the firmware of the machine:

UEFI running in Native Mode (not Compatibility/CSM/Legacy mode)

Windows 64bit and it’s associated requirements

Second Layer Address Translation (SLAT) and Virtualization Extensions (Eg, Intel VT or AMD V)

A Trusted Platform Module (TPM) is recommended.

Step Two: Enable Windows Features

The Windows features you’ll need to make VSM work are called Hyper-V Hypervisor (you don’t need the other Hyper-V components) and Isolated User Mode:

If these options are greyed out or unavailable for install, it will typically indicate that the hardware requirements in step one haven’t been met.

You’ll notice the name of the feature is called Isolated User Mode in here. It actually is the Virtual Secure Mode feature – you can thank a last minute name change for that. In order to not confuse people, this isn’t planned to change to reflect the VSM name at this time, and may look to being integrated as a standard Windows feature at a later stage.

Update: In Windows 10, Version 1607 this is indeed an integrated feature and no longer needs to be explicitly enabled.

Step Three: Configure VSM

VSM and the Trustlets loaded within are controlled via either Mobile Device Management (MDM) or Group Policy (GP).

For the purposes of this article, I’ll cover the Group Policy method as that’s the most commonly used option, but the same configuration is possible with MDM.

The GP setting you need to know about is called Turn On Virtualization Based Security, located under Computer Configuration \ Administrative Templates \ System \ Device Guard in the Group Policy Object Editor:

Enabling this setting, and leaving all the settings blank or at their defaults will turn on VSM, ready for the steps below for Device Guard and Credential Guard. In this default state, only the Hypervisor Code Integrity (HVCI) runs in VSM until you enable the features below (protected KMCI and LSA).

Device Guard

Now that we have an understanding of Virtual Secure Mode, we can begin to discuss Device Guard. The most important thing to realize is that Device Guard is not a feature; rather it is a set of features designed to work together to prevent and eliminate untrusted code from running on a Windows 10 system.

Device Guard consists of three primary components:

Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards.

VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.

Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with.

When these features are enabled together, the system is protected by Device Guard, providing class leading malware resistance in Windows 10.

Configurable Code Integrity (CCI)

CCI dramatically changes the trust model of the system to require that code is signed and trusted for it to run. Other code simply cannot execute. While this is extremely effective from a security perspective, it provides some challenges in ensuring that code is signed.

Your existing applications will likely be a combination of code that is signed by the vendor, and code that is not. For code that is signed by the vendor, the easiest option is just to use a tool called signtool.exe to generate security catalogs (signatures) for just about any application.

More detail on this in an upcoming post.

The high level steps to configure code integrity for your organization is:

Group devices into similar roles – some systems might require different policies (or you may wish to enable CCI for only select systems such as Point of Sale systems or Kiosks.

Use PowerShell to create integrity policies from “golden” PCs
(use the New-CIPolicy Cmdlet)

After auditing, merge code integrity policies using PowerShell (if needed)
(Merge-CIPolicy Cmdlet)

Discover unsigned LOB apps and generate security catalogs as needed (Package Inspector & signtool.exe – more info on this in a subsequent post)

Deploy code integrity policies and catalog files
(GP Setting Below + Copying .cat files to catroot - C:\Windows\System32\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\)

The Group Policy setting in question is Computer Configuration \ Administrative Templates \ System \ Device Guard \ Deploy Code Integrity Policy:

VSM Protected Code Integrity

The next component of Device Guard we’ll cover is VSM hosted Kernel Mode Code Integrity (KMCI). KMCI is the component that handles the control aspects of enforcing code integrity for kernel mode code. When you use Configurable Code Integrity (CCI) to enforce a Code Integrity policy, it is KMCI and it’s User-Mode cousin, UMCI – that actually enforces the policy.

Moving KMCI to being protected by VSM ensures that it is hardened to tampering by malware and malicious users.

Platform & UEFI Secure Boot

While not a new feature (introduced in Windows 8), Secure Boot provides a high-value security benefit by ensuring that firmware and boot loader code is protected from tampering using signatures and measurements.

To deploy this feature you must be UEFI booting (not legacy), and the Secure Boot option (if supported) must be enabled in the UEFI. Once this is done, you can build the machine (you’ll have to wipe & reload if you’re switching from legacy to UEFI) and it will utilize Secure Boot automatically.

For more information about the specifics of deploying Device Guard, start with the deployment guide.

Credential Guard

Although separate from Device Guard, the Credential Guard feature also leverages Virtual Secure Mode by placing an isolated version of the Local Security Authority (LSA – or LSASS) under it’s protection.

The LSA performs a number of security sensitive operations, the main one being the storage and management of user and system credentials (hence the name – Credential Guard)
Credential guard is enabled by configuring VSM (steps above) and configuring the Virtualization Based Security Group Policy setting with Credential Guard configured to be enabled.

Once this is done, you can easily check if Credential Guard (or many of the other features from this article) is enabled by launching MSINFO32.EXE and viewing the following information:

You can also check for the presence of the LSAIso process, which is running in VSM:

I hope this article has been useful for you and answered at least some of your questions about Device Guard and Credential Guard.

If your thirst for knowledge is not yet quenched and you need more information while you wait for the follow up posts, check out the following Channel9 videos that cover this topic:

https://channel9.msdn.com/Blogs/Seth...h-Dave-Probert
https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-...
https://channel9.msdn.com/Blogs/Seth...h-Dave-Probert

Stay tuned for further posts about this and other Windows 10 features. Hey, why not subscribe?
Click to expand...

Source: Windows 10 Device Guard and Credential Guard Demystified - Microsoft Tech Community - 376419

Tip How to Enable or Disable Device Guard in Windows 10

How to Verify if Device Guard is Enabled or Disabled in Windows 10

How to Enable or Disable Credential Guard in Windows 10

How to Verify if Credential Guard is Enabled or Disabled in Windows 10

Brink · Jan 29, 2021

Windows 10 Device Guard and Credential Guard Demystified

While helping Windows Enterprise customers deploy and realize the benefits of Windows 10, I've observed there's still a lot of confusion regarding the security features of the operating system. This is a shame since some of the key benefits of Windows 10 involve these deep security features. This post serves to detail the Device Guard and Credential Guard feature sets, and their relationship to each other.

First, let's set the foundation by thinking about the purpose of each feature:

Device Guard is a group of key features, designed to harden a computer system against malware. Its focus is preventing malicious code from running by ensuring only known good code can run.

Credential Guard is a specific feature that is not part of Device Guard that aims to isolate and harden key system and user secrets against compromise, helping to minimize the impact and breadth of a Pass the Hash style attack in the event that malicious code is already running via a local or network based vector.

The two are different, but complimentary as they offer different protections against different types of threats. Let's dive in and take a logical approach to understanding each.

It’s worth noting here that these are enterprise features, and as such are included only in the Windows Enterprise client.

Virtual Secure Mode

The first technology you'll need to understand before we can really dig into either Device Guard or Credential Guard, is Virtual Secure Mode (VSM). VSM is a feature that leverages the virtualization extensions of the CPU to provide added security of data in memory. We call this class of technology Virtualization Based Security (VBS), and you may have heard that term used elsewhere. Anytime we’re using virtualization extensions to provide security, we're essentially talking about a VBS feature.

VSM leverages the on chip virtualization extensions of the CPU to sequester critical processes and their memory against tampering from malicious entities.

The way this works is the Hyper-V hypervisor is installed - the same way it gets added in when you install the Hyper-V role. Only the hypervisor itself is required, the Hyper-V services (that handle shared networking and the management of VMs themselves) and management tools aren't required, but are optional if you’re using the machine for ‘real’ Hyper-V duties. As part of boot, the hypervisor loads and later calls the real 'guest' OS loaders.
The diagram below illustrates the relationship of the hypervisor with the installed operating system (usually referred to as the host operating system)

The difference between this and a traditional architecture is that the hypervisor sits directly on top of the hardware, rather than the host OS (Windows) directly interacting at that layer. The hypervisor serves to abstract the host OS (and any guest OS or processes) from the underlying hardware itself, providing control and scheduling functions that allow the hardware to be shared.

In VSM, we’re able to extend this by tagging specific processes and their associated memory as actually belonging to a separate operating system, creating a ‘bubble’ sitting on top of the hypervisor where security sensitive operations can occur, independent of the host OS:

In this way, the VSM instance is segregated from the normal operating system functions and is protected by attempts to read information in that mode. The protections are hardware assisted, since the hypervisor is requesting the hardware treat those memory pages differently. This is the same way to two virtual machines on the same host cannot interact with each other; their memory is independent and hardware regulated to ensure each VM can only access it’s own data.

From here, we now have a protected mode where we can run security sensitive operations. At the time of writing, we support three capabilities that can reside here: the Local Security Authority (LSA), and Code Integrity control functions in the form of Kernel Mode Code Integrity (KMCI) and the hypervisor code integrity control itself, which is called Hypervisor Code Integrity (HVCI).

Each of these capabilities (called Trustlets) are illustrated below:

When these capabilities are handled by Trustlets in VSM, the Host OS simply communicates with them through standard channels and capabilities inside of the OS. While this Trustlet-specific communication is allowed, having malicious code or users in the Host OS attempt to read or manipulate the data in VSM will be significantly harder than on a system without this configured, providing the security benefit.

Running LSA in VSM, causes the LSA process itself (LSASS) to remain in the Host OS, and a special, additional instance of LSA (called LSAIso – which stands for LSA Isolated) is created. This is to allow all of the standard calls to LSA to still succeed, offering excellent legacy and backwards compatibility, even for services or capabilities that require direct communication with LSA. In this respect, you can think of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’ instance that simply communicates with the isolated version in prescribed ways.

Deploying VSM is fairly straightforward. You simply need to verify you have the appropriate hardware configuration, install certain Windows features, and configure VSM via Group Policy.

Step One: Configure Hardware

In order to use VSM, you’ll need a number of hardware features to be present and enabled in the firmware of the machine:

UEFI running in Native Mode (not Compatibility/CSM/Legacy mode)

Windows 64bit and it’s associated requirements

Second Layer Address Translation (SLAT) and Virtualization Extensions (Eg, Intel VT or AMD V)

A Trusted Platform Module (TPM) is recommended.

Step Two: Enable Windows Features

The Windows features you’ll need to make VSM work are called Hyper-V Hypervisor (you don’t need the other Hyper-V components) and Isolated User Mode:

If these options are greyed out or unavailable for install, it will typically indicate that the hardware requirements in step one haven’t been met.

You’ll notice the name of the feature is called Isolated User Mode in here. It actually is the Virtual Secure Mode feature – you can thank a last minute name change for that. In order to not confuse people, this isn’t planned to change to reflect the VSM name at this time, and may look to being integrated as a standard Windows feature at a later stage.

Update: In Windows 10, Version 1607 this is indeed an integrated feature and no longer needs to be explicitly enabled.

Step Three: Configure VSM

VSM and the Trustlets loaded within are controlled via either Mobile Device Management (MDM) or Group Policy (GP).

For the purposes of this article, I’ll cover the Group Policy method as that’s the most commonly used option, but the same configuration is possible with MDM.

The GP setting you need to know about is called Turn On Virtualization Based Security, located under Computer Configuration \ Administrative Templates \ System \ Device Guard in the Group Policy Object Editor:

Enabling this setting, and leaving all the settings blank or at their defaults will turn on VSM, ready for the steps below for Device Guard and Credential Guard. In this default state, only the Hypervisor Code Integrity (HVCI) runs in VSM until you enable the features below (protected KMCI and LSA).

Device Guard

Now that we have an understanding of Virtual Secure Mode, we can begin to discuss Device Guard. The most important thing to realize is that Device Guard is not a feature; rather it is a set of features designed to work together to prevent and eliminate untrusted code from running on a Windows 10 system.

Device Guard consists of three primary components:

Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards.

VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.

Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with.

When these features are enabled together, the system is protected by Device Guard, providing class leading malware resistance in Windows 10.

Configurable Code Integrity (CCI)

CCI dramatically changes the trust model of the system to require that code is signed and trusted for it to run. Other code simply cannot execute. While this is extremely effective from a security perspective, it provides some challenges in ensuring that code is signed.

Your existing applications will likely be a combination of code that is signed by the vendor, and code that is not. For code that is signed by the vendor, the easiest option is just to use a tool called signtool.exe to generate security catalogs (signatures) for just about any application.

More detail on this in an upcoming post.

The high level steps to configure code integrity for your organization is:

Group devices into similar roles – some systems might require different policies (or you may wish to enable CCI for only select systems such as Point of Sale systems or Kiosks.

Use PowerShell to create integrity policies from “golden” PCs
(use the New-CIPolicy Cmdlet)

After auditing, merge code integrity policies using PowerShell (if needed)
(Merge-CIPolicy Cmdlet)

Discover unsigned LOB apps and generate security catalogs as needed (Package Inspector & signtool.exe – more info on this in a subsequent post)

Deploy code integrity policies and catalog files
(GP Setting Below + Copying .cat files to catroot - C:\Windows\System32\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\)

The Group Policy setting in question is Computer Configuration \ Administrative Templates \ System \ Device Guard \ Deploy Code Integrity Policy:

VSM Protected Code Integrity

The next component of Device Guard we’ll cover is VSM hosted Kernel Mode Code Integrity (KMCI). KMCI is the component that handles the control aspects of enforcing code integrity for kernel mode code. When you use Configurable Code Integrity (CCI) to enforce a Code Integrity policy, it is KMCI and it’s User-Mode cousin, UMCI – that actually enforces the policy.

Moving KMCI to being protected by VSM ensures that it is hardened to tampering by malware and malicious users.

Platform & UEFI Secure Boot

While not a new feature (introduced in Windows 8), Secure Boot provides a high-value security benefit by ensuring that firmware and boot loader code is protected from tampering using signatures and measurements.

To deploy this feature you must be UEFI booting (not legacy), and the Secure Boot option (if supported) must be enabled in the UEFI. Once this is done, you can build the machine (you’ll have to wipe & reload if you’re switching from legacy to UEFI) and it will utilize Secure Boot automatically.

For more information about the specifics of deploying Device Guard, start with the deployment guide.

Credential Guard

Although separate from Device Guard, the Credential Guard feature also leverages Virtual Secure Mode by placing an isolated version of the Local Security Authority (LSA – or LSASS) under it’s protection.

The LSA performs a number of security sensitive operations, the main one being the storage and management of user and system credentials (hence the name – Credential Guard)
Credential guard is enabled by configuring VSM (steps above) and configuring the Virtualization Based Security Group Policy setting with Credential Guard configured to be enabled.

Once this is done, you can easily check if Credential Guard (or many of the other features from this article) is enabled by launching MSINFO32.EXE and viewing the following information:

You can also check for the presence of the LSAIso process, which is running in VSM:

I hope this article has been useful for you and answered at least some of your questions about Device Guard and Credential Guard.

If your thirst for knowledge is not yet quenched and you need more information while you wait for the follow up posts, check out the following Channel9 videos that cover this topic:

https://channel9.msdn.com/Blogs/Seth...h-Dave-Probert
https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-...
https://channel9.msdn.com/Blogs/Seth...h-Dave-Probert

Stay tuned for further posts about this and other Windows 10 features. Hey, why not subscribe?
Click to expand...

Source: Windows 10 Device Guard and Credential Guard Demystified - Microsoft Tech Community - 376419

Tip How to Enable or Disable Device Guard in Windows 10

How to Verify if Device Guard is Enabled or Disabled in Windows 10

How to Enable or Disable Credential Guard in Windows 10

How to Verify if Credential Guard is Enabled or Disabled in Windows 10

Brink · Jan 29, 2021

Credential Guard lab companion

If you have heard about Credential Guard in Windows Server 2016 (and in Windows 10), but do not have an environment to try it out, here is a lab environment we built for you to play.

Lab access

The link will lead you to a sign up page, after that, you will see the following labs listed for Windows Server 2016:

Windows Server 2016 labs

There are 3 exercises in the “Implementing Breach Resistance Security in Windows Server 2016”:

Credential Guard

Remote Credential Guard

Device Guard

This blogpost will walk you through the Credential Guard lab details.

After click on the link of Breach Resistance lab, you be required to sign in and then you can launch the lab:

Sign-in

Launch page

It takes a few minutes to create the VMs, and once it has done, you will see the following machines prepared:

Initialize

DC: domain controller, which is not used for this exercise.

SRV01 and SRV02: both are Windows Server 2016, and used for the lab exercise.

Lab exercise – Explained

The steps are listed in the Content section:

Content

This lab is structured to cover the following in sequence:

Understand how attackers can use the hash in memory to gain access to domain controllers

Configure Credential Guard

Verify the hash in memory is protected using Credential Guard

You can follow the steps listed under the content section to complete the lab, the intent of the blog, is to break the procedures into groups, to help you understand the exercise better.

Prep the hash

Lsass.exe is the process which handles user logon, it stores the user credential information in its memory. The memory is cleared when the machine starts up. In this lab environment, all the virtual machines start at the time lab launches, when you logon to the machine, you will only have the logon user credential information in memory. In order to demonstrate an attacker gaining user access using other account’s hash, the first part of the lab is to simulate a server which has been running for a while, different users had remotely or locally connected to it, therefore, lsass memory stored many different user credential information.
This is accomplished by step 1-8.

Retrieving credential hash

Mimikatz is a popular tool for retrieving lsass memory information. The tool has been copied to the lab machines, step 9-13 walk you through the process of dumping lsass memory using Mimikatz.

Pass the Hash

Pass the hash is a hacking technique that allows an attacker to authenticate by using the underlying NTLM, instead of specifying the user password. In step 14 to 24, you will extract LabAdmin hash from lsass using Mimikatz, and use the hash to open a PowerShell console, and perform a couple of operations using the LabAdmin privilege:

Add a user to the domain admin group

Open remote PowerShell connection to a domain controller

Both operations could not be performed by the logon user. But using the hash of the LabAdmin, an attacker will be able to do it using the information retrieve from Lsass memory.

Configure and verify Credential Guard

Step 25 to 36 illustrate the steps to configure credential guard, then verify its status using msinfo32.exe and PowerShell.

Step 37 to 43 goes further to use Mimikatz to show the hash in Lsass is now encrypted using Credential Guard.

More info

The exercise illustrated the benefit of Credential Guard in Windows Server 2016 as well as Windows 10. For more information, you can find here.
Click to expand...

Source: Credential Guard lab companion Datacenter and Private Cloud Security Blog

See also:

Enable or Disable Credential Guard in Windows 10 Windows 10 Security System Tutorials

Verify if Credential Guard is Enabled or Disabled in Windows 10 Windows 10 Security System Tutorials

Windows 10: Windows 10 Device Guard and Credential Guard Demystified

Windows 10 Device Guard and Credential Guard Demystified

Windows 10 Device Guard and Credential Guard Demystified

Windows 10 Device Guard and Credential Guard Demystified

Windows 10 Device Guard and Credential Guard Demystified - Similar Threads - Device Guard Credential

Credential guard not running

Credential guard not running

Device/Credential Guard Windows 10 Home

Device/Credential Guard are not compatible.

VMware Player and Device/Credential Guard are not compatible

Device/Credential Guard are not Compatible - Virtualization

Windows 10 Device Guard and Credential Guard Demystified

Turn off Credential Guard or Device Guard

Turn off Credential Guard of Device Guard