Chinese Hackers Breached Diplomatic Networks; Microsoft Baton Drop Enforcement Never Deployed

A Chinese state-linked hacking group deployed an evolved version of the most dangerous firmware-level malware ever seen in the wild against diplomatic agencies in three Central Asian countries — and it worked because a Microsoft security patch, installed on all the targeted machines, had never been fully activated . Researchers from Kaspersky's Global Research and Analysis Team (GReAT) published their findings on October 22, attributing the campaign to APT41 — the prolific Chinese threat actor also known as Winnti and Double Dragon — with medium confidence. The new implant, named BlackX, targeted diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan.

The disclosure raises a question that matters beyond Central Asia: how many Windows machines worldwide are sitting in a state their administrators believe is patched but, in practice, is not?

BlackX: Criminal Bootkit Weaponized for State Espionage

The story starts in October 2022, when an unknown cybercriminal began advertising a UEFI bootkit called BlackLotus on a hacking forum for $5,000 . The cybersecurity community was skeptical — that price seemed implausibly low for firmware-level malware capable of defeating Windows security. Within months, Slovak security firm ESET confirmed BlackLotus was real, and that it could bypass Secure Boot on fully updated Windows 11 machines by exploiting a vulnerability known as "Baton Drop" — formally CVE-2022-21894. Microsoft issued patches in mid-2023. BlackLotus went quiet.

APT41 had taken note.

"In early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia," Kaspersky GReAT analysts wrote . Their analysis found that BlackX exploits the same CVE-2022-21894 vulnerability, uses an installation chain "remarkably similar" to BlackLotus's, and suggests APT41 either reverse-engineered the criminal tool from its public artifacts or obtained its source code through underground channels. The original BlackLotus source code was never officially published, though a stripped version appeared on GitHub in 2023. "This is an interesting observation," Kaspersky's team wrote, "as we rarely see APT actors borrow ideas or code from cybercrime actors."

APT41 is not new to firmware malware. In January 2022, Kaspersky attributed the MoonBounce APT41 firmware bootkit — then only the third confirmed UEFI bootkit ever found in the wild — to the same group. The U.S. Department of Justice indicted seven APT41 members in September 2020 on charges spanning attacks against more than 100 organizations across multiple countries. Five of those indicted are Chinese nationals who have not been extradited.

What Is UEFI Bootkit Malware, and Why Can't Antivirus Remove It?

UEFI — Unified Extensible Firmware Interface — is the firmware layer that initializes computer hardware before the operating system begins loading. The UEFI Forum specification sets the standards governing how this firmware layer interacts with operating systems and boot components across modern computing platforms. A bootkit that embeds itself at this level runs before Windows, before its security tools, and before any logging infrastructure can record it.

The practical consequence: once a UEFI bootkit is installed, it survives OS reinstallation and hard drive replacement, because it does not live on the operating-system drive. It resides in the EFI System Partition or in firmware NVRAM — below the reach of conventional antivirus. Security researchers have long described UEFI-level persistence as the adversary's "ideal outcome." BlackX confirmed active use of that capability against sitting government diplomatic networks.

How BlackX Breaches Fully Updated Windows Machines

Attackers deploy BlackX only after gaining administrator-level access to a target network — it is a late-stage persistence tool, not the initial intrusion vector. The installation chain is carefully designed for forensic evasion .

Two files are dropped: an installer executable ( inst.exe ) and an RC4-encrypted payload ( PVMDIJGKAX2 ). The installer contains no detectable malicious strings on its own; all bootkit components are packed inside the encrypted blob and decrypted at runtime using a key passed as a command-line argument. This design means static analysis of the installer alone reveals almost nothing.

Once running, the installer exploits CVE-2022-21894 to install custom Machine Owner Keys (MOK) into the UEFI firmware — effectively telling the firmware to trust the attacker's EFI files. Secure Boot, which is supposed to block unauthorized boot code, accepts them as legitimate.

Kernel Driver Bearing Chinese Business Certificate

The UEFI payload's primary goal is loading a malicious kernel driver into Windows. That driver bore a digital certificate issued to 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio), a Chinese business entity, as detailed in Kaspersky's BlackX driver analysis. The certificate has since been revoked.

