TPM 2.0 Devices and remediation of CVE-2023-24932 (Black Lotus) UEFI / Secure Boot Vulnerability. - Help for those with "Known Issues"

NetMan304 · Mar 25, 2025

Hello,
I have not been able to find assistance on this but if someone has found something please kindly link me a discussion that may already by started.

I won't beat this Black Lotus horse any more than it already has been... I find myself frustrated at the guidance in microsoft's official documentation on how to apply the mitigations ahead of the forced rollout:
How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932

Under the known issues section, I have a Dell Computer with a TPM 2.0.

Code:

TPM 2.0-based systems:  These systems that run Windows Server 2012 and Windows Server 2012 R2 
cannot deploy the mitigations released in the July 9, 2024 security update because of known compatibility issues with TPM measurements. 
The July 9, 2024 security updates will block mitigations #2 (boot manager) and #3 (DBX update) on affected systems.

Microsoft is aware of the issue and an update will be released in the future to unblock TPM 2.0-based systems.

To check your TPM version, right-click Start, click Run, and then type tpm.msc. 
On the bottom-right of the center pane under TPM Manufacturer Information, 
you should see a value for Specification Version.

I would like to get some guidance or a guide on how to rekey my machine and have the bad boot loaders revoked and not wait on a fix. is there any guidance on how to do so?

PS: I understand this is vague without any specifics. I will post them if this is the venue but for now I was more or less looking for a discussion on if this is possible, clarification on what the timing issues are with the TPM 2.0 systems and clarification on if this would be an appropriate venue for tackling this sort of task.

I have never been able to find this sort of guidance anywhere and as I am not a IT pro myself, or a complete security novice. I have a desire to tackle this sort of thing with a guide or how to.

Thanks! I look forward to any suggestions etc.

glasskuter · Mar 25, 2025

First let me say, I have secure boot disabled as I want no part of the revocation. I did find this flagged in my bookmarks but it is from 2023 but maybe it's what you want..

How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support

support.microsoft.com

antspants · Mar 25, 2025

Welcome.

I’m a little lost because I am also not really an IT person. So you’re trying to install Windows or update without luck due to TPM2 issues and Secure Boot? Wanting to beat whatever is coming.

22H2 is really old.

If so, have you tried creating the install media and installing with Rufus?
Using as a fresh install media or for an in-place upgrade

Rufus - Create bootable USB drives the easy way

Rufus: Create bootable USB drives the easy way

rufus.ie

As much as RUFUS can bypass TPM2.0 secure boot to upgrade to Windows 11 24H2, it will not work if the CPU lacks SSE4.2. Nothing will.

Again, I’m most likely out of my league and have mistaken your issue. Don’t try explaining, better I butt out.

P.S.

Here is a page that contains a security update posted in relation to CVE-2023-24932, created 6 days after July 9th (July 15th 2024)

TPM 2.0 device can't be recognized in Windows Server 2012 R2 - Microsoft Support

Fixes an issue in which TPM drivers can't recognize TPM 2.0 devices in Windows Server 2012 R2.

support.microsoft.com

garlin · Mar 25, 2025

NetMan304 said:

Under the known issues section, I have a Dell Computer with a TPM 2.0.

Code:

TPM 2.0-based systems:  These systems that run Windows Server 2012 and Windows Server 2012 R2
cannot deploy the mitigations released in the July 9, 2024 security update because of known compatibility issues with TPM measurements.
The July 9, 2024 security updates will block mitigations #2 (boot manager) and #3 (DBX update) on affected systems.

Microsoft is aware of the issue and an update will be released in the future to unblock TPM 2.0-based systems.

Unless you're running Server 2012 on your PC's, this warning is irrelevant to you.

antspants · Mar 25, 2025

garlin said:
Unless you're running Server 2012 on your PC's, this warning is irrelevant to you.

That’s what I was wondering when reading all that documentation. It referenced Server 2012 and Windows 8/8.1. That goes also for the download patches I linked to. Hence my confusion.

NetMan304 · Mar 25, 2025

antspants said:
So you’re trying to install Windows or update without luck due to TPM2 issues and Secure Boot?
22H2 is really old.

Let me clarify. I'm trying to do a clean install of Windows 10 that includes The mitigations for Black lotus all at once. Reload Bios / uefi from clean install using updated bootloader's and resetting Tpm with new keys, that aren't compromised.

I'm choosing Windows 10 due to personal preference. My computer is also compatible with Windows 11, per the manufacturer (Dell)

I can install Windows 10 just fine but since I have a TPM 2.0 the black lotus mitigation step #2 and #3 are automatically blocked on my system. This is in line with the documentation for Microsoft that states this will happen on those affected (tpm 2.0) systems + others.

