version 2019-08-31 by Artem Pronichkin
submit a
comment
(“issue”) or
edit
Good for you. You actually don't have to do anything.
You know, we at Microsoft take security very seriously. We want the important security features (such as Credential Guard) to be used by everyone. And we know very well that if special configuration is required to enable some feature, nobody will end up using it. So we worked hard to make sure Credential Guard works in Virtual Machines in default configuration.
Read this again. You do not need to change any settings. Whoever told you have to run ABC command or enable XYZ feature was wrong. Please see below for popular myths and misconceptions
You need to enable Nested Virtualization (“ExposeVirtualizationExtensions”) in order to have Credential Guard running inside a VM.
— Artem Pronichkin (@pronichkin) August 30, 2019
Honestly, I cannot believe how popular this myth still is!
Ouch! Sorry, I cannot help you there. You need to talk to the respective virtualization solution vendor. I might provide some links later, but your favorite search engine might serve you even better.
This functionality might be available—however, it may indeed require some special configuration. Moreover, you might need to reevaluate the security promise or goals of implementing this as part of end-to-end solution, especially if you consider not only in-guest attacks, but also host-based attacks. (See below for some examples of such thinking.)
Everything below is applicable to Hyper-V, running on a modern version of either Windows Server or Windows 10. If you are uncertain about availability of specific feature, please consult official product documentation or an in-depth blog post. This page is not intended to replace or substitute any of existing documentation. It can only provide an additional angle to look at the problem.
Before diving into details, we need to make sure we're on the same page.
We're primarily talking about Credential Guard here because that's what everyone seems to be obsessed with. Everyone have read about Mimikatz (or seen some cool demo) and believe they need Credential Guard. Well, who am I to disagree. However, out of this need, people seem to drive all sorts of false assumptions and unnecessary requirements. This becomes particularly noticeable when we start talking about virtual machines. Nowadays it seems that pretty much everyone have finally understood the prerequisites to run Credential Guard on bare metal (that is, on physical computers.) But when we add virtualization to the picture, everyone suddenly becomes utterly confused. So, we're here to debunk at least some of that confusion.
That's the actual technology that powers Credential Guard. Credential Guard fully depends on Virtual Secure Mode. The very problem of understanding and satisfying the requirements of Credential Guard (be it on a physical or virtual machine) is actually the problem of understanding and satisfying the requirements of running Virtual Secure Mode. Throughout this document, we keep saying “Credential Guard” because that's what everyone is concerned about (and we understand that's the end goal.) However, what we are actually talking about is enabling Virtual Secure Mode.
In fact, there is a bunch of other security technologies in Windows that are independent from Credential Guard but similarly to it depend on Virtual Secure Mode. For example:
Virtual Secure Mode is designed as an extensible infrastructure, where additional features can be plugged in as so-called “trustlets”. Hence, expect more and more features to be introduced over time with dependencies on Virtual Secure Mode—both in Windows and other software (such as SQL Server.)
All of such features would share the same requirements that are actually prerequisites to run Virtual Secure Mode. Hence, the below discussion applies entirely to any of such features. Just replace “Credential Guard” with the name of the feature you're concerned about—and keep reading.
That's simply another name for Virtual Secure Mode. Exactly the same thing, just slightly different accent. “Virtual Secure Mode” (VSM) is a Windows feature name, while “Virtualization-Based Security” (VBS) is more like a generic industry term. But for the context of this (and many others) document these terms mean exactly the same and are completely interchangeable.
Do not get confused. We prefer to say “Virtual Secure Mode” but you can use whatever name you please. Moreover, “VSM” just sounds less ambiguous than “VBS”.
No. That was true very long ago, for early versions of Windows 10. (Namely, versions 1507 and 1511.) Starting with Windows 10, version 1607, that's no longer true.
You might also know version 1607 under one of the following names:
None of these, or later versions of Windows require any optional features or components to be installed.
There are multiple hypervisor-related features you might find in “Windows Features” window (.\OptionalFeatures.exe).
Display Name
(used in “Windows Features”)Internal Name
(used in DISM or PowerShell)Comment Hyper-V Microsoft-Hyper-V-All Parent feature for “Hyper-V Management Tools” and “Hyper-V Platform” Hyper-V Platform Microsoft-Hyper-V Parent feature for “Hyper-V Hypervisor” and “Hyper-V Services” Hyper-V Hypervisor Microsoft-Hyper-V-Hypervisor Actual hypervisor, when used as part of Hyper-V feature, i.e. including management APIs. Virtual Machine Platform VirtualMachinePlatform Hypervisor component without management layer. Required for non-Hyper-V features like HVSI (not to be confused with HVCI), Containers, WSL2 or Windows Defender Application Guard, WDAG (not to be confused with WDAC) Windows Hypervisor Platform HypervisorPlatform Also known as “WHPX”. Allows 3rd party virtualization software (e.g. Qemu, VirtualBox, Android emulator, and soon VMware Workstation) to leverage Windows hypervisor in place of their own (while maintaining their own services and management layer), and hence coexist with other features that depend on it, such as host VSM Isolated User Mode IsolatedUserMode Legacy feature used in older versions of Windows 10 (see above). Not available or needed anymore
The funny thing is, all of the above features leverage Windows hypervisor, one way or another. But this plethora of options and their taxonomy might be highly confusing—and boy it is! (To make the list shorter and hence slightly less confusing, the above table does not include Hyper-V management features. The names of their respective components are pretty self-explanatory.)
Good news, however, is that you do not have to manually enable or configure any of them! If you see any guidance that tells that you need to enable any of these features (either manually or via script), that guidance is significantly outdated. It was authored for some very old version of Windows which is likely out of support already. If you are using that version of Windows, you have bigger problems to solve than enabling Credential Guard. Good luck!
That's not true. Nested virtualization is required if you need to run actual hypervisor inside a virtual machine. As per the previous chapter, you do not need to run hypervisor if all you need is Credential Guard.
Please read this again. You do not need to enable any optional features inside a virtual machine, or configure any settings for a virtual machine, if your end goal is to run Credential Guard.
(There are other valid scenarios where you indeed have to enable nested virtualization. These are the scenarios where you need to install any of the features from the above table. For instance, if you intend to run containers or Windows Defender Application Guard (WDAG) inside a VM, nested virtualization is your friend. But those scenarios are specialized and not meant to be as universal as Credential Guard or HVCI which are designed to run everywhere.)
You are talking about this PowerShell command:
Set-vmProcessor -vm $vm -ExposeVirtualizationExtensions $True
This command enables Nested Virtualization. That's exactly what it does. Nothing less, nothing more. You do not need to do that. Please check out the previous section.
This is a known prerequisite to enable Nested Virtualization. While not strictly required, it's advisable to disable Dynamic Memory if you intend to use Nested Virtualization. (More details here.) Note that it used to be a strict prerequisite for Nested Virtualization in some preview builds, but not anymore.
However, you are not going to use Nested Virtualization. So, this recommendation does not apply. If you believe you need Nested Virtualization please see above.
This is yet another known requirement related to Nested Virtualization. It applies to scenarios where all of the following is true.
As a reminder, there may be various reasons to run VSM inside a VM. Credential Guard is one of them. However, if you only need VSM (and any features that depend on it, such as Credential Guard), you do not have to enable Nested Virtualization . Hence, this limitation does not apply to you.
Fine, but when is it actually needed?
The most common scenario where all of the above conditions are valid is running so-called “Guarded Host” inside a VM, e.g. for a Shielded VMs lab. Shielded VMs technology (or, more precisely, virtual TPM functionality) relies on VSM on the host (and such host is called Guarded Host.) If your host is actually a VM itself, you end up in this scenario.
Another less common use case where the same set of conditions applies is scenario known as “Repair Garage” used in some Shielded VMs implementations. It is different from the abovementioned lab scenario in the sense that the only Shielded VM is the “Garage” itself. It runs under a hypervisor which runs directly on bare metal. As such, we can call it “Level 1” or “Parent” VM. The “Child” or “Level 2” VMs are not necessarily shielded. However, since this scenario still involves nested virtualization, it falls into the same bucket from prerequisites standpoint.
In either case, VSM of “Parent“ VM cannot benefit from DMA protection. The reason is that Hyper-V does not provide a virtual device with IOMMU functionality (an equivalent of “Intel Virtualization Technology for Directed I/O” or VT-d.)
So, if you configure Virtual Secure Mode for such scenarios, you should not set it to require DMA protection. In other words, the value of “RequirePlatformSecurityFeatures” parameter should be 1 instead of 3.
If you are curious what are the meanings of different numerical values of “RequirePlatformSecurityFeatures”, they seem to match those of “RequiredSecurityProperties” property of “Win32_DeviceGuard” WMI class. However, the only officially documented values are 1 and 3.
Anyhow, unless you intend to run “child” virtual machines (shielded or otherwise) inside your “parent” virtual machine, you do not need the nested virtualization feature. Consequently, the DMA Protection limitation does not apply to your scenario. You can safely expect that DMA Protection is available, and hence require it. That is, set “RequirePlatformSecurityFeatures” to 3.
However, if you indeed aim to use Nested Virtualization, and hence relax the DMA Protection requirement, please be aware that you are trading off a valuable security feature—so you have to understand your scenario and implications well.
Consequences
Strictly speaking, DMA protection functionality (IOMMU) does not make sense for a virtualized environment anyhow—because there's no DMA hardware in a virtual machine. (Unless you specifically enable Guest RDMA .) If the “parent” VM is shielded (e.g. in a “Repair Garage” scenario), it provides sufficient protection from the host-based attacks, even in the absence of DMA protection in the guest.
(The physical machine of course still needs this important functionality. Please see below for details on Shielded VMs threats and countermeasures.)
In a typical lab scenario, however, the “parent” virtual machine is typically not shielded, while the “child” VMs might be. (Because, if you already can run a Shielded VM as your “Level 1” VM—that is, under a hypervisor running on bare metal—you probably do not need to do that in a lab anymore.) In this configuration, the “child” VM's secrets are expected to be secured by the VSM running in the host—which in our case is “parent” VM. However, as the latter is not shielded, these secrets are still vulnerable to host-based attacks. Hence, this is a perfectly valid lab scenario, but it does not provide any real protection. It cannot be used for vulnerability assessment, penetration testing or actual production deployment.
Well this assumption is not as false as previous ones. However, it is still false. In fact, you do not need a TPM to run Credential Guard. This is true for both physical (bare metal) and virtual machines. So, a TPM is not strictly a requirement.
However, TPM is highly recommended. As documentation says, “A TPM provides protection for VBS encryption keys that are stored in the firmware. This helps protect against attacks involving a physically present user with BIOS access.”
Please note the emphasis I added to previous paragraph. This is very important for the following discussion.
Virtual TPM and VM identity
Virtual TPM (vTPM) is somewhat an unusual virtual device. While most of VM devices can be added or removed, a virtual TPM can only be enabled or disabled. Similarly to a physical TPM, soldered on the motherboard, you cannot truly remove it, or replace with an instance of another device. Even if you disable vTPM, and then enable it back, it's still the original instance of the device with the previously existing contents. Normally it does not matter, but please keep this in mind in case of any troubleshooting or security compromise.
You can clear or re-initialize a virtual TPM similarly to a physical TPM. However, if for some reason you need to actually replace it, you will need to create another VM configuration from scratch. That would affect other identities of the VM. Some of them are more or less easy to change (to mimic those of original VM)—for instance, SMBIOS GUID, Serial Number or MAC addresses of the vmNICs. However, some other identities are very hard (if ever possible) to modify—such as PNP IDs of virtual devices.
To put it simply, you don't. There are no technical requirement to have any of Shielded VMs features if you want to run Credential Guard or any other feature powered by Virtual Secure Mode (e.g. HVCI.)
Devil in details
However, let's talk about threat modeling a little. As explained above, having a TPM is strongly advised. Without a TPM, your machine (or anything protected by VSM inside a machine) is vulnerable for attacks by anyone with physical access. For a physical, bare-metal machine, that's anyone hanging out nearby your computer. Plain and simple. But for a virtual machine, the list goes on and on. Virtualization is a blessing for IT because it provides unprecedented abstraction and flexibility. But the direct consequence of this abstraction is the need to rethink the concept of “physical access”.
At very least, that includes anyone hanging out nearby your virtualization host. However, an equivalent of physical access includes anyone (no matter how remote they are) with administrative privileges on the virtualization host (e.g. your virtualization administrator). But protecting the host itself is not enough. Because the list also includes anyone with access to virtual machine files in one way or another. For some environments that might include the storage (SAN) administrator, backup operator, antivirus administrator, whoever manages the patching infrastructure, network administrator, datacenter technicians—or even the hardware vendor who is authorized to come in and swap bad parts in servers.
(From the standpoint of a Shielded VMs implementation we call all these parties collectively “Fabric Administrators”—however, this might be confusing, especially considering what a “Fabric” means in other contexts. We intentionally unify them under a generic term because they are all equally untrusted from the perspective of a VM owner—the party we call “a Tenant”).
What I'm trying to say here, the concept of “physical access” is very different comparing with that with a physical computer. For a virtual machine, “physical access” is… well, virtual.
And so what?
So, looking at the above recommendation again, we should add a TPM to mitigate the physical presence attack vector. Is that it? Well, yes, if we were talking about a physical machine. But with a virtual machine, that list of people who have an equivalent of “physical access” might be endless.
For this very reason, simply adding a virtual TPM does not add anything to our threat model. Now instead of protecting the VM disk files, we need to protect much smaller resource or configuration files (where the contents of virtual TPM lives.) Even though virtual TPM contents is always encrypted at rest, the encryption key has to be stored somewhere. And by default there's nowhere else to store it other than the host itself. Which means it is still perfectly accessible to anyone with access to the host (online or offline.)
Yes, the purpose of Credential Guard is to protect from attacks from within the same operating system (e.g. malicious processes—such as Mimikatz.) In some context, we can also call them “in-guest” or “online” attacks. If your threat model only counts for these types of attacks, running Credential Guard (even without a TPM) would address that. But if you also consider attack at the host level (e.g. malicious or careless administrator), we're just getting started.
So, what about host-based attacks? You have a magical checkbox for it, too?
Now we're talking. Unofrtunately, addressing this specific attack vector is not easy at all. Turns out, to do that comprehensively, you need a whole bunch of new things.
If you never thought of some of these things before, don't blame yourself. Virtualization technologies evolved heavily over the last couple decades. However, until very recently, they were not considered mature enough, performing enough, or valuable enough to gain prime-time attention for production and serve real security-sensitive workloads. Moreover, the threat landscape also evolved rapidly, and it took quite some time for malicious actors (or your friendly pentesters) to start paying attention to compromising virtualized assets. Finally, that all caused a paradigm shift in how we think about security and protection—and nowadays, “assume breach” and “defense in depth” are hot topics.
And only when it all happened, we as an industry started thinking of what's needed to provide physical-level security (or better) for virtualized world.
- Decouple the storage of protected secret (vTPM contents) from the encryption key protecting this secret.
- Offload key protection to an external authority which is not controlled or accessible by virtualization host (“Fabric”) administrators.
- A mechanism to ensure that keys can only be decrypted by predefined list of known such authorities. (Using the concept of public and private keys.)
- Because hosts still need access to the key when turning on the VMs or accepting incoming live migrations, implement a mechanism of delivering said key to the host and storing it host's secure area (which is also based on Virtual Secure Mode—ironically, here one application of security technology helps to secure a separate, logically independent instance of the very same technology. That's the beauty of pluggable “trustlet” model.)
- A protocol to ensure the abovementioned transfer is done securely and only to authorized hosts.
- Set up a comprehensive set of technical protections that prevent host (or “Fabric”) administrators from intercepting the keys or decrypted secrets while VMs are running. That includes regular features protecting VSM, such as DMA protection, as well as additional safeguards—such as preventing debuggers, memory dump encryption, application whitelisting (Device Guard Code Integrity or Windows Defender Application Control, WDAC), etc.
- A way to define, in a structured way, a known good set (baseline) of host configuration—including all of the protections mentioned above, and their settings (e.g. exact Code Integrity policy applied.)
- A mechanism to check (attest) a given host against the defined baseline.
- A mechanism to ensure that key delivery only happens when a host passes attestation.
- Yet another mechanism to ensure the previously obtained key is invalidated automatically should the host suddenly deviate from the baseline (e.g. Code Integrity policy was modified or lifted.)
- A framework to enforce protections on VM level (policy), so that security properties are embedded into VM configuration and cannot be arbitrarily changed by whoever has access to the host-level settings or storage.
- A mechanism to ensure that policy applies automatically to all new VMs created by (or on behalf of) specific owner.
- A mechanism to ensure that only known good media (“Clean Source”) is used to provision a virtual machine. (Otherwise an administrator or malware running at Fabric level could poison a VM before it's even created.)
- A mechanism to deliver VM specialization data (e.g. domain join credentials or certificates) during provisioning in a secure manner so that the VM maintains its identity from the “day zero”. Otherwise, there's no way to ensure that VM popped on the network is the actual VM you provisioned (e.g. prevent MitM attack.)
- At the same time, ensure that host administrators cannot sniff or tamper with the abovementioned VM credentials.
- Probably other things which are less important or which I forgot of.
Shielded VMs solution address precisely the concerns above, so that you can be confident that your secrets—while protected by Credential Guard in the Guest—are immune to “physical presence”-equivalent attacks at the host.
Wait, so you first said that I do not need Shielded VMs, but now you say I do?
Yes, this is a classic example of “yes but actually no” scenario. You do not technically need Shielded VMs to enable Credential Guard. However, you might consider this a requirement if you assess the security of end-to-end solution. Or you might very well dismiss this requirement if you rule host-based attacks out of the picture and decide that hosts are ultimately trustworthy “as is” without the need of policy enforcement or attestation. (E.g. if you're running at a cloud provider which you fully trust.) But again, in this case, you don't even need a TPM in your machines. It does not provide any additional security benefit. (Note that it still does make sense to enable Credential Guard in such machines in order to protect from in-guest attacks.)
This gray sidebar is intended to help you make an educated decision, not to push you in one direction or another.
Finally, it's worth mentioning that “Shielded VMs” term is a bit overloaded. Having a VM “Shielded” by ticking a checkbox in Hyper-V management interface will not magically deliver on the security promise explained above. From the list of features above it should be obvious that they work closely together and depend on one another. Having only some parts of the solution will not help you much, if ever. So, if you are interested in this comprehensive set of protections you need to implement the whole Shielded VMs solution, or infrastructure. That might include both technical features (e.g. Host Guardian Service or HGS) as well as organizational or process-level changes. The cornerstone of the Shielded VMs solution is role separation , and you cannot technically enforce it if there are no separate roles in your processes.
However, believe it or not, but planning a Shielded VMs implementation is not the topic of this document. As such, let's get back to answering the original question.
No, you do not need Shielded VMs for running Credential Guard in the VMs. However, if your threat model includes not only in-guest, but also host-based attack vectors (which is an equivalent of “physical access” for virtual machines) you definitely should implement the full Shielded VMs solution. No other technology available in market today can deliver this comprehensive set of protections. Moreover, a partial implementation would not provide end-to-end security, because all of the components depend on one another, back to back.
Encryption-supported VMs is a subset of Shielded VMs functionality. Or, put it slightly different, it's an alternative security policy option for virtual machines, on par with Shielded. They provide the same virtual TPM functionality and offloaded key protection.
As such, Encryption-supported VMs rely on all the same infrastructure as full Shielded VMs solution. Just as with Shielded VMs, you cannot have Encryption-supported VMs without deploying the full solution. Having Encryption-supported instead of Shielded does not lower any of the infrastructure requirements or eliminate the need for any upfront investments.
However, Encryption-supported VMs provide slightly more convenience—both for virtual machine owner (“Tenant”) and host (“Fabric”) administrator. As such, it might be a viable alternative to Shielded VMs in some scenarios where you can trade off some secuirty.
To reiterate, if your end goal is to run Credential Guard, you do not need Encryption Supported VMs—just as you don't need Shielded VMs either.
However, if your threat model assumes host-based attack vectors, and you are looking at Shielded VMs to address those, you can consider Encryption-supported VMs. But you will need to carefully assess different available policy options and validate them against your threat model before deciding between Shielded or Encryption-supported.
As I said multiple times already, you don't need to do anything. However, I knew you won't simply believe me, so here are some details.
This is one of key requirements of Virtual Secure Mode, and hence Credential Guard. However, it's enabled by default for all Generation 2 virtual machines.
Note that technically you can enable VSM even without Secure Boot by setting “RequirePlatformSecurityFeatures” to 0. That would even allow you to run VSM in a Generation 1 VM. (However, in this case you would actually need to enable nested virtualization as well.)
By the way, that's how Guarded Host is enabled for Shielded VMs in scenario where none of the physical security features (Secure Boot, TPM and/or IOMMU) are available. This is typical for a rather niche interim use case where you need “encryption for the sake of encryption” (read: for compliance.) For such scenarios, Shielded VMs architecture provides couple of less-secure modes—namely, AD-based attestation or Host Key attestation.
However, based on the above, it should be already obvious that such configuration do not provide any reasonable level of protection. Without a TPM, you're vulnerable to offline attacks (either with physical presence, or host-based.) Without Secure Boot, you can expect even less. For instance, a malicious process running in Guest can also compromise VSM right away by tampering with the boot loader. As such, while technically possible, this configuration is not supported for Credential Guard whatsoever.
Secure Boot is UEFI feature. As such, it is only available for Generation 2 virtual machines. There's no way to “emulate” Secure Boot functionality for a legacy BIOS-based machine.
(Even though some other features may be available for Generation 1 virtual machines—such as BitLocker with offloaded key protection. This won't address any of VSM or Credential Guard requirements. So, this is irrelevant for the topic of this document.)
Please do not abbreviate “Generation 2” as “Gen2”. This sounds wrong. I mean, it's a common mantra nowadays that Microsoft loves Linux. But not up to the point of making our features sound indistinguishable from a name of a popular Linux distribution. Unless you're sending a telegram and hence have to pay by the letter, please use full name of the feature: “Generation 2”. Show a little respect. Trust me, it does not hurt to type a little more.
This is a feature that actually allows you to run Virtual Secure Mode without having a hypervisor running inside virtual machine. Instead, it provides the required isolation services from the host (while not compromising security.)
Similarly to Secure Boot, this feature is enabled by default for all Generation 2 virtual machines (starting with configuration version 8.0 .) You do not have do anything about it. That's the whole point of this document.
If you're running on-premises, there's no need to deploy Generation 1 VMs, especially for newer services and applications. Generation 2 VMs provide numerous improvements and additional features comparing to Generation 1 VMs. Guest VSM and virtual TPM are just some of them.
However, you can disable this feature if you want. That might be helpful in some edge case scenarios, such as:
Set-vmSecurity -vm $vm -VirtualizationBasedSecurityOptOut $True
Yes, to disable a feature, you need to enable ($True) a setting that opts out this feature. So PowerShell, much intuitive, wow. Don't ask me.
Note that you can even disable Guest VSM for a Shielded VM. (Unlike other settings like vTPM, it's not part of the VM Security Policy.) That would stop VSM (and hence Credential Guard) from running inside a VM. (Unless nested virtualization is enabled, and the effective VSM configuration does not require DMA protection.)
Potentially, this may decrease the Guest OS resistance against the threats running inside the virtual machine. However, this will not make the VM vulnerable to host-based attacks (offline or online) because the machine is still Shielded (and hence protected in flight), and its disks are still encrypted (and hence protected at rest.)
This, of course, is never a recommended scenario. I only explain it for the sake of completeness and demonstrating the risk assessment approach.
All of the above talks about satisfying Credential Guard prerequisites (host or guest level.) But even once all prerequisites are met, the feature is not enabled by default. (It may, on some newest PCs or operating systems, but generally it is not. The primary reason for that is ensuring backwards compatibility with potential legacy applications or security settings.)
So, you still need to enable Credential Guard yourself (and/or other features you're interested in, such as HVCI.) Use your preferable configuration delivery tool—such as Group Policy, MDM or direct registry manipulation. Please do it!