---
title: "BlackX Bypassed Secure Boot on Fully Patched Windows Boxes — Legally"
description: "Microsoft fixed the bug in 2022. The fix needs a step almost nobody takes, and its own new advisory still doesn’t say so."
author: "Luis Goa"
published: 2026-11-03T16:03:13Z
modified: 2026-11-04T09:41:13Z
url: https://rews.cc/a/blackx-bypassed-secure-boot-on-fully-patched-windows-boxes-l-3949b1
language: en
tags: ["cybersecurity", "windows", "secure-boot", "malware", "microsoft", "tech"]
publisher: "Rews (https://rews.cc)"
---

# BlackX Bypassed Secure Boot on Fully Patched Windows Boxes — Legally

*Microsoft fixed the bug in 2022. The fix needs a step almost nobody takes, and its own new advisory still doesn’t say so.*

By Luis Goa · November 3, 2026 · https://rews.cc/a/blackx-bypassed-secure-boot-on-fully-patched-windows-boxes-l-3949b1

## In brief

- Kaspersky’s BlackX bootkit bypassed Secure Boot on Windows machines with every patch installed
- It exploits CVE-2022-21894 (“Baton Drop”), fixed by Microsoft in 2022 but not fully revoked since
- Closing the gap needs a manual admin step most IT staff never run, per Kaspersky and Microsoft’s own documentation
- Kaspersky ties BlackX, used against diplomats in Tajikistan, Uzbekistan and Turkmenistan, to APT41 with medium confidence
- Microsoft’s Oct. 22, 2026 advisory on the related certificate’s expiry omits any mention of the exploitation risk

Every machine BlackX infected had every Microsoft patch installed. That is the finding Kaspersky published after tracing a UEFI bootkit through diplomatic networks in Tajikistan, Uzbekistan and Turkmenistan: Secure Boot bypassed, kernel drivers loaded before Windows Defender or any other endpoint tool was running, on systems with a fully current update history. The bug Kaspersky found BlackX using was patched by Microsoft in 2022. Four years later it still works, because closing it takes a second step that is not part of the patch.

UEFI is the firmware that runs the instant a PC powers on, before Windows exists as a concept to the hardware. It initializes memory and devices, then hands off to an operating system loader. Secure Boot is the part of that firmware responsible for checking a digital signature on each piece of boot software before running it, so that a machine that has been compromised, physically or remotely, can’t be made to boot attacker-supplied code instead of the real OS. One of the things Secure Boot checks is the boot manager, the small program on its own disk partition that is the first thing to load the actual kernel.

The checked signature is only as good as the list of certificates it trusts. CVE-2022-21894, nicknamed Baton Drop, is a logic flaw in the Windows boot manager that lets an attacker who already has administrative access on a machine roll the installed boot manager back to an older, vulnerable version — one that is still signed by a certificate Secure Boot still trusts, even after the bug in that old boot manager has been fixed in the current version. Roll back, and the new fix is irrelevant: the old, exploitable code runs instead, with Secure Boot’s blessing. Under the right conditions the same flaw lets an attacker pull BitLocker’s disk-encryption keys. Microsoft’s own [security blog guidance on the vulnerability](https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/), published in April 2023 to help administrators hunt for compromise, lays out the mechanism in those terms.

BlackLotus was the bootkit that made Baton Drop real rather than theoretical. It was advertised for sale on a hacking forum in October 2022 for $5,000; ESET confirmed in March 2023 that it worked as advertised, and its source code leaked in July 2023, which is roughly how a copy ends up in a second group’s hands three years later. BlackLotus was the first malware documented running in the wild that defeated Secure Boot on fully updated Windows 11. BlackX, per Kaspersky’s write-up, reuses BlackLotus’s exploitation of Baton Drop almost unchanged — researchers called the implementation “remarkably similar” — while swapping in a different kernel driver and a different set of second-stage payloads, evidence Kaspersky reads as a reverse-engineered or source-derived copy rather than a shared codebase.

## A patch that doesn’t finish the job

