4

I've read some blogs that describe Windows Credential Guard: how it works and which security benefits it provides.

However, some of them mention that Windows can "access" credentials using RPC calls to Virtual Secure Mode (VSM).

But if Windows OS is able to communicate with VSM (Credential Guard), both running on the hypervisor, why isn't an attacker with local administrative privileges not able to do the same?

NB: Please correct me, if some details regarding Windows Credential Guard are wrong.

|improve this question
5

First off, it's important to know what Windows Credential Guard does and does not protect. It does protect domain credentials that have been used to log onto the current system, so that tools such as Mimikatz can't just dump LSASS and obtain cached credentials in a format that can be used to pivot to other systems on the network. It also protects domain credentials that have been used for RDP. It does not protect local accounts, Kerberos service tickets (Kerberos TGT is protected though), digest credentials, or cached logon password verifiers (these are hashes, not usable credentials).

WCG is part of the new Virtualisation Based Security (VBS) feature in Windows 10. The way it works is to use the Hyper-V hypervisor to run both the primary operating system and a secure secondary operating system in tandem. The secure secondary operating system is known as Virtual Secure Mode (VSM) and it comprises of the Secure Kernel Mode (SKM) and Isolated User Mode (IUM). Effectively, you can think about VSM as a kind of isolated version of the LSA, running outside of the operating system.

One of the key security requirements of running VSM properly is to enable Secure Boot. When this is enabled, all pieces of code from the Windows boot loader to the Hyper-V hypervisor to the SKM and IUM are protected via a signed chain of trust. Since the secure VM has numerous security features enabled (SMEP, TPM, IOMMU/VT-d, SLAT) it becomes impossible to gain code execution on the secure VM without some kind of SMM or hardware vulnerability. As the normal OS (where an attacker would gain code execution) is itself virtualised separately by Hyper-V, it is entirely isolated from the secure VM and cannot influence it except via the exposed APIs.

As such, the only way to get access to the data stored within the VSM is via the exposed APIs. These APIs are exposed only to the kernel (ring0) in the normal operating system. The main operating principle of WCG is that it acts like an oracle. You ask it to generate a remote login token for a particular system using cached credentials, and it does so. You can't see the cached credentials, and you can't use the generated token to recover the cached credential or generate other login tokens. You also can't use it to generate malicious tokens, like a kerberos golden ticket, which was possible in the past via such tools as Mimikatz.

Future reading that you might find interesting:

|improve this answer
  • Thanks for an excellent answer. By "secure VM" you mean VSM? By "cached credentials" you mean things like NT hash and TGT? And by "main OS" you mean Windows 10 or equivalent? – Shuzheng Nov 18 '18 at 15:12
  • Keep in mind that While the VSM is protected by hardware (in theory), exploits in the IOMMU, hypervisor escapes and API exploits have been found often enough in the past that absolute trust in this construction is as unwarranted as it was with the non-virtualised protections. – John Keates Nov 18 '18 at 16:42
  • @Shuzheng Yes, VSM is the secure VM and the "main OS" or "normal OS" is Windows 10. Cached credentials are the raw passwords used for domain logon, TGT, etc. that are protected by WCG. – Polynomial Nov 18 '18 at 19:44
  • 1
    @JohnKeates This is true. Alex Ionescu did a rather thorough review of this as part of the BH2015 talk I linked, which is a worthwhile read. – Polynomial Nov 18 '18 at 19:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.