Once running in the Windows kernel, the driver disables process, thread, and registry callbacks that endpoint detection and response (EDR) tools and antivirus products depend on for visibility. It also tampers with Event Tracing for Windows (ETW) — the telemetry pipeline security products use to observe system behavior. Kaspersky noted that specific ETW-tampering routines targeted its own product and Avast; dynamic analysis confirmed these routines failed against Kaspersky's self-protection mechanisms.

The driver protects BlackX's own files through a kernel-level misdirection: when Windows receives a request to open a BlackX file on disk, the driver intercepts the call and returns a handle to the Windows Calculator ( calc.exe ) instead, making the file appear harmless to any inspection tool.

Cloud Storage as Command Post: How BlackX Hides in Enterprise Network Traffic

The kernel driver loads two distinct user-mode espionage payloads.

The first is a Remote Access Trojan (RAT) that routes all command-and-control traffic through Google Drive, OneDrive, Yandex.Disk. It polls these cloud platforms, parses files by suffix to identify commands versus data, and exfiltrates stolen information through the same channels. Connections to Google and Microsoft cloud services are routine in enterprise environments and rarely trigger network-level alerts — making this an effective way to blend espionage traffic into normal business activity.

The second payload, which Kaspersky calls OxiDLLRunner, is a malicious DLL obfuscated using OLLVM, an open-source compiler-based obfuscation framework with documented Chinese-nexus APT tooling prevalence. It loads via DLL sideloading: a legitimate executable — a renamed version of jcef_helper.exe disguised as googleupdate.exe — loads the malicious DLL as if it were a trusted component. OxiDLLRunner then decrypts and executes a Rust-based payload communicating with the command-and-control domain www[.]archivetj[.]com , from which it receives additional modules to execute in memory.

Three Overlapping Clues Tie BlackX to APT41, China's Premier Spy Group

Kaspersky assigned BlackX to APT41 at medium confidence based on three converging indicators.

First, in June 2026, ESET published ESET's FishMonger APT41 research on FishMonger — a threat actor widely believed by the security community to operate under APT41's umbrella, connected to the Chinese contractor I-SOON — describing a kernel implant whose debug path contained the identifier "xdd". That same ESET report included limited indications of a UEFI bootkit component. Kaspersky found "xdd" appearing multiple times within BlackX's payloads and concluded BlackX is the UEFI component ESET identified in its earlier publication.

Second, the DLL-sideloading pattern — abusing a legitimate executable to load an encrypted payload — recurs across documented Chinese-speaking APT operations. Third, OLLVM obfuscation aligns specifically with Chinese-nexus tradecraft, where the framework has been consistently adopted.

APT41, active since at least 2012, is distinctive for combining state-directed espionage with financially motivated cybercrime, as documented in the MITRE ATT&CK APT41 profile . The 2020 APT41 federal indictment cited cryptocurrency theft and COVID-19 pandemic relief fraud alongside government-directed intelligence collection.

Microsoft Never Deployed Promised Auto-Enforcement of Baton Drop Patch

The most consequential finding in Kaspersky's report is not the malware itself — it is the patch.

The machines BlackX compromised had installed the relevant Microsoft security updates. The problem was structural.

Microsoft's patch for CVE-2022-21894 works by revoking the "Windows Production PCA 2011" certificate used to sign vulnerable UEFI boot components, adding it to the DBX — the firmware's Forbidden Signature Database. This process is documented in Microsoft CVE-2022-21894 security guidance . This revocation does not happen automatically when an administrator applies the patch. Instead, completing the protection requires manually setting a specific Windows registry flag and allowing a related scheduled task to finish the blocklisting process. Microsoft documents this second step, but Kaspersky's assessment was that the documentation does not surface it in a way most system administrators are likely to notice.

Microsoft outlined a three-phase Secure Boot rollout for the fix: Phase 1 (manual activation, released May 9, 2023), Phase 2 (a simplified procedure, released July 11, 2023), and Phase 3 — an "Enforcement Phase" that would activate the revocation automatically without any administrator intervention. Microsoft targeted Q1 2024 for the Enforcement Phase. As of Kaspersky's October 22 findings , it had not shipped.

