A newly identified UEFI bootkit called BlackX has bypassed Secure Boot on fully patched Windows systems by exploiting the four-year-old Baton Drop vulnerability. For UK buyers, it's a blunt reminder that hardware root of trust and Secure Boot only work if every revocation step is actually completed.
View the data behind this chart
| Phase | Starts (week) | Duration (weeks) |
|---|---|---|
| Baton Drop patched (CVE-2022-21894) | 0 | 4 |
| BlackLotus bootkit circulates | 40 | 20 |
| ESET confirms Secure Boot bypass | 62 | 4 |
| BlackLotus source partly leaks | 80 | 4 |
| BlackX espionage campaign found | 155 | 1 |
| Windows PCA 2011 cert expires | 155 | 1 |
What happened: the BlackX espionage campaign
Kaspersky researchers have detailed a UEFI bootkit named BlackX, deployed in an espionage operation discovered in early 2026 and attributed with medium confidence to APT41, a Chinese state-sponsored group also tracked as Brass Typhoon, Wicked Panda and Barium.
The campaign targeted diplomatic agencies in Central Asia, specifically Tajikistan, Uzbekistan and Turkmenistan. BlackX loaded a malicious driver built to interfere specifically with security solutions from Kaspersky and Avast once it had gained a persistent foothold beneath the operating system.
An old flaw, a new weapon: Baton Drop resurfaces
BlackX does not rely on a fresh zero-day. It exploits Baton Drop (CVE-2022-21894), the same Secure Boot bypass used by BlackLotus, a bootkit that has circulated on hacker forums since October 2022 and was confirmed by ESET in March 2023 as capable of compromising fully patched Windows 11 machines.
Kaspersky says BlackX's exploit implementation is "remarkably similar" to BlackLotus, enrolling custom Machine Owner Keys and loading arbitrary EFI files to defeat Secure Boot. BlackLotus's source code leaked, incompletely, in July 2023 — yet Kaspersky found code in BlackX samples that is missing from that public leak, suggesting the operator either reverse-engineered BlackLotus or bought its source outright. That points to bootkit capability spreading beyond its original author, a trend that matters for anyone building vulnerability management strategies around firmware-level CVEs.
Inside the payload: what BlackX does once it's booted
After bypassing Secure Boot, BlackX injects a Windows kernel driver signed with a now-revoked certificate issued to Wenjiang District Mingyu Network Technology Service Studio. The driver disables security-related processes and registry callbacks and tampers with Event Tracing for Windows providers to blind monitoring tools.
Some of its evasion routines only activate if Kaspersky or Avast products are detected — a targeted approach Kaspersky says is ineffective against its own software. The driver also protects the bootkit's files by intercepting attempts to open them and launching the Windows Calculator instead. From there it deploys a remote access trojan that uses Google Drive, OneDrive or Yandex.Disk for command-and-control, plus OxiDLLRunner, an obfuscated loader sideloaded via googleupdate.exe that decrypts a hidden payload and pulls further plugins from an external domain.
- •Kernel driver signed with a revoked certificate
- •ETW tampering and security process termination
- •File-access interception disguised as Calculator
- •RAT using legitimate cloud storage for C2
- •OxiDLLRunner Rust-based plugin loader
Why patched Windows still fell: the manual revocation gap
Every BlackX victim Kaspersky examined was running a fully patched version of Windows. The weakness is procedural, not technical: the Baton Drop fix revokes the "Windows Production PCA 2011" certificate used to sign vulnerable UEFI components, but that revocation does not happen automatically when the patch installs. An administrator has to trigger it manually.
Kaspersky flags this as an update-process gap that almost no organisation closes in practice. Crucially, the certificate's October 19, 2026 expiry date does nothing to stop vulnerable binaries loading — it only helps once the certificate is explicitly added to a Secure Boot blocklist. Patch compliance dashboards that only track Windows update status will miss this entirely.
What UK infrastructure teams should audit now
This is a firmware governance problem as much as a malware story. UK buyers should treat Secure Boot revocation status as a distinct control to verify, separate from standard patch cadence, across both server and workstation estates.
As a broader firmware-security best practice, audits should also extend beyond the OS into server firmware security and BMC configurations, with particular attention to long-lived or securing end-of-support servers where DBX updates can be skipped during lifecycle extension or managed through third-party maintenance arrangements. Detection teams should also confirm their managed detection & response capability can spot ETW tampering and unsigned driver loads, since a host reporting as fully patched can still be silently compromised at the boot chain.
- •Confirm Windows Production PCA 2011 revocation has been manually applied, not just patched
- •Audit Secure Boot DBX status separately from OS patch compliance
- •As general best practice, extend firmware checks to BMC and remote management interfaces
- •Flag drivers signed by unfamiliar or revoked certificates
- •As general best practice, review legacy/end-of-support servers maintained outside standard patch cycles
View the data behind this chart
| BlackLotus (2022) | BlackX (2026) | UK impact | |
|---|---|---|---|
| Secure Boot bypass | Baton Drop exploit | Same Baton Drop exploit | Unpatched DBX still vulnerable |
| Target security tools | Generic AV/EDR | Kaspersky & Avast specific | Vendor-specific defences needed |
| Source availability | Leaked (partial) July 2023 | Reverse-engineered or bought | Supply chain risk grows |
| C2 channel | Custom infrastructure | Google Drive, OneDrive, Yandex | Harder to spot in cloud traffic |
| Observed targets | Various espionage ops | Central Asian diplomatic agencies | Shows nation-state tooling reuse |
The bigger picture: bootkit tooling is spreading
BlackX shows a bootkit once associated with a single notorious family being adapted — reverse-engineered or purchased — by another operator entirely, with its own payloads and C2 infrastructure. That commoditisation of boot-level capability is a warning sign for any sector that assumes nation-state-grade firmware attacks stay confined to one actor or one region.
It also reinforces a point relevant well beyond this campaign: prevention controls degrade fast once an attacker is inside. Separate industry data cited alongside this research found that once attackers are operating with valid credentials, only 37% of their follow-on actions get blocked, based on 338 million simulations run in production environments. Firmware integrity has to sit alongside zero trust assumptions and strong endpoint security solutions, not replace them.