Kaspersky reports that a new UEFI bootkit, BlackX, ran on fully patched Windows machines at diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. It abuses the old Baton Drop flaw to get around Secure Boot. The patch for that flaw protects a machine only after an administrator completes a manual revocation step, and Kaspersky says the targets had not done it.
Kaspersky published the research on 22 October 2026 and says it identified the attack in early 2026. It attributes the activity to APT41 with medium confidence. This post follows the attack in the order it runs, then explains why patching alone did not stop it.
How Does BlackX Compare With BlackLotus?
Kaspersky says its team first saw BlackLotus advertised on a hacking forum in October 2022 for 5,000 US dollars. ESET confirmed in March 2023 that the bootkit was real and that it bypassed Secure Boot through Baton Drop, tracked as CVE-2022-21894.
BlackX uses the same flaw in a very similar way. Kaspersky saw differences in the exploit code and in the kernel driver, so it treats BlackX as a related but separate tool.
How Does the Attack Run, Step by Step?
Kaspersky says the operators deploy BlackX only after they have compromised a network and obtained administrator privileges. The chain below follows its write-up.
- FootholdAttackers already control the network and hold administrator rights.
- Installerinst.exe runs with an encrypted data file and its key, then drops files to the system and UEFI partitions.
- Baton DropThe exploit installs a custom Machine Owner Key, which lets the machine load arbitrary EFI files.
- Kernel driverThe bootkit injects a driver signed with a certificate that its issuer has revoked.
- BlindingThe driver switches off security callbacks, tampers with ETW and hides the bootkit files.
- PayloadsA cloud-storage RAT and a sideloaded DLL that unpacks a Rust payload run in user mode.
The installer is a plain file with no malicious strings. Kaspersky observed it launched as C:\ProgramData\Intel\inst.exe with two arguments: the name of an extensionless encrypted file and the RC4 key that decrypts it. Attackers can rename these files, so treat the path as one example and not as a complete detection rule.
What Does the Kernel Driver Do?
The bootkit’s main job is to inject a malicious driver into the Windows kernel. Kaspersky lists four things the driver does:
- It disables the process, thread and registry callbacks that security products rely on.
- It tampers with ETW providers, so security tools cannot read the events they would normally collect.
- It protects the bootkit files by catching kernel file-open requests and returning a handle to
calc.exeinstead. - It deploys the user-mode payload.
Some of the tampering runs only when Kaspersky or Avast products are present. Kaspersky says these routines fail to interfere with its own products. Because the driver works below the operating system’s normal defences, this is the kind of rootkit behaviour that is hard to see from inside Windows.
How Does the Implant Talk to Its Operators?
Kaspersky describes two user-mode payloads. The first is a remote access trojan that uses cloud storage as its command channel. Kaspersky saw Google Drive, OneDrive and Yandex.Disk. The implant polls the storage and acts on files by their suffix, for example to run a .NET method, upload a file or download one.
The second payload is OxiDLLRunner, a DLL obfuscated with OLLVM. It is loaded by googleupdate.exe, which Kaspersky identifies as a renamed jcef_helper.exe.
This is classic DLL sideloading: a legitimate program loads the attacker’s library. The DLL decrypts v8_context_snapshot.bin from the same folder, and that file holds shellcode followed by a Rust program. The Rust payload contacts www[.]archivetj[.]com and runs plugin DLLs in separate threads. Traffic to Google Drive, OneDrive or Yandex.Disk from a server that has no reason to use them is worth a look in your logs.
Why Does Kaspersky Point to APT41?
Kaspersky assigns the activity to APT41 with medium confidence and lists three reasons:
- The identifier “xdd” appears in several BlackX payloads. It also appears in a kernel implant described in ESET’s June 2026 report on the China-aligned FishMonger group. Kaspersky assesses that BlackX is the UEFI bootkit ESET mentioned.
- DLL sideloading with a legitimate executable and an encrypted file is common among Chinese-speaking actors.
- OLLVM obfuscation is also commonly used by Chinese-speaking actors.
ESET’s own wording was careful. It spoke of “limited indications of possible UEFI bootkit involvement”. Read the APT41 link as Kaspersky’s assessment, not as settled fact. Our APT41 profile gives the background on the group.
Why Did Fully Patched Machines Fall?
Kaspersky is direct on this point: the targeted machines were fully patched. The Baton Drop fix works by revoking the “Windows Production PCA 2011” certificate, but, in Kaspersky’s words, the revocation does not happen automatically when the patch is installed. An administrator has to trigger it. Kaspersky lists a registry flag and a scheduled task named Secure-Boot-Update; Microsoft’s guide (KB5025885) sets the AvailableUpdates value under the Secureboot key and starts the existing Secure-Boot-Update task.
Microsoft’s guide for the related BlackLotus fix, CVE-2023-24932, says the mitigations are not enabled by default and must be applied in stages. It adds that the change cannot be reverted if you keep using Secure Boot. Dual-boot machines need every Windows install updated before the revocation, or one of them may fail to start.
Microsoft planned an “Enforcement Phase” that would revoke the certificate automatically. Kaspersky says that stage had not been implemented when it published. It also notes that the certificate expired on 19 October 2026, and that expiry does not stop vulnerable boot binaries from loading unless the certificate is blocklisted.
- Used in a real campaignYesKaspersky reports BlackX in attacks on diplomatic agencies in early 202622 Oct
- Public exploit codeYesA Baton Drop proof of concept has been on GitHub since 9 August 2022; six repositories carry the CVE id, some of them detection toolsread 25 Oct
- CISA KEV listingNot seenCVE-2022-21894 is not in the catalogue’s 23 October release23 Oct
The flaw is old. NVD published the record on 11 January 2022. Microsoft, as the CNA, scores CVE-2022-21894 at 4.4 (CVSS 3.1, shown on NVD), because an attacker needs high privileges. Kaspersky’s case shows how that score can understate the damage when attackers already hold administrator rights.
How Do You Close the Gap?
Install the patch, then confirm the revocation took effect on each machine. Installing the update is not the same thing, as this campaign shows. These steps follow Microsoft’s guide and Kaspersky’s findings.
- Read Microsoft’s guide firstIt lists the staged mitigation for CVE-2023-24932, including the revocation of Windows Production PCA 2011.
- Update every Windows installOn dual-boot machines, Microsoft says to install updates from 9 July 2024 or later on all of them before you revoke.
- Apply the revocation in stagesMicrosoft says you cannot undo it while Secure Boot stays on, so test on a pilot group first.
- Check the machine, not the patch listLook for event 1037 in the event log, or confirm the PCA 2011 certificate is in the DBX, as Microsoft’s guide describes.
- Keep endpoint security runningKaspersky advises protection on all machines and constant review of its alerts.
If you cannot test the revocation yet, put these machines on a watch list. Search for the file names Kaspersky published, such as inst.exe in a ProgramData folder and a renamed googleupdate.exe. Also review who can obtain administrator rights, since BlackX needs them.
What Is Still Open?
Kaspersky names three countries and diplomatic agencies as the victims, but the write-up gives no total number of organizations. Attribution rests on a few shared clues and is rated medium confidence. It is also unclear when Microsoft will start automatic enforcement, which would remove the need for the manual step.