Microsoft’s fix for Baton Drop shipped in three pieces over two years, and only the first was a conventional patch. The 2022 update closed the logic flaw in the current boot manager. The May 2023 servicing update, covered in Microsoft’s own [tech-community walkthrough](https://techcommunity.microsoft.com/blog/windows-itpro-blog/revoking-vulnerable-windows-boot-managers/4121735), added a new trusted certificate, Windows UEFI CA 2023, to the signature database (DB) that Secure Boot checks against — new boot managers would now be signed and trusted under it. The April 2024 update added the tooling to put the old certificate, Windows Production PCA 2011, onto Secure Boot’s forbidden-signatures database (DBX), which is the only thing that actually stops an old, vulnerable, 2011-signed boot manager from running. None of that DBX revocation happens by installing the update. An administrator has to run it as a separate, manual step.

**How the 2022 patch left a four-year gap** Microsoft's staged fix for CVE-2022-21894, and the opt-in step attackers kept finding unset

| From | To | How |
| --- | --- | --- |
| Baton Drop found *(CVE-2022-21894, Jan 2022)* | Boot manager patched *(2022)* | fixed in code |
| Boot manager patched *(2022)* | BlackLotus exploits old cert *(sold Oct 2022, confirmed Mar 2023)* | old cert still trusted |
| BlackLotus exploits old cert *(sold Oct 2022, confirmed Mar 2023)* | New trust cert added to DB *(May 2023 update)* | response |
| New trust cert added to DB *(May 2023 update)* | DBX revocation tool shipped *(April 2024 update)* | adds revocation path |
| DBX revocation tool shipped *(April 2024 update)* | Manual admin step required *(not run by most orgs)* | opt-in, not forced |
| Manual admin step required *(not run by most orgs)* | 2011 cert expires *(Oct 19, 2026)* | still unset, 4 yrs later |
| 2011 cert expires *(Oct 19, 2026)* | BlackX exploits same gap *(APT41, found by Kaspersky, 2026)* | expiry ≠ revocation |
| Manual admin step required *(not run by most orgs)* | BlackX exploits same gap *(APT41, found by Kaspersky, 2026)* | same gap, second actor |

Based on [Kaspersky Securelist and Microsoft tech-community documentation](https://securelist.com/uefi-bootkit-blackx/121539/)

Microsoft’s own stated reason for not forcing the revocation is that doing so immediately would brick dual-boot machines and any device that hadn’t yet received every prerequisite update — Secure Boot would simply refuse to start an OS signed only under the now-untrusted certificate. So the DBX update ships as something administrators opt into, and the instructions for actually enabling it, per Kaspersky, sit in a 2023 Microsoft knowledge-base article that most IT staff never see, because installing a security update is normally the whole job. “This patch deployment practice creates a problem,” a Kaspersky researcher wrote in the firm’s [technical report on BlackX](https://securelist.com/uefi-bootkit-blackx/121539/), “as it is extremely unusual for a system administrator to take extra steps after installing an update. Usually, when applying patches, system administrators take no further action unless an installation failure occurs.”

> 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. As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit.

## What BlackX actually does

Deployment presumes the attacker already has administrator rights on the target network — BlackX is a second-stage tool, not an initial-access exploit. Kaspersky’s analysis traces an installer, inst.exe, which carries no malicious code of its own; it unpacks an RC4-encrypted blob named PVMDIJGKAX2 that holds the actual bootkit files, writes them to both the system partition and the UEFI partition, and enrolls a custom Machine Owner Key that lets arbitrary EFI binaries load once Secure Boot has been walked past via Baton Drop. The malicious kernel driver it installs disables the process, thread and registry callbacks that security products rely on and tampers with the Windows event-tracing (ETW) subsystem that many of them use for telemetry; it is signed with a now-revoked certificate issued to a Chinese entity, Wenjiang District Mingyu Network Technology Service Studio. Code built to specifically interfere with Kaspersky or Avast products is present but, Kaspersky found while testing it, does not actually work against Kaspersky’s own software.

Kaspersky attributes BlackX to APT41, also tracked as Brass Typhoon or Wicked Panda, with medium confidence, on three threads of evidence: a debugging-path string, “xdd”, that also turns up in a kernel implant ESET tied to the same group in a June 2026 report; the combination of DLL side-loading with an encrypted payload blob, a pattern Kaspersky describes as common among Chinese-speaking threat actors; and obfuscation on one component built with OLLVM, a tool associated with the same cluster of groups. Second-stage payloads include a remote-access tool that uses Google Drive, OneDrive or Yandex.Disk as its command channel, and a loader Kaspersky calls OxiDLLRunner that decrypts shellcode out of a file masquerading as a Chrome component and talks to a domain, archivetj\[.\]com, to pull further modules.

## The warning that still isn’t in the manual

The certificate at the center of all this, Windows Production PCA 2011, hit its scheduled expiration on October 19, 2026. Expiration is not revocation: binaries already signed under that certificate keep running after the expiry date exactly as before, because Windows checks whether a signature is on the DBX forbidden list, not whether the certificate that produced it has expired. Only an explicit DBX entry blocks the old boot managers, and that entry is the same manual step administrators have been skipping since 2024.

Microsoft published a [knowledge-base article on the certificate’s expiration](https://support.microsoft.com/en-us/servicing/os/secure-boot/2026/10/kb5132953-windows-production-ca-2011-expiration-bootloader-updates) on October 22, 2026 — three days after the expiry, and roughly two weeks before Kaspersky’s BlackX report went public. It describes the transition to the newer Windows UEFI CA 2023 as routine operational housekeeping: WDAC and App Control impacts, installation-media behavior, confirmation that the expiration “does not cause computers to stop turning on or prevent Windows from starting.” It does not mention Baton Drop, CVE-2022-21894, or the fact that machines without the manual DBX revocation remain exposed to exactly the rollback attack BlackX used. Asked about this, a Microsoft representative pointed customers to that same article. Nowhere in it does Microsoft say the patches already installed on a BlackX victim’s machine do nothing, on their own, to stop Baton Drop.

A fully automatic fix has been described, not shipped. Microsoft’s 2024 tech-community post on the revocation process says an “Enforcement Phase” is planned, in which the DBX update would be pushed to all capable devices with no administrator action and no option to disable it — removing the manual step this whole gap depends on. As of that post’s most recent revision, the timing was “currently under evaluation.” No enforcement date has been announced since. The number worth watching next isn’t in any Microsoft advisory: it’s how many Windows installations, two patch cycles and one certificate expiration after the first attacker figured this out, still haven’t taken the step the fix was supposed to make automatic.

## See also

- [CVE-2022-21894 — Security Update Guide](https://msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-21894) — msrc.microsoft.com · Microsoft's official advisory entry for the Baton Drop vulnerability
- [Windows Secure Boot certificate expiration and CA updates](https://support.microsoft.com/en-us/servicing/os/secure-boot/2025/06/windows-secure-boot-certificate-expiration-and-ca-updates) — support.microsoft.com · Microsoft's overview of the full 2011-to-2023 certificate transition schedule