I'm looking for a way to have a system with the mitigations applied for black lotus and not just a system that relies on revoked or vulnerable bootloaders.

Essentially I would like to apply the mitigations proactively and not wait for forced roll out.

garlin said:
Unless you're running Server 2012 on your PC's, this warning is irrelevant to you.

I've always been under the impression that since these articles are geared towards IT professionals they only list "IT professional" builds as affected. It does appear that steps #2 and #3 are being blocked on my system.

Yes an update SHOULD be issued by Microsoft and / or OEM in due time but I am not wanting to wait..... If possible

antspants · Mar 25, 2025

NetMan304 said:
Yes an update SHOULD be issued by Microsoft and / or OEM in due time but I am not wanting to wait

I can’t help but keep coming back to the fact Microsoft has dealt with this in 2023 & July 2024 . Also, again, Build 22H2 is extremely old and in itself, probably a security issue.

New Microsoft script updates Windows media with bootkit malware fixes

Microsoft has released a PowerShell script to help Windows users and admins update bootable media so it utilizes the new "Windows UEFI CA 2023" certificate before the mitigations of the BlackLotus UEFI bootkit are enforced later this year.

www.bleepingcomputer.com

And again, again. I should probably stay out of it. Garlin always buries me with his knowledge.

garlin · Mar 25, 2025

To summarize in simple terms:

1. MS was informed a previous version of the EFI boot file wasn't secure, and was being actively exploited by hackers. To prevent its abuse, MS needed to ban several variants of the boot file by revoking the boot file's signing certificate (issued by MS). When Secure Boot is enabled, the old boot file will no longer work.

This will force everyone to replace the EFI boot file with a new boot file provided by MS. The new boot file is included in W10 and W11 Monthly Updates since at least June 2024, but not automatically installed for active use.

Before moving ahead, you need to consider:
- Do I have a dual boot setup where an older Windows version exists and it doesn't have/get a copy of the new boot file. By revoking the old file, these Windows systems are unbootable and MS won't provide you a workaround (though someone might post a fix).

- Do I have a bootable ISO media that's older than Dec 2023? It will have the same outdated boot file, and won't be usable unless you follow specific steps to replace the file(s). If you're only committed to running W11 24H2, there isn't a problem.

2. Before the new boot file is permitted, a new signing certificate (issued by MS) needs to be installed to the UEFI's DB ("Allowed signers") database. Adding the new signing certificate (without revoking the old cert) will allow both versions of the boot file to work.

3. When the old signing certificate is added to the UEFI's DBX ("Banned signers") database, all old boot files dating back to Windows 8 stop working if Secure Boot is enabled. Windows itself has to know when to switch the boot file from the old to the new version. You can only have one version of the boot file in place at a time.

4. These steps are done by changing specific registry keys, and rebooting Windows twice in a row (with a bit of a pause to allow it to do some background tasks related to the transition). Failure to follow the steps in sequence could prevent your Windows from booting again. Unless you enter UEFI and temporarily disable Secure Boot mode.

MS originally intended to make the revocation changes mandatory and be automatically applied. But there's enough early issues with selected PC and software partners, that it's left as a voluntary process for now.

Presuming you're read, and understand the answers to the two questions from (#1), jump down to the "Mitigation deployment guidelines"

- Check your Windows has been updated to anything newer than June 2024's updates.

- If you have BitLocker enabled, make a backup copy of the key. Or temporarily turn off BitLocker before running the steps. You can re-enable BitLocker if the migration succeeds.

- You do not need to follow the steps for updating install media, if you're only going to use the latest W11 24H2 ISO to re-install Windows in the future.

Steve C · Mar 26, 2025

I'm mystified by this. Do regular 24H2 users need to take any action?

NetMan304 · Mar 26, 2025

antspants said:
I can’t help but keep coming back to the fact Microsoft has dealt with this in 2023 & July 2024 . Also, again, Build 22H2 is extremely old and in itself, probably a security issue.

New Microsoft script updates Windows media with bootkit malware fixes

Microsoft has released a PowerShell script to help Windows users and admins update bootable media so it utilizes the new "Windows UEFI CA 2023" certificate before the mitigations of the BlackLotus UEFI bootkit are enforced later this year.

www.bleepingcomputer.com

And again, again. I should probably stay out of it. Garlin always buries me with his knowledge.

The solution does not work for my particular system. the Microsoft documentation states that the mitigations are blocked for TPM 2.0 systems and when I try to run that script it's just abruptly closes on me without any error.

My build may not be the freshest OS that Microsoft makes but it still is a currently updated and patched distribution.

NetMan304 · Mar 26, 2025

So i did a bunch of research today and I found some pretty lengthy articles about how TPM work and I'm definitely a lot more knowledgeable on their role in secure boot.
I believe I would feel up to resetting the TPM and clearing everything although I haven't been able to find any documentation on why the black lotus mitigations are intentionally blocked due to TPM 2.0 systems... something to do with the timing of them.

