KIungefiltert

· 4 min read · Auf Deutsch lesen

BlackX: UEFI bootkit bypasses Secure Boot via the old Baton Drop flaw

The BlackX bootkit got past Secure Boot on fully patched Windows PCs at Central Asian diplomatic bodies, because the needed revocations were never switched on. Kaspersky suspects APT41.

security

Translated from the German original with an AI language model, approved by me. Read the original

Kaspersky has analyzed a new UEFI bootkit called BlackX. It was used in early 2026 in an espionage campaign against diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan. What stands out is less the malware than what it exploits: a flaw that has been known and patched since 2022. Even so, according to BleepingComputer, every victim was running a fully patched Windows release.

What happened

A bootkit is malware that hooks into a computer's startup process and loads before the operating system. Antivirus tools barely see it there, and reinstalling Windows won't necessarily remove it. Secure Boot is supposed to prevent exactly that: the UEFI firmware (the modern successor to the BIOS) only starts bootloaders whose signatures it trusts.

BlackX abuses Baton Drop (CVE-2022-21894). This flaw sits in old Windows boot managers that Microsoft still signed, and it can be used to defeat Secure Boot. The attackers used it to enroll their own keys (Machine Owner Keys), which let them load any EFI file they wanted. Kaspersky calls the implementation "remarkably similar" to the well-known BlackLotus bootkit, and The Hacker News describes BlackX as an updated version of it. BlackLotus's source code was never fully public, so the attackers either rebuilt it by reverse engineering or got it some other way.

One point matters for context: BlackX wasn't how the attackers got in. They were already inside the network with administrator rights before installing the bootkit, and it's unknown how they got there. The bootkit was there to keep a persistent, quiet foothold.

Once running, BlackX loads a kernel driver that shuts down security processes and Windows monitoring features such as ETW, the event tracing system. The driver is signed with a certificate that has since been revoked. Some routines only run if Kaspersky or Avast products are installed. I need to correct my WhatsApp post here: Kaspersky says these particular routines didn't work against its products. On top of that come espionage tools, including a remote access trojan that uses Google Drive, OneDrive and Yandex.Disk as its command channel, and a loader called OxiDLLRunner.

Who is behind it?

Kaspersky attributes the campaign to the China-linked group APT41 with "medium confidence." That's an informed assessment, not proof. ESET sees similarities to its June 2026 research on FishMonger, a group counted under the APT41 umbrella, but won't confirm a link without comparing samples.

Why patching alone isn't enough

This is the real story. The Baton Drop patch fixes the boot manager, but the old vulnerable boot manager still carries a valid signature, so an attacker with admin rights can simply bring it along. The only fix is a revocation: an entry in the firmware's blocklist (DBX) that marks the old "Windows Production PCA 2011" certificate as untrusted. Windows doesn't apply this step on its own. Admins have to trigger it, and Kaspersky says the attackers count on the fact that many organizations never have.

New since my post: the PCA 2011 certificate expired on October 19, 2026. That doesn't protect you, because firmware keeps loading the old binaries as long as the certificate isn't blocklisted. According to its guidance on CVE-2023-24932 (last updated September 30, 2026), Microsoft still hasn't set a date for automatic enforcement. We're still in the "Deployment Phase."

Who is affected

The known targets were diplomats in Central Asia. No German or other Western victims have been reported. But in principle, any Windows machine with Secure Boot that lacks the revocations is exposed, and that's likely a very large number, in companies and government agencies included. Needing admin rights limits the risk but doesn't remove it. If you're specifically targeted, you lose a layer of protection you thought you had.

What you should do

  • Install Windows updates. That's the baseline.
  • Actively apply the Secure Boot revocations following Microsoft's guidance: add the "Windows UEFI CA 2023" certificate, update the boot manager, then add PCA 2011 to the DBX. Afterwards, check that the status actually took effect.
  • Test first and create recovery media. A revocation can't be undone while Secure Boot is on, not even by reformatting. Old boot USB sticks and recovery media may stop working. Start with one device per hardware model.
  • Keep firmware (UEFI) up to date so devices can take the new certificates cleanly.
  • Keep admin rights scarce. BlackX needed them before it could do anything.

My take: Secure Boot is only as strong as its blocklist. A green "all updates installed" tells you nothing about that.

Sources