BlackX UEFI Bootkit Targets Central Asian Diplomats

Kaspersky researchers have identified a UEFI bootkit they call BlackX in a campaign against diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan. The campaign is technically significant because it uses the Baton Drop vulnerability, tracked as CVE-2022-21894, to interfere with the UEFI boot process and maintain control below the Windows operating-system layer.

According to Kaspersky’s Securelist report, the activity was observed in early 2026 after attackers had already compromised victim networks and obtained administrator privileges. The researchers attribute the operation to APT41 with medium confidence. That attribution is an assessment, not a confirmed identification of the operators. Kaspersky also found implementation similarities to the BlackLotus bootkit, but the report does not establish that BlackX is a direct continuation of BlackLotus or prove how its developers obtained the relevant code or design.

Why the bootkit matters

UEFI bootkits operate before Windows starts. That position can give malware an opportunity to influence the operating-system launch process, load code into the Windows kernel, and interfere with security tooling that normally monitors activity inside the operating system. BlackX uses this model to deliver a malicious driver and subsequent user-mode payloads.

The campaign also demonstrates why installing a security update does not always complete the remediation process. Kaspersky found that the affected systems were fully patched for the Baton Drop vulnerability, but the protection was not fully active because a required certificate-revocation step had not been triggered. This distinction is important for administrators responsible for firmware security, Windows update governance, and Secure Boot controls.

Reported attack sequence

Kaspersky states that the attackers deployed BlackX after gaining access to victim networks and acquiring administrator privileges. The supplied research does not identify the initial access method, the compromised accounts, or the exact route used to move through the networks. Those elements therefore remain unconfirmed.

For installation, the researchers observed an executable named inst.exe and an extensionless file named PVMDIJGKAX2. The second file contained the material required to install the bootkit and was protected with RC4 encryption. The installer was observed with a command line containing the encrypted file and a decryption key. Because the malicious components were stored in the package rather than embedded directly in the installer, investigators may have less content to recover from the executable alone.

The installer placed files in both Windows and UEFI-related locations and used an implementation of Baton Drop that Kaspersky described as notably similar to the mechanism used by BlackLotus. The objective was to install custom Machine Owner Keys, or MOKs. These keys can allow arbitrary EFI files to load and can therefore be used to undermine Secure Boot protections.

Kaspersky identified differences between the BlackX and BlackLotus implementations. Since BlackLotus source code has not been publicly released, the researchers assess that BlackX’s operators may have reverse-engineered the earlier bootkit or obtained its source code from cybercriminals. This is a researcher assessment rather than a confirmed history of the malware.

Kernel-level interference and persistence

Once the UEFI component is active, BlackX launches a driver into the Windows kernel. Kaspersky reports that this driver is different from the driver used by BlackLotus and was signed with a certificate associated with Wenjiang District Mingyu Network Technology Service Studio. The report says the certificate, identified by serial number 0bcdf5e0da32d68900b8b7638459d072, had been revoked by its issuer at the time of publication.

The driver is designed to weaken security visibility. Kaspersky observed it disabling process, thread, and registry callbacks associated with security products and altering Event Tracing for Windows providers so that security software cannot access their output normally. Some routines specifically attempted to act when Kaspersky or Avast products were installed. During dynamic analysis, however, Kaspersky found those procedures ineffective against Kaspersky products.

The driver also protects BlackX files from inspection or removal. When the kernel receives requests to open those files, the driver can return a handle to calc.exe instead of a handle to the requested malicious file. This behavior can mislead tools or responders that rely on ordinary file-access results.

Second-stage payloads and command and control

Kaspersky observed two user-mode payloads delivered through the bootkit. One is a remote-access trojan capable of loading additional .NET payloads. Rather than relying on a conventional dedicated command server, observed versions communicated through cloud-storage services including Google Drive, OneDrive, and Yandex.Disk.

The RAT examined files stored in the connected service and interpreted them according to suffixes. The reported functions included receiving .NET tasks, returning command results, uploading files, downloading files to the infected machine, and sending initial system information. This arrangement can blend command traffic with legitimate cloud-service activity, although the report does not quantify how frequently each service or function was used.

The second payload, named OxiDLLRunner by Kaspersky, is an obfuscated malicious DLL. It is loaded through a legitimate executable delivered by the bootkit. The executable is identified in the report as googleupdate.exe, with the original filename jcef_helper.exe and MD5 hash AF8A983B9ADA07EAE1259BF2953ABD40. A neighboring file named v8_context_snapshot.bin contains encrypted content that the DLL decrypts and executes.

