Enable windows virtualization based security esxi что это

With version 6.7, VMware added support for the Windows 10 virtualization-based security (VBS) feature to the vSphere suite. Microsoft’s VBS is also available for Windows Server 2016 operating systems (OSes).

What is Virtualization-based Security (VBS)?

VBS uses hardware and software virtualization features to enhance Windows system security by creating an isolated, hypervisor-restricted, specialized subsystem.

Basically, Microsoft is using a Windows role (or component) called the Hyper-V role, which boots the OS. This hypervisor allows Microsoft to isolate some sensitive information in places that would normally be accessible to the OS. Here we can think of cached credentials and such things.

Most modern systems have a Trusted Platform Module (TPM) 2.0 device built into the hardware. However, someone had to do it in software. And this is the goal. To give you an idea, here is a screenshot from a VMware blog post.

As you can see, the Windows 10 virtual machine (VM) has a hypervisor role active and has the credentials stored elsewhere.

What are the restrictions on VBS-enabled VMs?

VBS is only usable on Windows 10 and Windows Server 2016, and vSphere features exist that are not compatible with VBS:

• VMware Fault Tolerance (FT)
• vSphere PCI passthrough
• vSphere hot add for CPU or memory

What are the vSphere requirements for VBS?

As mentioned above, VBS is only available as of vSphere 6.7. The requirements for working with VBS are:

• A VM with virtual hardware 14
• Hardware virtualization and an input/output memory management unit (IOMMU) exposed to the VM
• Secure boot enabled
• EFI firmware
• 64-bit CPU
• Intel VT-d or AMD-Vi ARM64 system memory management units (SMMUs)
• TPM 2.0

How do you enable VBS?

In the VMware vSphere client, first connect to vSphere and select the VM for which you want to enable VBS.

1. Shut down the VM and tick the Enable box next to Virtualization Based Security under VM Options.

Note: The VM has to be booting EFI (not BIOS) to satisfy the requirements. If you are creating new Windows 10 or Windows 2016 VMs, you should make sure you are selecting UEFI firmware before installing. After installing the system, it is pretty difficult to switch.

And once the VM is up and running, we’ll need to activate the Hyper-V role. You can do this through a simple command appwiz.cpl, which automatically brings up the window where we select Add/Remove Turn Windows features on and off. Once there, we can look for the Hyper-V section and check the box Hyper-V Hypervisor.

If you want to add a Hyper-V role on Windows Server 2016, you’ll use the Add roles and features wizard within your Server Manager.

Once you’re done, it’ll ask you to reboot the system.

Let’s continue after the VM comes up.

1. In the VM, open gpedit.msc and browse to:

Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Set it to Enable and configure the options as follows:

• Select Platform Security Level: Secure Boot and DMA Protection
• Virtualization Based Protection of Code Integrity: Enabled with UEFI lock
• Credential Guard Configuration: Enabled with UEFI lock

If you want to be able to turn off Windows Defender Credential Guard remotely, choose Enabled without lock.

If you want to activate VBS for multiple systems, you can do this via Group Policy in your domain.

Final words

I think there will be further expansion of VBS in Windows Server 2019. It is a great feature that helps protect Windows against malware and all kinds of attacks where credentials are involved.

Subscribe to 4sysops newsletter!

VMware vSphere 6.7 has brought this feature in collaboration with Microsoft. It is great to see that these two giants now work hand in hand on features that improve security.

Virtualization Based Security (VBS) is a Microsoft Windows feature that was introduced in Windows 10, Windows Server 2016 and higher. Microsoft VBS uses hardware virtualization features to create and isolate a secure region of memory from the normal operating system. For example, Windows can use this isolated memory space to store credentials (Credential Guard) to mitigate the pass the hash vulnerability.

Virtualization Based Security effectively reduces the Windows attack surface, so even if a malicious actor gains access to the OS kernel, the protected content can prevent code execution and the access of secrets, such as system credentials

