Deploy Credential Guard - Windows 10

Credential Guard is an awesome feature in Windows 10 that is designed to prevent credential theft even on a system that is completely compromised. I think it's safe to say we can thank Benjamin Delpy (@gentilkiwi) and others like Chris Campbell and Skip Duckwall for the advent of Credential Guard. Ben's tool, Mimikatz, as well as Chris and Skip's Pass-the-Hash research definitely brought this issue into the spotlight and put additional pressure on Microsoft to put some R&D into the problem. 

Credential Guard uses what Microsoft calls "Virtualization based security" to isolate credentials so that malware or attackers with admin privileges can't view or extract them. For more information on why this is so important see my previous post which links to my Derbycon talk. TLDR; When (not if) one of your systems gets compromised, attackers look for credentials and move around laterally until they get what they want. Without Credential Guard it is trivial to view credentials that Windows stores in memory. Depending on the version of Windows these credentials may be in plaintext, hashed, or in the form of a Kerberos ticket.

For example, here is the output of Mimikatz on a Windows 10 system running as a local user and not joined to a domain:

Here you can see the local user's hash that is stored in memory. If this was Windows 7, by default you would see the actual password in plaintext. Now lets look at the output when Credential Guard is enabled:

But wait, it looks like the NTLM hash is still accessible in memory? I confirmed with Benjamin Delpy that this is indeed the case when running Windows 10 LTSB 2015 with a local account. He said this has been fixed in the Anniversary Update so this shouldn't be the case when running LTSB 2016 or the latest Windows 10 CSB. I joined the machine to a domain and on the results were what I originally expected with no credentials accessible:

Configuring Credential Guard

So how do we turn this on? The first thing you need to consider is the prerequisites, which vary depending on the version of Windows 10. At a minimum, you'll need:

• 64-bit CPU with virtualization extensions such as Intel VT-x or AMD-V
• TPM 1.2 or 2.
• UEFI firmware with Secure Boot enabled
• Windows 10 Enterprise, Education, 2016 Server or Enterprise IoT

You can enable Credential Guard via GPO, registry, or with a Microsoft provided Powershell script; however keep in mind the prerequisites must already be in place for Credential Guard to be successfully enabled. If the system didn't have Secure Boot enabled when Windows was installed, you'll have to enable Secure Boot and re-install Windows before Credential Guard will work. On my list of things to do is to find a way to poll systems remotely (probably with Powershell) and output a report on Credential Guard status. Also notice Credential Guard can't be run on Windows 10 Pro. In my mind Credential Guard and Device Guard are the primary motivating reasons to buy Enterprise.

For initial testing, my preferred method of enabling Credential Guard is with the DG_Readiness Powershell script from Microsoft which you can currently find here. This tool allows you to verify a system has the required prerequisites, enable or disable Credential Guard or Device Guard or both, and check to see if they are enabled/running. Run it with the -Capable flag to check the prerequisites:

Don't worry if you see HSTI Validation failed. I'm not exactly sure what this means but it doesn't seem to affect Credential Guard. If you see any other errors in red you'll need to fix those before you can enable Credential Guard. If you don't see any other errors you can run the Readiness Tool with the -Enable flag which will enable both Credential Guard and Device Guard. I ran into an issue when enabling CG this way where some applications wouldn't start because of a "digital signature" error. Running the Readness Tool with the -Disable -DG flags fixed the issue by disabling Device Guard. I assume this had to do with Device Guard being enabled but no configuration for it. Because of this issue, I'd recommend enabling Credential Guard with the -Enable -CG flags as shown:

When the system reboots Credential Guard should be running. You can verify this with the Readiness Tool and the -Ready flag or by running msinfo32.exe. This is what they should look like:

Credential Guard Configured But Services Not Running

When running Windows 10 LTSB 2016 or CSB I've ran into an issue where in msinfo32.exe it appears Credential Guard is configured, but the services are not running. I'm not sure what causes this, but the workaround below worked for me.

• Ensure all prerequisites are in place on the system
• Configure Credential Guard with the Readiness Tool
• After a reboot msinfo32.exe shows Credential Guard configured, but services not running
• Disable Secure Boot in the BIOS
• After a reboot msinfo32.exe shows Credential Guard configured and oddly services running even though Secure Boot is disabled
• Re-Enable Secure Boot
• After a reboot msinfo32.exe shows Credential Guard configured and services remain running

Update - 7-11-17

Ran into this again on an HP Prodesk 600 G1 SFF and the workaround above didn't work. When I looked at tpm.msc it showed "TPM Not Ready". I initialized the TPM from tpm.msc, rebooted, and had to confirm a BIOS message to initialize the chip. I then disabled Credential Guard and re-enabled it with the readiness script and then Credential Guard Services showed "Running" in msinfo32.exe. 

Other Notes

In my experience you can't image a machine when Credential Guard is enabled.

Additional Resources

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

https://blogs.technet.microsoft.com/poshchap/2016/09/23/security-focus-check-credential-guard-status-with-powershell/

Deploying Privileged Access Workstations - Derbycon Talk and Slides

Here is the recording of my Derbycon talk on deploying privileged access workstations and other ways to limit lateral movement and credential theft. Here are the slides from that talk - http://www.slideshare.net/BlueTeamer/deploying-privileged-access-workstations-paws-66374801.

I'll also be giving an updated version of this talk at Dakotacon 2017. Hope to see you there!

Bitlocker Group Policies - Store Recovery Keys in AD

