Kaspersky attributes Central Asia diplomatic compromise to APT41 BlackX bootkit

Kaspersky attributed an early 2026 compromise of diplomatic networks in Tajikistan, Uzbekistan, and Turkmenistan to APT41 with medium confidence, saying intruders used the BlackX UEFI bootkit to persist after gaining administrator privileges, in findings published Oct. 22, 2026.

Kaspersky GReAT analysts said, “In early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia.” That sample, BlackX, is a firmware-level UEFI bootkit, which is malicious code that runs during the boot process before the operating system starts. It bypassed Windows Secure Boot, a security standard that ensures only trusted software loads during startup, on fully patched machines by exploiting CVE-2022-21894, known as Baton Drop. The vulnerability had already drawn multiple security updates from Microsoft because it remained exploitable in 2023.

Researchers compared BlackX to BlackLotus, a criminal UEFI bootkit first advertised on a hacking forum in October 2022 for $5,000. At the time of the advertisement, no BlackLotus samples had been found in the wild, so no one could verify the claims made in the forum post. ESET confirmed BlackLotus could bypass Secure Boot through Baton Drop in March 2023, though its source code was never officially published.

Since the release of those updates, the BlackLotus bootkit has gone quiet, with no publicly known attacks using it. Kaspersky assesses that BlackX is the UEFI bootkit component referenced in ESET’s June 2026 FishMonger report, which included limited indications of an unidentified bootkit component. ESET’s June 2026 FishMonger post suggested the possible use of an unspecified UEFI bootkit component that might exploit CVE – 2023 – 24932.

The compromised computers had installed Microsoft’s security updates, yet the Baton Drop patch did not automatically revoke the vulnerable Windows Production PCA 2011 certificate. Completing the fix required administrators to set a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and run the Secure-Boot-Update scheduled task. These manual activation steps were required after patching, meaning patch installation alone was insufficient. Microsoft’s planned automatic Enforcement Phase, targeted for Q1 2024, had not shipped as of Oct. 22, 2026, so automatic revocation was never deployed.

The vendor had outlined a three-phase Secure Boot rollout, releasing Phase 1 manual activation on May 9, 2023, Phase 2 simplified procedure on July 11, 2023, and targeting Phase 3 Enforcement Phase for Q1 2024. Microsoft built the delivery so enforcement required an opt-in manual action, set Q1 2024 as the target for making it automatic, and had not shipped that step by Oct. 22, 2026. Kaspersky characterized the exposure as structural rather than user error. The documentation for the second step exists on Microsoft’s website, but Kaspersky assessed that it does not surface in a way most system administrators are likely to notice.

Certificate expiry is not the same as active blocklisting. The Windows Production PCA 2011 certificate expired Oct. 19, 2026, but expiry alone does not block vulnerable signed boot components without a DBX blocklist update. Windows and UEFI judge validity from the signing date rather than load time, so code signed before the Oct. 19, 2026 expiry can still pass even though the certificate has expired.

Only an explicit DBX update – the firmware’s Forbidden Signature Database – blocks vulnerable signed boot components after expiry. Microsoft’s Baton Drop update does not revoke the vulnerable certificate automatically out of fear of breaking dual-boot systems that rely on the certificate to load. Kaspersky assessed that the documentation instructions are quite hard for an average IT administrator to notice.

A Windows computer that received the patch but skipped the manual activation step stays exposed, and its administrator has no clear sign that anything is wrong. The resulting exposure is systemic across nominally patched systems.

BlackX persists in the EFI System Partition, a disk partition used to boot the device, or firmware NVRAM, non-volatile memory on the motherboard, meaning it survives operating system reinstallation and hard drive replacement because it loads before Windows starts. Attackers installed custom Machine Owner Keys, which tell the firmware which signatures to trust, into UEFI firmware so the firmware trusts attacker-signed EFI files, after which Secure Boot accepts those files as legitimate and treats malicious boot code as authorized. Kaspersky described UEFI-level persistence as the adversary’s ideal outcome, and BlackX represents confirmed active use of that technique against sitting government diplomatic networks. The campaign moved UEFI bootkits from a theoretical ideal outcome to confirmed real-world use against governments.

The installation chain used two files: inst.exe and an RC4-encrypted, extensionless file named PVMDIJGKAX2. RC4 is an encryption algorithm. Securelist recorded the exact invocation as C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1, where the last argument is the RC4 key used for decryption. The installer itself contained no detectable malicious strings, and static analysis reveals almost nothing because all bootkit components are packed inside the encrypted blob and decrypted at runtime.

The BlackX kernel driver was signed with a certificate issued to Wenjiang District Mingyu Network Technology Service Studio (温江区明宇网络技术服务工作室), serial number 0bcdf5e0da32d68900b8b7638459d072, later revoked by its issuer. The certificate issuer identifies the driver as signed by a Chinese business before revocation.

