CVE-2023-24932. 2023 feels like so long ago, and yet, this is still an issue. Why? Because it’s quite frankly a mess to deal with and has multiple moving parts. I highly recommend reading though the following Microsoft articles in order to have a full understanding of the issues and resolutions:
- How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
- Original guidance, released 2023-05-09
- Last updated 2025-05-05
- Enterprise Deployment Guidance for CVE-2023-24932
- Updated guidance as of 2025-02-13
- Secure Boot DB and DBX variable update events
- Released 2022-06-15
My scripts, as well as an additional ReadMe are published to GitHub: https://github.com/ajf8729/BlackLotus
Also be sure to check out other posts about this topic, as the more information out there about it, the better:
- Gary Blok
- https://github.com/gwblok/garytown/tree/master/BlackLotusKB5025885
- https://garytown.com/powershell-script-kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932
- https://garytown.com/configmgr-task-sequence-kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932
My Solution – Remediation Scripts, But With a Twist
So i decided to build somewhat universal scripts that could be deployed via Intune Remediations, ConfigMgr CIs, or run ad-hoc/as a run script. This proved to be a bit of a challenge at first, as my remediation scripts were designed to exit at multiple places, sort of a “choose your own adventure” story. But this doesn’t play nice with the traditional detection/remediation method used by Intune Remediations and ConfigMgr CIs.
The answer? Put all of the code in the detection script!
This seemed both odd and “not right” to me at first, but I’ve heard of others doing it before, and it let me combine detection and remediation in once script, handling all of the edge cases and failure scenarios that I could come up with and test/validate.
Phase 1 – The Easy Part
Based of the guidance, I decided to break this work down into 2 logical phases. Phase 1 consists of steps 1 and 2 in the published guidance, which will install the updated certificate definitions to the secure boot DB, and update the boot loader on the device to one signed by the new 2023 CA. After phase 1 is complete, a device will still boot to older boot loaders, and still must go through phase 2 to completely mitigate the BlackLotus vulnerability. Phase 1 can be completed safely on devices with no direct impact.
The most up to date version of my phase 1 remediation script is published to my GitHub: https://github.com/ajf8729/BlackLotus/blob/main/BlackLotusPhase1Remediation.ps1
Remediation script configuration in Intune:
CI configuration in ConfigMgr:
Phase 2 – The “Breaking” Part
Phase 2 is where the breaking changes will occur. In phase 2, steps 3 and 4 from the published guidance are performed, which will enable the revocation of the 2011 CA, and apply a Secure Version Number (SVN) update to the firmware in order to prevent rollbacks. Once phase 2 is complete, the device will no longer boot to any media signed with the old CA.
Configure this script as a Remediation or CI in the same fashion as the above screenshots.
The most up to date version of my phase 2 remediation script is published to my GitHub: https://github.com/ajf8729/BlackLotus/blob/main/BlackLotusPhase2Remediation.ps1
Updating Bootable Media, and PXE Support (?)
Microsoft has provided a script (https://support.microsoft.com/en-us/topic/updating-windows-bootable-media-to-use-the-pca2023-signed-boot-manager-d4064779-0e4e-43ac-b2ce-24f434fcfa0f) to update bootable media to use a newer boot loader. However, as documented in the guidance, you will no longer be able to PXE boot device using ConfigMgr, as documentation will be provided later:
Lastly…
I’ll likely be updating these scripts a bit more in the near future, I’d like to expand the logging a bit further and there will likely be an issue that pops up somewhere. As my buddy Johannes says, this is an MVP (Minimum Viable Product)!
Hopefully there is a solution to the PXE problem soon. If you decide to give these scripts a whirl, please let me know if you run into issues or have any feedback. Comments here, issues on GitHub, or just ping me in the WinAdmins Discord Community (@krbtgt), all options are welcome!
I tried your remediation scripts, so far the output says it has worked out and updates went OK but how do i verify this correctly ? How do i know the cert is working ? I check the signing (digital signature) on the bootload.efi file in the system32 folder after applying the patch but that still says it is signed with the 2011 cert .
Have you tried step 2b in this article: mount the efi file and checked the file?:
https://support.microsoft.com/en-au/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Is “Phase 2 – The “Breaking” Part” really necessary or is it just to complete the mitigation?
Part 2 is necessary to completely mitigate the vulnerability, as this will revoke the 2011 CA rendering older boot loaders unusable, and apply the SVN update to prevent rollbacks/resets to make the device vulnerable again.
Hi Anthony,
Have you or anyone else encountered issues with your solution? I really love the work you put into doing this and really didn’t want to re-invent the wheel. I read up on Gary Blok’s also and while also great, is less streamlined as yours.
I’ve been using my solution in my labs since building them and haven’t run into any issues. There’s a few folks in the WinAdmins community that used it as well and provided some feedback early on when I was fixing a few issues, but I’ve not heard of any issues since. Gary’s solution is also great and I think has a lot more builtin in terms of feedback/help/etc; I built mine as sort of a “get the job done” script.