Below are some screenshots for configuring Bitlocker in both TPM Only and TPM+PIN modes. These policies will also automatically store Recovery Keys in Active Directory in the Bitlocker Recovery tab in Active Directory Users and Computers (ADUC). If you are configuring AD to store Bitlocker recovery keys reference the link in the "Additional Resources" section about verifying your AD schema version.

The policy Interactive Logon: Machine account lockout threshold is set at 10 failed logons and then the machine should reboot into Bitlocker Recovery mode. This helps prevent a brute force attack of the Windows login screen and is definitely a good idea especially when using TPM Only. 

Delegating the Right to View Bitlocker Recovery Keys

You can delegate the right to view Bitlocker recovery keys on a particular OU by giving full control of msFVE-RecoveryInformation objects to a user or group of your choice. Domain Admins are the only group that can view these recovery keys by default. 


Note: To view the Bitlocker Recovery tab in ADUC on Windows 7 you may need to add that feature in appwiz.cpl, but it should be viewable on Windows 10 as soon as the GPO is applied. 

Additional Resources

http://theitbros.com/config-active-directory-store-bitlocker-recovery-keys/

Windows 10 - Is Bitlocker TPM Only Secure Enough?

I’ve spent the last week or so researching Bitlocker as a replacement for a third party whole disk encryption product. Microsoft previously recommended pre-boot authentication as a best practice but with Windows 8.1+ they say the following which I’m starting to agree with after some research:

“In the end, many customers will find that pre-boot authentication improves security only for a shrinking subset of devices within their organization. Microsoft recommends a careful examination of the attack vectors and mitigations outlined in this document along with an evaluation of your devices before choosing to implement pre-boot authentication, which may not enhance the security of your devices and instead will only compromise the user experience and add to support costs.” - https://technet.microsoft.com/en-us/itpro/windows/keep-secure/choose-the-right-bitlocker-countermeasure

I’ve read about different Bitlocker attacks including Cold Boot where they freeze the memory of a running system to extract the contents. It sounds like this is technically possibly the results are very unreliable and highly dependent on type and size of memory, etc.

I also read about the “Evil Maid” attack from 2009 which is mitigated by effectively implementing Secure Boot. Similarly there was some research done by Ian Haken where he takes advantage of a vulnerability in Windows on a Bitlocker TPM Only system by tricking it into authenticating to a domain controller he controls and poisoning the Windows cache. This has since been patched with MS15-122 and MS16-014.

There are also Direct Memory Attacks (DMA) which “allows certain types of hardware devices to communicate directly with a device’s system memory. For example, if you use Thunderbolt to connect another device to your computer, the second device automatically has Read and Write access to the target computer’s memory.” This really isn’t a concern unless your device has a Firewire, Thunderbolt port or similar and if it does you can often disable the port via BIOS. 

My Conclusion

Certainly pre-boot authentication is a more secure setup as it is one more hoop for an attacker to jump through. Pre-boot authentication would prevent DMA, Cold Boot, and the attacks that have since been patched. However, if your devices don’t have ports that allow DMA attacks, TPM Only Bitlocker is probably sufficient for most organizations as long as you ensure Secure Boot is enabled, a Supervisor/BIOS password, and Boot Order is set to only boot to the hard drive. It might make sense to take advantage of the usability benefits of TPM+Only on low risk assets and implement TPM+PIN on higher risk assets. 

_________________________________________________________________________

Below is a good excerpt from this article: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/protect-bitlocker-from-pre-boot-attacks

For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented. These mitigations may be inherent to the device or may come by way of configurations that IT can provision to devices and Windows itself.

Although effective, pre-boot authentication is inconvenient to users. In addition, if a user forgets their PIN or loses their startup key, they’re denied access to their data until they can contact their organization’s support team to obtain a recovery key. Today, most new PCs running Windows 10, Windows 8.1, or Windows 8 provide sufficient protection against DMA attacks without requiring pre-boot authentication. For example, most modern PCs include USB port options (which are not vulnerable to DMA attacks) but do not include FireWire or Thunderbolt ports (which are vulnerable to DMA attacks).

BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be configured with pre-boot authentication if they are running Windows 10, Windows 7, Windows 8, or Windows 8.1 and disabling the ports using policy or firmware configuration is not an option. Windows 8.1 and later InstantGo devices do not need pre-boot authentication to defend against DMA-based port attacks, as the ports will not be present on certified devices. A non-InstantGo Windows 8.1 and later device requires pre-boot authentication if DMA ports are enabled on the device and additional mitigations described in this document are not implemented. Many customers find that the DMA ports on their devices are never used, and they choose to eliminate the possibility of an attack by disabling the DMA ports themselves, either at the hardware level or through Group Policy. Many new mobile devices have the system memory soldered to the motherboard, which helps prevent the cold boot–style attack, where the system memory is frozen, removed, and then placed into another device. Those devices, and most PCs, can still be vulnerable when booting to a malicious operating system, however.

You can mitigate the risk of booting to a malicious operating system:

• Windows 10 (without Secure Boot), Windows 8.1 (without Secure Boot), Windows 8 (without UEFI-based Secure Boot), or Windows 7 (with or without a TPM). Disable booting from external media, and require a firmware password to prevent the attacker from changing that option.
• Windows 10, Windows 8.1, or Windows 8 (certified or with Secure Boot). Password protect the firmware, and do not disable Secure Boot.

Additional Resources

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/types-of-attacks-for-volume-encryption-keys