Overview
Secure Boot is designed to establish trust before Windows even begins to load. But that trust depends on more than simply installing the latest Windows security updates. A new UEFI bootkit known as BlackX demonstrates the problem. Security researchers have observed the malware targeting diplomatic organisations in Tajikistan, Uzbekistan and Turkmenistan during early 2026. The activity is suspected of being linked to the China-aligned APT41 threat group. BlackX appears to be an evolution or copycat of the notorious BlackLotus bootkit, exploiting the same fundamental weakness in how vulnerable Windows boot components remain trusted when Secure Boot revocations have not been properly applied.
The Patch Was Installed — But the Trust Was Still There
BlackLotus exploited CVE-2022-21894, known as Baton Drop, to load malicious code before Windows starts. Microsoft previously made clear that this vulnerability was primarily a persistence and defence-evasion mechanism rather than an initial access method. An attacker would already need administrator or physical access to the device. The critical issue is what happens after the Windows update is installed. Simply patching the operating system does not necessarily prevent vulnerable boot components from being loaded. Microsoft also required organisations to apply Secure Boot revocation measures, including adding the affected Windows Production PCA 2011 certificate to the UEFI Forbidden List (DBX). BlackX appears to be taking advantage of organisations that completed the patching step but never completed the revocation step. The expiry of the certificate on 19 October 2026 does not itself prevent vulnerable binaries from loading. The binaries must actually be blocklisted.
BlackX Reuses an Old Idea
Kaspersky’s analysis found that BlackX installation is remarkably similar to BlackLotus. After attackers obtain administrator privileges, an installer deploys encrypted installation material and writes components to both Windows and UEFI partitions. The objective is to install Machine Owner Keys (MOK) and interfere with Secure Boot so that arbitrary EFI components can be loaded during the boot process. What makes this particularly interesting is that BlackLotus source code was never publicly released. This suggests that the attackers either reverse-engineered the original malware or obtained its source code elsewhere. It is a reminder that sophisticated threat actors do not necessarily need to develop an attack technique from scratch. Existing criminal tooling can become the foundation for state-sponsored operations.
The Security Product Is Not the Final Boundary
Once BlackX establishes itself before the operating system, its UEFI payload can inject a malicious driver into the Windows kernel. The driver is designed to interfere with endpoint security products and has been observed using a certificate belonging to a Chinese company that has since been revoked. The malware then goes further, deploying user-mode espionage capabilities. Researchers observed a remote access trojan capable of delivering additional .NET payloads while using legitimate cloud services such as Google Drive, OneDrive and Yandex.Disk for command-and-control. Another component, OxiDLLRunner, uses DLL sideloading through the legitimate googleupdate.exe process to launch a Rust-based payload. This creates a layered attack: UEFI persistence, kernel-level interference, security-tool tampering and user-mode espionage.
The APT41 Connection
The connection to APT41 is not presented as absolute attribution, but several pieces of evidence point in that direction. Earlier research into FishMonger, an activity assessed to operate under the APT41 umbrella, identified limited indications of a UEFI bootkit capability. Researchers also identified an "xdd" string shared between BlackX and a FishMonger kernel implant. DLL sideloading is another technique commonly associated with China-aligned threat activity. Together, these overlaps suggest that BlackX may represent a continuation or adaptation of an existing operational capability.
Expert in the Cloud Insight
BlackX highlights a security principle that is easy to overlook:
A vulnerability can be patched while the trust that allowed the vulnerable component to execute remains in place.
Secure Boot is not simply a switch that is either enabled or disabled. It is a chain of trust involving firmware, certificates, bootloaders, revocation databases and operating-system components.
For enterprise security teams, this means Secure Boot compliance should validate more than whether Windows updates are installed. Firmware configuration, DBX revocations, certificate status, bootloader versions and unexpected Machine Owner Keys all form part of the security boundary.
The deeper lesson is even more important: removing the vulnerability from the software is not always enough — the organisation must also remove its ability to be trusted.
Leave a Reply