Windows 10 Enterprise Serie: Secure your secrets – Credential Guard
Part 10 of our Windows 10 blogseries is about the security of your credentials. A big amount of security targets is the virtual identity. Passwords and sessiontickets can be stolen and used to get access to your enterprise data or remote systems. Securing those “secrets” should be a priority in enterprises.
What is Credential Guard and how about advantages and disadvantages in using this security technology? Credential Guard relies (same as Device Guard – blogpost here) on virtualization based security. In other words, the local security authority (LSA) of Windows 10 stores the “secrets” (password hashes, Kerberos tickets) in a different component on the virtualization layer.
In Windows versions prior to Windows 10 the LSA service stored those secrets in the process memory and was vulnerable to pass-the-hash and pass-the-ticket attacks.
Short security excurse:
Pass-the-hash attacks are possible if the attacker was able to get the password hash of a user. The authentication protocols like NTLM or LanMan have the problem, that those hashes weren’t salted. Were “salted” means random data, which is added to the hash of the password per authentication. If a user inputs username and password to authenticate, the password will not be send in clear text to the authentication destination. The OS does an API call to get the hash and authentication is done by username and hash. An attacker just needs username and hash to authenticate on any remote server on which the user has access to.
Pass-the-ticket attacks are somehow the same. An attacker needs to completely compromise a system to extract a user’s Kerberos ticket and authenticate on remote servers with that ticket. Those tickets have a lifetime of 10 hours per default.
The Theory behind
For a better understanding the process without credential guard:
- Type in domain, username and password
- The Credential Provider will call the LogOnUser function and pass the data to LSA
- LSA calls all plugins (NTLM, Kerberos, Digest, etc.) for SSO experience
- The plugins generate the hashes and tickets which are needed for authentication
- LSA additionally stores hashes and tickets in process memory
- Authentication via username and hash or ticket
At this point the attacker is able to extract those “secrets” from the process memory.
Here is a good way to test the “vulnerability” of LSA:
- Get yourself Sysinternals ProcDump from Microsoft
- Get a small Developer Opensource Project named Mimikatz (the binaries not the sources) http://blog.gentilkiwi.com/mimikatz
Mimikatz will convert the hashed passwords for you from the dump file.
- Open an administrative shell (in my example powershell) navigate to procdump.exe and type
Code: procdump.exe –accepteula –ma lsass.exe [filename]
- Navigate to mimikatz und type
Code: .\mimikatz.exe (this will open the mimikatz internal shell)
Oh okay now we have my Windows 10 log-on Microsoft Account. Not bad. Billing Information, Bitlocker recovery keys of my Windows 10 Devices an much more. But not finished yet.
- Type in Code: sekurlsa::credman
Ah fine! Now we got my domain credentials. The credentials are lying calm and quiet in process memory in a hashed version.
That was surprisingly easy. To be fair I need local admin rights to execute this. But gaining local admin rights is not as hard. A Linux live CD and physical access is all you need.
So here is the advantage of credential guard:
There is a new component called “isolated LSA environment” (LSAiso). LSAiso runs on the virtualization layer (virtualization based security) to store and protect the hashes and tickets. It’s like a small container with less code, no drivers and running within the virtualization layer. The normal LSA communicates with the LSAiso per procedure calls and nothing else of the OS is allowed to access LSAiso without the LSA.
With credential guard enabled there is another step in the process, where LSA calls LSAiso and stores the data in the virtualization layer.
Now it’s not (hopefully) extractable without the initial call of the LSA.
To implement Credential Guard, it is necessary to have the required hardware:
- TPM (v1.2) chip - optional (TPM stores the encryption key)
- Processor with virtualization support (intel VT-x or AMD-V and second level address translation)
And the Software requirements:
- UEFI Version 2.3.1 or higher
- Windows 10 Enterprise
- 64-bit because of Hyper-V requirements
Configuration and validation
To activate Credential Guard, you need to configure the following:
- Install Hyper-V feature
- Install isolated user mode feature
- Enable virtualization based security via GPO (or via registry)
- GPO: Administrative templates -> system -> Device Guard
-> Turn-On virtualization based security -> enabled
--> Platform Security Level -> Secure Boot or Secure Boot with DMA Protection (DMA = Direct Memory Access)
--> Credential Guard Configuration -> enabled with UEFI lock (credential guard cannot be disabled remotely)
- Registry: HKLM\System\CurrentControlSet\Control
-> Device Guard
--> DWORD “EnableVirtualizationBasedSecurity“ set to Value 1
--> DWORD “RequirePlatformSecurityFeatures“ set to value 1 for secure boot and value 2 for secure boot and DMA protection
-> DWORD „LsaCfgFlags“ set to value 1 for enabling credential guard with UEFI lock and value 2 without UEFI lock
You can build your company images with activated features via DISM, scripts or other preferred methods and configure through GPO, logon scripts or compliance management in SCCM to deploy credential guard in your enterprise.
How to verify if Credential Guard is activated?
- Check the running processes:
-> Secure system (belongs to virtual secure mode)
-> Credential Guard
- Also check system overview of msinfo32.exe
-> There should be five device guard entries
After activating Credential Guard and verifying that everything is enabled and running, try the “LSA hack” again and look at the results. In my case there is no relevant information in the lsa dump file because everything should be stored in the LSAiso on virtualization layer.
Woohoo cool feature but what about disadvantages? Yep there are few of them:
- First of all: old versions like NTLMv1, MS-Chapv2 and light Kerberos encryption like DES aren’t supported; they will be handled with the traditional LSA process
- Credentials that were managed outside of this process aren’t supported as well (obviously)
- And with every new technology the recurring problem of third party products. Security support provider which call the security support provider interface and ask the LSA for hashes directly are not supported. Credential guard will not allow custom calls for hashes. So you need to test all of them with credential guard before deploying enterprise-wide.
So let’s talk about my personal Opinion:
Credential Guard is a nice feature which gives your enterprise much more safety. The requirements aren’t that hard and the technical way for configuration and management is easy as hell.
But the most important: It does nothing to users. You get more safety without impact (okay it needs a reboot ;) ). No one has to learn about that new credential stuff, nothing gets more complicated. An old rule I learned on security:
If it gets more complicated for your users, it’s less secure. Because they will find a way around it, that you cannot control.
Credential Guard is more security without a big overhead.
/* Style Definitions */
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;