Virtualization-Based Security to Protect Your Secrets
What is Windows Defender Credential Guard?
Windows Defender Credential Guard is a security feature in Windows 10 Enterprise and Windows Server 2016 and above that uses virtualization-based security to protect your credentials. With Credential Guard enabled, only trusted, privileged applications and processes are allowed to access user secrets, or credentials. Without Credential Guard enabled, Windows stores credentials in the Local Security Authority (LSA) which is a process in memory. With Credential Guard enabled, it uses virtualization-based security and the ‘isolated LSA’ process to store and protect user secrets. This process is not accessible to the rest of the operating system, as it is running in a virtualized environment. Some potential concerns with Credential Guard are that when it is enabled, you can no longer utilize some older protocols for authentication, these include NTLMv1, Digest, CredSSP, and MS-CHAPv2. Unconstrained Delegation and DES Encryption are also not allowed. You should ensure that these are not being used throughout your organization before enabling Credential Guard. A more in-depth explanation of Credential Guard and all of its pre-requisites can be read in Microsoft documentation.
What Does This Mean For You?
If you’re reading this blog, then you probably are looking to see how you can take action to try to further secure your credentials and Active Directory environment. Without Credential Guard enabled, Windows stores secrets in the LSA, but attackers who are able to gain privileged access to an endpoint can query the LSA for the secrets in memory and compromise a hash or ticket. Using a tool like Mimikatz, that hash/ticket could then be used in a Pass-The-Hash or Pass-The-Ticket attack to elevate privileges further and move laterally within an organization. Credential Guard is a way to protect your organization from these types of attacks, as the isolated LSA process that is storing the secrets when it is enabled, is not able to be queried by attackers. If possible, every endpoint that is not using one of the protocols mentioned earlier, that meets the pre-requisites for Credential Guard, should have it enabled. Unfortunately, Credential Guard doesn’t fully protect from a tool like Mimikatz, while it will make it so the isolated LSA can’t be queried, Mimikatz is capable of capturing the credentials being entered. The author of Mimikatz mentions in a tweet that if a malicious actor has control of an endpoint, and a privileged user logs in after the machine has been taken over, it is possible for them to get the credentials and elevate their privileges.
Seeing It In Action
Without Credential Guard enabled, using Mimikatz I am able to query the credentials currently stored in the LSA process to get the NTLM hash of an account remotely logged into the machine.
This hash can be used in the Pass-The-Hash attack and could potentially result in escalated privileges or lateral movement.
After enabling Credential Guard through Group Policy, you can see there is a new process running ‘LsaIso’.
This is the isolated LSA process that is now being used to store the credentials when querying this server again using Mimikatz, we can see a different result.
As you can see, the results are much different, and I have not received an NTLM hash from the credential dump like I did previously.
To Review Credential Guard
Credential Guard is a way for an organization to protect your domains credentials from being compromised. This security feature in Windows 10 and Windows Server 2016 allows you to store credentials in a virtualized process that is not able to be queried by the operating system. Limiting the attack vectors that malicious actors (or red teams) have to move laterally within your environment should be every blue teams’ number one concern, if you can prevent them from escalating privileges, then that’s one step closer to prevent them from gaining access to critical information or compromising the domain.
Leave a Reply