BlackX bypasses Secure Boot on fully patched Windows machines through a revocation nobody enabled

October 2022. The BlackLotus bootkit goes on sale for $5,000, exploiting Baton Drop (CVE-2022-21894) to defeat Secure Boot. Early 2026. A derivative called BlackX strikes diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan. October 22, 2026. Kaspersky publishes its report. The point: the affected machines were fully patched — the problem was the patch itself, which does not activate on its own.

A fix that does not trigger by itself

The report’s most uncomfortable finding fits in one sentence. The victims had installed the Windows updates for CVE-2022-21894, and yet BlackX still bypassed Secure Boot. The reason has been documented by Microsoft since 2023 but remains little known: the Baton Drop fix only takes effect once the “Windows Production PCA 2011” certificate is revoked, and that revocation is not automatic when the update is installed.

In practice, an administrator must set a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, and a scheduled task named Secure-Boot-Update must run. Kaspersky notes these steps are “buried deep” on Microsoft’s site, and that the automatic “enforcement phase” the vendor had planned was still unimplemented at the time of publication.

The certificate expired on October 19, 2026. But expiry alone does not stop the vulnerable binaries from loading — they must be added to the revocation list. Until that happens, an attacker can still sign or reuse the vulnerable boot components.

BlackX is not an initial-access vector. Kaspersky notes that attackers deployed it after already gaining administrator privileges, by an unspecified method. Microsoft has long described such bootkits as a persistence and defense-evasion mechanism — once installed, they survive OS reinstalls and load before Windows does.

What BlackX does once installed

The installer, inst.exe, relies on an RC4-encrypted file named PVMDIJGKAX2 that stores installation components and strings. Keeping those resources outside the executable makes the full package harder to collect and analyze for incident responders.

Once on the machine, the bootkit enrolls its own Machine Owner Keys (MOK) to load arbitrary EFI files — the mechanic inherited from BlackLotus. It then injects a kernel driver whose signing certificate has since been revoked. That driver attempts to disable security callbacks for processes, threads and the registry, and interferes with ETW (Event Tracing for Windows) providers. Kaspersky notes that these routines failed to disrupt its own products during testing.

To protect its files, the driver intercepts file-open requests and returns a handle to calc.exe instead. The espionage payloads follow: a RAT that uses Google Drive, OneDrive and Yandex.Disk for command and control, and a second component, OxiDLLRunner, side-loaded through a legitimate googleupdate.exe. The latter decrypts v8_context_snapshot.bin to launch a Rust implant that talks to www[.]archivetj[.]com.

Published indicators include the installer under C:\ProgramData\Intel\inst.exe, the encrypted file PVMDIJGKAX2, and a driver signed in the name of “Wenjiang District Mingyu Network Technology Service Studio” — a certificate that has since been revoked.

The APT41 link

Kaspersky links BlackX to APT41 with medium confidence. The link runs through the ESET report of June 2026 on FishMonger and through the use of DLL side-loading, a favored technique of the group.

BlackX is assessed as a reworking of BlackLotus. But BlackLotus’s source code was never made public, so the authors either reverse-engineered it or obtained it through other channels. The implementation differences researchers found point to a reimplementation rather than a straight copy.

That changes the strategic reading. BlackLotus was not a one-off commercial kit — it became a reusable codebase for a state actor, adapted to its own diplomatic targets. The UEFI threat has changed nature: from a forum kit to a maintained espionage tool.

How to check whether you are exposed

Affected machines are Windows systems that have the Baton Drop patches installed but not the Windows Production PCA 2011 revocation applied. The reflex to correct is believing that “patched equals protected.”

• Verify the revocation, not the patch. Follow Microsoft’s guidance on managing boot manager revocations and confirm, device by device, that the revocation steps ran after the update.
• Test before a broad rollout. Kaspersky warns that automatic revocation can break dual-boot systems that rely on the PCA 2011 certificate — which is precisely why Microsoft made the step manual.
• Hunt the indicators. Look for C:\ProgramData\Intel\inst.exe, the file PVMDIJGKAX2, the driver signed “Wenjiang District Mingyu Network Technology Service Studio,” and traffic to archivetj[.]com.
• Question the initial access. Because BlackX requires administrator privileges first, ask how such access could have been obtained on sensitive machines — that is often where the real compromise began.

Verdict

If you manage a Windows estate with sensitive endpoints, do not settle for an “up to date” status. Verify machine by machine that the Windows Production PCA 2011 revocation is actually active — that is the only thing separating a patched machine from a protected one against BlackX and its derivatives. If you run dual-boot systems, test the revocation on a sample before generalizing, since it can break boot. The deeper lesson outlives this bootkit: a security fix whose activation step is manual and optional is, in practice, a fix nobody has.

References

• Kaspersky Securelist — How APT41 revived the BlackLotus bootkit to attack diplomatic organizations in Central Asia
• The Hacker News — BlackX UEFI Bootkit Bypasses Secure Boot on Patched Windows Systems Missing Revocations
• Microsoft — Guidance for investigating attacks using CVE-2022-21894 (BlackLotus campaign)