BlackX exposes the limits of Windows patches against boot attacks

Installing the relevant patches was not enough to protect the organizations affected by BlackX. In an article published on November 3, Ars Technica describes how this malware bypassed Secure Boot despite those updates. The problem lies in the continued trust placed in older, vulnerable boot managers, which require an additional action to block after the patches are installed.

Secure Boot checks the digital signatures of software executed at startup to prevent unauthorized code from loading. BlackX and its predecessor BlackLotus exploit a Windows boot manager vulnerability known as Baton Drop and tracked as CVE-2022-21894. Microsoft patched this vulnerability in 2022 without immediately revoking trust in the certificate used to sign the older, vulnerable versions. Those versions could therefore still be used to bypass the protection.

The response then developed in stages. In 2023, Microsoft introduced a new signing certificate. In 2024, another update provided the means to add the old certificate to Secure Boot’s database of forbidden signatures. According to Ars Technica, the organizations infected by BlackX had installed these patches, but the necessary revocation had not been enforced automatically.

This choice addresses a concrete risk: blocking the old certificate before installing the new one can prevent a machine from booting. It does, however, leave administrators with an additional operation to perform. Kaspersky, which discovered the BlackX infections, says the instructions for enabling this protection are difficult to find. Microsoft, for its part, directs customers to its documentation, Ars Technica reports.

The scope of the attack needs to be stated precisely. A bootkit requires attackers to have already compromised the device. Its value then lies in running very early, before many Windows defenses, and loading malicious drivers into the kernel. It can also survive a system reinstallation if the infected boot partition remains intact. The article does not clearly specify the situation for individual users.

The operational lesson therefore goes beyond the mere availability of a patch. In this case, checking that updates are installed does not establish that older, vulnerable components are actually blocked at startup. The incident illustrates the need to distinguish between fixing a vulnerability, providing the means to block older versions, and actually enabling that block, while accounting for the risk of rendering machines unusable.