A previously undocumented UEFI bootkit called BlackX was used in a campaign targeting diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan, according to Kaspersky. The campaign was identified in early 2026 and publicly disclosed on October 22. Kaspersky assessed with medium confidence that the attackers were linked to APT41.
Key Points
- BlackX targeted diplomatic organizations in three Central Asian countries.
- Attackers used the bootkit after gaining administrator access, to maintain access and avoid detection.
- Systems had received Windows updates, but Secure Boot certificate revocation was not fully applied.
- Kaspersky linked the campaign to APT41 with medium confidence and advised checking Secure Boot protections and monitoring for suspicious activity.
How BlackX works
Kaspersky’s Global Research and Analysis Team (GReAT) said attackers first compromised victim networks and obtained administrator privileges. They then installed BlackX as a persistence and defense-evasion tool, rather than using it to gain initial access. Microsoft has similarly described this type of bootkit as requiring prior privileged access or physical access to a device.
Kaspersky found that BlackX closely resembles BlackLotus, a UEFI bootkit advertised on a cybercrime forum in October 2022 for $5,000. ESET confirmed BlackLotus’s capabilities in March 2023. BlackLotus exploited Baton Drop, tracked as CVE-2022-21894, to bypass Windows Secure Boot. The vulnerability has a CVSS score of 4.4.
Kaspersky found that BlackX uses an exploit implementation similar to BlackLotus. It installs custom Machine Owner Keys, or MOKs, which allow attacker-controlled EFI files to load and let the attackers manipulate the Secure Boot process. Kaspersky said the BlackX developers may have reverse-engineered BlackLotus or bought its source code from cybercriminals, as BlackLotus source code has not been publicly released.
In the observed attacks, the installer was named inst.exe and came with an extensionless, RC4-encrypted file named PVMDIJGKAX2. The command line was C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The final string is the RC4 key used to decrypt the external file, which contains installation files and strings that are not embedded in the installer itself.
The installer writes files to the Windows system partition and the UEFI partition, then exploits Baton Drop to install the custom MOKs. Kaspersky said this separation of the installer and its encrypted resources makes collection and analysis more difficult.
How BlackX Bypasses Secure Boot
The installation and persistence sequence described in Kaspersky’s analysis.
Technical context: BlackLotus is the known predecessor with similar capabilities. Kaspersky said BlackX may have been reverse-engineered from BlackLotus or derived from its source code; this origin remains an assessment, not a confirmed fact.
Payloads and evasion
The UEFI payload injects a malicious driver into the Windows kernel. The driver is signed with a certificate belonging to Wenjiang District Mingyu Network Technology Service Studio. Its issuer had revoked the certificate, which Kaspersky identified by serial number 0bcdf5e0da32d68900b8b7638459d072.
The driver tries to disable process, thread and registry callbacks used by security products, tamper with Event Tracing for Windows providers, and protect BlackX files from inspection. To hide protected files, it intercepts kernel file-opening requests and returns a handle to calc.exe instead of the requested malicious file. Some routines were designed to activate when Kaspersky or Avast products were installed, but Kaspersky’s dynamic analysis found that they did not interfere with Kaspersky products.
Kaspersky observed two user-mode payloads used for cyberespionage. One is a remote-access Trojan that can load additional .NET payloads. It uses Google Drive, Microsoft OneDrive and Yandex.Disk for command-and-control communications, and can collect system information, upload selected files and interpret files on the cloud-storage services according to their suffixes.
The second payload, OxiDLLRunner, is an obfuscated malicious DLL loaded through DLL sideloading by a legitimate executable named googleupdate.exe. The executable’s original filename was jcef_helper.exe, and its MD5 is AF8A983B9ADA07EAE1259BF2953ABD40. OxiDLLRunner decrypts a file named v8_context_snapshot.bin in the same directory and launches its contents, which include shellcode followed by a PE file containing a Rust-based payload.
The Rust payload communicates with www[.]archivetj[.]com. It can receive DLL files that export a function named create_plugin and run those plugins in separate threads, according to Kaspersky.
Why Windows updates were not enough
The targeted systems had received the relevant Windows security updates, but the Baton Drop mitigation had not been fully activated. Kaspersky said the issue was incomplete revocation of the Secure Boot certificate used to sign vulnerable UEFI components, not simply a failure to install Windows patches.
The required revocation concerns the “Windows Production PCA 2011” certificate. Installing the update does not automatically revoke it. Kaspersky said manual activation requires setting a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and creating a scheduled task named Secure-Boot-Update.
Kaspersky said the manual process was designed in part to avoid breaking dual-boot systems that rely on the certificate. Microsoft’s planned “Enforcement Phase” was intended to revoke the certificate automatically without user interaction, but Kaspersky reported that the phase had not been implemented when its report was published. The certificate expired on October 19, 2026, but expiration alone did not prevent vulnerable binaries from loading. It must be explicitly blocklisted through the Secure Boot revocation mechanism.
Microsoft’s deployment guidance calls for updated trust certificates and boot managers to be installed before older trust relationships are revoked. Revocation can affect recovery drives, installation media and network-boot services that still use older signed components.
Attribution and defenses
Kaspersky linked the campaign to APT41 with medium confidence, citing technical overlaps with activity associated with FishMonger, also known as Aquatic Panda and Earth Lusca, as well as patterns it said are common among Chinese-speaking threat actors.
In June 2026, ESET reported FishMonger activity involving a kernel implant with a PDB path beginning C:\Users\xdd\Desktop. Kaspersky found the identifier “xdd” in multiple BlackX payloads and assessed that BlackX could be the UEFI bootkit component referenced in the ESET reporting.
The earlier reporting also described a possible UEFI bootkit component that may have exploited CVE-2023-24932, another Secure Boot bypass vulnerability associated with BlackLotus. Kaspersky additionally cited DLL sideloading, encrypted external resources and OLLVM obfuscation as traits it associated with Chinese-speaking threat actors. These overlaps informed its assessment but did not establish the attribution with high confidence.
Organizations should verify that Secure Boot certificate updates, boot-manager updates and revocation steps have actually been applied, rather than relying on Windows patch status alone. Kaspersky advised checking the status of the Windows Production PCA 2011 revocation and the Secure Boot forbidden-signature database, and auditing for unexpected EFI files, unauthorized MOKs, unfamiliar boot entries, suspicious kernel drivers and changes to system or UEFI partitions.
Defenders should also investigate suspicious administrator activity, review Google Drive, OneDrive and Yandex.Disk activity on sensitive endpoints for unusual file transfers, command traffic or code delivery, and check legitimate programs such as googleupdate.exe for unexpected DLL sideloading. Before broad certificate revocation, organizations should test recovery drives, installation media, dual-boot configurations and network-boot systems for compatibility.
Kaspersky recommended security tools that can block exploitation when a patch is installed but its protection is not fully activated, along with continued monitoring of security alerts.
About the Author
