Bypassing Windows’ Credential Guard

Hello,

Today, we will talk about Microsoft Windows’ Credential Guard and how to bypass it.

Before we go in depth about what is credential guard and how to bypass it, we need some context. So, lets get into it! One of the most common attacks in a penetration test is Pass-the-Password or Pass-the-Hash.

Pass-The-Hash or Pass-the-Password

• A Pass-the-hash or Pass-the-Password attack is basically passing the found password hash/password around the network with a list of usernames to see what else you get access to.
• We perform this attack for lateral or vertical movement in a penetration test. In order to pass a hash/password, we need to obtain the hash.
• A common method to obtain this hash is by dumping the memory of the machine using mimikatz and the sekurlsa module. When we run this module with the logonpasswords value, mimikatz will dump LSA secrets which will contain credentials of recently logged on users.
  LSA or lsass.exe is a process that handles user authentication, password changes and token creations.
• One of the things stored in the lsass.exe’s memory is password hashes of domain users who recently logged on. After dumping the LSA secrets which contains, among other things, password hashes of domain users, we can either crack it or pass it around the network.

In order to mitigate this, Microsoft came up with various methods, one of which is Virtualization Based Security(VBS).

• Virtualization Based Security : A software technology that leverages the CPU’s virtualization capabilities and enables the creation of isolated regions of memory in a secure way. This is the foundation on which the operating system security of windows is built.
• VBS runs a hypervisor on the physical hardware instead of running it on the operating system. Microsoft also built the Virtual Secure Mode(VSM) which is a set of hypervisor capabilities offered to the Hyper-V partitions.
• VSM creates isolated regions in memory where the OS can store sensitive information. These isolated regions in the memory can only be accessed through the hypervisor which runs at a higher privilege than kernel.

Now, VSM and VBS might confuse you because I said they do the same thing — Create the isolated region in the memory to store sensitive data.

Difference between VBS and VSM

• VBS is the umbrella technology which leverages the hypervisor and hardware capabilities of the CPU to enforce system security. The specific implementation of creating an isolated memory to store sensitive data is done by VSM.
• VSM uses the capabilities provided by VBS to create the isolated memory regions. Now going back to accessing this secure memory region, since the permissions required are higher than the kernel itself, we cannot access it with SYSTEM privileges.

VSM maintains the isolation through different trust levels known as Virtual Trust Levels(VTL).

Virtual trust Levels (VTL)

Different VTL represent different isolation memory region. Microsoft currently supports 16 levels ranging from VTL 0 to VTL 1.

The two important trust levels we will focus on are VTL 0 and VTL 1.

• VTL 0 (VSM Normal Mode) — In this mode, the isolated memory region contains the regular user mode processes, normal kernel and kernel-mode data.
• VTL 1 (VSM Secure Mode) — In this mode, the secure memory region stores critical functionalities and data.

Microsoft has used VSM as a foundation for several mitigations, one of which is the Windows Credential Guard.

When Credential Guard is enabled, the lSASS runs a trustlet in VTL1 as LSAISO.exe (LSA Isolated). A trustlet is basically a special and secure process used to handle critical and sensitive information. This trustlet or the process LSAISO.exe is where sensitive information such as the domain user credential hashes are stored.

From windows PowerShell, we run the following command to check if credential guard is enabled on our target computer:

Get-ComputerInfo

The screenshot above shows that Credential Guard is enabled. Next, we will launch mimikatz and try to dump all of the LSA secrets using the following commands:

privilege::debug
sekurlsa::logonpasswords full

Here, you will notice that you are able to dump hashes for Local Accounts, but not for Domain Accounts. You should see the below error

Unable to dump domain hashes

Bypass Credential Guard — Exploit Security Support Provider Interfaces(SSPI)

Now in order to bypass credential guard, instead of trying to extract hashes from the cache, we need to change our approach and intercept the login credentials while the users are trying to log in.

In order to do this, we use an authentication mechanism supported by Microsoft called Security Support Provider Interfaces(SSPI).

• All applications and services that require authentication use SSPI.
• Some of the more well known SSPs are kerberos and NTLM.
• These providers are included in the SSPI as DLLs, and when authentication takes place, SSPI decides which one to use.

Windows also gives us the option to register our own SSP through the AddSecurityPackage API and through the HKEY_LOCAL_Machine/System/currentcontrolset/control/LSA/Security Packages registry key.

When a system starts up, the LSASS loads the DLLs present in the list pointed to by this registry key. This means if we develop our own SSP and register it with LSASS, we can force the SSPI to use our malicious authentication SSP DLL for authentication.

Fortunately, mimikatz does this whole process for us. It will provide the required custom SSP and inject it directly in the memory of lsass.exe process without dropping the DLL on the disk.

Mimikatz leverages the fact that the SSP are called with plaintext credentials through the SSPI. This eliminates the whole processes of capturing a hash and cracking it.

Let’s run mimikatz and enable privileged mode. We will then run the misc module with the memssp command:

.\mimikatz.exe
privilege::debug
misc::memssp

Now, we sit and wait for a domain user to login with their credentials. We can view the captured credentials stored at :
C:\Windows\System32\mimilsa.log. We can open this file and locate the domain user credentials.

Disclaimer : I could not attach few screenshots in the post to show what the outputs look like due to some issues with my lab environment.

I hope this helped you in understanding the underlying technology of the Windows Credential Guard and how to bypass it using mimikatz.

Comment below if you have any doubts or feedback.

Thanks for reading it and I will see you in the next one!