The communication between the Windows OS and the credentials that are stored in an isolated memory space, will be done over RPC calls.

Requirements

VM Hardware Requirements

• VM hardware 14 or higher.
• Guest OS that supports Virtualized based Security that exists of the following VM hardware settings.
  • IOMMU
  • Hardware virtualization
  • EUFI boot firmware
  • Secureboot
• vTPM (Optionally)

The following will also be needed when using vTPM:

vCenter Requirements

• Enterprise plus license (for the native key provider)
• ESXI Cluster
• Key Provider (Native or 3th party)

Configure VMware Native Key Provider

Let me start by saying vTPM is not required to have to implement Microsoft VBS with Credential Guard. Credential Guard will work, but it will be less secure.

The only way to assign a Trusted Platform module device to a VM, is by having a configured key provider in vCenter (Native or 3th party). The key provider need to be maintained, so it will be an additional dependency in the infrastructure.

In the previous versions of vSphere, you could only configure external key providers like HyTrust to enable those security features. Guess what? VMware has finally released a native key provider called vSphere Native Key Provider.

Click here for more information about Key Providers.

We will use the vSphere Native Key Provider in this example.

1. Login to the vCenter web GUI, click on the vCenter object, click on Configure and select Key Providers.
2. Click on the ADD button and select ADD NATIVE KEY PROVIDERS to open the wizard.

3. Enter a name for the vSphere Native Key Provider and if needed enable the Use Key Provider only with TPM protected ESXI hosts if needed. In my lab, I disabled this option, because i’m using nested ESXI hosts.

Note: Use Key Provider only with TPM protected ESXI hosts will only enable the vSphere Key Provider on hosts that that physcially has a TPM 2.0 chip.

4. Create a backup of the vSphere Native Key Provider.

Microsoft VBS

Configure VBS in an existing Windows VM

Note: You should only enable the Virtualized Based Security option when the Windows Guest OS has been installed with an EUFI firmware. Converting from BIOS to EUFI could be a hard time in Windows.

1. Select the Windows VM and click on edit settings.
2. Click on the VM Options tab.
3. Enable the Virtualized Based Security option.
4. Click on Save to commit the changes.

Configure VBS in a new Windows VM

1. Create a new Windows VM (Windows 10, Windows 2016 or higher).
2. Select the latest compatibility mode to get the latest VM Hardware version.

3. Select a compatible Windows Guest OS Family that supports Microsoft Virtualized Based Security.

Have you noticed the guest OS output in the VM summary? This only means that the VM hardware has been optimized for the use of VBS. VBS still needs to be enabled inside the Guest OS.

Configure VBS in Guest OS

The virtual machine CLT02 has been configured with the required VM hardware components and is now ready to be configured for VBS in the Guest OS. Let’s have a look at the current System Information > System Summary on the CLT02 VM without VBS enabled in the Guest OS:

Next step is to enable the Microsoft VBS within the Guest OS with the security options you would like to have configured. More information can be found on the official Microsoft website.

1. Open the local group policy with gpedit.msc and browse to Computer Configuration > Administrative Templates > System > Device Guard.
2. Enable the setting: Turn On Virtualization Based Security.
3. Configure the VBS options: (Configure the options according your needs.)

4. Reboot the server to activate the VBS functionalities.

Verify with Device Guard and Credential Guard hardware readiness tool

Microsoft released a PowerShell script to verify the readiness of VBS with those security options on your Windows system. You can also enable and disable VBS security options with it. The script can be downloaded from here.

1. Download the Device Guard and Credential Guard hardware readiness tool powershell script.
2. Run the following command to verify if this device is Device Guard and Credential Guard capable.

.DG_Readiness_Tool_v3.6.ps1 -Capable

Note: Running the script for the first time requires a reboot, because of the Driver verifier that needs to be enabled.

3. Re-run the script again and this time you would see something like this.

