BlackX Bootkit: The Secure Boot Fix Your Patched Windows Is Missing

What BlackX Is, and Why It Matters Beyond Central Asia

BlackX is a UEFI bootkit discovered by Kaspersky GReAT in early 2026 during an APT campaign against diplomatic agencies in Tajikistan, Uzbekistan, and Turkmenistan, published in a Securelist report on October 22, 2026. A bootkit is malware that loads as early as possible in a device's boot sequence - before Windows itself - which puts it ahead of many security tools. BlackX is a revival of the infamous BlackLotus bootkit, first advertised on a hacking forum in October 2022 for $5,000 and confirmed in the wild by ESET in March 2023.

Kaspersky attributes the BlackX campaign to the APT41 threat actor with medium confidence, citing identifiers shared with ESET's FishMonger research, DLL sideloading patterns, and OLLVM obfuscation common among Chinese-speaking threat actors. One detail makes the case unusual: BlackLotus's source code was never published, so the attackers behind BlackX either reverse-engineered the original bootkit or purchased its source - a rare case of an espionage actor investing in cybercrime tooling.

The attack sequence matters for understanding your exposure. BlackX is deployed after the attackers have already compromised the network and obtained administrator privileges - Microsoft's own guidance notes this class of malware requires administrative or physical access. The bootkit is the persistence layer: it exploits Baton Drop (CVE-2022-21894) to roll back the Windows boot manager to a vulnerable older version, enrolls custom Machine Owner Keys (MOK) in the machine's firmware, and from then on can load arbitrary EFI files at every boot. It is the difference between an attacker who can be evicted and one who owns the startup sequence.

Why Fully Patched Machines Got Infected Anyway

This is the part of the story that every Windows owner should sit with for a moment. When Kaspersky began the investigation, the natural assumption was that the victims had skipped their updates - Baton Drop was disclosed and patched back in 2023. The investigation proved the opposite: the targeted machines were fully patched.

"The patch for the Baton Drop vulnerability is designed to revoke the 'Windows Production PCA 2011' certificate used to sign vulnerable UEFI components. However, this revocation does not happen automatically upon patch installation - the user has to trigger it manually." - Kaspersky Securelist, October 22, 2026

Microsoft's comprehensive fix, documented in KB5025885, works in stages: install the updates, migrate the machine to the 2023 Secure Boot certificates, and then add the old "Windows Production PCA 2011" certificate to the UEFI Forbidden Signature Database (DBX) - which permanently untrusts every bootloader signed with it. That last step is triggered by a registry value and a scheduled task, deliberately manual because automatic enforcement could break dual-boot systems and older boot media that still depend on the 2011 certificate.

Microsoft's original three-phase plan included an "Enforcement Phase" that would flip the revocation on automatically. According to Kaspersky's report, that stage has never been implemented. And on October 19, 2026, the Windows Production PCA 2011 certificate passed its scheduled expiration date - which sounds like salvation but changes nothing, because UEFI firmware does not check calendar expiry for bootloaders. Only a DBX entry blocks them.

The result is a protection gap measured in years: Microsoft's April 2024 revocation tooling, a manual step buried deep in documentation that Kaspersky assesses is "quite hard for an average IT administrator to notice," and an attack team that Kaspersky believes deliberately invested in a BlackLotus copycat because so few organizations completed the procedure. The same pattern has happened before - Kaspersky points to the 2025 ToolShell vulnerability as another Microsoft fix that required manual activation.

The Two-Minute Check

Applying the Fix: The Official KB5025885 Procedure

Before running anything: this procedure comes from Microsoft's KB5025885, and Microsoft's own warnings deserve respect. The revocation is permanent - Microsoft states it cannot be reverted by disabling it, reinstalling, or even reformatting the disk, as long as you continue using Secure Boot. Some devices may enter BitLocker recovery during the process. Read the precautions in the next section first, then proceed.

Before You Flip the Switch: The Honest Risk List

We will not pretend this is a one-click cleanup. Microsoft's documentation lists real consequences, and you should weigh them:

What a BlackX Infection Looks Like

If you administer machines that could plausibly be targeted - diplomacy, government, defense-adjacent supply chains - the Securelist report and coverage by Cybersecurity News publish these indicators of compromise. If any are present, the response is professional incident response, not a registry edit: Kaspersky notes the malicious driver returns a handle to calc.exe when security tools try to open the bootkit's files, and that the bootkit's installer keeps its components inside an encrypted container to frustrate analysis.

What BlackX Does Once It Is In

Understanding the payload explains why this campaign is treated as espionage rather than crime. The bootkit injects a kernel driver whose job is to blind security software: Kaspersky reports it disables process, thread, and registry callbacks used by security solutions and tampers with ETW providers so security tools cannot read their output. Some routines activate only if Kaspersky or Avast products are present - and in Kaspersky's own testing, those routines failed to interfere with their products at all. The driver also protects the bootkit's own files by intercepting file-open requests and handing back a handle to calc.exe instead.

Above the driver sit two user-mode espionage payloads. One is a RAT that loads further .NET stages and takes its commands from cloud storage - Google Drive, OneDrive, and Yandex.Disk were all observed - using innocuous file suffixes as a command protocol. The other, which Kaspersky named OxiDLLRunner, is an OLLVM-obfuscated DLL that decrypts a companion file and runs a Rust payload communicating with its C2 to fetch plugin DLLs. For a look at how defenders trace this kind of infrastructure, our email header forensic analyzer covers the same tradecraft on the messaging side.

Where This Fits in the October Security Picture

BlackX is the second story this month where "installed the update" and "actually protected" turned out to be different states - and the pattern is worth internalizing. October's Patch Tuesday shipped KB5127648 with an actively exploited Windows Shell zero-day, September's KB5124008 carried two more, and the PHP runtime spent the month under a scanning campaign we documented in our PHP2Shell patch guide and its DPRK campaign follow-up. The common thread: attackers now audit the gap between a vendor's patch and its activation, exactly as Kaspersky assesses the BlackX operators did. Hygiene still matters on every layer - email authentication stops the message that carries the initial access, recognizing fake virus pop-ups stops the scareware path, and supported operating systems get the fixes at all. A bootkit needs admin access first; every layer you harden is a layer it has to defeat.