Credential Guard on Windows
Contents
Contents
Introduction
This post will aim to explain Credential Guard and Virtualization Based Security (VBS) which is the technology that makes it possible. There has been many discussions, papers, and talks about this subject. The goal of this post is for me to write out the technical details of this technology in my own words.
There are many interesting and insightful resources available online that can also help you understand how this technology works, resources I have found useful will be linked in the References section at the end of the post. I recommend looking through these resources as they are made by people that know much more about what they are talking about.
This post will also provide the steps taken to enable Credential Guard and will show the technology in action by attempting to dump secrets from LSASS.
Introduction to Virtualization Based Security
VBS is a key component that is capable of provided three security features, Device Guard, Credential Guard, and Guarded Fabric. This post will focus on Credential Guard, however, before talking about it we must first understand how how VBS makes it possible for this security feature to exist.
The figure below shows a pretty typical scenario of how an operating system runs. It has the hardware on which the operating system runs, within the operating system we have the kernel (ring 0) and userland (ring 3) where the user will run their applications, such as firefox.
However, there is a fatal flaw in this diagram. We usually assume that the NT Kernel at ring 0 is secure, as a result if an attacker gains the capability to run their own code at ring 0 we can assume everything below it is also compromised. Furthermore, userland also holds some very important information. For example, the LSASS process may store the NTML hash, clear-text password, or Kerberos tickets of a domain user logged onto the system. This creates a serious issue if an attacker is able to dump the memory of the LSASS process. As we will see later this is the exact thing that Credential Guard aims to mitigate.
Now comes into play VBS, as you can see from the diagram below the architecture looks a bit different. We now have a hypervisor and two virtual machines running on top of it. The two virtual machines running on top of the hypervisor are called virtual trust levels (VTL), they are separated into VTL 0 and VTL 1. VTL 0 is our normal world where the existing huge NT Kernel is located with many different drivers, this is also where the user wil be performing their every day tasks with Firefox.
VTL 1 is a secure world, it is very difficult to gain access from VTL 0 to VTL 1 since they are separated by a hypervisor. This secure world contains a small kernel named SKM (it may be called Secure Kernel by some), this is a very small kernel that performs a few very specific tasks in VTL 1. The main goal was to make the SKM extremely minimal in order to decrease the attack surface, unlike the main Windows NT Kernel the SKM is around 300KB and only has two modules that provide code integrity (SKCI.dll) and cryptographic operations (CNG.sys).
Now, userland in VTL 1 is a bit different than userland in VTL 0. Userland in VTL 1 is refereed to as the Isolated User Mode (IUM), processes that run in the IUM are called trusted processes (trustlets). There are some differences between a trustlet and regular process. For starters a trustlet takes the form of a regular PE binary, however, there are some properties that are specific to IUM. Limitations are set on which DLLs they can import from, the PE header includes a .tPolicy field in order to provide metadata to the SKM, and the binary itself is signed with a certificate related to the IUM. Furthermore, trustlets also have a process attribute associated with them that is set to PS_CP_SECURE_PROCESS in order to signify that it is a trustlet.
Now you may begin seeing the usefulness of VBS, we now have a space that we can perform tasks that an attacker will struggle to gain access to. In fact this is the entire threat model of VBS, we are assuming that VTL 0, where the user themselves runs their programs, is compromised at ring 0 level. This means that neither kernelspace or the userland can be trusted.
This is a huge win from a defensive perspective, we can now place a trusted process, such as LSASS, in VTL 1 and an attacker will have difficulty accessing it since there is a separation at the hypervisor level.
Introduction to Credential Guard
Now it was already mentioned that LSASS is a process that holds secrets that an attacker can take advantage of. It usually holds a users hashed password and Kerberos tickets, however, depending on the logon type it may also store a users plaintext password.
An attacker with the correct permissions on the system is capable of dumping the memory allocated to the LSASS process, this will result in the attacker being able to retrieve the users hash and Kerbeos tickets. These can be used for a Pass the Hash and Pass the Ticket attack.
Credential Guard has the goal of mitigating these attacks, this is done by only storing encrypted blobs of the information in LSASS within VTL 0. This means that an attacker will be able to dump the memory contents of the LSASS process, however, since the data is encrypted it will be useless to them. Lets go into a bit more detail as to how the data is stored and how we can perform the regular LSASS functionality in order to keep our Single Sign On abilities.
Now since we have Credential Guard enabled a new trustlet in VTL 1 named LSAISO will be created, this trustlet is responsible for performing all the sensative tasks related to the NTML hashes, clear-text passwords, and Kerberos tickets. This means that the only point at which they will be plaintext is inside of VTL 1 (there is an exception discussed later). LSASS in VTL 0 still plays a vital role in the process, however, since it is not trusted we can only allow it to store the hashes and tickets in a encrypted form. The only entity that can decrypt it is the LSAISO located in VTL 1.
Furthermore, it is important to understand that the LSASS process in VTL 0 acts as a proxy. For example, if we are dealing with a Kerberos ticket the LSASS processes will receive a ticket from the Domain Controller in encrypted form, which it cannot decryp, and will forward it to the LSAISO. This is the same position a man-in-the-middle attacker would be in if they where sniffing the network traffic.
If we are dealing with a plaintext password that a user used to login to the system this password will be sent from LSASS to LSAISO. The password will then be encrypted within LSAISO, after it will be returned to LSASS and stored in an encrypted format. If at any point the password in the form of a hash is required for a NTLM challenge the encrypted form of it will be sent from LSASS to LSAISO, and a proper response will be generated. Now there is a issue here, if LSASS is compromised before a user types in their password then it may be possible for an attacker to intercept it. However, if it is compromised after an attacker gained access they will only be able to gain access to the encrypted blob.
Now to finish this section of a brief description of how the LSASS process in VTL 0 communicates with LSAISO in VTL 1 will be given. In order for LSASS to communicate with LSAISO Advanced Local Procedure Call (ALPC) is used to create a port through which an RPC interface is exposed on. This RPC interface consists of a set of function that LSASS can use to communicate with LSAISO.
Enabling Credential Guard
This section will describe the steps taken in order to enable Credential Guard. It will be enabled through group policy on a workstation joined to a domain. Before we begin lets run Mimikatz on the workstation before we enable Credential Guard. As you can see from the screenshot below we are able to get the hashes and clear text password of the Administrator domain user.
In order to enable Credential guard head over to Computer Configration -> Polcies -> Administrative Templates Policy -> System -> Device Guard within the group policy object you are editing.
Next open the Turn On Virtulization Based Security option. Enable the option and go down towards the Credential Guard Configration, set it to Enabled with UEFI lock. A UEFI lock is an option that can prevent the system from booting when Credential Guard is disabled. This is done by setting a EFI runtime variable in the firmware memory, this will be performed during a reboot. Of course, UEFI is required for this to happen. If you wish you can use the option without the lock
Information about whether VBS and Credential Guard are enabled can be viewed in System Information (msinfo32.exe). As can be seen below VBS is running and Credential Guard is setup.
You can also view the LSASS process and LSAISO trustlet running, note you cannot access LSAISO since it is running in VTL 1.
Now if we use Mimikatz to dump LSASS again we can see that the hash and password are no longer in a plaintext format.