
A new UEFI bootkit campaign tracked as BlackX has infected fully patched Windows machines by exploiting the same Secure Boot weakness that made BlackLotus infamous, raising a sharp question about whether Microsoft’s patch strategy left organizations exposed for too long. The answer is not simple: Microsoft did fix the underlying flaw in 2022, but additional trust-revocation steps meant to fully block the attack were not automatically enforced on many systems.
What BlackX did on patched Windows systems
According to the reporting from Ars Technica, BlackX was able to run on systems that had already received Microsoft’s 2022, 2023, and 2024 updates. That matters because BlackLotus, first publicly documented in 2023, was the first in-the-wild UEFI bootkit known to bypass Secure Boot on fully updated Windows 11 devices.
UEFI bootkits are especially dangerous because they execute before Windows fully loads. That early foothold lets attackers load malicious code before many operating system defenses are active, and it can make the malware far harder to detect or remove than an ordinary Windows infection.
Why Secure Boot was supposed to stop this
UEFI, or Unified Extensible Firmware Interface, is the firmware layer that starts up a PC, initializes hardware, and hands control to the operating system. One of its most important security features is Secure Boot, which checks digital signatures to make sure only trusted boot components run during startup.
The key target in both BlackLotus and BlackX is the Windows boot manager, a signed component stored on a dedicated partition. Both bootkits exploit a flaw known as Baton Drop, tracked as CVE-2022-21894, which can let attackers bypass Secure Boot and, in some cases, extract BitLocker encryption keys.
The flaw was patched, but trust was not fully revoked
Microsoft fixed CVE-2022-21894 in 2022. The problem, as described in the source report, is that fixing the code flaw was only part of the job. Older vulnerable boot managers were still trusted unless Microsoft’s certificate revocation measures were also applied and activated.
That gap is what allowed BlackLotus to thrive after the original fix, and it appears to have been the opening BlackX used as well.
The long, awkward rollout of Microsoft’s mitigation
In May 2023, Microsoft began a broader mitigation effort by adding a new signing certificate, Windows UEFI CA 2023, to Secure Boot’s trusted database. In 2024, it introduced another update that would allow the older Windows Production PCA 2011 certificate to be added to Secure Boot’s forbidden-signatures database, preventing older vulnerable boot managers from running.
But the important detail is that these changes did not automatically revoke trust everywhere. Microsoft reportedly held back from immediate enforcement because of the risk that devices without the necessary updates could fail to boot and become unusable.
That caution created an uncomfortable middle ground: the vulnerability was fixed, but protection was incomplete unless administrators took extra steps. As a result, systems could remain vulnerable for years after the original patch.
Was Microsoft to blame?
The evidence in the source material points to a shared problem rather than a single culprit. Microsoft did patch the flaw, but it also left a long delay between the fix and full revocation of trust in the older boot components. That delay was driven by a legitimate fear of breaking machines that had not received the right updates.
At the same time, Kaspersky, which discovered the BlackX infections, argues that Microsoft’s deployment model made the danger easy to miss. Most administrators, the company said, would assume an update is enough and would not realize they needed to perform an additional manual action to activate the protection.
- Microsoft fixed the underlying CVE-2022-21894 vulnerability in 2022.
- It added a new trusted certificate in 2023.
- It later provided a way to revoke the old certificate in 2024.
- Yet many systems remained exposed unless admins manually completed extra steps.
Why the extra step mattered so much
Kaspersky said the instructions for activating the patch are buried deep in Microsoft’s documentation and are easy for an average IT administrator to miss. The firm also noted that installing updates alone is usually treated as the end of the job, not the beginning of another configuration process.
Microsoft, according to the source report, pointed customers to a Knowledge Base post published two weeks ago, but that guidance did not clearly warn that the current patches do not by themselves protect against Baton Drop attacks. Kaspersky said Microsoft also leaves out the fact that most administrators still need to take an additional action described in a 2023 Knowledge Base article.
The security trade-off Microsoft faced
There was no perfect option. Revoke the old certificate too early, and machines that lacked the necessary update path could stop booting. Delay too long, and attackers have a window large enough to weaponize the gap. BlackX shows what can happen when that window stays open for years.
In Kaspersky’s view, the attacker behind BlackX likely understood that many organizations had not realized the Baton Drop patch still needed manual activation. The company said the threat actor appears to have studied BlackLotus closely and built a copycat bootkit around the same weakness.
What the BlackX case means now
BlackX is notable not because it introduced a new trick, but because it proved that a years-old Secure Boot bypass could still work against fully patched systems. That makes it another reminder that firmware-level threats are slower to die than ordinary software bugs, especially when remediation depends on trust revocation across a vast ecosystem.
For defenders, the immediate lesson is that patch status alone may not tell the full story. In this case, the difference between “updated” and “protected” depended on whether the revocation process had actually been completed.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cybersecurity Tech News
Last Modified: November 3, 2026 at 10:31 pm
0 views
