Posted inVMware

How to Enable Virtualization-Based Security (VBS) and Credential Guard on VMware vSphere

What Do Hackers Do After Gaining Local Admin Rights?

Imagine Windows Server as an office building. The Administrator account acts just like a master key. Once malware infiltrates and successfully escalates privileges to SYSTEM or Admin, virtually all standard perimeter defenses collapse.

An attacker needs only run one familiar Mimikatz command: sekurlsa::logonpasswords. Instantly, the LSASS (Local Security Authority Subsystem Service) process memory is completely dumped. Every NTLM hash and Kerberos ticket belonging to accounts that have logged into this server is laid bare. From there, hackers can effortlessly launch Pass-the-Hash attacks to pivot to a Domain Controller within minutes.

To eliminate this threat at its root, Microsoft and VMware turned to a hardware-assisted approach: isolating credential stores inside an impenetrable memory enclave. This is the underlying mechanism of Virtualization-Based Security (VBS) and Credential Guard.

Comparing 3 Methods to Protect Credentials on Virtual Machines

When managing Windows Server instances on a virtualized infrastructure, you typically have three primary options:

  • Method 1: Using traditional Antivirus or EDR. The security agent runs directly within the OS to monitor LSASS memory access. While straightforward to deploy, it is frequently bypassed by attackers using unhooking techniques or Bring Your Own Vulnerable Driver (BYOVD) exploits.
  • Method 2: Tiered administrative architecture combined with Windows LAPS. The system periodically rotates Local Administrator passwords automatically and prevents administrators from casually using Domain Admin credentials on workstations or application servers. While this limits blast radius if a machine is compromised, it does not stop in-memory dumping on the compromised host itself.
  • Method 3: Hardware isolation via VBS and Credential Guard on vSphere. The hypervisor segregates the virtual machine into two distinct worlds: Normal World (where standard Windows operates) and Secure World (Virtual Secure Mode – VSM). The sensitive authentication process LsaIso.exe is offloaded to run inside Secure World. Even if an attacker obtains full SYSTEM privileges in Windows, the CPU hardware blocks any attempt to tamper with this VSM enclave.

Detailed Pros and Cons Analysis

The comparison table below helps you weigh security posture against operational overhead:

Criteria Antivirus / EDR LAPS & Tiered Access VBS + Credential Guard
LSASS Dump Mitigation Moderate. EDR can be circumvented via zero-day exploits or kernel-level tampering using validly signed vulnerable drivers. Indirect. Restricts lateral movement scope across the network but does not prevent direct RAM dumping on the compromised host. Near absolute. Hypervisor-level memory partitioning shields memory from any process running in the Normal World.
Deployment Complexity Low. Requires only agent installation and policy rollout from a centralized management console. Moderate. Demands restructuring Active Directory tiering models and altering IT administrative workflows. Relatively High. Requires specific CPU hardware features, vCenter Key Provider configuration, VM settings modifications, and Group Policy deployment.
Resource Overhead Consumes 2% – 5% CPU and 300MB – 800MB RAM for background scanning processes. Negligible, incurring only minor overhead during periodic password sync back to AD. Adds approximately 1% – 3% CPU overhead due to nested virtualization / nested paging (SLAT) processing costs.

Deployment Strategy: Defense-in-Depth

Across the 8-host ESXi infrastructure I manage, no single tool offers a 100% guarantee. Relying solely on EDR leaves the environment vulnerable to kernel-level zero-days.

The most resilient defense strategy is multi-layered: implement LAPS to contain lateral movement, maintain EDR for early threat detection and anomaly alerting, and enable VBS with Credential Guard as the final, unyielding bastion. Even if attackers gain full administrator control over a VM, they remain completely locked out of the VSM enclave.

Hardware and Software Prerequisites on vSphere

Before configuring, ensure your VMware infrastructure meets the following requirements:

  • ESXi and vCenter: Version 6.7 minimum, though vSphere 7.0 Update 2 or later (or vSphere 8.0) is highly recommended to leverage Native Key Provider.
  • Physical Server CPU: Support for virtualization technologies like Intel VT-x + EPT or AMD-V + RVI, with IOMMU (Intel VT-d or AMD-Vi) enabled in the host BIOS.
  • Virtual Machine (VM) Specs: Minimum Virtual Hardware Version 14, EFI firmware, and Secure Boot enabled.
  • Guest OS: Windows Server 2016 or higher (optimized for Windows Server 2022 and 2025).
  • Key Provider: vCenter must have a Native Key Provider configured or connect to an external KMS if you plan to add a vTPM device to the VM.

Step-by-Step 4-Stage Deployment Workflow

