Kaspersky Says APT41 Revived the BlackLotus Bootkit to Infect Fully Patched Diplomatic Machines in Central Asia, Because the Baton Drop Fix Does Nothing Until Administrators Switch It On

NEW YORK - The machines were fully patched, and the bootkit got on them anyway. Kaspersky said on Thursday that a hacking group it links to APT41 planted a copy of the BlackLotus UEFI bootkit on computers at diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan by exploiting Baton Drop, a Secure Boot flaw that Microsoft patched in 2023.

The fix was installed. What was missing, Kaspersky researchers Georgy Kucherin, Vladimir Nestor and Vasily Berdnikov wrote, was a second, manual step that revokes the certificate the exploit relies on. "Our investigation proved this wrong," they wrote of their first assumption that the victims had skipped updates. "The targeted machines were fully patched."

A cybercrime bootkit in an espionage campaign

BlackLotus first surfaced in October 2022 as a $5,000 listing on a hacking forum that promised a Windows bootkit able to bypass Secure Boot. ESET confirmed in March 2023 that it was real and that it abused Baton Drop, tracked as CVE-2022-21894. Since Microsoft's updates, no publicly known attacks have used it, Kaspersky said.

In early 2026, Kaspersky found a close relative it named BlackX. The attackers installed it only after they had already compromised the victims' networks and obtained administrator rights, dropping an installer at C:\ProgramData\Intel\inst.exe alongside an RC4-encrypted, extensionless file named PVMDIJGKAX2 that held everything the installer needed. The decryption key was passed on the command line, so the installer itself carried no malicious strings, which the researchers said makes it harder for incident responders to recover the bootkit's components.

The exploit chain closely matches BlackLotus and, like it, installs custom Machine Owner Keys so the attackers can load arbitrary EFI files. Because the BlackLotus source code was never published, Kaspersky said, the BlackX operators either reverse-engineered it or bought it from criminals, an unusual borrowing by a state-linked group.

A driver built to blind security tools

The bootkit's job is to inject a malicious kernel driver into Windows. That driver was signed with a certificate issued to Wenjiang District Mingyu Network Technology Service Studio, serial number 0bcdf5e0da32d68900b8b7638459d072, which has since been revoked. It disables process, thread and registry callbacks tied to security products, tampers with Event Tracing for Windows providers so security tools cannot read their output, and protects the bootkit's files by handing back a handle to calc.exe when anything tries to open them. Some routines targeted Kaspersky and Avast products specifically; Kaspersky said those failed against its own software.

The driver then deployed one of two espionage payloads. One is a remote access tool that takes orders through files in Google Drive, OneDrive or Yandex.Disk accounts, parsing each file by its suffix. The other, which Kaspersky calls OxiDLLRunner, is an OLLVM-obfuscated DLL side-loaded by a legitimate executable renamed googleupdate.exe (original name jcef_helper.exe). It decrypts a file named v8_context_snapshot.bin into shellcode and a Rust payload that talks to www[.]archivetj[.]com and runs plug-in DLLs.

Kaspersky attributed the campaign to APT41 with medium confidence, citing an identifier, "xdd," that also appears in a kernel implant ESET described in June 2026 in attacks by the FishMonger group, along with DLL side-loading and OLLVM obfuscation common among Chinese-speaking actors.

The patch that waits for a human

Microsoft's Baton Drop protection works by revoking the "Windows Production PCA 2011" certificate that signed the vulnerable boot components. That revocation is not applied when the update installs. It has to be triggered manually: a registry flag is set under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, and a scheduled task named Secure-Boot-Update is created. Microsoft designed it that way because automatic revocation could break dual-boot systems, Kaspersky noted, but "it is extremely unusual for a system administrator to take extra steps after installing an update."

Microsoft's deployment plan includes an enforcement phase that would revoke the certificate automatically, but Kaspersky said that phase had not been implemented when it published. The certificate expired on Oct. 19, 2026, which does not stop vulnerable binaries from loading unless the certificate is placed on the Secure Boot block list.

What response teams should do

• Inventory which Windows endpoints and servers have the Baton Drop revocation actually applied, not just the update installed, using Microsoft's KB5025885 guidance for CVE-2023-24932. Prioritize machines that hold diplomatic, government or other sensitive data.
• Test before rolling out. Microsoft's guidance cautions that once the mitigation is enabled it cannot be reverted while Secure Boot stays on, and that reformatting the disk does not remove the revocations. Kaspersky noted that applying the revocation automatically could break dual-boot systems that rely on the old certificate.
• Hunt for C:\ProgramData\Intel\inst.exe launched with two arguments, extensionless encrypted blobs beside it, and unexpected changes to the EFI system partition or enrolled Machine Owner Keys.
• Search for kernel drivers signed with certificate serial 0bcdf5e0da32d68900b8b7638459d072, a googleupdate.exe whose original filename is jcef_helper.exe, and a v8_context_snapshot.bin in the same folder.
• Block and look back for DNS and proxy traffic to archivetj[.]com, and review unusual processes talking to Google Drive, OneDrive or Yandex.Disk APIs.
• Because the driver suppresses security callbacks and event tracing, treat any host where that telemetry suddenly goes quiet as a lead, and collect boot partitions for offline analysis rather than trusting on-host scans.

Microsoft's KB5025885 also notes that this class of malware requires physical or administrative access to the device, which means a bootkit finding should be handled as evidence of a wider intrusion that started earlier.