APT41 Adopts BlackLotus Techniques: BlackX UEFI Bootkit Hits Central Asian Diplomats

According to Kaspersky GReAT analysis, the sole available source, APT41 used the BlackX UEFI bootkit against diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan in Q1 2026. Attribution to APT41 rests on Kaspersky's proprietary operational patterns with "medium confidence." BlackX exploits a vulnerability not assigned a standard CVE, dubbed Baton Drop in the report, to compromise Secure Boot. The bootkit installs a kernel driver signed with a revoked certificate and maintains persistence through a user-mode RAT that communicates via public cloud storage.

How BlackX Bypasses Secure Boot via Baton Drop

BlackX's entry mechanism into UEFI firmware passes through the Baton Drop vulnerability. The bootkit installs custom Machine Owner Keys (MOK) in the firmware database, allowing arbitrary EFI images to load without Secure Boot integrity checks blocking them. The implementation is "remarkably similar" to that observed in BlackLotus, with differences indicating reverse-engineering or acquisition rather than an identical copy.

The BlackLotus source code has never been published online. According to Kaspersky GReAT, "the source code of the BlackLotus bootkit has never been published online." The high technical similarity between the two bootkits implies APT41 operators accessed the original code through purchase or decompilation, not public release.

The Signed Driver and Ineffective Anti-Security Routines

BlackX loads a malicious kernel driver signed with a legitimate certificate belonging to Wenjiang District Mingyu Network Technology Service Studio. The certificate serial number is 0bcdf5e0da32d68900b8b7638459d072; the source confirms the certificate was already revoked at the time of the analysis publication. The method of certificate acquisition is not specified by the source.

The driver implements anti-analysis techniques targeting security solutions on the system. It disables process, thread, and registry callbacks by intercepting security component registrations. It also manipulates ETW (Event Tracing for Windows) providers to reduce visibility of malicious actions. Some routines include code specific to Kaspersky and Avast, but direct dynamic analysis demonstrated that "these procedures are useless—they fail to interfere with Kaspersky products in any way." The driver protects bootkit files by intercepting kernel requests and returning handles to calc.exe, rendering components invisible to direct filesystem reads.

Persistence and the Cloud Storage C2 Channel

After the boot phase, BlackX deploys a user-mode RAT that loads .NET payloads. The command-and-control communication mechanism leverages public cloud storage services: the source observed the use of Google Drive, OneDrive, and Yandex.Disk. The RAT interprets files on the storage based on a numeric suffix in the filename: 0X01 triggers execution of the TEST.Class1.RunCMD method, 0X02 collects results.

The source does not specify whether the use of three distinct cloud services introduces tactical redundancy or complicates perimeter blocking. It also does not describe whether traffic to these platforms blends with ordinary traffic on target networks.

"we rarely see APT actors borrow ideas or code from cybercrime actors" — Kaspersky GReAT (Securelist)

Why This Matters

APT41's adoption of techniques developed for the BlackLotus crimeware fractures the traditional separation between state-sponsored actors and criminal operators. According to the direct source quote above, this dynamic is rare: APT groups tend to develop proprietary tools or inherit infrastructure from other state operations, not retrieve code from the criminal market.

The UEFI bootkit represents a threat class with extremely limited visibility. Traditional security tools operate at the OS level; a firmware compromise precedes any runtime control. Persistence extends beyond disk reformatting and OS reinstallation. The compromise of Secure Boot, an architectural pillar of trust in the Windows boot chain, erodes an assumption many organizations still consider solid.

What We Know and What We Don't

What to Do Now

Standard UEFI Mitigation Measures (not specific to the documented threat):

• Verify MOK (Machine Owner Keys) database integrity on systems with diplomatic or government assets in the indicated geographic areas
• Confirm certificate revocation checks are active and correctly applied
• Monitor traffic to public cloud storage services as an anomalous indicator on high-risk-profile systems
• Evaluate UEFI firmware scanning as part of incident response procedures on suspect systems

These recommendations represent standard UEFI security measures; the source provides no operational guidance specific to the BlackX threat.

Editorial Close

The BlackX case illustrates a convergence between criminal tools and state operations that Kaspersky GReAT describes as rare. The technical similarity to BlackLotus, whose source code was never public, raises questions about how the original bootkit was accessed. At the same time, the APT41 attribution with "medium confidence" and the lack of independent sources demand caution in assessing the overall picture. The Kaspersky report remains, for now, the sole available source on this campaign.

Sources

• securelist.com