BlackX Bootkit Bypasses Secure Boot on Patched Windows PCs: Why DBX Revocation Matters

What BlackX is and who it hit​

Kaspersky's Global Research and Analysis Team (GReAT) found BlackX and described it in a Securelist report. Securelist analysts reported the findings on October 22, 2026. They say BlackX uses Baton Drop, a vulnerability tracked as CVE-2022-21894, and shares parts of its design with the BlackLotus bootkit. The targets were narrow and important: the bootkit was used to spy on diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan.

This was not a drive-by attack. BlackX is installed after attackers have already gained access to a victim's network and administrator-level rights. Its installer, inst.exe, works with an encrypted file named PVMDIJGKAX2, which contains components needed to install the malware. Kaspersky says inst.exe holds no malicious strings of its own. Every installation component sits inside the RC4-encrypted file, and the decryption key is passed on the command line. Securelist says this design can make it harder for incident responders to recover all the bootkit's parts from the installer alone. Kaspersky does not say how the attackers first got into the networks.

How it works:

• Secure Boot bypass: BlackX exploits CVE-2022-21894 (Baton Drop) on compromised Windows systems to register a custom Machine Owner Key (MOK) and load arbitrary EFI binaries.
• Kernel foothold: After bypassing Secure Boot, BlackX loads a malicious Windows kernel driver. Kaspersky says the driver was signed with a certificate issued to a Chinese company, and the issuer has since revoked it.
• Blinding defenders: The malicious kernel drivers obstruct security product callbacks and ETW, and spoof open requests for bootkit files to point to calc.exe handles. In plain terms, if a security tool tries to open the bootkit's files, it gets Windows Calculator instead.
• Vendor-specific code: Some of BlackX's routines specifically check whether Kaspersky or Avast products are installed. Kaspersky adds that in its own testing, these routines did not actually interfere with its products.

Kaspersky saw two espionage payloads. The first is a remote access trojan (RAT) that uses Google Drive, OneDrive or Yandex.Disk as its command channel, and it can run .NET modules and move files. The second, which Kaspersky calls OxiDLLRunner, is an OLLVM-obfuscated DLL sideloaded by a legitimate executable renamed googleupdate.exe. It decrypts a file called v8_context_snapshot.bin and launches a Rust implant that talks to archivetj[.]com and accepts plugin DLLs.

Kaspersky also noticed that BlackX's exploit chain is very close to BlackLotus's, although the BlackLotus source code was never published. The researchers suggest the attackers either reverse-engineered BlackLotus or bought its source from cybercriminals. They note that state-backed (APT) groups rarely borrow from criminal tooling like this.

Attribution: Kaspersky links the campaign to APT41 with medium confidence, not certainty. Its evidence includes the identifier "xdd" appearing repeatedly in BlackX payloads. The same identifier shows up in a kernel implant PDB path from a June 2026 ESET report on FishMonger, a group widely tied to APT41. Kaspersky also points to DLL sideloading and OLLVM obfuscation, patterns it associates with Chinese-speaking actors. Some secondary coverage drops the hedge and presents the attribution as settled. Kaspersky's own report does not.

Section summary: This is a targeted espionage campaign that starts after a network compromise. It is not a mass-infection threat, but it is a serious one because the malware runs before Windows' own defenses load.

Why "fully patched" didn't mean "protected"​

Kaspersky's investigation took a turn here. The researchers first assumed the victims had skipped updates. Instead, Kaspersky said all known BlackX victims were using a fully patched Windows release. The bootkit nevertheless worked because administrators had not manually activated the additional Secure Boot revocations.

The cause is how Microsoft built the fix. Patching the boot manager doesn't help much if firmware still trusts the old, vulnerable boot managers, because an attacker with admin rights can simply put one of those back on the EFI partition. Securelist says the protection against Baton Drop depends on revoking trust in the "Windows Production PCA 2011" certificate used to sign vulnerable UEFI components. According to Kaspersky, that revocation needs a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and a scheduled task named Secure-Boot-Update. Installing the update does neither.

Kaspersky's researcher was blunt about the result, saying instructions for activating the patch are "buried deep on the Microsoft website." Their reasoning is that admins rarely take extra steps after an update unless something fails.

One detail in Kaspersky's report needs correcting. It says Baton Drop was disclosed in 2023. The CVE number and Microsoft's patch history say otherwise: the flaw is a Secure Boot security feature bypass vulnerability originally disclosed and patched by Microsoft in January 2022. 2023 is when BlackLotus turned it into a real-world problem.

The expired certificate doesn't save you​

You might assume that because the Windows Production PCA 2011 certificate expired, it no longer matters. Kaspersky says that is wrong. The certificate expired on October 19, 2026, but vulnerable binaries signed with it can still load unless the certificate is on the blocklist. UEFI firmware generally checks the forbidden-signatures database (DBX), not expiry dates. Only revocation closes the gap.

Is Microsoft to blame? The case for each side​

For the prosecution:

• In Mezha's account, a Microsoft representative pointed customers to a Knowledge Base post published two weeks earlier, and that post does not warn that the patches alone don't stop Baton Drop.
• Kaspersky says Microsoft's own deployment plan includes an "Enforcement Phase" that would revoke the 2011 certificate automatically, and that this phase had not shipped when Kaspersky published.
• The enforcement date has moved. Microsoft's "Latest Windows hardening guidance and key dates" page (KB5036534) still has an older entry promising mandatory enforcement in "October 2024 or later." The same page now also lists the Enforcement Phase as "January 2026 or later." It says enforcement won't start before then and that Microsoft will give at least six months' advance notice. By late October 2026, Kaspersky says it still hadn't happened.

For the defense:

• Microsoft's revocation guidance (KB5025885) warns that once the mitigation is applied, it cannot be undone while Secure Boot stays on. Even reformatting the disk won't remove it. Forcing that on a few hundred million PCs with inconsistent firmware could leave many of them unable to boot.
• The same document lists real compatibility problems:
  • VMware x86 VMs with Secure Boot fail to boot after the mitigations.
  • HP machines with Sure Start need firmware updates first.
  • Qualcomm-based Arm64 devices were blocked pending firmware fixes.
  • Systems with Symantec Endpoint Encryption can't apply the mitigations.
  • Windows Server 2012 and 2012 R2 systems with TPM 2.0 couldn't deploy them until updates released on or after April 8, 2026.
• Kaspersky notes that automatic revocation could break dual-boot systems that rely on the 2011 certificate.
• Microsoft also says plainly that the BlackLotus-style exploit is not an initial-access technique. The attacker needs admin rights or physical access first.

Our assessment: Both sides have a point. Microsoft faced a real dilemma: revoke too early and machines stop booting, wait too long and Baton Drop stays usable. The communication was the weak part. When a vendor ships a fix that does nothing until an admin flips a registry value, and then lets its own enforcement deadline slip for two years, a compliance dashboard showing all-green patch status gives a false sense of safety. The victim organizations still had a separate failure: attackers got administrator rights on their networks in the first place.

What administrators should do​

Microsoft's KB5025885 describes a staged process. Here is the outline, with Microsoft's warnings kept intact:

1. Install current monthly updates on every supported device. Microsoft says this is step one whether or not you plan to apply the revocation.
2. Back up BitLocker recovery keys. Microsoft suggests running manage-bde -protectors -get %systemdrive% from an elevated prompt and recording the 48-digit recovery password.
3. Deploy the "Windows UEFI CA 2023" certificate to the Secure Boot DB and switch to the 2023-signed boot manager. Microsoft says this may already be done on devices marked "High Confidence" in recent cumulative updates. Microsoft says the mitigations are interlocked so they can't be applied out of order.
4. Update all recovery and install media before revoking anything. Microsoft warns that if you install a Windows security update from April 2026 or later and then enable the PCA 2011 revocation, Secure Version Number (SVN) 5.0 is written to firmware. That invalidates older external boot media not built with updates from January 2025 or later.
5. Apply the DBX revocation. Microsoft documents setting AvailableUpdates to 0x80 under the Secureboot key, then running the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task.
6. Verify it worked. Look for Event ID 1037 in the event log, or run this PowerShell check as administrator. It should return True:
   [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
7. Optionally, apply the SVN firmware update. This stops attackers from rolling back to older boot managers.

Before step 5, test on hardware that represents your fleet. That matters most for VMware guests, dual-boot machines and the firmware families Microsoft lists as problematic. If a device won't boot after revocation, Microsoft's recovery procedure is:

1. Turn Secure Boot off.
2. Reset the Secure Boot keys to factory defaults. Use "Reset", not "Clear".
3. Restore the boot files.
4. Turn Secure Boot back on.

The machine is exposed to bootkits until the last step is done.

Home users get less help. Mezha notes that Microsoft's 2023 KB doesn't make clear what consumers should do. Our view, based on the threat model: this attack needs an administrator-level intruder, so a typical home PC user is not the target. Wait for Microsoft's automatic enforcement rather than running firmware-level commands without a recovery drive.

Section summary: For fleets that face targeted attackers, check the DBX state directly. Patch compliance and "Secure Boot: On" do not show whether a device is protected.

The bigger lesson​

BlackX does not show that Secure Boot is broken. It shows that a security fix can be only partly applied, because the patch shipped while the protection stayed switched off. Kaspersky makes the same point with ToolShell, the 2025 SharePoint flaw whose fix also needed a manual step, and says BlackX's operators probably bet that few organizations had activated the Baton Drop revocation. Mezha and Dataconomy are right that patched machines were infected. The useful takeaway for admins is to verify that the revocation is actually active on each device, not to assume the patch did it.

Tell us how far your organization has gotten on the 2023 certificate rollout, and whether your patch dashboards report DBX status at all.