The driver disables process, thread, and registry callbacks used by security tools and tampers with Event Tracing for Windows providers, effectively blinding endpoint visibility. When security tools request to open BlackX files, the driver intercepts the call and returns a handle to calc.exe instead, hiding the malicious files by redirecting file-access requests to a benign executable. Routines in the driver aimed at Kaspersky and Avast security tools failed against Kaspersky’s self-protection during dynamic analysis, so the anti-security routines were ineffective against Kaspersky products.

The driver differs from the one deployed by BlackLotus, and Kaspersky’s report does not establish a direct continuation between BlackX and BlackLotus or prove how the developers obtained the relevant code or design. Researchers believe APT41 actors built BlackX as a copycat after reverse-engineering BlackLotus or purchasing its source code, though Kaspersky frames this as a researcher assessment rather than confirmed history. The patch gap motivated the actor to invest time in understanding how BlackLotus works and creating a copycat of this bootkit.

After the bootkit gains a foothold, the first payload is a remote access trojan that executes secondary .NET modules and communicates through Google Drive, OneDrive, and Yandex.Disk, parsing cloud files by suffix to separate commands from exfiltrated data. Workers routinely reach Google and Microsoft cloud services from corporate networks, and those links seldom set off network-level alerts, letting command-and-control traffic hide among normal cloud storage use. Both command receipt and data theft use legitimate cloud storage services. The RAT polls these platforms and exfiltrates stolen information through the same channels, supporting functions such as receiving .NET tasks, returning command results, uploading and downloading files, and sending initial system information.

The second-stage component is OxiDLLRunner, an OLLVM-obfuscated DLL sideloaded through googleupdate.exe, which was originally jcef_helper.exe with MD5 AF8A983B9ADA07EAE1259BF2953ABD40. OxiDLLRunner decrypts v8_context_snapshot.bin and runs a Rust-based payload contacting www[.]archivetj[.]com. Researchers describe OLLVM as an open-source compiler-based obfuscation framework with documented prevalence in Chinese-nexus APT tooling, and the obfuscation choice aligns with tradecraft associated with Chinese-nexus actors. The payload fetches multi-threaded plugins from the command domain, receiving DLL files that export a function named create_plugin and executing them in separate threads for in-memory execution.

Kaspersky’s attribution of the campaign to APT41 rests on multiple indicators carried with medium confidence. The identifier xdd appears multiple times in BlackX payloads and matches a FishMonger kernel implant that ESET described in June 2026, including a debug path of C:\Users\xdd\Desktop. Kaspersky researchers Georgy Kucherin and Vladimir Nestor wrote that while the vulnerability exploitation chain was implemented very similarly to BlackLotus, they spotted differences between the exploits. Kaspersky stated, “We observed the identifier xdd used multiple times in the BlackX bootkit payloads, so we assess that BlackX is the UEFI bootkit referenced in the ESET blog post.”

FishMonger is connected to the Chinese contractor I-SOON and is widely believed by the security community to operate under APT41’s umbrella, which Kaspersky uses as part of the APT41 attribution chain. Kaspersky also cites the recurrence of DLL-sideloading across documented Chinese-speaking APT operations as a second attribution indicator, and the specific alignment of OLLVM obfuscation with Chinese-nexus tradecraft as a third. However, Kaspersky’s attribution is an assessment, not a confirmed identification of the operators, and these attribution points support a working hypothesis but do not independently prove APT41 responsibility.

APT41 has been active since at least 2012 and blends state-directed espionage with financially motivated cybercrime under one umbrella. The U.S. Department of Justice indicted seven APT41 members in September 2020, covering attacks spanning more than 100 organizations across multiple countries, including cryptocurrency theft and COVID-19 relief fraud, and citing both espionage and financially motivated charges. Five indicted Chinese nationals have not been extradited because the Chinese government does not extradite its own nationals, leaving all five at large. Kaspersky had previously attributed the MoonBounce UEFI bootkit to APT41 in January 2022, calling it the third confirmed UEFI bootkit found in the wild.

BlackX is a late-stage persistence tool, not the initial intrusion vector, meaning attackers only deploy it after already holding administrator-level access in the target network. The initial access method, the compromised accounts, and the exact route used to move through the networks remain unconfirmed. The report also does not quantify how frequently each cloud service or RAT function was used, and public reporting stops short of naming the people or organization behind the infrastructure. Kaspersky urges organizations to monitor security alerts, and its Exploit Prevention component can stop exploits even when a patch is missing or unapplied.

For organizations with high-threat profiles, particularly in government, diplomatic, and critical infrastructure sectors, Kaspersky recommends pairing patch verification with endpoint security solutions that include dedicated UEFI firmware scanning capability. Daily CyberSecurity advises blocking www.archivetj.com and watching for suspicious inst.exe executions or unusual Google Drive and OneDrive traffic on endpoints. The Baton Drop gap resembles the ToolShell SharePoint vulnerability from 2025, which also required a manual activation step following initial patching. With the automatic Enforcement Phase still undelivered as of Oct. 22, 2026, administrators must manually complete the revocation step to close the gap that BlackX exploited against Central Asian diplomatic agencies in early 2026.