HVCI and Credential Guard is enabled, the only thing that is absent is TPM.

4. Power off the Windows VM and add a Trusted Platform Module (vTPM).

Note: if you cannot see Trusted Platform Module under Other devices you probably don’t have a configured Key Provider in vCenter.

5. Power on the Windows VM and perform the same powershell command.

We now have VBS running with Credential Guard on our Windows 2019 test VM.

Pass the Hash tests

On a machine without VBS

In my home lab, I have a Windows 2019 VM with VBS not enabled. Let’s see perform the Pass The Hash method on this VM. I’m using the Mimikatz tool for this demo. Once a user logged into Windows, the credentials will be saved in the Local Security Authority in memory. With Mimikatz, we can exploit this and retrieve NTLM hashes. With these hashes, we can decrypt the hash to retrieve the password in plain text, and we can also create an authentication token to execute tasks on other servers for example.

1. Let’s start with logging in with a testuser that has local administrator rights on a member server.

2. Start Mimikatz and perform the following command to get debug rights (this or Local System rights is required for many Mimikatz commands).

privilege::debug

3. Let’s perform the following command to lists all available provider credentials. This usually shows recently logged on user and computer credentials.

sekurlsa::logonpasswords

We now have the NTLM hash of the user that has domain admin privileges.

Decrypt the hash

We can easily decrypt the hash to retrieve the password in plain text on hashes.com.

Create a authentication token with the hash.

We can also use the hash to create an authentication token to log on the domain controller for example. This can be done with Mimikatz as well.

1. use the following command to create an authentication token:

sekurlsa::pth /user:domainuser /domain:vkb.lan /ntlm:hash

The authentication token has been created and a new CMD window opened. When verifying the active user with whoami, I can still see that the active user is named testuser.

2. Let’s switch over to powershell by entering the word powershell.

3. Perform the following command to start a powershell session to the domain controller with a domain admin user by using the authentication token:

Enter-PSSession -ComputerName domaincontroller.fqdn

We now have a powershell session to the domain controller with a domain admin user. This shows to you all, how easy the Pass The Hash method is.

On a machine with VBS

Microsoft VBS should mitigate the Pass The Hash hack by storing the credentials in an isolated memory space. Let’s perform the same steps on CLT02 that has VBS enabled.

1. Open Mimikatz and get the debug privileges.
2. Retrieve the logon passwords.

We are now unable to see the NTLM hash in Mimikatz, because the credentials are stored in an isolated memory space.

VMware vSphere 6.7 offers the ability to enable virtualization-based security (VBS) for virtual machines. Let’s find out what kind of protection this setting provides, what’s needed to get it going and how to configure a virtual Domain Controller to use it.

Virtualization-based Security (VBS) uses virtualization features to create and isolate a secure region of memory from the normal Operating System. Windows Server can use this «virtual secure mode» to host a number of security solutions, providing them with greatly increased protection from vulnerabilities in the operating system, and preventing the use of malicious exploits which attempt to defeat protections.

Benefits of using Virtualization-based Security

Virtualization-based Security (VBS) uses the Windows hypervisor to create this virtual secure mode, and to enforce restrictions which protect vital system and Operating System resources, or to protect security assets such as authenticated user credentials.

With the increased protections offered by Virtualization-based Security, even if malware gains access to the Operating System’s kernel, the possible exploits can be greatly limited and contained because the hypervisor can prevent the malware from executing code or accessing platform secrets.

For Active Directory Domain Controllers, specifically, Virtualization-based Security offers:

Secure Boot

The Secure Boot feature in Windows Server 2016, and up, is designed to protect the virtual machine from malicious boot loaders. In traditional Basic Input/Output System (BIOS)-based systems, a rootkit may replace the Windows boot loader, remaining invisible and undetectable on the Domain Controller.