The decrypted content begins with shellcode and includes a Rust-based payload. Kaspersky reports that this payload communicates with www[.]archivetj[.]com and is designed to receive DLLs exporting a function named create_plugin. Those DLLs are then executed in separate threads. The domain is defanged here and should be treated as a non-clickable indicator.

Attribution and targeting assessment

Kaspersky’s medium-confidence APT41 assessment rests on several observations. The researchers connected BlackX to a kernel implant discussed by ESET in reporting on FishMonger activity, noting a recurring xdd identifier and a possible UEFI bootkit component. They also cited the use of a legitimate executable for DLL sideloading alongside an encrypted file, a pattern Kaspersky describes as common among Chinese-speaking threat actors, and the use of OLLVM obfuscation.

These points support a working attribution hypothesis, but they do not independently prove APT41 responsibility. The report does not identify individual operators, a specific organization responsible for the infrastructure, or the initial access technique. The confirmed scope described by Kaspersky is the targeting of diplomatic agencies in the three named Central Asian countries.

The patching gap behind the exposure

Kaspersky initially considered whether the affected machines lacked updates. Its investigation instead found that the systems were patched, but the relevant mitigation had not been activated fully. Microsoft’s protection for Baton Drop depends on revoking the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. According to Kaspersky, installing the update does not automatically perform that revocation.

The report says administrators must set a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and create a scheduled task named Secure-Boot-Update. Kaspersky explains that this manual model was intended to avoid disrupting dual-boot systems that rely on the certificate. The researchers assess that the instructions are easy for administrators to miss and note that the planned automatic enforcement phase had not been implemented when they published their findings.

The practical lesson is that update compliance reports may not be sufficient evidence that a boot-chain vulnerability is mitigated. Organizations need to verify the state of the certificate blocklist and the related Secure Boot configuration directly.

What organizations should do now

• Validate the complete Baton Drop remediation. Confirm not only that relevant Windows updates are installed, but also that the required certificate-revocation process has been activated on supported systems. Review the registry and scheduled-task state through approved administrative tooling and document exceptions, including systems with dual-boot requirements.
• Audit Secure Boot and UEFI trust configuration. Record Secure Boot state, authorized MOKs, firmware settings, and unexpected EFI files. Investigate changes that do not match the organization’s approved build and change-management records.
• Monitor boot and kernel telemetry. Look for unexpected UEFI changes, new or unusual kernel drivers, certificate anomalies, attempts to interfere with process or registry callbacks, and gaps in ETW visibility. A sudden loss of expected security telemetry should be treated as an investigation trigger.
• Hunt for the reported artifacts carefully. Review for inst.exe, PVMDIJGKAX2, googleupdate.exe, jcef_helper.exe, and v8_context_snapshot.bin, while recognizing that filenames alone are not proof of compromise. The reported MD5 and defanged domain can support searches, but should be combined with parent-process, file-location, signing, and boot-integrity evidence.
• Examine cloud-storage activity. Investigate unexplained access from servers or workstations to Google Drive, OneDrive, or Yandex.Disk, especially when associated with unusual file transfers, command-like content, or newly installed .NET assemblies. Do not block legitimate services indiscriminately; apply identity, device, and application context.
• Prepare for boot-level incident response. If BlackX is suspected, isolate the host using procedures that preserve forensic evidence, involve firmware and endpoint specialists, and avoid relying solely on Windows file deletion. Validate UEFI and Secure Boot state, review trusted keys, and rebuild affected systems according to a trusted organizational process when integrity cannot be established.
• Use layered prevention. Maintain endpoint protection, exploit-prevention controls, privileged-access restrictions, and centralized monitoring. Kaspersky’s findings show why a patch-management program should verify effective control activation rather than treating installation status as the final security outcome.

Conclusion

BlackX illustrates how a threat actor can combine a UEFI bootkit, kernel-level tampering, DLL sideloading, encrypted payloads, and cloud-storage communications into a resilient espionage platform. Kaspersky confirmed the presence of the bootkit in a campaign targeting Central Asian diplomatic organizations and assessed an APT41 connection with medium confidence. For defenders, the most immediate concern is broader than one malware family: Secure Boot protections depend on the actual state of firmware trust and certificate revocation, not simply on whether a Windows update appears in an inventory report.

Sources

Securelist: “How APT41 revived the BlackLotus bootkit to attack diplomatic organizations in Central Asia”. Technical findings in this analysis are attributed to Kaspersky researchers through that report.