A related timing issue adds confusion without resolving it. The "Windows Production PCA 2011" certificate expired on October 19, 2026 — three days before Kaspersky's report. Certificate expiry, however, is not the same as active blocklisting. Because Windows and UEFI firmware evaluate a certificate's validity at the time a binary was signed — not at the time it loads — vulnerable signed boot components can still execute after the signing certificate expires. Only an explicit DBX update blocks them.

Kaspersky drew a parallel to the ToolShell SharePoint vulnerability from 2025; Kaspersky's ToolShell parallel observation noted that vulnerability also required a manual activation step following initial patching. "It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch," the team wrote.

This is not a user-error problem. Microsoft designed a patch delivery architecture that placed the critical enforcement step in an opt-in manual action, announced a date to make it automatic, and quietly missed that date. The resulting exposure is systemic: every Windows machine on which the patch was applied without the underpublicized second step remains vulnerable in a state its administrator has no obvious reason to question.

To verify whether Baton Drop enforcement is active: consult Microsoft's DBX registry procedure for the specific registry key and scheduled task that complete the DBX update. Organizations with high-threat profiles — particularly in government, diplomatic, and critical infrastructure sectors — should pair patch verification with endpoint security solutions that include dedicated UEFI firmware scanning capability.

Frequently Asked Questions

What is a UEFI bootkit, and why does reinstalling Windows not remove it?

UEFI (Unified Extensible Firmware Interface) is the firmware layer that runs before the operating system starts, initializing hardware and determining what software can load. A bootkit embedded at this level does not reside on the operating-system drive — it lives in the EFI System Partition or in the firmware's own NVRAM. Reinstalling Windows replaces the OS but leaves the firmware layer untouched. Hard drive replacement is similarly ineffective for the same reason. Because the malicious code executes before any security tool has a chance to load, it can also disable or blind those tools before they initialize. Removing a UEFI bootkit typically requires either specialized firmware scanning software or, in severe cases, reflashing the affected device's firmware from a trusted source.

How do I know if my Windows machine has Baton Drop patch enforcement activated?

Applying the Microsoft security update for CVE-2022-21894 is not sufficient by itself. Completing the protection requires a second manual step: setting a specific Windows registry flag and allowing a related scheduled task to run, as documented in the DBX blocklist verification steps. This updates the firmware's Forbidden Signature Database (DBX) to actively block the vulnerable "Windows Production PCA 2011" signed boot components. Security teams can also use firmware audit utilities — including those provided by endpoint security vendors and independent UEFI analysis tools — to inspect the DBX contents and confirm whether the relevant certificate has been added to the blocklist.

Is APT41 directly linked to Chinese government intelligence services?

U.S. government assessments and security firm attribution both describe APT41 as operating with direction from China's Ministry of State Security, a conclusion supported by DOJ APT41 indictment evidence . The 2020 DOJ indictment charged five Chinese nationals — identified as contractors for a company with ties to Chinese state security — alongside two Malaysian nationals who helped with financial operations. The Chinese government does not extradite its own nationals; all five Chinese individuals named in the indictment remain at large. APT41 is unusual among nation-state hacking groups in running both government-directed espionage campaigns and independent financially motivated cybercrime operations under the same organizational umbrella.

Did the expiry of the "Windows Production PCA 2011" certificate on October 19, 2026 close the Baton Drop vulnerability?

No. Certificate expiry and active blocklisting are different security mechanisms that achieve different things. A certificate that has expired can still validate the digital signatures on software binaries that were signed while it was valid, because Windows and UEFI firmware use a timestamping mechanism to evaluate signature validity at the moment of signing rather than at the moment of loading. Vulnerable UEFI boot components signed by the "Windows Production PCA 2011" certificate before it expired can therefore still load on unprotected systems. What actually stops them is an update to the DBX — the firmware's Forbidden Signature Database — that explicitly marks those components as forbidden regardless of their signature. That DBX update is the step Microsoft's Enforcement Phase was supposed to automate, and which has not yet been deployed as of Kaspersky's October 22 report.