Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates

Important note about the SkuSiPolicy.p7b policy

For instructions to apply the updated policy, see the Deploying a Microsoft-signed revocation policy (SkuSiPolicy.p7b) section. 

In this article

• Summary

• Scope of Impact

• Available mitigations

• Understanding mitigation risks

• Mitigation deployment guidelines

  • Deploying an audit mode policy

  • Deploying a Microsoft-signed revocation policy (SkuSiPolicy.p7b)

  • Updating external boot media

• Windows Event logs

  • Policy activation events

  • Audit and block events

• Policy removal and recovery procedure

• ​​​​​​​Changes made to this article​​​​​​​​​​​​​​

Summary

Microsoft was made aware of a vulnerability in Windows that allows an attacker with administrator privileges to replace updated Windows system files that have older versions, opening the door for an attacker to reintroduce vulnerabilities to Virtualization-based security (VBS).  Rollback of these binaries might allow an attacker to circumvent VBS security features and exfiltrate data that is protected by VBS. This issue is described in CVE-2024-21302 | Windows Secure Kernel Mode Elevation of Privilege Vulnerability.

To resolve this issue, we will revoke vulnerable VBS system files that are not updated. Because of the large number of VBS-related files that must be blocked, we use an alternative approach to block file versions that are not updated.

Scope of Impact

All Windows devices that support VBS are affected by this issue. This includes on-premises physical devices and virtual machines (VMs). VBS is supported on Windows 10 and later Windows versions, and Windows Server 2016 and later Windows Server versions.

The VBS state can be checked through the Microsoft System Information tool (Msinfo32.exe). This tool collects information about your device. After starting Msinfo32.exe, scroll down to the Virtualization-based security row. If the value of this row is Running, VBS is enabled and running.

The VBS state can also be checked with Windows PowerShell by using the Win32_DeviceGuard WMI class. To query the VBS state from PowerShell, open an elevated Windows PowerShell session and then run the following command:

After running the above PowerShell command, the VBS state status should be one of the following.

Available mitigations

For all supported versions of Windows 10, version 1507 and later Windows versions, and Windows Server 2016 and later Windows Server versions, administrators can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b). This will block vulnerable versions of VBS system files that are not updated from being loaded by the operating system.  

When the SkuSiPolicy.p7b is applied to a Windows device, the policy will also be locked to the device by adding a variable to the UEFI firmware. During startup, the policy loads and Windows blocks the loading of binaries that violate the policy. If the UEFI lock is applied and the policy is removed or replaced with an older version, the Windows boot manager will not start, and the device will not start. This boot failure will not show an error and the system will proceed to the next available boot option which might result in a boot loop.

An additional Microsoft-signed CI policy which is enabled by default and requires no additional deployment steps has been added which is not bound to UEFI. This signed CI policy will be loaded during boot and the enforcement of this policy will prevent rollback of VBS system files during that boot session. Unlike the SkuSiPolicy.p7b, a device can continue to boot if the default enabled policy has been tampered or removed. This mitigation is available on devices with Windows 10 22H2 and later. The SkuSkiPolicy.p7b can still be applied by administrators to provide additional protection for rollback across boot sessions.  

Windows Measured Boot logs used to attest the boot health of the PC include information about the policy version being loaded during the boot process. These logs are securely maintained by the TPM during boot, and the Microsoft attestation services parse these logs to verify that the correct policy versions are being loaded. The attestation services enforce rules that ensure a specific policy version or higher is loaded; otherwise, the system will not be attested as healthy.

For the policy mitigation to work, the policy must be updated using the Windows servicing update since the components of Windows and the policy must be from the same release. If the policy mitigation is copied to the device, the device might not start if the wrong version of the mitigation is applied, or the mitigation may not work as expected. Additionally, mitigations described in KB5025885 should be applied to your device.

On Windows 11 Secured-core PCs, Dynamic Root of Trust for Measurement (DRTM) adds an additional mitigation for the rollback vulnerability. This mitigation is enabled by default for systems running Windows 11, version 24H2. On these systems, the VBS-protected encryption keys are bound to the default-enabled boot session VBS CI policy and will only unseal if the matching CI policy version is being enforced. To enable user-initiated rollbacks, a grace period has been added to enable safe rollback of 1 version of Windows update package without losing the ability to unseal the VSM master key. However, the user-initiated rollback is only possible if the SkuSiPolicy.p7b is not applied. The  VBS CI policy enforces that all boot binaries have not been rolled back to revoked versions. This means that if an attacker with administrator privileges rolls back vulnerable boot binaries, the system will not start. If the CI policy and binaries are both rolled back to an earlier version, the VSM-protected data will not be unsealed.

Understanding mitigation risks

You need to be aware of potential risks before applying the Microsoft-signed revocation policy. Please review these risks and make any necessary updates to recovery media before applying the mitigation.

