Overview
Kaspersky researchers have analysed BlackX, a UEFI bootkit used in an espionage campaign in early 2026. BlackX exploits the old Baton Drop vulnerability (CVE-2022-21894) to bypass Secure Boot, then loads a malicious kernel driver built to interfere with security products from Kaspersky and Avast. Kaspersky attributes the activity, with medium confidence, to APT41 (also tracked as Brass Typhoon, Wicked Panda and Barium).
Campaign and Targets
- Victims were diplomatic agencies in Central Asia, notably in Tajikistan, Uzbekistan and Turkmenistan.
- All affected machines were running fully patched Windows releases, because Baton Drop's fix does not take effect on its own (see below).
How BlackX Works
- Secure Boot bypass: Baton Drop lets the attacker enroll custom Machine Owner Keys (MOKs) and load arbitrary EFI files.
- Relationship to BlackLotus: Kaspersky calls the exploit implementation "remarkably similar" to BlackLotus, but BlackX is a separate codebase with a different driver and payloads. Some BlackLotus samples contain code absent from the leaked public repository yet present in BlackX, so the author may have reverse-engineered BlackLotus or obtained its source rather than using the leak.
- Kernel driver: Signed with a now-revoked certificate issued to "Wenjiang District Mingyu Network Technology Service Studio". It disables security-related processes and registry callbacks, tampers with ETW providers, and applies some of that tampering only when Kaspersky or Avast products are present (ineffective against Kaspersky's). It also protects the bootkit's files by intercepting open requests and launching Windows Calculator instead.
Payloads
- A RAT that uses Google Drive, OneDrive or Yandex.Disk for command and control, executing .NET payloads and transferring files.
- OxiDLLRunner, an OLLVM-obfuscated DLL sideloaded by
googleupdate.exe. It decryptsv8_context_snapshot.binto run shellcode and a Rust payload that fetches DLL plugins fromarchivetj[.]com.
Why Patching Is Not Enough
The Baton Drop fix relies on revoking the Windows Production PCA 2011 certificate, but revocation is not automatic; administrators must apply it manually. The certificate expired on October 19, 2026, yet expiry alone does not stop vulnerable boot binaries from loading. They must be blocklisted.
Recommended Actions
- Follow Microsoft's guidance on revoking vulnerable Windows boot managers and add the PCA 2011 certificate to the Secure Boot blocklist (DBX) on managed fleets.
- Hunt for the indicators above:
googleupdate.exesideloading,v8_context_snapshot.binoutside a legitimate browser path, and traffic toarchivetj[.]com. - Alert on unexpected MOK enrollments and changes to the EFI System Partition.
- Enable firmware-level protections and test boot-chain revocation changes on a pilot group first, since DBX updates can render older boot media unbootable.
- Treat any host suspected of a bootkit infection as fully compromised; reimage and reflash firmware where possible.