A UEFI bootkit dubbed BlackX was used in an espionage campaign in early 2026 that targeted diplomatic agencies across Central Asia. According to Kaspersky and reporting by BleepingComputer, BlackX exploited the old Baton Drop vulnerability (CVE-2022-21894) to bypass UEFI Secure Boot and load a malicious kernel driver built to interfere with security products. The campaign is a sharp reminder that firmware defenses and Windows update hygiene have to be verified, not assumed.
How UEFI Secure Boot works and why it matters
UEFI Secure Boot is a firmware feature that checks each stage of the boot chain against trusted signatures before letting it run. When it is enabled, the firmware refuses to load bootloaders, drivers, and other early-boot components that are not signed by a key trusted in the firmware's signature database. The goal is to stop unsigned or tampered code—exactly the kind of thing a bootkit needs—from running before the operating system's own protections come online.
Microsoft documents this chain across its Windows platforms, including guidance on updating UEFI Secure Boot certificates on Windows devices, and the feature is a hard requirement for a modern Windows 11 install. Because Secure Boot trusts specific signing certificates, an attacker who can enroll their own trusted key or replace a signed component can make malicious EFI code look legitimate. That is the gap BlackX drove a wedge into.
BlackX, Baton Drop, and the return of BlackLotus
BlackX closely resembles BlackLotus, a UEFI bootkit that appeared on a hacking forum in October 2022, advertised for around $5,000. ESET confirmed in March 2023 that the BlackLotus advertisement was genuine: the bootkit could bypass Secure Boot through Baton Drop (CVE-2022-21894), a flaw in how Windows handled certain UEFI components, and it could compromise even fully patched Windows 11 systems at that time.
Kaspersky researchers describe BlackX's implementation of the exploit as "remarkably similar" to BlackLotus, but with differences in the kernel driver and follow-on payloads. Some BlackLotus samples analyzed by Kaspersky contained code that was missing from the incomplete July 2023 source leak yet present in BlackX—suggesting the operator either reverse-engineered BlackLotus or purchased its source code. Borrowing capability from cybercrime in this way is unusual for an APT actor.
How BlackX installs and bypasses UEFI Secure Boot
The attackers deployed BlackX only after they had already compromised victim networks and obtained administrator privileges; the reporting does not describe the initial access method, so it should not be assumed. To install the bootkit, they dropped an installer named inst.exe and an RC4-encrypted, extensionless file named PVMDIJGKAX2. The installer was launched as:
C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1
The final argument is the RC4 key used to decrypt the package. Notably, inst.exe itself contains no obvious malicious strings, the real components live inside PVMDIJGKAX2, which complicates recovery by incident responders.
The package drops files onto both the system and UEFI partitions to exploit Baton Drop. The objective is the same as in BlackLotus: enroll custom Machine Owner Keys (MOKs) so that arbitrary EFI files can be loaded on the target machine, defeating UEFI Secure Boot even when it appears enabled.
What the malicious driver does after it loads
Once UEFI Secure Boot is bypassed, the UEFI payload injects a malicious Windows kernel driver. This driver is signed with a certificate belonging to an organization named Wenjiang District Mingyu Network Technology Service Studio (serial number 0bcdf5e0da32d68900b8b7638459d072), which the issuer had revoked by the time of the report.
The driver is built to blind endpoint security: it disables process, thread, and registry callbacks tied to security products and tampers with Event Tracing for Windows (ETW) providers so those products lose visibility. Some tampering routines run only when Kaspersky or Avast products are detected. The driver also hides the bootkit's own files by intercepting attempts to open them and launching Windows Calculator instead.
On top of this defensive layer, the bootkit deploys espionage payloads, reported by the researchers as:
- A RAT that uses Google Drive, OneDrive, or Yandex.Disk for command-and-control to execute .NET payloads and move files.
- OxiDLLRunner, an OLLVM-obfuscated DLL sideloaded by
googleupdate.exethat decryptsv8_context_snapshot.binto launch shellcode and a Rust payload, which retrieves DLL plugins fromarchivetj[.]comand runs theircreate_pluginfunctions in separate threads.
Why a fully patched system was still vulnerable
The most important operational detail: Kaspersky says all BlackX victims were running a fully patched Windows release. The bootkit still succeeded because administrators had not applied the additional Secure Boot revocations that close Baton Drop. Installing Windows updates alone does not necessarily mean the relevant certificate and revocation updates have been deployed and applied: Microsoft's guidance describes a staged update process, including steps to update Secure Boot certificates and apply the applicable revocation list. Administrators should verify the deployment state rather than assume that patch installation has completed the process. Likewise, the expiration of the Windows Production PCA 2011 certificate does not, by itself, block vulnerable binaries; as BleepingComputer's coverage of the BlackX campaign notes, the relevant certificate or binaries must be revoked or otherwise blocked through the applicable Secure Boot revocation mechanism.
What defenders should do
BlackX is attributed with medium confidence to APT41 (also tracked as Brass Typhoon, Wicked Panda, and Barium); attribution should be treated as an assessment, not established fact. Practically, "patched" is not the same as "remediated" for firmware issues. Verify that Baton Drop revocations are actually applied and that UEFI boot integrity is intact, follow Microsoft's published certificate-update guidance for Windows devices, and review privileged access, since the bootkit was installed only after the attackers already held administrator rights. Checking and enabling Secure Boot on every Windows device is necessary, but pairing that with verified certificate revocation is what turns a nominal defense into a real one. Problems below the OS boundary are not rare either, BitLocker wrapper bypasses carry a similar warning at the pre-boot layer, and this is the same lesson BlackX teaches at the firmware layer.
Source
- BleepingComputer: https://www.bleepingcomputer.com/news/security/blackx-uefi-bootkit-exploits-baton-drop-flaw-to-bypass-secure-boot
- Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance
