In early 2026, a new bootkit dubbed BlackX has reemerged with techniques reminiscent of BlackLotus, enabling attackers to bypass Windows Secure Boot protections. The campaign targets diplomatic missions in Central Asia—specifically in Tajikistan, Uzbekistan, and Turkmenistan—deploying espionage malware even on fully patched systems. Researchers have linked the operation to APT41 with moderate confidence, although definitive attribution remains unconfirmed.
How BlackX Works
BlackX leverages a vulnerability known as Baton Drop (CVE-2022-21894) to subvert the startup trust chain. Attackers must already have administrator access before executing this exploit, making it a tool for escalating existing compromises rather than initiating breaches. The infection chain begins when the attacker delivers an installer alongside an encrypted companion package. This split design means that without the companion file, incident responders miss key indicators, complicating forensic work.
Once fully installed, components are dropped into both the system partition and the UEFI partition. BlackX installs malicious Machine Owner Keys, allowing attacker-controlled EFI files to be loaded at boot time. A signed—but now revoked—driver is then injected into the Windows kernel. That driver tries to disable critical security auditing via suppressed callbacks and interference with Event Tracing for Windows, reducing visibility into malicious operations.
Payloads & Espionage Tools
BlackX’s observed payloads include a remote access Trojan that can load additional .NET modules and communicate via common cloud services like Google Drive, OneDrive, and Yandex.Disk. These services function as command-and-control channels under the guise of normal network traffic. A second payload, named OxiDLLRunner, uses DLL sideloading: it loads through a legitimate executable, decrypts shellcode in a nearby data file, and runs a Rust binary. From there, the toolkit can pull in extra DLL plugins, each executing in parallel threads for modular expansion of capabilities.
Researchers tie these techniques to observed patterns from APT41 based on shared identifiers in development, code overlaps with past FishMonger operations, similar DLL sideloading methods, and use of OLLVM obfuscation. While these connections underpin a medium-confidence attribution, researchers caution that BlackX may derive either from a leaked or acquired version of BlackLotus—or via reverse-engineering—but these scenarios are speculative.
The Secure Boot Revocation Gap
The attack succeeds even on devices fully updated because revocation of vulnerable certificates wasn’t fully enforced. Components signed under the older Windows Production PCA 2011 root continue to be trusted in many environments. Even though Microsoft issued a certificate expiration notice on October 19, devices using affected binaries still booted normally after expiration. As a result, relying solely on patching isn’t enough—revocation mechanisms must be confirmed operational. But changing revocation policies can risk breaking older boot configurations or recovery media.
Risk indicators include files like C:\ProgramData\Intel\inst.exe and renamed loaders such as googleupdate.exe or jcef_helper.exe. Encrypted payload containers may appear under names such as v8_context_snapshot.bin, with C2 communication domain archives like www.archivetj.com. Other telltale signs are specific development names, DLL plugin exports, and the misuse of legitimate signed drivers that have since been revoked.
What this means: BlackX demonstrates that endpoint protection alone isn’t sufficient when Secure Boot’s trust anchors aren’t maintained or revoked properly. Diplomatic and high-risk sectors remain prey if their bootchains are trusted despite known vulnerabilities. As investigators expand their monitoring, organizations should audit trust paths, validate revocation status, and scrutinize boot and UEFI partitions. Detection is the first step—response must follow swiftly for such stealthy operations.
