BlackX, UEFI bootkit, attacks diplomatic missions from Tajikistan, Uzbekistan and Turkmenistan

In the early weeks of 2026, diplomatic organizations in Central Asia - specifically in Tajikistan, Uzbekistan and Turkmenistan - were attacked with a new UEFI kit to which Kaspersky researchers have baptized as BlackX. According to the technical report published by the Russian firm, the main objective of this malware is to undermine Windows boot defenses and disable or evade third-party security solutions to maintain persistent and covert access to high-value equipment.

The facts confirmed by Kaspersky are as follows: BlackX acts at the UEFI firmware level, installs components in both the system partition and the UEFI partition, explores a known vulnerability in Secure Boot (CVE-2022-21894, the so-called "Baton Drop") and delivers a kernel payload that injects a fraudulently signed driver and a set of user-space payloads dedicated to espionage and remote control. The firm observed specific files used in the installation - for example, an executable installed in C:\ ProgramData\ Intel\ inst.exe and an encrypted file used as a package - and execution procedures with RC4 keys that allow the decompression and writing of disk components.

Technically, BlackX resumes the same technique as BlackLotus bootkit: add keys (MOK, Machine Owner Keys) or load EFI binaries before the operating system starts, so that the malicious code runs with very early privileges and can interfere with Secure Boot and anti-malware mechanisms. The operation of CVE-2022-21894 makes it possible to load unauthorised binaries at that stage. It is important to stress that the operation is not trivial: to deploy a bootkit widely the attacker needs administrative privileges in the machine or physical access to the equipment; therefore, BlackX is used as a mechanism of persistence and evasion after an initial commitment, not as an initial vector, something already indicated by Microsoft when BlackLotus was documented.

What does the code do after loading: the UEFI component installs a kernel driver signed with a certificate belonging to an entity that was later revoked, and attempts to alter the operation of security solutions in the system (with specific routines for Kaspersky and Avast products, which Kaspersky considers ineffective in the analyzed sample). In addition, the package includes user space charges: a remote access Trojan that can download .NET modules and use legitimate cloud synchronization services like Google Drive, OneDrive and Yandex.Disk as control and control channels to camouflage traffic, and a malicious DLL (sideloaded by googleupdate.exe) that runs a Rust binary that contacts a remote domain to receive additional plugins.

Technical attribution is partial and cautious: Kaspersky links the campaign to an actor with methodologies consistent with China-sponsored attacks, and associates BlackX with APT41 based on technical and tactical overlaps and cross-analysis with previous reports. ESET, for its part, has documented families and operations under the umbrella of APT41 (FishMonger / Aquatic Panda) that used backdoors such as SprySOCKS and sometimes UEFI components. These connections are, however, estimates based on indicators and patterns of behaviour: attribution to a state actor remains a forensic inference, not an irrefutable evidence.

Why some systems remain vulnerable even if they are "patched": vulnerability CVE-2022-21894 has a patch, but additional mitigation requires manual steps to add and block certificates in the Secure Boot (DBX) lock list. Kaspersky points out that many administrators did not carry out these manual actions - for example, add the CA used by certain binaries to the prohibited list - and therefore BlackX can remain effective even on machines with applied updates. For details on the protection of the DBX boot and management process, Microsoft maintains reference technical documentation: Microsoft Secure Boot guidance.

Practical consequences: the presence of a bootkit like BlackX in a diplomatic environment means persistent control below the operating system, superior difficulty in detecting intrusion with traditional tools, and real risk of continued espionage (file collection, discrete exfiltration, side movements with compromised credentials). In addition, if malicious binaries are registered in the firmware or MOK keys were added, a simple reinstallation of the operating system does not guarantee mediation; the infection can survive a formatting without intervention at the firmware level.

What is safe and what is not confirmed: it is confirmed that Kaspersky observed the campaign against diplomatic missions in the above-mentioned countries and that the bootkit reuses BlackLotus technique to evade Secure Boot. It is a reasonable estimate, supported by ESET analysis, that actors associated with APT41 are behind, but the complete attribution may contain uncertainties and depends on correlations of indicators and methodologies. It is also publicly unknown whether the original BlackLotus code was purchased or replicated by reverse engineering; both scenarios are plausible and mentioned by experts.

Specific and immediate recommendations for security managers and officials:

1) Audit and implementation of DBX / Forbidden List mitigation: In addition to installing all Windows patches, run the manual steps recommended by Microsoft to manage the list of certificates blocked in Secure Boot and ensure that compromised certificates do not allow the loading of malicious binaries (see Microsoft guide above).

2) Review the integrity of the firmware and UEFI partitions: use forensic and integrity tools such as CHIPSEC (https: / / github.com / chipsec / chipsec) to detect changes in the EFI partition, added keys (MOK) or unexpected binaries at boot.

3) If there is a suspicion of commitment, isolate and forestall before repairing: Ofline disk images, memory overflow, and UEFI partition analysis should precede any reinstallation. In high-risk diplomatic environments consider firmware reflexes by reliable suppliers and complete reinstallation from verified means.

(4) Review privileges and initial access vectors: Since deployment requires high privileges or physical access, investigate how the attackers obtained these privileges (phishing, exposed credentials, service operation, physical access) and apply mitigation: password rotation, multifactor authentication, network segmentation, account review with privileges and physical access control.

5) Monitor outgoing traffic and unusual activities in cloud services: BlackX uses legitimate synchronization services such as C2; audit the use of accounts on Google Drive, OneDrive and Yandex.Disk, and establish control policies and alerts for unusual access.

UEFI-level threats raise the technical link to the response and require high-exposure organisations to rethink their firmware governance processes, patches and confidence lists. To understand the technical context and background of the original BlackLotus vector, it is appropriate to review the ESET analysis published in 2023 on that bootkit: ESET - BlackLotus analysis. For CVE references and technical details of the above vulnerabilities, see the official NVD data sheets: CVE-2022-21894 and CVE-2023-24932.

In short, BlackX is a resurgence and adaptation of a high-impact technique that forces you to put aside surface solutions (just apply the patch) and to take a complete forensic and firmware approach. For diplomatic organizations and other critical institutions, the priority should be to check the integrity of the start-up and to close the vectors that allowed the attacker's initial entry.