Improving Security with Credential Guard (Part 2)

If you would like to read the first part in this article series please go to:

In my previous article, I explained how a pass the hash attack works, and I mentioned that a new Windows feature called Credential Guard is designed to protect against this and other similar types of attacks. In this article, I want to explain what Credential Guard is, and how it works.

Before I get started, I need to explain that although Credential Guard can greatly improve an organization’s security, it is not appropriate for use in every situation. Credential Guard works by moving Kerberos, NTLM, and Credential Manager secrets out of the Local Security Authority, and into a new repository called the Isolated LSA Process. The problem with this is that there may be processes running on the machine that expect authentication secrets to reside in the Local Security Authority. If those processes cannot find the authentication secrets in the anticipated location, then applications depending on those processes will break. In other words, not every application is compatible with Credential Guard, so it is important to test for application compatibility before deploying Credential Guard in a production environment.

Unfortunately, I can’t tell you exactly which applications Credential Guard will break, but I can tell you that according to TechNet (, the things that will cause applications to break under Credential Guard include:

  • Kerberos DES encryption support
  • Kerberos unconstrained delegation
  • Extracting the Kerberos TGT
  • NTLM version 1

The TechNet article also notes that Credential Guard must not be enabled on domain controllers, because Credential Guard isolates the very process that the authentication services depend on, thereby causing the domain controller to fail.

So with that said, let’s talk about how Credential Guard works. As previously mentioned, Credential Guard takes the secrets that would ordinarily be stored in the Local Security Authority, and places them instead into the Isolated LSA Process. For the benefit of anyone who might not be familiar with the Local Security Authority, it among other things, is the repository within which user and system credentials are normally stored.

In isolating the Local Security Authority, Windows makes use of something called Virtual Secure Mode. Virtual Secure Mode is new to Windows 10 and Windows Server 2016, and is used by Credential Guard and by a somewhat similar security feature called Device Guard.

The key to understanding Virtual Secure Mode is to understand (from a high level) server virtualization. Hypervisors such as Microsoft’s Hyper-V or VMware’s ESXi leverage virtualization extensions that are built into the CPU. This hardware assisted virtualization does a couple of different things. First, it allows the virtualization host to host virtual machines without having to use hardware emulation. Although early virtualization solutions did use hardware emulation, the emulation layer negatively impacted the performance of the virtual machines, and sometimes also caused stability issues.

The other thing that hardware assisted virtualization does is to provide isolation to the virtual machines. A virtual machine is unable to see into a parallel virtual machine, or into the parent operating system because the hardware (with help from the hypervisor) isolates the virtual machines from one another.

The important thing to understand is that the hardware plays a major role in the virtualization process, and that modern hypervisors cannot function unless virtualization capabilities exist and are enabled at the hardware level. In fact, Microsoft even provides a Hardware Assisted Virtualization Detection Tool (

Virtual Secure Mode has a number of similarities to hypervisors such as Hyper-V or ESXi. One of the key similarities is that a “real” hypervisor works independently of the server’s operating system. Yes, Hyper-V can be installed as a Windows Server role, but Microsoft also offers a version called Hyper-V server that installs on bare metal. VMware ESXi functions similarly in that it too installs at the bare metal layer. As such, the hypervisor sits between the hardware and the virtual machines.

When Virtual Secure Mode is enabled, a hypervisor is placed between the hardware and the Windows operating system. Virtual Secure Mode exists parallel to the host operating system, in an isolated space. In essence, you can think of Virtual Secure Mode as using a very lightweight virtual machine that serves a very specific purpose.

The advantage to this approach is that because Virtual Secure Mode exists as a “virtual machine”, its contents are completely isolated from the server’s operating system.

As previously discussed, Credential Guard works by moving the Local Security Authority’s contents into the Isolated LSA Process (which is sometimes referred to as LSAIso). This raises two questions. First, if the Local Security Authority is now empty, what happens if a process makes an LSA call? Second, how does Windows access the Isolated LSA Process if it is indeed isolated?

Even with Credential Guard enabled, the Local Security Authority still exists, but its behavior changes. With Credential Guard enabled, the Local Security Authority functions as a proxy. If a process makes an LSA call, the Local Security Authority receives the call and then contacts the Isolated LSA Process on behalf of the process that made the call.

Microsoft does not disclose all of the details regarding exactly how the Local Security Authority communicates with the Isolated LSA Process. Since the Isolated LSA Process functions similarly to a virtual machine, there is presumably a secure, dedicated virtual network link between the LSA and the Isolated LSA Process.

Although Credential Guard depends on the use of Virtual Secure Mode, it is important to note that Virtual Secure Mode does not belong exclusively to Credential Guard. Device Guard also leverages Virtual Secure Mode, and it is possible for Device Guard and Credential Guard to share the Virtual Secure Mode space.

Now that I have explained the basics of how Credential Guard works, it is time to take a look at the implementation process. In Part 3 of this series, I will begin showing you how to set up Virtual Secure Mode and Credential Guard.

About The Author

2 thoughts on “Improving Security with Credential Guard (Part 2)”

  1. Thank you for this series. I have a question regarding Credential Guard and RDP-ing to servers. We have SSO implemented for RDP, when CG is enabled, that ability is lost, it appears this is by design:

    Are there any workarounds? Loosing SSO because of CG will be a major undertaking, if at all possible.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top