One of the articles i found regarding the nuances of ensuring your tpm is configured securely:

TPM Attestation

None of the articles clarify / provide insight as to why Microsoft would block bootloader revocations on TPM 2.0 systems and leave these systems unpatched.

Scott · Mar 26, 2025

NetMan304 said:
None of the articles clarify / provide insight as to why Microsoft would block bootloader revocations on TPM 2.0 systems and leave these systems unpatched.

Not all TPM 2.0 systems, just those running Windows Server 2012.

NetMan304 · Mar 26, 2025

Garlin: Thank you for your thorough explanation.
Although,
I must admit I'm struggling to feel confident that I've conveyed my intentions with this thread accurately.
With all due respect, I feel like I'm communicating with AI.
I understand why they are necessary and how the revocations work.
I understand the risks.

What i don't understand is how to apply them on a TPM 2.0 system and what exactly the concern is that has caused Microsoft to withold the mitigations on those systems.

Scott said:
Not all TPM 2.0 systems, just those running Windows Server 2012.

View attachment 129443

Yes i see that it says only server but seeing as my windows 10 pro version is definitely having the mitigations withheld as well I'd venture to say that it's all windows builds that have a TPM 2.0 system and the only ones they mentioned in the articles as affected are the only ones that should be being modified by IT professionals and not consumer versions that get updates rolled out by Microsoft.... IMHO

These articles are not for consumers running consumer versions of Windows and therefore consumer builds are not "affected".

I may just have to try and apply them and see what happens. Not that it will be a noticable issue but seeing as i can't even get a conversation going on the topic, it may be my only option.

I may call Microsoft Or maybe TCG. I'll post back with results.

Are there any other TPM 2.0 users that find themselves frustrated by the lack luster patch schedule for these critical security vulnerabilities?

Thanks

garlin · Mar 26, 2025

Mitigations are not automatic yet, the final goal to have Windows silently perform this task. But as you can see in the instructions, it requires two phases of reg key changes and reboots. MS isn't being "lackluster", it recognizes the opportunity for someone who isn't technical to "brick" their system is high, which is why they're proceeding with caution.

The framework to roll out the changes are already embedded inside a patched W10 or 11 system today. If you don't feel comfortable to follow the process today, that's your prerogative. But you can't say MS isn't concerned. Implementing the changes is far cleaner than where MS was about a year ago.

glasskuter · Mar 26, 2025

NetMan304 said:
Are there any other TPM 2.0 users that find themselves frustrated by the lack luster patch schedule for these critical security vulnerabilities?

IMO ....some users did manually apply the revocations, but more did not. I'm sure most corporate IT departments did since Black Lotus malware is geared to attacking corporate environments. But for domestic users, I think only those who are paranoid about security applied the revocations before MS rolls them out automatically.

While yes, you are receiving security updates now using 22h2, you won't get updates come October of this year. I would be more concerned about getting Windows 11 up to date than I would be about the revocations. But that's just me.

hsehestedt · Mar 26, 2025

I'll play with this again. It's been a long time since I played with this, but I was easily able to patch all my systems. I even scripted a lot of the steps. But that was probably a good year ago.

I'll post back once I update all my procedures based upon the latest info. It's low priority so it may be a couple days.

garlin · Mar 26, 2025

hsehestedt said:
I'll play with this again. It's been a long time since I played with this, but I was easily able to patch all my systems. I even scripted a lot of the steps. But that was probably a good year ago.

I'll post back once I update all my procedures based upon the latest info. It's low priority so it may be a couple days.

The current guidance is really strange in asking you to check event logs if your DB or DBX changes have taken effect. I found a PS function on GitHub which decodes the UEFI certificates list back into their normal names.

Not sure why MS doesn't just write a PS script like this one. Run the script to report which certs have already been installed.

NetMan304 · Mar 26, 2025

hsehestedt said:
I'll play with this again. It's been a long time since I played with this, but I was easily able to patch all my systems. I even scripted a lot of the steps. But that was probably a good year ago.

I'll post back once I update all my procedures based upon the latest info. It's low priority so it may be a couple days.

Thank You Very Much!

garlin said:
The current guidance is really strange in asking you to check event logs if your DB or DBX changes have taken effect. I found a PS function on GitHub which decodes the UEFI certificates list back into their normal names.

Not sure why MS doesn't just write a PS script like this one. Run the script to report which certs have already been installed.

Code:

[B]PS C:\Windows\System32> powershell -NoExit -File Check_UEFI-DB.ps1[/B]

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

Secure Boot: ENABLED

