- Install Ansible on Windows - Thu, Jul 20 2023
- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 2023
Single sign-on (SSO) is a good thing, don`t you agree? After all, SSO enables our users to (a) sign into the Active Directory domain once, and (b) gain transparent access to network and potentially cloud resources without being prompted for reauthentication.
Windows-based computers support SSO by caching the user's credentials in RAM. Specifically, the password hash is stored in user-mode Local Security Authority Subsystem Service (LSASS) process memory.
The problem? Any rogue party with an appropriate penetration testing tool (such as Mimikatz) can feasibly connect to a target system over the network and pluck the logged-on user's password hash from unprotected LSASS memory. This is what's known as a "pass the hash" attack. This type of attack can also target Kerberos’ ticket-granting-tickets ("pass-the-ticket") or plaintext passwords ("pass-the-pass").
Enter virtualization-based security
In Windows Server 2016 and Windows 10, Microsoft appears to be going "all in" with regard to virtualization-based containerization. Sure, we've had file system and registry virtualization since Windows Vista. In addition, Hyper-V forms the basis of Microsoft's private and public cloud strategies. And then there's Docker containers...
Anyway, in Windows 10 and Windows Server 2016, we have a new feature called Credential Guard that's engineered to stop the "pass-the-*" attacks we previously described.
Look—Microsoft is known for confusing terminology. For example, in the Microsoft literature, you'll see references to both Device Guard and Credential Guard. Specifically, Credential Guard is a single feature in the larger Device Guard feature set. Device Guard is beyond the scope of today's article; visit TechNet for a detailed description of the Device Guard feature set.
For that matter, Microsoft originally called Credential Guard “Virtual Secure Mode” (VSM). Oh well. One thing for which we can always count on Microsoft is an ever-changing cornucopia of three-letter acronyms (TLAs).
Credential Guard works by storing logon credentials (what Microsoft calls "derived credentials") in an isolated Local Security Authority (LSA) process that is completely inaccessible from the rest of the operating system. Windows' LSA process uses remote procedure calls to access the isolated LSA container and pluck out user credentials.
The isolated LSA process (formally termed "Isolated User Mode" [IUM]) hosts no device drivers. It contains only enough Windows OS binaries to allow for secure credential access. The binaries are digitally signed by a certificate that is trusted by the Windows security subsystem. Here's a Visio drawing I whipped up to illustrate how Credential Guard works:
Microsoft Windows Credential Guard schematic diagram
Credential Guard requirements
At first blush, the Credential Guard hardware and software requirements seem pretty steep, at least if your shop doesn't have fairly current hardware. Here's the list:
- Operating systems: 64-bit Windows 10 Enterprise or Windows Server 2016
- Firmware: UEFI firmware v2.3.1 or higher. The key point here is that the system's UEFI must support Secure Boot. Recall that Secure Boot is a UEFI feature embraced by Microsoft that prevents unsigned (unauthorized) OS loaders or device drivers from loading during startup.
- CPU virtualization extensions: Intel VT-x or AMD-V with SLAT support
- TPM v 1.2 or 2.0: Trusted Platform Module (TPM) is a motherboard chip that stores Credential Guard encryption keys
As of this writing, you can't enable Credential Guard on a Windows 10-based VM.
Enabling Credential Guard via Group Policy
The easiest way to deploy Credential Guard is to do so in local or domain Group Policy. Pop open your Group Policy editor and navigate to the following location:
Computer Configuration\Administrative Templates\System\Device Guard
We're looking for the policy named “Turn on Virtualization Based Security,” as shown in the following screen capture from my Windows Server 2016 Technical Preview (TP) 5 VM:
Enable Credential Guard in local Group Policy
Disabling Credential Guard
After enabling this policy, you have two choices about how you want Credential Guard to behave:
- Enabled with UEFI lock: Credential Guard can't be remotely disabled. An administrator needs to locally logon to the machine in question to disable the feature (along with modifying Group Policy if necessary).
- Enabled without lock: Credential Guard can be disabled remotely via Group Policy.
However, you'll want to perform due diligence before enabling Credential Guard across your enterprise. The reason for this is that Credential Guard prevents the use of older NTLM credentials and unconstrained Kerberos delegation for security reasons. That second point may tweak a few of you in our readership because Kerberos delegation is a standard method to allow our line-of-business (LOB) applications to forward account credentials.
We can use good ol' System Information (msinfo32.exe) to determine whether Credential Guard is enabled or disabled. My virtual machine wouldn't work with UEFI, so you can see in the following screenshot that Credential Guard is enabled but not running:
Verify Credential Guard status with MSINFO32
Remaining vulnerabilities
We must always keep in mind that no single security feature or measure alone provides complete protection. Here's a laundry list of scenarios that Credential Guard can't mitigate:
Subscribe to 4sysops newsletter!
- Software that doesn't store secrets within Windows feature protection (Microsoft recently announced that Credential Guard now protects credentials stored in Windows Credential Manager.)
- Local user accounts
- Microsoft Accounts
- Key loggers or other physical attacks
When you say “Local user accounts” is that the built-In Administrator account and/or other local administrator accounts on the machine?
does credential guard work or can be implemented on MS Windows Server 2008 or 2003 ? I found some blogs which states that credential guard has been implemented from Windows 10 and MS Windows Server 2016 onwards.
Thanks
Sushanth