This turned out to be a somewhat interesting Saturday afternoon. I finally got some time to play around with the Virtual Secure Mode feature that is available in Windows 10 Enterprise (only). Since that feature requires the Hyper-V hypervisor to be installed, and I’m still running Windows Server 2012 R2 on my main Hyper-V hosts, testing this in a virtual machine was not an option. Instead I used a Dell XPS 13 (4393) Core i7 box, which is a quite nice machine.
Note: Windows Server 2016 will support virtual TPM 2.0 device to guest VMs, and also will support nesting of virtual machines, testing should be much easier in the future.
Virtual Secure Mode (VSM) explained
Simply put, VSM is a Hyper-V container that isolates the lsass.exe process from the running Windows 10 machine. Reducing the risk of credentials being “ripped” from the computer using tools like mimikatz, and used for pass-the-hash attacks. Something worth mentioning, that I learned the hard way, is that VSM only protect domain credentials, not local accounts.
Enabling the Virtual Secure Mode (VSM)
The documentation around implementing VSM is scarce to say the least, making the project require a bit of research. But here are the steps to enable VSM in Windows 10 Build 10130.
- Enable Secure Boot and UEFI in BIOS, as well as TPM. Both version 1.2 and 2.0 (PTT) seems to work, but on my Dell XPS 13 I had enabled 2.0.
- Deploy Windows 10 Build 10130 with a deployment solution of your choice (MDT or SCCM). Configure the solution to join the machine to the domain (again VSM only protects domain credentials).
- Install the Hyper-V feature in Windows 10. In my testing I had issue when adding the Hyper-V Platform and Hyper-V Management Tools at the same time. But adding the Platform first, and then Management tools fixed that problem.
Adding the Hyper-V feature. - Enable the Virtual Secure Mode (VSM) policy setting , conveniently named “Enable Credential Guard” (was named LSA Credential Isolation in earlier Windows 10 builds). The setting is found in the “Computer Configuration / System / Device Guard / Turn on Virtualization Based Security” policy
Configuring the “Turn on Virtualization Based Security” policy.
- Finally, configure the BCD in Windows 10 to start VSM by running the following command in an elevated Command prompt and then reboot the machine:
bcdedit /set vsmlaunchtype auto
Verify that VSM is running
You can verify that VSM is running by either looking in Task Manager for the “Secure System” process, or in the Event Viewer / System view.
Event Viewer, showing the Wininit information about credential guard (Lsalso.exe).
Task Manager with Secure System process running.
Putting VSM to the test
Finally it’s time to put VSM to the test. On the machine with VSM enabled, I logged in as a domain user (VIAMONSTRAJohan), switched over to a local admin account and run the following mimikatz command:
mimikatz.exe privilege::debug sekurlsa::logonpasswords exit
Here is the output, showing the isolated LSA information. The next image is same command from a machine without VSM enabled.
Virtual Secure Mode (VSM) enabled, showing the LSA isolated data in mimikatz.
Virtual Secure Mode (VSM) disabled, showing the NTLM hash in mimikatz, which can be used for pass the hash attacks.