UEFI DB Certificates
--------------------
        Microsoft Corporation UEFI CA 2011
        Microsoft Windows Production PCA 2011

UEFI DBX Certificates
---------------------
        Microsoft Windows PCA 2010


PS C:\Windows\System32>
PS C:\Windows\System32> powershell -NoExit -File Check_UEFI-DB.ps1
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

Secure Boot: ENABLED

UEFI DB Certificates
--------------------
        Microsoft Corporation UEFI CA 2011
        Microsoft Windows Production PCA 2011

UEFI DBX Certificates
---------------------
        Microsoft Windows PCA 2010


PS C:\Windows\System32>

I still have the original ones. I will try step 2 and 3 in a couple hours, right now I must leave the house.

garlin · Mar 26, 2025

@hsehestedt, I found an Enterprise KB which suggests you can run with scissors and collapse the 4 steps into only 3 reboots.

For information about how to apply Mitigation 1 and Mitigation 2 in two separate steps (if you want to be more cautious, at least at first) see KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932. Or you can apply both mitigations by running the following single registry key operation as an administrator:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x140 /f

As the mitigations apply, the bits in the AvailableUpdates key will be cleared. After setting it to 0x140 and restarting, the value will change to 0x100 and then, after another restart, it will change to 0x000.

The boot manager mitigation will not be applied until the firmware indicates that the 2023 certificate mitigation is successfully applied. These operations cannot be performed out of order.

When both mitigations are applied, a registry key will be set to indicate that the system is “2023 capable”, meaning that the media can be updated and Mitigation 3 and Mitigation 4 can be applied.

In most cases, completing Mitigation 1 and Mitigation 2 requires at least two restarts before the mitigations are fully applied. Adding additional restarts in your environment will help ensure that the mitigations are applied sooner. However, it may not be practical to artificially inject additional restarts and may make sense to rely on the monthly restarts that occur as part of applying the security updates. Doing so means less disruption in your environment but at risk of taking longer to get secure.

After deploying Mitigation 1 and Mitigation 2 to your devices, you should monitor your devices to ensure that they have the mitigations applied and are now “2023 capable”. Monitoring can be done by looking for the following registry key on the system. If the key exists and is set to 1, then the system has added the 2023 certificate to the Secure Boot DB variable. If the key exists and is set to 2, then the system has the 2023 certificate in the DB and starts with the 2023 signed boot manager.

Registry Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Key Value name WindowsUEFICA2023Capable
Data Type REG_DWORD
Data 0 – or key does not exist - “Windows UEFI CA 2023” certificate is not in the DB
1 - “Windows UEFI CA 2023” certificate is in the DB
2 - “Windows UEFI CA 2023” certificate is in the DB and the system is starting from the 2023 signed boot manager.

Important Mitigation 1 and Mitigation 2 must be completed before applying Mitigation 3 and Mitigation 4.

For information about how to apply Mitigation 3 and Mitigation 4 in two separate steps (if you want to be more cautious, at least at first) see KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932 Or you can apply both mitigations by running the following single registry key operation as an Administrator:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x280 /f

Applying both mitigations together will only require one restart to complete the operation.

Bottom line, the whole manual process can be collapsed into:

1) reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x140 /f
2) shutdown /r /t 0

After 1st reboot

4) reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates

If result = 100, then continue:
5) shutdown /r /t 0

After 2nd reboot

6) reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates

If result = 0, then continue:
7) reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v WindowsUEFICA2023Capable

If result = 2, then continue:
8) reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x280 /f
9) shutdown /r /t 0

After 3rd reboot

10) powershell -C "[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'"

If result = $True, done!

NetMan304 · Apr 13, 2025

garlin said:
@hsehestedt, I found an Enterprise KB which suggests you can run with scissors and collapse the 4 steps into only 3 reboots.

After 2nd reboot

6) reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates

If result = 0, then continue:
7) reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v WindowsUEFICA2023Capable

If result = 2, then continue:
8) reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x280 /f
9) shutdown /r /t 0

After 3rd reboot

10) powershell -C "[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'"

If result = $True, done!

Sorry for the delay in response.... I never can get step 6 to complete. I keep getting a value of 140 returned. Anyone know how to remedy this for known issue 2.0 TPM? PCR timing banks?

TPM 2.0 Devices and remediation of CVE-2023-24932 (Black Lotus) UEFI / Secure Boot Vulnerability. - Help for those with "Known Issues"

Member

My Computer My Computer

At a glance

aka Mama Glass

My Computers My Computers

At a glance

At a glance

Like a rolling drone.

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Like a rolling drone.

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Like a rolling drone.

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

aka Mama Glass

My Computers My Computers

At a glance

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

Attachments

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

My Computer

My Computers

My Computers

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer

My Computers

My Computers

My Computer

My Computer

My Computer

My Computer