A cybercriminal advertised a UEFI bootkit, dubbed BlackLotus, that could bypass Secure Boot, for $5,000 — a claim Kaspersky and others later tied to real tooling and to a new variant discovered in early 2026.
BlackX: a revived UEFI bootkit deployed against Central Asian diplomatic targets
In early 2026 Kaspersky identified a complex APT campaign that used a UEFI bootkit the researchers named BlackX to target diplomatic agencies in Tajikistan, Uzbekistan, and Turkmenistan. BlackX closely resembles the earlier BlackLotus bootkit, which ESET had confirmed in March 2023 as exploiting the Baton Drop vulnerability (CVE‑2022‑21894). Attackers deployed BlackX only after obtaining administrator privileges on compromised networks and used an installer package designed to hide payload components from responders.
How the install works and why the exploit succeeded
Operators dropped three main artifacts to install BlackX: an installer executable named inst.exe, an encrypted blob named PVMDIJGKAX2, and used an RC4 key provided on the installer command line. The installer was launched as:
C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1
PVMDIJGKAX2 contained the files and strings needed for installation; inst.exe itself contained no malicious strings or embedded blobs, making traditional artifact hunting harder. The package wrote files to both system and UEFI partitions and implemented an exploitation chain designed to install custom Machine Owner Keys (MOK) so arbitrary EFI files could be loaded under Secure Boot — mirroring BlackLotus’s objective and reusing implementation patterns from the earlier bootkit.
Crucially, the infected systems Kaspersky analysed were fully patched for Baton Drop, but the patch required manual activation to revoke the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI binaries. The manual steps are: set a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and create a scheduled task named Secure-Boot-Update. Microsoft’s published rollout plan describes a future “Enforcement Phase” to revoke the certificate automatically; as of Kaspersky’s publication that enforcement had not been implemented. The certificate expired on October 19, 2026, but expiration alone does not prevent vulnerable binaries from loading unless the certificate is blocklisted.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coveragePayloads delivered from UEFI to kernel and user space
The UEFI payload’s immediate goal was to inject a malicious kernel driver. That driver — signed with a certificate issued to 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio), serial number 0bcdf5e0da32d68900b8b7638459d072 — has been revoked by its issuer. The driver attempted multiple anti‑security measures: disabling process, thread, and registry callbacks tied to security solutions, tampering with Event Tracing for Windows (ETW) providers, and protecting its files by intercepting kernel file-open requests and returning a handle to calc.exe instead of the malicious file. Kaspersky observed driver code paths intended to run only if Kaspersky or Avast products were present; during dynamic analysis these routines failed to affect Kaspersky products.
Two user‑mode espionage payload patterns were observed. One was a RAT that can load further .NET tasks and uses cloud storage for C2 — Kaspersky saw versions using Google Drive, OneDrive, and Yandex.Disk. The RAT iterates over files and interprets them by suffix: 0X01 (.NET task to run TEST.Class1.RunCMD), 0X02 (output), 0X03 (upload task), 0X04 (uploaded file), 0X05 (download task), 0X06 (download status), and SSSR (initial system info).
The second payload, dubbed OxiDLLRunner, is an OLLVM‑obfuscated DLL loaded via the legitimate googleupdate.exe (original filename jcef_helper.exe, MD5 AF8A983B9ADA07EAE1259BF2953ABD40) delivered by the bootkit. The DLL decrypts v8_context_snapshot.bin to reveal shellcode followed by a Rust PE that communicates with www[.]archivetj[.]com and fetches DLLs exporting a create_plugin function, which are then launched in separate threads.
Attribution: evidence linking BlackX to APT41 with medium confidence
- ESET published a June 2026 post on attacks by the FishMonger actor (community‑linked to APT41) describing a kernel implant with a PDB path beginning C:\Users\xdd\Desktop and suggesting an unspecified UEFI bootkit may have been used.
- Kaspersky observed the identifier “xdd” used repeatedly in BlackX payloads, aligning with the ESET finding and suggesting BlackX could be the bootkit ESET referenced.
- The operator pattern — payloads loaded via legitimate executables abused for DLL sideloading combined with encrypted payload blobs — is noted in the report as common among Chinese‑speaking actors; OLLVM obfuscation in OxiDLLRunner is another tactic Kaspersky associates with that grouping.
On that basis Kaspersky assigns a medium confidence attribution to APT41 for the BlackX campaign.
What this means for diplomatic agencies, system administrators, and security teams
- Diplomatic agencies: systems used in diplomatic missions in Tajikistan, Uzbekistan, and Turkmenistan were the observed targets; agencies should assume UEFI‑level persistence is possible where manual patch activation was not performed.
- System administrators: installing vendor updates may not be sufficient if vendor guidance requires manual follow‑up actions (for Baton Drop, setting a registry flag and creating Secure-Boot-Update). Administrators should verify certificate blocklisting and scheduled task presence beyond mere patch count.
- Security teams: layers of detection and response must account for firmware‑level implants that can protect their files and tamper with kernel callbacks and ETW. Observables include the specific filenames and blobs Kaspersky documented (inst.exe, PVMDIJGKAX2, v8_context_snapshot.bin) and C2 infrastructure such as www[.]archivetj[.]com.
The BlackX campaign underscores a practical problem: a patch can exist without delivering full protection unless administrators perform vendor‑specified activation steps. Kaspersky’s analysis suggests the attackers anticipated that shortfall and adapted BlackLotus techniques into BlackX to exploit it. Whether the planned automatic “Enforcement Phase” for Baton Drop will arrive, and whether certificate blocklisting will outpace similar reuse, are the immediate operational questions the affected organisations will need answered.