With Secure Boot, a virtual machine no longer boots with BIOS, but with Unified Extensible Firmware Interface (UEFI). UEFI checks the signature of the boot loader before launching, detecting any malware impersonating, replacing or tampering with the Windows boot loader.

Direct Memory Access (DMA) Protection

Direct Memory Access (DMA) attacks try to grab the memory of a running Operating System to gain access to BitLocker keys and other information from the memory. In vSphere, you can take advantage of an Input/Output Memory Management Unit (IOMMU) to connect a DMA-capable I/O bus to the main memory.

With IOMMU, memory of Windows Server 2016 installations, and  up, is protected from malicious devices that are attempting DMA attacks and faulty devices that are attempting errant memory transfers because a device cannot read or write to memory that has not been explicitly allocated (mapped or re-mapped) for it.

Hypervisor-enforced Code Integrity (HVCI)

Kernel-mode Code Integrity enforces kernel-mode memory protections by protecting the Code Integrity validation path with Virtualization-based Security. All drivers in the virtual machine must be compatible with virtualization-based protection of code integrity; otherwise, the virtual machine fails.

Code Integrity (CI) Policies

Historically, most malware has been unsigned. Simply by deploying code integrity policies, organizations can get immediately protection against unsigned malware. By using Code Integrity policies, an enterprise can also select exactly which binaries can run in both user mode and kernel mode. When completely enforced, it will only load specific applications or software with specific signatures.

Note:
Code Integrity policies are independent of Hypervisor-enforced Code Integrity (HVCI). However, when using CI policies without HVCI, the enforcement will not be as strong as when using CI Policies with HVCI.

Note:
Windows Server 2019 expands on the CI policies feature in Windows Server 2016 by offering built-in CI policies for robust yet quick deployment of Code Integrity.

Other features like Application Guard, Credential Guard and Windows Sandbox, operating in their separate memory spaces are features targeted towards Windows-based devices and are not applicable to Domain Controllers. Well… when you adhere to the rule of thumb not to browse the Internet and install all kinds of software on your Domain Controllers, that is.

Note:
Do not configure Credential Guard on Domain Controllers.

Getting Ready

For Virtualization-based Security (VBS) you’ll need to meet the following requirements:

• At least one ESXi host running VMware vSphere 6.7, or up, managed by vSphere
• At least one virtual machine running hardware version 14 (Compatible only with ESXi 6.7 and later), or up, configured with Virtualization Based Security. and installed with Windows Server 2016, or a later version of Windows Server in this virtualization state.

Note:
The Virtualization Base Security option enables CPU virtualization extensions, IOMMU, EFI firmware and Secure Boot.

Configuring Virtualization-based Security

Configuring Virtualization-based Security consists of three steps:

1. Configure the right virtual machine settings on vSphere 6.7
2. Configure the right security settings in the virtual Domain Controller
3. Install the Hyper-V feature on the virtual Domain Controller

Configure the right virtual machine settings

First, we need to create a virtual Domain Controller that meets the requirements.

ESXi 6.7

When creating a new virtual machine for a Domain Controller, on the 2 Select a name and guest OS page of the New virtual machine wizard, make sure as a Compatibility level you pick ESXi 6.7 virtual machine (or up), resulting in hardware version 14. Pick Microsoft Windows Server 2016 or later (64-bit) as the Gues OS version. Then, make sure you select the option Enable Windows Virtualization Based Security:

vSphere 6.7

In the vSphere Web Client, when creating a new virtual machine, take care of the following settings:

• On the Select compatibility page of the New Virtual Machine wizard, select ESXi 6.7 and later. The accompanying text below this settings will then indicate that This virtual machine uses hardware version 14, which provides the best performance and latest features available in ESXi 6.7.
• On the Select a guest OS page of the New Virtual Machine wizard, specify Microsoft Windows Server 2016 or later (64-bit) as the Guest OS Version and select the option Enable Windows Virtualization Based Security:

Configure the right security settings in the virtual Domain Controller

