Credential Guard: Defeating Pass-the-Hash Attacks Q&A

We recently ran a webinar on Credential Guard, a new security feature in Windows 10 designed to reduce exposure to Pass-the-Hash attacks in your environment. As always, we had some great questions in the Q&A and didn’t have time to answer them all, so I’ve written up the questions and answers for your reference if you attended and we didn’t answer your question, or if you just want to learn more about Pass-the-Hash and Credential Guard. You can now watch the entire webinar and select highlight clips on-demand here.
You say the hash can’t be reversed – what about Rainbow Tables?
The hash can’t be mathematically (or perhaps more accurately cryptographically) reversed, and I’m glad you brought up the topic of Rainbow Tables – so let’s break this one down.
I like the analogy of using a blender to liquidize fruit. Imagine you’ve never seen a banana before, but someone gives you banana that’s been liquidized in a blender, and they tell you it’s banana. If someone else gave you liquidized banana, you’d be able to recognize it by what it looks, smells and tastes like, but you’re never going to be able to ‘reassemble’ it to work out what a banana looks like. The liquidized banana represents the NTLM hash.
The nice thing about the NTLM hash (as far as attackers are concerned at least) is that it will always produce the same hash for a given password. So anyone who uses P@33w0rd for their password will have the same NTLM hash, in the same way that anyone who puts a banana in a blender will always end up with something that looks, smells and tastes like liquidized banana. If they put an apple in a blender, they’ll get a different result.
Now suppose someone had lots of different fruit and went to the trouble of taking a picture of each one before putting it in a blender. They then blended it and put the liquidized fruit next to the picture of the fruit in its original form. Having never seen a banana before, you could recognize the look, smell and taste of liquidized banana and see the corresponding picture, so now you know what a banana looks like. You could do the same with liquidized apple, pear, pineapple, whatever to ‘lookup’ the picture that corresponds to what you recognize (the look, smell and taste).
A Rainbow Table is effectively a lookup for hashes. Someone has gone to the trouble of creating (or more likely writing a program to create) millions of possible passwords – each one corresponding to the picture of the fruit in its original form in our analogy. For each password, they generate the hash (corresponding to the liquidized fruit) and the password and hash become columns in a simple but very long lookup table. If I’ve got a hash, I can then use that table to look-up the hash and find what the originating password would have been.
It’s important to understand that the goal of using a Rainbow Table is to determine the actual, plain-text password once you have the hash. If you can get the actual password, as an attacker you don’t need to use Pass-the-Hash, you can use the user name and password directly, which will open more doors beyond NTLM authentication.
What if I use Kerberos?
I’ve focused on Pass-the-Hash attacks in this webinar, specifically looking at using the NTLM hash that’s stored in memory by the LSA. However, when Kerberos is used, the Ticket-Granting Ticket (TGT) and session ID ‘secrets’ are also stored in memory by the LSA. Using a similar approach to a Pass-the-Hash attack, you can initiate Pass-the-Ticket attacks in a similar way if you have access to these secrets – in fact mimikatz implements a module to demonstrate that. Credential Guard will mitigate this because these Kerberos secrets are stored in the isolated LSA memory.
Does Credential Guard require Device Guard to be enabled?
No. It’s a bit confusing that the Group Policy setting to enable Credential Guard is within the Device Guard settings, but Credential Guard can be enabled without Device Guard. However, Device Guard is going to give you much stronger protection as its going to prevent most malware from executing – Credential Guard then adds value should anything get past Device Guard and try to access those LSA secrets from memory.
Can I configure Credential Guard during OS Deployment with SCCM?
You should be able to set the local policy settings (HKLM\Software\Policies\Microsoft\Windows\DeviceGuard) during the OSD Task Sequence. The device needs to be restarted once Credential Guard and Virtualization Based Security has been enabled, which will happen in due course when the Task Sequence is running. But by that time the device will have downloaded the Domain Group Policy anyway.
Is it possible to enable the Credential Guard UEFI lock later, starting without and when everything is running and you feel secure, then enable UEFI lock?
Yes, however once you’ve enabled UEFI lock you would need to have an administrator present at the device to disable it.
Are there authentication methods that won’t work in an enterprise environment that you need to be aware of, when implementing (anything that you can’t logon to with Credential Guard enabled)?
Microsoft have kept the isolated components to a minimum, so for the most part the LSA functions as it always has. Credential Guard is simply isolating the secrets normally stored in memory. There are no changes to the authentication methods themselves, so they should all work exactly the same with or without Credential Guard.