Note These risks are only applicable to the SkuSiPolicy.p7b policy and not applicable to default enabled protections.

• User Mode Code Integrity (UMCI). The Microsoft-signed revocation policy enables user mode code integrity so that rules in the policy are applied to user mode binaries. UMCI also enables Dynamic Code Security by default. Enforcing these features may introduce compatibility issues with applications and scripts and may prevent them from running and have a performance impact on start up time. Before deploying the mitigation, follow the instructions to deploy audit mode policy to test for potential issues.

• UEFI Lock and Uninstalling updates. After applying the UEFI lock with the Microsoft-signed revocation policy on a device, the device cannot be reverted (by uninstalling Windows updates, by using a restore point, or by other means) if you continue to apply Secure Boot. Even reformatting the disk will not remove the UEFI lock of the mitigation if it has already been applied. This means that if you attempt to revert the Windows OS to an earlier state that does not have the applied mitigation, the device will not start, no error message will be displayed, and UEFI will proceed to the next available boot option. This might result in a boot loop. You must disable Secure Boot to remove the UEFI lock. Please be aware of all possible implications and test thoroughly before you apply the revocations that are outlined in this article to your device.

• External Boot Media. After the UEFI lock mitigations have been applied to a device, external boot media must be updated with the latest Windows update installed on the device. If external boot media is not updated to the same Windows update version, the device might not boot from that media. See the instructions in the Updating external boot media section before applying the mitigations.

• Windows Recovery Environment. The Windows Recovery Environment (WinRE) on the device must be updated with the latest Windows updates installed on the device before the SkuSipolicy.p7b is applied to the device. Omitting this step might prevent WinRE from running the Reset PC feature.  For more information, see Add an update package to Windows RE.

• Pre-boot Execution Environment (PXE) boot. If the mitigation is deployed to a device and you attempt to use PXE boot, the device will not start unless the latest Windows update is also applied to the PXE server boot image. We do not recommend deploying mitigations to network boot sources unless the PXE Boot server has been updated to the latest Windows update released on or after January 2025, including the PXE boot manager.  

Mitigation deployment guidelines

To address the issues described in this article, you can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b). This mitigation is only supported on Windows 10, version 1507 and later Windows versions, and Windows Server 2016. Before you deploy the Microsoft-signed revocation policy (SkuSiPolicy.p7b), you should test for compatibility issues by using an audit mode policy.

Note If you use BitLocker, make sure that your BitLocker recovery key has been backed up. You can run the following command from an Administrator command prompt and take note of the 48-digit numerical password:

Windows Event logs

Windows logs events when code integrity policies, including SkuSiPolicy.p7b, are loaded and when a file is blocked from loading because of policy enforcement. You can use these events to verify that the mitigation has been applied.

Code integrity logs are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational > Application and Services logs > Services logs > Microsoft > Windows > AppLocker > MSI and Script.

For more information on code integrity events, see the Windows Defender Application Control operational guide.

Policy Removal and Recovery Procedure

If something goes wrong after applying the mitigation, you can use the following steps to remove the mitigation:

1. Suspend BitLocker if it is enabled. Run the following command from an elevated Command Prompt window:

   Manager-bde -protectors -disable c: -rebootcount 3

2. Turn off Secure Boot from the UEFI BIOS menu.
   
   The procedure for turning off Secure Boot differs between device manufacturers and models. For help locating where to turn off Secure Boot, consult with documentation from your device manufacturer. More details can be found in Disabling Secure Boot.

3. Remove the SkuSiPolicy.p7b policy.

   1. Start Windows normally and then sign in.
      
      The SkuSiPolicy.p7b policy must be removed from the following location:

      • ​​​​​​​<EFI System Partition>\Microsoft\Boot\SkuSiPolicy.p7b​​​​​​​

   2. Run the following commands from an elevated Windows PowerShell session to clean up policy from those locations:

      $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b"
      $MountPoint = 's:'
      
      $EFIPolicyPath = "$MountPoint\EFI\Microsoft\Boot\SkuSiPolicy.p7b"
      $EFIDestinationFolder="$MountPoint\EFI\Microsoft\Boot"
      mountvol $MountPoint /S
      if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
      
      if (Test-Path   $EFIPolicyPath ) {Remove-Item -Path $EFIPolicyPath -Force }
      
      ​​​​​​​mountvol $MountPoint /D

4. Turn on Secure Boot from BIOS.
   
   Consult with the documentation from your device manufacturer for locating where to turn on Secure Boot.
   
   If you turned off Secure Boot in Step 1 and your drive is protected by BitLocker, suspend BitLocker protection and then turn on Secure Boot from your UEFI BIOS menu.

5. Turn on BitLocker. Run the following command from an elevated Command Prompt window:

   Manager-bde -protectors -enable c:

6. Restart your device.