BlackX UEFI bootkit: how the Baton Drop bypass reaches fully patched Windows systems
Researchers at Kaspersky's Global Research and Analysis Team (GReAT) have published details on BlackX, a UEFI bootkit that installs itself beneath the operating system of fully patched Windows machines. The researchers link the implant to an espionage campaign against diplomatic organizations in Central Asia and attribute it to APT41 with medium confidence; The Hacker News reports that it abuses the “Baton Drop” Secure Boot bypass tracked as CVE-2022-21894. Because the fix for that flaw requires a manual step many administrators never took, a vulnerability patched in 2022 is useful again at the firmware level.
What BlackX is
BlackX is a bootkit: instead of attacking Windows from the inside, it manipulates the boot process so its code runs before the operating system loads. Kaspersky's researchers describe it as similar to BlackLotus, the earlier bootkit known for abusing the same vulnerability, and The Hacker News characterizes BlackX as an updated version of that lineage. The comparison matters because BlackLotus demonstrated that Secure Boot bypasses are not theoretical. Once a working bootkit exists, the protection users assume is switched on can be quietly neutralized.The Baton Drop bypass
CVE-2022-21894 lets an attacker with administrative access to a machine, or brief physical access, enroll their own keys and load unsigned code during boot. Microsoft shipped a fix in 2022, but the patch alone does not finish the job: the vulnerable boot managers must also be revoked, and that step has to be applied manually. Systems where it was skipped stay exploitable even with every Windows update installed, as Aviatrix's threat research team explains in its write-up of the campaign.“Microsoft's patch for CVE-2022-21894 does not automatically revoke the vulnerable 'Windows Production PCA 2011' certificate – administrators must manually trigger the Secure Boot revocation after applying the patch.” – Aviatrix threat researchersA related detail is easy to misread. The “Windows Production PCA 2011” certificate, which chained the vulnerable boot managers to Microsoft's trust store, expired on October 19, 2026. Researchers caution that this expiry fixes nothing by itself: vulnerable binaries still load unless they have been explicitly revoked. The revocation, not the calendar, is the part that matters.
An espionage campaign below the OS
Kaspersky reports that BlackX was deployed in early 2026 against diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan. The company links the campaign to APT41, a Chinese state-sponsored actor, with medium confidence – an assessment echoed by Aviatrix, which notes the group is also tracked as Brass Typhoon. As with any attribution short of a conviction, the label describes the researchers' reading of the evidence, not an established fact. The chain itself starts conventionally: the attackers need administrative access, after which they enroll their own key and position the bootkit where the firmware will execute it. From there the implant loads a kernel driver signed with a certificate that has since been revoked. According to Kaspersky's analysis, the driver strips away security software's process, thread and registry callbacks and tampers with event tracing, effectively blinding security tools on the infected machines.- The bootkit persists below the operating system, in a layer most endpoint tools never inspect.
- A kernel driver disables security tooling by removing callbacks and tampering with tracing, leaving defenders with an incomplete picture.
- The final payload is a remote access trojan whose command channel hides in legitimate cloud storage services such as Google Drive, OneDrive and Yandex.Disk.
- Researchers observed loader components delivered via DLL side-loading and obfuscated to resist analysis.
What survives a reinstall
The practical consequence for defenders and home-lab operators is uncomfortable but simple: reinstalling Windows does not reliably remove a bootkit. The implant lives in the EFI system partition, and a routine reinstall does not necessarily wipe that partition or restore the boot binaries on it. A machine can boot into a fresh, fully updated Windows and still load attacker code first. To be clear, such implants do not spread on their own – the attacker needs administrative or physical access first – but once one is in place, the wipe-and-reinstall reflex is not the clean slate it appears to be.What is actually worth checking
- Confirm that Secure Boot is enabled (msinfo32 shows the Secure Boot State on Windows).
- Apply Microsoft's guidance for revoking vulnerable boot managers rather than assuming updates handle it; the Baton Drop fix requires that manual revocation step.
- On dual-boot or home-lab machines, review enrolled Machine Owner Keys with mokutil and remove any entries you did not create.
- Treat a security product that silently stops starting as an incident, not a bug – this driver's job is to blind security tools.
- If a machine is genuinely suspected, repartition the disk or reflash the firmware instead of trusting a plain reinstall; the EFI system partition is the point of persistence.










