Slightly clear the fog around BlackLotus mitigations

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 after the update is applied. Files to update the bootloader of the operating system, PXE or media bootloaders can be found in %Systemroot%\Boot\*_EX after the cumulative update has been applied.

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.

Steps to activate the mitigations on a running OS

Activating the mitigations after installing the cumulative update involves three 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.

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 mounts the EFI partition (similar to Mountvol x: /s), copies the new certificate, and initiates the database update upon rebooting.

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 folders to the boot partition.

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

The final step 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.

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?

Considering that Secure Boot only protects the boot process but not the OS loader, 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. They are located in \RemoteInstall\Boot\x64.

So, Windows PE (specifically the Windows PE WIM) does not need to be updated, because the necessary boot files are provided by the WDS server. However, to update the WDS server you need to get the “new” PXE boot files, signed with the Windows UEFI CA 2023 certificate, and those are part of the cumulative update. Some files are only extracted if you update a WinPE WIM file. For example, you won’t find the C:\Windows\Boot\PXE_EX folder if you apply the cumulative update to running Windows 11.

Follow these steps to update the WDS/PXE server

  • On a Windows download and install the latest ADK and the Windows PE addon
  • 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 following commands in an administrative CMD (replace <cumulativeUpdate>.msu with the file name of the CU):
  • After that, copy the 2 files from the C:\NewPXEFiles folder to your WDS server to C:\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 does only serve clients trusting the new Windows UEFI CA 2023 certificate. PCs, which have not been updated, will no longer boot from this PXE server.

Offline images

Offline images are operating systems imported into SCCM or MDT. I will focus on MDT in this blog, but the process is similar for SCCM. Typically, these images are packed into WIM files and applied to the PC’s hard drive from WinPE. The BCDBoot.exe utility creates the BCD and copies boot files from the applied OS to the EFI boot partition.

BCDBoot is started from Windows PE and copies the boot files from %OSDrive%\Windows\Boot and other folders. Those boot files are signed with the old certificate and will cause a security error while starting on a PC not trusting the new Windows UEFI CA 2023 certificate. In 2024.7B (means the July 2024 cumulative update), BCDBoot has been extended. It now checks, if the client’s UEFI trusts the new Windows UEFI CA 2023 certificate. Depending on the trust status, it copies the appropriate boot files to the EFI boot partition. This only works if BCDBoot.exe from the offline image is used and if the offline image has at least the July 2024 cumulative update integrated. Windows PE has its own BCDBoot.exe, which is not capable of checking the UEFI. This one always applies the “old” boot files.

At the end this means, that your offline image needs to be updated with the July 2024 CU or later. There are two ways to consider. You can take following approach to deploy your offline image to PCs with the revocations applied, without patching the Install.WIM file before:

  • 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 apply the new files to the boot partition using %OSDisk%\Windows\System32\BCDBoot.exe %OSDisk%\Windows /bootex /offline

Alternatively, update the install.WIM of your offline image with the 2024 July cumulative update. 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.

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.

Files copied during CU application

When a cumulative update is applied, the following files, relevant to BlackLotus mitigations, are copied to the hard disk and need to be moved to their correct locations manually by applying the mitigation steps:

Files used for Firmware update

  • C:\Windows\System32\SecureBootUpdates\dbupdate.bin
  • C:\Windows\System32\SecureBootUpdates\dbupdate2024.bin
  • C:\Windows\System32\SecureBootUpdates\dbxupdate.bin
  • C:\Windows\System32\SecureBootUpdates\DBXUpdate2024.bin
  • C:\Windows\System32\SecureBootUpdates\DBXUpdateKB.bin
  • C:\Windows\System32\SecureBootUpdates\SKUSiPolicy.P7b

Files used for OS update

  • C:\Windows\Boot\DVD_EX\EFI\en-US\efisys_EX.bin
  • C:\Windows\Boot\DVD_EX\EFI\en-US\efisys_noprompt_EX.bin
  • C:\Windows\Boot\Fonts_EX\chs_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\cht_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\jpn_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\kor_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\malgunn_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\malgun_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\meiryon_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\meiryo_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\msjhn_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\msjh_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\msyhn_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\msyh_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\segmono_boot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\segoen_slboot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\segoe_slboot_EX.ttf
  • C:\Windows\Boot\Fonts_EX\wgl4_boot_EX.ttf
  • C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi
  • C:\Windows\Boot\EFI_EX\bootmgr_EX.efi
  • C:\Windows\Boot\EFI_EX\de-DE\bootmgfw_EX.efi.mui
  • C:\Windows\Boot\EFI_EX\de-DE\bootmgr_EX.efi.mui
  • C:\Windows\Boot\EFI_EX\en-US\bootmgfw_EX.efi.mui
  • C:\Windows\Boot\EFI_EX\en-US\bootmgr_EX.efi.mui
  • …continued for more languages

Additional files when updating Windows PE

  • C:\Windows\Boot\PXE_EX\wdsmgfw_EX.efi
  • C:\Windows\Boot\PXE_EX\de-DE\wdsmgfw_EX.efi.mui
  • C:\Windows\Boot\PXE_EX\de-DE\wdsmgfw_EX.efi.mui
  • …continued for more languages





Leave a Reply