After installing Windows Server 2016, or up, on the new virtual Domain Controller and configuring it as a Domain Controller for (one of) your Active Directory domain(s), perform the following actions in the virtual machine or on any other domain-joined machine that has the Group Policy Management Console feature installed:

• Sign in with an account that has sufficient permissions in Active Directory to create Group Policy objects and link them to the Domain Controllers Organizational Unit (OU). Typically, a member of the Domain Admins group has these permissions.
• Open the Group Policy Managment console, by either:
  • Picking it from the Tools menu in Server Manager.
  • Selecting it in the Start Menu from the Windows Administrative Tools folder.
  • Clicking the Start button and typing gpmc.msc followed by a press of the Enter button on the keyboard.
  • right-clicking the Start button and typing gpmc.msc followed by a click on the OK button.
• The Group Policy Management window appears.
• In the left navigation pane, expand the forest node, then the Domains node, than your domain. Select the Domain Controllers Organizational Unit (OU).
• Right-click Domain Controllers and select the Create a GPO in this domain, and Link it here… menu option.
  The New GPO pop-up window appears.
• In the New GPO pop-up window, type a name for the Group Policy object.
• Click the OK button.
• In the left navigation pane, expand the Domain Controllers OU and select the newly created Group Policy object.
• Dismiss the Group Policy Management Console pop-up telling you that You have selected a link to a Group Policy Object (GPO). Except for changes to link properties, changes you make here are global to the GPO, and will impact all other locations where this GPO is linked. by clicking the OK button, if it pops up.
• Right-click the Group Policy object and select Edit… from the context menu.
  The Group Policy Management Editor window appears.
• In the left navigation pane of the Group Policy Management Editor window, expand the Computer Configuration node, then the Policies node, the Administrative Templates node, the System, and finally the Device Guard node.

• In the main pane, double-click the Turn on Virtualization Based Security group policy setting.
  The Turn on Virtalization Based Security window appears
• In the top part of the Group Policy setting, select the Enabled option.
• At the left Options: pane, select the following options:
  • For Virtualization Based Protection of Code Integrity:, select Enabled without lock from the drop-down list. As we are configuring Virtualization-based Security through Group Policy, we’d want Group Policy to be able to remove the settings remotely as well, if need be.
  • Enable the Require UEFI Memory Attributes Table option.
  • For Secure Launch Configuration:, select Enabled from the drop-down list.
• Click the OK button at the bottom of the Turn on Virtualization Based Security window to save the Group Policy settings and close the Turn on Virtualization Based Security window:

• Close the Group Policy Management Editor window.
• In the left navigation pane of the Group Policy Management window, right-click the Domain Controllers OU. Select Group Policy Update… from the context menu.
  The Force Group Policy update window appears.
• Click the Yes button to answer the question Are you sure you want to update policy for these computers?
  The Remote Group Policy update results window appears.
• Click the Close button to close the window.
• Close the Group Policy Management window.

Install the Hyper-V feature on the virtual Domain Controller

If you’ve managed the Group Policy settings from another machine than the virtualized Domain Controller running Windows Server 2016, or up, sign into the Domain Controller with an Active Directory account that has administrative privileges on the Domain Controller.

Run the following lines of Windows PowerShell in an elevated PowerShell window on each Domain Controller that you want enabled with Virtualization-based Security:

Install-WindowsFeature Hyper-V

Restart-Computer

Concluding

Virtualization-based Security offers benefits for virtualized Domain Controllers running Windows Server 2016, and up. It uses nested virtualization, where Microsoft Hyper-V offers the secure memory regions and vSphere offers the virtualization platform as it would do for any virtual machine.

Further reading

Virtualization-based Security (VBS)
Introducing support for Virtualization Based Security in vSphere 6.7
Overview of Device Guard in Windows Server 2016
Enabling Windows 10 Virtualization Based Security with vSphere 6.7