Step 1: Set Up vSphere Native Key Provider on vCenter

If you are running vSphere 7.0 U2 or newer, you do not need to invest in an expensive third-party KMS solution:

  1. Access the vSphere Client, select your vCenter Server in the left inventory > click the Configure tab.
  2. Navigate to the Security section > select Key Providers > click Add > select Add Native Key Provider.
  3. Assign a name to the provider (for example: NKP-Cluster-Prod). Uncheck Use key provider only for TPM hosts if your physical cluster hosts do not have discrete TPM 2.0 chips installed.
  4. Click Add Key Provider. Immediately afterward, you must click Back up to download the .p12 certificate file. The Key Provider will only transition to an Active state once this backup step is completed.

Step 2: Enable VBS and Add a vTPM to the Virtual Machine

Power off the Windows Server virtual machine before modifying virtual hardware parameters:

  1. Right-click the VM > select Edit Settings.
  2. Switch to the VM Options tab > expand Boot Options: Set Firmware to EFI and check the Secure Boot box.
  3. Still under the VM Options tab, scroll down to Virtualization Based Security: Check Turn On Virtualization Based Security. vSphere will automatically configure the supporting hardware virtualization flags.
  4. Switch to the Virtual Hardware tab, click Add New Device > select Trusted Platform Module (vTPM). This device allows Windows to securely manage cryptographic keys and certificates.
  5. Click OK and power on the VM.

If you need to batch-apply this across 20–30 VMs in a cluster, you can run the following PowerCLI script instead of manual configuration:

# Connect to vCenter Server
Connect-VIServer -Server vcenter.company.local

$VMName = "SRV-FILE-01"
$vm = Get-VM -Name $VMName

# Ensure the VM is powered off before updating VBS
if ($vm.PowerState -eq "PoweredOff") {
    $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
    $spec.Flags = New-Object VMware.Vim.VirtualMachineFlagInfo
    $spec.Flags.VbsEnabled = $true
    
    $vm.ExtensionData.ReconfigVM($spec)
    Write-Host "[OK] Successfully enabled VBS on $VMName" -ForegroundColor Green
} else {
    Write-Warning "[!] Please power off $VMName before changing configuration!"
}

Step 3: Enable Credential Guard via Local Group Policy

After the VM boots into Windows Server, configure the OS to activate Credential Guard:

  1. Press Windows + R, type gpedit.msc, and hit Enter (or edit the GPO from your Domain Controller to apply across your server OU).
  2. Navigate to the following path:

    Computer Configuration > Administrative Templates > System > Device Guard.
  3. Double-click the Turn On Virtualization Based Security policy and set it to Enabled.
  4. Under the Options pane below, configure the following settings:
    • Select Platform Security Level: Choose Secure Boot and DMA Protection (or Secure Boot on older hardware).
    • Credential Guard Configuration: Select Enabled with UEFI lock to prevent attackers from disabling it via the registry without physical reboot access.
    • Secure Launch Configuration: Select Enabled (if the CPU supports DRTM boot protection).
  5. Click OK. Open Command Prompt as Administrator, run the policy update command, and reboot the system:
gpupdate /force
shutdown /r /t 0

Step 4: Verify and Confirm the Configuration

Once the server completes rebooting, open PowerShell as Administrator and run:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | 
Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

A properly configured system returns the following values:

  • VirtualizationBasedSecurityStatus = 2: VBS is enabled and running normally.
  • SecurityServicesRunning: Displays value 1, confirming Credential Guard is actively safeguarding LSASS.

For graphical confirmation, open the Run dialog, enter msinfo32. In the System Summary pane, scroll to the bottom to verify that Virtualization-based security shows Running and Device Guard Security Services Running displays Credential Guard.

Field Notes and Production Best Practices

Based on hands-on infrastructure administration, here are 3 critical caveats to keep in mind:

  • vMotion Migrations: Virtual machines equipped with vTPM migrate seamlessly across ESXi hosts via vMotion. However, every host in the cluster must connect to the same Key Provider. If a host lacks the encryption key, compatibility checks will immediately halt migration.
  • Database Application Latency: For compute- and memory-heavy workloads like Microsoft SQL Server or Oracle DB, nested virtualization overhead can introduce a 1% – 2% memory latency penalty. Always benchmark database performance in a staging environment before rolling out to mission-critical production databases.
  • Backup Solution Compatibility: Modern enterprise backup tools such as Veeam Backup & Replication v11+ or Commvault support vTPM-enabled VMs. However, make sure that encryption metadata backup options are enabled so VM restore operations proceed smoothly.
Share:
Tags: