BlackX UEFI bootkit abuses Baton Drop CVE-2022-21894 on patched Windows: how to revoke PCA 2011

Kaspersky has published its analysis of BlackX, a UEFI bootkit used in an espionage campaign against diplomatic agencies in Central Asia earlier this year. It matters beyond that campaign for one reason: every machine it infected was fully patched. BlackX abuses the Baton Drop flaw, CVE-2022-21894, to get past Secure Boot, and the fix for that class of attack exists but is not switched on by default. Administrators have to enable it by hand. Kaspersky attributes the operation, with medium confidence, to the China-linked group APT41.

Key points

• Kaspersky says BlackX is a UEFI bootkit, found in an early-2026 campaign against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan, that bypasses Secure Boot through Baton Drop (CVE-2022-21894).
• The victims were running fully patched Windows; the revocation of the "Windows Production PCA 2011" certificate that blocks the attack has to be triggered manually.
• Kaspersky attributes the campaign to APT41 with medium confidence and says BlackX's exploit code closely resembles the 2022-era BlackLotus bootkit.
• The PCA 2011 certificate expired on 19 October 2026, but Kaspersky warns that expiry alone does not stop vulnerable boot binaries from loading; the certificate must be blocklisted.
• Microsoft's guidance for the revocation is KB5025885, which tracks CVE-2023-24932; as we read it, a date for automatic enforcement has not been announced.

What to do

Who is affected: Windows PCs and servers that boot with UEFI Secure Boot and have not completed Microsoft's boot manager revocation. A fully patched system is still exposed until the revocation is applied, because the security updates install the new boot components but do not turn the revocation on.

What to do: follow Microsoft's KB5025885 steps. In outline, as the page describes them:

1. Update every Windows installation on the device to the July 2024 cumulative update or later, and update recovery and install media first. Microsoft warns that the device may fail to boot from media that has not been updated.
2. Back up the BitLocker recovery key. Some devices go into BitLocker recovery after the change.
3. Test on one device of each hardware class. Some firmware fails the updates.
4. Set the AvailableUpdates value under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot and run the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task after each change. The documented values are 0x5944 (add the 2023 certificates and update the boot manager) and 0x80 (add PCA 2011 to the revocation list, the DBX). 0x200 is an optional further step.
5. Check the result: Event ID 1037 is logged when the revocation is applied, and the DBX should contain the PCA 2011 entry.

Mind the caveats. Microsoft says the revocation cannot be reverted while Secure Boot stays in use, and "even reformatting of the disk" does not remove it. Known issues it lists include HP Sure Start devices that need firmware updates, Arm64 devices, VMware virtual machines with Secure Boot, and Symantec Endpoint Encryption. Dual-boot systems are the reason the step is manual: Kaspersky says automatic revocation could break them.

Check whether you are exposed: the revocation is not applied if the PCA 2011 entry is missing from the DBX. Kaspersky's indicators include the file names inst.exe, PVMDIJGKAX2, googleupdate.exe and v8_context_snapshot.bin, and the command-and-control domain archivetj[.]com. Treat these as hunting leads, not a complete list: Kaspersky's report, as we could read it, does not give every indicator in full.

What happened

Kaspersky's researchers identified the campaign in early 2026. Their report, published on 22 October 2026, describes an attacker who first obtained administrator privileges inside victim networks and then dropped two files: an installer called inst.exe and an RC4-encrypted file with no extension, PVMDIJGKAX2, that holds the components. The installer runs with the RC4 key passed on the command line, which means inst.exe on its own contains no malicious strings or embedded payloads, a design that makes it harder for scanners to flag.

The installer places files on both the Windows system partition and the EFI system partition. The Baton Drop exploit then lets the attacker enrol custom Machine Owner Keys (MOKs), which in turn allows arbitrary EFI files to load and Secure Boot to be subverted. From that point the bootkit runs before Windows and its security products start.

Its UEFI payload injects a malicious kernel driver. The driver is signed with a certificate issued to a Chinese-named studio, and that certificate has since been revoked. According to Kaspersky, the driver:

• disables process, thread and registry callbacks that security products rely on;
• tampers with Event Tracing for Windows (ETW) providers, which are used for monitoring;
• includes routines aimed at Kaspersky and Avast products (Kaspersky says its own dynamic analysis showed these did not work against its products);
• protects the bootkit's files by handing back a handle to calc.exe whenever something tries to open them.

Two espionage payloads follow. The first is a user-mode remote access tool that uses Google Drive, OneDrive or Yandex.Disk for command and control, executes .NET modules and transfers files. The second, which Kaspersky calls OxiDLLRunner, is an obfuscated DLL (OLLVM) loaded by sideloading through a legitimate googleupdate.exe (originally jcef_helper.exe). It decrypts v8_context_snapshot.bin to run a Rust payload that contacts a server and runs DLL plugins through a create_plugin export. BleepingComputer, summarising the report on 24 October, adds that the plugins are fetched from archivetj[.]com.

Background

The story starts with BlackLotus. In October 2022 the bootkit was advertised on a hacking forum for $5,000, and in March 2023 ESET confirmed it could compromise fully patched Windows 11 machines by exploiting CVE-2022-21894 (Baton Drop). ESET's analysis, reported by BleepingComputer, found the bootkit wrote its own MOK into the MokList NVRAM variable so it could load a self-signed bootkit through a Microsoft-signed shim without re-exploiting the flaw at every boot. ESET also pointed out that Microsoft's June 2022 fix for the original bug was insufficient because the UEFI revocation list had not been updated.

Microsoft's answer was to revoke trust in the "Windows Production PCA 2011" certificate that signs the vulnerable boot components. The KB5025885 page describes a staged rollout: mitigations were added from April 2024, with a deployment phase from July 2024 where customers are encouraged to apply them. An "enforcement" phase, which would add PCA 2011 to the DBX automatically on capable devices with no way to disable it, was described as coming later with at least six months' notice. When we read the page, it did not give an enforcement date.

BlackLotus source code leaked on GitHub in July 2023. BleepingComputer reports that the leaked repository was incomplete, and that Kaspersky found code in some BlackLotus samples that was missing from the public repository but present in BlackX. Kaspersky's reading is that the BlackX authors either reverse-engineered BlackLotus or got its source from elsewhere. Kaspersky also notes that no public BlackLotus attacks had been seen between 2023 and this campaign.

How it works

Secure Boot is a chain of trust: the firmware only runs boot components signed by keys it trusts, and a revocation list (the DBX) names components it must refuse even if they are validly signed. Baton Drop works because Microsoft-signed boot components with a known flaw are still trusted. An attacker with administrator rights can place an old, vulnerable but validly signed binary on the EFI partition and exploit it. As long as the certificate that signed it is not in the DBX, the firmware has no reason to refuse it.

That is why patching alone did not help. Kaspersky's central argument is that the targeted machines were fully patched and the problem was the design of the fix. The update revokes PCA 2011, but the administrator must "trigger it manually", by setting the registry flag and running the Secure-Boot-Update task. Kaspersky says the manual step is intentional, because automatic revocation could break dual-boot systems. It calls the result a gap in the update process, since administrators rarely take manual steps after installing security updates.

The certificate's expiry date adds a trap. PCA 2011 expired on 19 October 2026, three days before Kaspersky's report. Both Kaspersky and BleepingComputer stress that an expired certificate does not by itself stop the vulnerable binaries from loading. What counts is the blocklist.

What it means

For administrators: the BlackX case turns an item that many teams had parked on the "someday" list into an incident-response question. Kaspersky's finding that every victim was fully patched means patch compliance reports do not show Secure Boot exposure. Inventory which devices have applied the revocation, and plan the update of recovery media, which is the part most likely to cause trouble.

For defenders in targeted sectors: the campaign hit diplomatic agencies, and the attacker needed administrator access first. A bootkit is a persistence tool that sits below the operating system, so the question is not how they got in but how hard it is to get them out. Kaspersky advises security products with exploit prevention and close attention to their alerts.

For Microsoft and the ecosystem: the case is an argument about defaults. A mitigation that exists but is off by default protects nobody who does not know about it. The tension Kaspersky describes, between not breaking dual-boot setups and protecting patched machines, is the same one that keeps the enforcement date open. Kaspersky's report also cites ToolShell as another example of patches that needed more than installation.

For the attackers: BlackX shows the value of a leaked, half-complete tool. BleepingComputer's summary of the report says BlackX differs from BlackLotus in its kernel driver and follow-on payloads, so reuse of the exploit code was combined with new components.

What we don't know yet

• Who did it. The APT41 attribution is medium confidence. Kaspersky's reasons include a PDB path fragment ("xdd") that ESET also saw in its June 2026 report on the FishMonger actor, and the sideloading and OLLVM habits common to Chinese-speaking actors. Those are circumstantial.
• How many were infected. We found no victim count in the sources we read.
• How the attackers got administrator access on the victim networks.
• Whether other groups hold the same code. Kaspersky's note that the code might have been obtained from another source leaves this open.
• When Microsoft will enforce the revocation. The KB page we read had no date.

What to watch next

Watch Microsoft's KB5025885 page for an enforcement date, because that would move the revocation from optional to automatic. Watch for further vendors confirming BlackX samples or sharing indicators, and for any response from Microsoft about the findings. For our earlier coverage of another case where the patch was only half the work, see our report on the PHP2Shell exploitation.

Sources

• Kaspersky Securelist: BlackX UEFI bootkit analysis (primary source)
• Microsoft: KB5025885, how to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932
• BleepingComputer: BlackX UEFI bootkit exploits Baton Drop flaw to bypass Secure Boot
• BleepingComputer: BlackLotus bootkit bypasses UEFI Secure Boot on patched Windows 11