BlackX exploits a patch gap years

Every machine that booted BlackX had been patched. That is the detail that matters. The organizations hit by the bootkit had installed Microsoft's fixes for Baton Drop, the boot-manager logic flaw tracked as CVE-2022-21894, along with the follow-up updates shipped in 2023 and 2024. Yet the malware still slipped past Secure Boot and executed before Windows had fully loaded. What the defenders had done was apply the patches. What most of them had not done was take the extra, easily missed step that actually turns those patches into protection.

BlackX is the name researchers at Kaspersky gave to the bootkit behind these infections. It follows BlackLotus, which became the first publicly documented in-the-wild UEFI bootkit able to bypass Secure Boot on fully updated Windows 11 systems after its discovery in 2023. The two families share their method: both lean on Baton Drop, a logic flaw in the Windows boot manager that lets an attacker get around Secure Boot and, under certain conditions, pull BitLocker keys out of a machine.

How a bootkit gets under Windows

UEFI, short for Unified Extensible Firmware Interface, is the firmware that runs the moment a computer is switched on. It loads system configuration settings, identifies and initializes hardware, and gets the machine ready to hand off to its operating system. Secure Boot sits inside that process. It builds a chain of trust by checking the digital signature of each piece of boot software before allowing it to run, which is meant to stop anyone who controls a device — physically or through malware — from substituting their own boot code for the legitimate kind.

The boot manager is one of the components that has to carry a valid signature. It lives on a small dedicated partition on the drive and handles the initial loading of the OS. Baton Drop breaks that arrangement. Because the flaw lives in the boot manager's logic, exploiting it lets an attacker skip past Secure Boot rather than defeat the signature check itself.

Getting that far is the whole game for a bootkit. Code that runs this early can load a malicious driver into the Windows kernel before most of the operating system's defenses are up. Detection is hard without specialized security tooling, and the implant can outlast a clean OS reinstall if the infected boot partition is left in place. Bootkits still require the attacker to compromise a device first, but the payoff is a combination of stealth, persistence, and deep control over the machine that is hard to match.

The fix that needed a second step

Microsoft patched Baton Drop in 2022 but did not revoke trust in the certificate used to sign older, vulnerable boot managers. BlackLotus exploited that remaining gap, and it was the discovery of that malware that turned Secure Boot bypass from a theoretical concern into a demonstrated, working attack.

Two months after BlackLotus surfaced, in May 2023, Microsoft began a yearslong effort to close the hole for good. That month's patch batch included security updates meant to stop attackers from loading older vulnerable boot managers, and the mitigation added a new signing certificate, Windows UEFI CA 2023, to Secure Boot's database of trusted certificates. In 2024, Microsoft went further and provided a way to add the old certificate, Windows Production PCA 2011, to Secure Boot's forbidden-signatures database. That step, once taken, would keep boot managers signed under the 2011 certificate from running at all.

The 2024 update still did not revoke trust in the older boot managers on its own. Microsoft held back from enforcing the revocation outright because of the risk of leaving potentially millions of devices unbootable if they had not received the necessary updates first. So the update arrived in a kind of purgatory: installed, but dormant until someone deliberately activated it. That state has persisted ever since, and it is what let BlackX get around Secure Boot three years after BlackLotus did.

Buried instructions and a widening gap

Kaspersky's researchers pinned the problem on how the patch was delivered rather than on whether it existed.

"This patch deployment practice creates a problem—as it is extremely unusual for a system administrator to take extra steps after installing an update," a researcher from Kaspersky, the security firm that discovered the BlackX infections, wrote recently. "Usually, when applying patches, system administrators take no further action unless an installation failure occurs. These instructions for activating the patch are buried deep on the Microsoft website, and we assess that they are quite hard for an average IT administrator to notice."

— a researcher from Kaspersky, the security firm that discovered the BlackX infections

A Microsoft representative said in an email that the company is advising customers to follow guidance in a Knowledge Base post published two weeks ago. That post, however, does not warn that the patches released to date do nothing to protect customers from Baton Drop attacks. Nor does it make plain what Kaspersky points out: after installing the patches, most administrators still have to perform an additional action described in a separate 2023 Knowledge Base article. The status for home Windows users is not clear from that article.

Why the attackers placed their bet

Kaspersky's read is that the campaign was built on an assumption about how organizations behave, not on a new technical trick.

"It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch," Kaspersky said. "As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit."

— a researcher from Kaspersky, the security firm that discovered the BlackX infections

That framing fits the evidence. The vulnerable boot managers were never supposed to remain usable this long. The 2023 certificate work and the 2024 forbidden-signatures mechanism both exist to retire them. What was missing was a reason for an administrator to go find the switch and flip it — and an explicit warning about what stays open until they do.

The line between safety and a brick

Microsoft's hesitation is not hard to understand from the inside. Push the revocation before the new certificate is in place and a machine stops booting altogether; for an IT team, that is a fleet-wide outage with no patch to apply, because the device cannot reach one. Hold the old certificate as trusted, and the window stays open for anyone willing to do the work of building a bootkit against it. Four years and counting into that compromise, exploitation is close to a certainty rather than a risk.

The middle ground Kaspersky describes does not require Microsoft to choose either extreme. It requires the company to be explicit about what remains exposed when the 2011 certificate is not manually revoked, and to put that warning somewhere administrators will actually see it. The Knowledge Base article published two weeks ago is the obvious candidate, and as things stand it leaves that warning out.

What administrators should take from this

The practical lesson is uncomfortable for anyone who treats "patched" as a binary state. For Baton Drop, the updates Microsoft shipped in 2023 and 2024 are a prerequisite, not the finish line. Organizations running Windows at scale should confirm whether the revocation of the Windows Production PCA 2011 certificate has actually been activated on their devices, rather than assuming that a clean update history means Secure Boot is intact.

The exposure is not evenly spread. A bootkit still needs an initial compromise before it can be planted, so the victims were already reachable by whatever intrusion preceded the implant. What BlackX adds is what happens afterward: a foothold that survives the reinstall many responders reach for first, and that sits below the layer most endpoint tools can see. Recovery from an infection of this kind means dealing with the boot partition, not just the operating system on top of it.

For everyone else, the story is a reminder that mitigations with a manual activation step can drift for years without anyone noticing they were never switched on. Whether Microsoft chooses to make that step harder to miss, or leaves it where it is, will shape how many more organizations discover the gap the way these ones did — after the bootkit has already run. Reporting based on original coverage from Ars Technica.