Red Team

APT41-linked BlackX bootkit beats Secure Boot on patched Windows

Kaspersky’s BlackX bootkit bypasses Secure Boot on fully patched Windows via Baton Drop because the PCA 2011 revocation was never enabled.

Illustration of a target over a computer boot sequence representing the BlackX UEFI bootkit bypassing Secure Boot

Kaspersky has found a China-linked bootkit, BlackX, defeating Secure Boot on Windows machines that had every relevant update installed. It works because the fix for an old BlackLotus flaw only takes effect once administrators switch it on by hand, and on most estates that has never happened.

What happened

Kaspersky’s GReAT researchers detailed BlackX on 22 October 2026. It is a UEFI bootkit deployed in early 2026 against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. Kaspersky attributes the campaign to APT41 with medium confidence. APT41, also tracked as Winnti, blends state espionage with profit-driven crime.

BlackX closely resembles BlackLotus, the bootkit advertised on a criminal forum in 2022 for $5,000 and confirmed as genuine by ESET in March 2023, when it was shown to bypass Secure Boot. Because the full BlackLotus source code was never officially published, Kaspersky suggests the BlackX authors either reverse-engineered BlackLotus or bought the code. Kaspersky notes that state-backed crews rarely borrow criminal tooling so directly.

Kaspersky first assumed the victims had missed their updates, but the machines were fully patched. The attackers succeeded because the revocation step that actually closes Baton Drop (CVE-2022-21894) had never been enabled.

The technical picture

BlackX is a late-stage persistence tool rather than a way in. Kaspersky observed the operators deploying it only after they had compromised the victim network and gained administrator rights. The installer itself contains nothing obviously malicious; the components it needs sit inside a separate RC4-encrypted blob, which frustrates responders trying to recover it.

Once running, the chain abuses Baton Drop to enrol attacker-controlled Machine Owner Keys, after which the firmware will happily load arbitrary EFI binaries.

From there the UEFI payload injects a kernel driver signed with a certificate issued to a Chinese company, Wenjiang District Mingyu Network Technology Service Studio, which has since been revoked. The driver strips process, thread and registry callbacks used by security products, interferes with Event Tracing for Windows so that telemetry dries up, and hides its own files by handing back a handle to calc.exe when anything tries to open them. Some routines targeted Kaspersky and Avast products, though Kaspersky says they did not work against its own.

Two espionage payloads followed. One is a remote access trojan that uses Google Drive, OneDrive and Yandex.Disk as its command channel, which blends neatly into normal corporate traffic. The other, OxiDLLRunner, is an OLLVM-obfuscated DLL sideloaded by a legitimate executable renamed googleupdate.exe, which runs a Rust implant that pulls plugins from a remote server. Attribution rests on the string “xdd” appearing in BlackX and in a FishMonger kernel implant ESET described in June 2026, plus sideloading and obfuscation habits common to Chinese-speaking actors.

The patch problem is documented in Microsoft’s own guidance, KB5025885. The Secure Boot mitigations for the BlackLotus family ship in Windows updates but are “not enabled by default”. Full protection means adding the Windows UEFI CA 2023 certificate, moving to a 2023-signed boot manager, and then placing “Windows Production PCA 2011” in the DBX, the firmware’s forbidden signatures list. Microsoft’s planned Enforcement Phase, which would do this automatically, still has no announced date. The 2011 certificate expired on 19 October 2026, but as Kaspersky and others point out, expiry does not stop binaries signed while it was valid from loading. Only a DBX entry does that. This is distinct from the broader certificate replacement programme: the issue here is a live campaign abusing an unrevoked certificate.

Flow diagram of the BlackX attack chain from administrator access through Baton Drop exploitation to espionage payloads

Why it matters for UK organisations

The victims were in Central Asia, but the weakness is generic. Any Windows estate that has taken the monthly updates without completing the revocation steps sits in the same state as those diplomatic machines. Kaspersky’s own assessment is that the activation guidance is buried and that few administrators take extra action after a patch installs cleanly. In my experience, compliance tooling reports Secure Boot as enabled and stops there; the DBX itself is rarely examined.

APT41 is no stranger to firmware implants or to Western targets: US prosecutors indicted members in 2020 over intrusions at more than 100 organisations in several countries. A bootkit that survives reinstallation and blinds endpoint tooling is exactly what a patient espionage team wants on a UK government supplier, law firm or defence contractor it has already breached. Cyber Essentials and most patch-compliance reporting measure whether updates are installed, not whether optional mitigations inside them are active, so dashboards can show green while the gap remains.

Expert view

When we run red team exercises, firmware persistence is rarely in scope, partly because it is hard to remediate and partly because clients assume Secure Boot handles it. BlackX shows why that assumption deserves testing. The bootkit needs admin rights first, so it is not a mass threat. It is, however, the sort of implant that turns a contained incident into one where you cannot trust rebuilt machines.

The bigger lesson concerns opt-in fixes. Microsoft has good reasons for caution: once the revocations are applied with Secure Boot on, they cannot be reversed, older recovery and installation media may stop booting, some devices drop into BitLocker recovery, and KB5025885 lists firmware known issues on certain HP, Qualcomm Arm64, VMware and Apple Boot Camp configurations. But a fix that breaks things if forced, and does nothing if left alone, puts the burden squarely on IT teams. Kaspersky believes the attackers bet on exactly that. I would treat “patched but not mitigated” as a finding in its own right in any assessment.

What to do now

  1. Measure first. Using the checks in KB5025885, establish across your fleet whether the Windows UEFI CA 2023 certificate is in the DB and whether Windows Production PCA 2011 is in the DBX. Microsoft documents the PowerShell queries and event IDs (1036, 1037, 1799) that confirm each stage.
  2. Prioritise high-value endpoints. Start with privileged access workstations, administrator laptops, executives, staff who travel, and servers that support identity. This maps to the Cyber Essentials secure configuration and security update management controls.
  3. Prepare before revoking. Escrow BitLocker recovery keys, rebuild recovery and installation media, update all Windows installs on dual-boot machines, check firmware with your hardware vendors, and pilot one device per model before going wider.
  4. Protect admin rights. BlackX needs administrator access to install. Tight privileged access management, separate admin accounts and controls on local admin rights remain the most effective barrier, in line with the Cyber Essentials user access control requirements.
  5. Hunt for the symptoms. Watch for unexpected changes to the EFI System Partition and MOK enrolment, gaps in EDR or ETW telemetry, and unusual cloud-storage API traffic from endpoints. Ask your EDR vendor whether it scans UEFI and boot components.
  6. Update your incident playbooks. If firmware persistence is suspected, a reimage is not enough. Plan for revocation, firmware reflash or hardware replacement.

Bottom line

BlackX is not a new zero-day; it exploits a years-old flaw with a fix that most organisations have downloaded but never switched on. A state-linked group has noticed that gap and built tooling around it. UK teams should stop treating Secure Boot as a box that is either ticked or not, check their DBX this week, and plan a careful revocation rollout before someone else’s bootkit makes the decision for them.

Sources

Related Posts