Hi, I’m Helmut Wagensonner, a Cloud Solution Architect at Microsoft. Despite the detailed information we’ve previously provided about mitigating the UEFI BlackLotus bootkit, it appears there is still considerable confusion surrounding the entire process. What specifically needs to be addressed, and why are manual steps required to activate the mitigations?
Understanding BlackLotus and its mitigations
BlackLotus is bootkit, which manages to inject itself into the boot process, even if Secure Boot is enabled on your system. BlackLotus modifies the UEFI firmware, embedding its own code into the boot process. This ensures that it is loaded before the operating system, giving it control at the lowest level. By infecting the UEFI, BlackLotus achieves persistence, as it survives OS reinstalls and hard drive replacements. The BlackLotus bootkit executes during the early boot phase, before the OS is fully loaded. It hooks into the bootloader, which is responsible for loading the operating system. During the boot process, the bootkit injects malicious code into the OS kernel, allowing it to run with high privileges.
Therefore, the BlackLotus mitigations require updates not only to your operating system but also to your PC firmware. Essential files to update the firmware are included in the monthly cumulative updates, starting with the April 2024 CU (2024.4B). These files are located in %Systemroot%\System32\SecureBootUpdate%Systemroot%\Boot\*_EX
Why manual activation is necessary
Upon applying the cumulative Windows update, the new files are only copied to the hard drive, meaning the mitigations are not yet active and the system remains vulnerable. This design allows large enterprises to manage a mix of patched and unpatched devices for a period, providing flexibility during the update process. Therefore, the activation steps must currently be performed manually. An enforcement date, when cumulative updates will automatically activate these mitigations, has yet to be determined.
Please be aware, that this update only addresses Microsoft bootloaders. 3rd party bootloaders signed by Microsoft use a different certificate (UEFI CA 2011). This includes, for example, dual boot systems or 3rd party disk encryption software. Those boot loaders will get updated at a later date. At them moment of writing this is planned for late 2024 / early 2025.
Steps to activate the mitigations on a running OS
Please note: In some cases devices may go into Bitlocker Recovery mode. Please make sure to have your Bitlocker Recovery Key ready, before you apply the mitigation steps.
Activating the mitigations after installing the cumulative update involves four main steps. I will not get too technical here because detailed instructions can be found in the “Mitigation deployment guidelines” section of this article. Summarized, activating the mitigations does:
- Tell the PC (UEFI) to trust a new certificate
- Replace the OS bootloader with a new one, signed with the new certificate
- Prevent the PC (UEFI) from trusting the old certificate.
- Update the Secure Version Number (SVN) in the UEFI firmware, so that older boot managers cannot start.
Each step typically involves setting a Registry value followed by one or two reboots.
1. Update the UEFI “Allowed Signature Database” (DB)
The first step updates the UEFI, causing Secure Boot to trust the new bootloaders signed with a new certificate. Setting the Registry key for this step appends the new certificate to Secure Boot Allowed Signature Database (DB) which indicates firmware to trust new boot manager on subsequent boots.
At this stage, the PC can boot both old and new bootloaders (those signed with the old and new certificates). However, since the PC can still boot old bootloaders, it remains vulnerable.
2. Update the Operating System
Next, the bootloader of the running operating system is replaced with a new one signed with the new certificate. By setting the Registry key for step 2, the system copies the new boot files from the C:\Windows\Boot\*_EX
Since step 1 enables the PC to boot both old and new bootloaders, the OS will still start after this change.
3. Update the UEFI to revoke bootloaders signed with the old certificate
Step three is to update the UEFI’s forbidden signature database (DBX) to prevent the PC from trusting old bootloaders. This update makes the PC only boot operating systems updated in step 2, ensuring the system is protected and mitigations are in place.
Please note: From this point on, media with bootloaders signed with the old certificate will no longer boot on this PC. More technical information about the UEFI updates can be found here.
4. Update the Secure Version Number in UEFI
Each time a new bootloader is released, it checks its Secure Version Number (SVN) against the SVN stored in the firmware. If the bootloader’s SVN is lower than the one in the firmware, it will refuse to boot. This step is optional. As long as the SVN in the UEFI is absent or lower than the boot manager’s SVN, the system will boot. However, to enhance security, it’s recommended to update the SVN in the UEFI to prevent older boot managers from booting the operating system.
Please note: Only apply the SVN update to the UEFI after ensuring that all bootable media (such as PXE, ISO, and USB drives) have been updated.
PXE, Windows PE and offline OS images
PXE and Windows PE
In an enterprise, a typical deployment involves PXE booting, starting a Windows Pre-install Environment (WinPE), downloading a Windows offline image, and applying it to the hard drive. Does every component (PXE, WinPE, offline OS) have to be updated to boot on a PC, which has the UEFI revocations applied.
Secure Boot Firmware validates the all-boot loader components against the revocations installed in Secure Boot UEFI’s forbidden Signature Database(DBX). So, it’s important that all files running before the handover to the OS loader (winload.efi) are signed with the new certificate. For PXE boot this includes the Network Boot Program (wdsmgfw.efi) and the Boot Manager (bootmgfw.efi). Both files are provided from the WDS server, located in \RemoteInstall\Boot\x64
Hence, Windows PE (specifically the Windows PE WIM) does not need to be updated and can boot on both, updated and not updated PCs, depending on which boot files the PXE server provides. The PXE server on the other hand can only provide one set of boot files: Either those signed with the old certificate or those, signed with the new Windows UEFI CA 2023 certificate.
Please note: After updating the boot files in on the PXE server, PC’s trusting the “old” UEFI certificate will no longer boot.
Follow these steps to update the WDS/PXE server to provide WinPE boot files signed with the Windows UEFI CA 2023 certificate:
- On a Windows 11 PC, download and install the latest ADK and the matching Windows PE addon from the ADK download site.
- From the Windows Update catalog download the latest cumulative update for your PE version (make sure it’s the July 2024 CU or later)
- Assuming you installed the ADK in its default location and downloaded the CU to C:\temp, run the commands below in an administrative CMD (replace <cumulativeUpdate>.msu with the file name of the CU):
- After that, copy the 2 files from the
C:\NewPXEFilesfolder to your WDS server toC:\RemoteInstall\Boot\x64.
MD C:\Mount MD C:\NewPXEFiles Dism /Mount-Image /ImageFile:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us\winpe.wim" /Index:1 /MountDir:C:\Mount Dism /Image:C:\Mount /Add-Package /PackagePath:"C:\Temp\<cumulativeUpdate>.msu" Copy C:\Mount\Windows\Boot\PXE_EX\wdsmgfw_ex.efi C:\NewPXEFiles\wdsmgfw.efi Copy C:\Mount\Windows\Boot\EFI_EX\bootmgfw_ex.efi C:\NewPXEFiles\bootmgfw.efi Dism /Unmount-Image /MountDir:C:\Mount /Discard
Now your PXE/WDS server only serves clients trusting the new Windows UEFI CA 2023 certificate. PCs, which have not been updated, will no longer boot from this PXE server.
Offline OS images
Offline images are operating systems imported into SCCM or MDT. Typically, these images are packed into WIM files and are applied to the PC’s hard drive from WinPE using DISM.exe. After that, the BCDBoot.exe utility creates the BCD and copies boot files from the applied OS to the EFI boot partition, to make the system bootable.
Older versions of BCDBoot.exe (i. e. the one coming with Windows PE) cannot differentiate between updated and non-updated UEFI Secure Boot database. They always use files signed with the “old” certifacte to populate the boot partition. The July 2024 cumulative update brings a new BCDBoot version, which is capable of checking the PC’s firmware, if the UEFI trusts the old or the new cert. Depending on the trust status, it copies the appropriate boot files to the EFI boot partition.
By the way: If you ever wondered about the \Windows\Boot\*_EX folders after applying a CU – these are exactly the folders with the new boot files.
Both, MDT and Config Manager use BCDBoot from Windows PE to copy the boot files. This will always result in an installation trusting the “old” certificate, even if your Install.WIM has been updated with the latest CU. To solve this problem, you need to re-populate the boot partition using the new version of BCDBoot from an OS image, which has the July 2023 CU applied. This ensures the appropriate boot files are copied to the boot partition. It automatically overwrites existing files so there’s no need to re-initialize the boot partition before.
At the end this means, that your offline image needs to be updated with the July 2024 CU or later, to make use of the new BCDBoot version. There are two ways to consider.
You can take following approach to deploy an offline image to PCs with the revocations applied, without using an already patched Install.WIM:
- In an OS deployment task sequence apply the operating system (i. e. Windows 11 23H2)
- Offline apply the latest cumulative update for your OS (at least the July 2024 update)
- In a Run Commandline task start BCDBoot.exe from the applied operating system. Here is an example:
%OSDisk%\Windows\System32\BCDBoot.exe %OSDisk%\Windows - This will apply the “new” boot files, if your PC trusts the Windows UEFI CA 2023 certificate. Otherwise it will apply the “old” boot files
- Restart Computer
Hint: You can force BCDBoot.exe to always apply the new files to the boot partition using %OSDisk%\Windows\System32\BCDBoot.exe %OSDisk%\Windows /bootex /offline
Alternatively, integrate the 2024 July cumulative update into your Windows image file (i. e. Install.WIM). In this case you can skip the 2nd step of the above. If you prefer this method, download the latest cumulative update from the Microsoft Update Catalog. Assuming your offline image is located in C:\DeploymentShare\Operating Systems\Windows 11, your desired edition is “Enterprise Edition” and the update has been downloaded to C:\Temp, you can use following commands in an administrative command prompt:
MD C:\Mount Dism /Mount-Image /ImageFile:"C:\DeploymentShare\Operating Systems\Windows 11\Sources\Install.WIM" /Index:3 /MountDir:C:\Mount Dism /Image:C:\Mount /Add-Package /PackagePath:"C:\Temp\<cumulativeUpdate>.msu" Dism /Unmount-Image /MountDir:C:\Mount /Commit
If you want to update another edition within the WIM file (i. e. Professional Edition) you may have to change the value of the /Index option.
Windows PE boot ISO/USB images (ConfigMgr, MDT)
Booting from ISO files (DVD) or USB boot media follows the same principle as the PXE boot. The Win PE image itself (boot.wim) does not necessarily need to be patched but it’s recommended to do this. However, the boot managers need to be updated and, as far as ISO/DVD is concerned, also the El-Torito boot file. There are a couple of pre-requisites to be met and it requires a lot of manual steps, so that I summarized everything in a Powershell script, which can be downloaded at the end of this article.
To execute this script, follow this steps:
- Create a standard Task Sequence media (ConfigMgr) or boot media (MDT). This can be either an ISO or a WIM file.
- Download the script (at the end of this article)
- Copy everything to a client, which has at least Win 11 22H2 with patch level September 2024 installed.
- Install the latest ADK (download from the ADK download site)
- Install the Windows PE addon (download also from the ADK download site)
- Open a Terminal session in administrative mode.
- Run the script with below syntax.
The syntax of the script is as follows:
Update-CMBootimage.ps1 -ImageFile <Path to original ISO or WIM> -TargetType <ISO|USB> [-USBDrive <USB drive letter>] [-Partitions <1|2>] [-Outputdirectory <Path to output directory] [-ForceAdmin]
The USBDrive and the Partitions parameter are only valid if TargetType is set to USB. The OutputDirectory is only considered when TargetType is ISO. If omitted, the output directory is set to the executing user’s desktop folder. The ForceAdmin switch restarts the script in Admin mode, when started from a non-elevated Powershell.
Examples:
Update-CMBootImage.ps1 -ImageFile .\Install.ISO -TargetType ISO -OutputDirectory C:\Users\myself\Desktop -ForceAdmin
This creates an updated ISO file in C:\Users\myself\Desktop using the Window PE boot.wim from Install.ISO. If the Powershell session does not run elevated, it restarts the script in administrative mode.
Update-CMBootImage.ps1 -ImageFile C:\Temp\WinPE.wim -TargetType USB -USBDrive E: -Partitions 2
This creates an USB boot media (must be inserted) on drive E: using WinPE.WIM as OS. The USB drive will have 2 partitions. A boot partition (FAT32, 2GB) and an image partition (NTFS, remaining space).
Enforcement timeline
Currently, there is no defined enforcement date. The manual activation steps outlined above will remain necessary until mitigation enforcement is implemented. This will likely apply to new media and future Windows versions, including ISO images with cumulative updates or new Windows PE versions, until enforcement date is reached. The timeline can be found in the chapter “Timing of Updates” in this article.
Procedure for large Enterprises
When managing large enterprises, there may be a period where a mixed mode is necessary. This situation can create challenges, especially when using the PXE (Preboot Execution Environment) scenario. The PXE server can only provide one set of boot files at a time, meaning it cannot differentiate between patched and unpatched UEFIs. Administrators must choose whether to PXE-boot PCs that trust either the 2011 certificate or the new 2023 certificate.
To address this, administrators can choose to not to apply the revocations of the Microsoft Windows Production PCA 2011 certificate (Step 3 in the Mitigation Deployment Guidelines), until all PCs are updated to trust the Windows UEFI CA 2023 certificate. The following table provides an overview of the boot compatibility based on the boot files the PXE server provides. The “Steps” mentioned in the PC State column refer to the three mitigation steps in the Mitigation Deployment Guidelines. “PXE updated” means the PXE server provides boot files signed with the new 2023 certificate.
| PC State | PXE not updated | PXE updated |
|---|---|---|
| PC is not patched and still trusts the old Microsoft Windows Production PCA 2011 certificate | ✓ | ✗ |
| PC is patched (Step 1) and trusts the new Windows UEFI CA 2023 certificate | ✓ | ✓ |
| PC is patched (Step 1) and revocations for the old certificate have been applied (Step 3) | ✗ | ✓ |
Please Note: Your system remains vulnerable unless you apply Step 3 of the Mitigation Deployment Guidelines.
Here’s a step-by-step migration plan to guide you through the process. Use this as a foundation for more detailed planning:
- Install Updates: Ensure that all PCs have the July 2024 (or later) cumulative update installed.
- Deploy Mitigation Scripts:
- Step 1: Apply Step 1 of the Mitigation Deployment Guidelines by deploying the custom script to all PCs.
- Step 2: Apply Step 2 of the Mitigation Deployment Guidelines by deploying another custom script to all PCs.
- Update Environment:
- Update your environment to support the new Windows UEFI CA 2023 certificate. This includes updating your PXE server, your OS deployment using the updated BCDBoot, and other related components.
- Complete Mitigation:
- Once your entire environment is set to use the new Windows UEFI CA 2023 certificate, apply Step 3 of the Mitigation Deployment Guidelines by deploying the final custom script to all PCs.
I disabled the comment function on my posts because of massive spam. But I’m on LinkedIn from time to time…
Leave a Reply
You must be logged in to post a comment.