Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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.
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:
