Skip to content
Hacker Posts

BlackX UEFI bootkit bypasses Secure Boot via Baton Drop

Kaspersky details BlackX, a UEFI bootkit that abuses CVE-2022-21894 (Baton Drop) to bypass Secure Boot on patched Windows. Tied to APT41 with medium confidence; Central Asian diplomats hit.

Published 3 min read
researchapt41uefibootkit

Kaspersky's GReAT team has detailed BlackX, a UEFI bootkit used against diplomatic organizations in Central Asia in early 2026. The full write-up is on Securelist, published October 22; The Hacker News relayed it. Kaspersky assesses BlackX as a revived BlackLotus — the bootkit sold on forums in 2022 — and attributes the activity to APT41 with medium confidence. The point for defenders: the affected machines were patched, but Microsoft's fix for the exploited flaw needs manual steps most operators never take.

How it bypasses Secure Boot

BlackX exploits CVE-2022-21894, the "Baton Drop" Secure Boot bypass. Its UEFI payload runs before the OS starts, then enrols a Machine Owner Key (MOK) so it can load arbitrary EFI files on every boot.

The reason a patched system is still exposed: Baton Drop is only closed once the vulnerable "Windows Production PCA 2011" signing certificate is added to the Secure Boot DBX revocation database — and that revocation requires a manual trigger. Kaspersky notes the automatic enforcement phase had not been rolled out at publication. The certificate expired on October 19, 2026, but, per the report, "this does not prevent the vulnerable binaries from loading." Expiry is not revocation.

Post-exploitation

After the bootkit, Kaspersky documents a signed malicious kernel driver that tampers with endpoint security, with some routines conditional on Kaspersky or Avast being present. A follow-on RAT uses Google Drive, OneDrive and Yandex.Disk for command and control, and a sideloaded OxiDLLRunner (launched via googleupdate.exe) beacons to archivetj[.]com.

Attribution — read the hedge

Kaspersky's APT41 call is medium confidence, resting on an overlap with an ESET FishMonger report from June 2026, reuse of the string "xdd," DLL sideloading with an encrypted payload, and OLLVM obfuscation. These are assessments, not an indictment. Treat "APT41" as the current best hypothesis, not a settled fact.

Indicators of compromise

Kaspersky published these artifacts in the Securelist report (no consolidated hash table was provided):

Files:
  C:\ProgramData\Intel\inst.exe
  PVMDIJGKAX2                     (encrypted payload)
  googleupdate.exe                (orig. jcef_helper.exe, MD5 AF8A983B9ADA07EAE1259BF2953ABD40)
  v8_context_snapshot.bin
Installer command line:
  C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1
Driver signing cert serial (revoked):
  0bcdf5e0da32d68900b8b7638459d072
Domain:
  www[.]archivetj[.]com

Action checklist

  1. Push the Secure Boot revocations. Apply Microsoft's Baton Drop mitigation — the one that adds the "Windows Production PCA 2011" certificate to DBX. The OS patch alone does not close CVE-2022-21894.
  2. Verify DBX actually updated. On Windows, check that the revocation applied (e.g. [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) for the expected entries); a patched build with an un-updated DBX is still exploitable.
  3. Hunt for the IOCs above, especially the C:\ProgramData\Intel\inst.exe path and archivetj[.]com beacons.
  4. Watch for unexpected MOK enrolments — a bootkit that survives reinstall is loading via an attacker-added key.

Context

Bootkit-level Secure Boot bypasses keep landing on the same structural gap: Microsoft ships the fix, but leaves revocation manual to avoid bricking dual-boot and recovery media, and the revocation never gets applied at scale. BlackLotus hit that gap in 2023; BlackX is the same gap, re-weaponized against a narrower, higher-value target set three years later. If you treated "we're patched" as the end of the Baton Drop story, this is the reminder that it wasn't.

Related stories