A Suspected APT41 Bootkit Beat Secure Boot on Fully Patched Windows, Kaspersky Says, Because the Baton Drop Revocation Is Opt-In

Kaspersky says a UEFI bootkit it calls BlackX was used in early 2026 against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan, and that the targeted Windows machines were fully patched. In a report published on October 22, which BleepingComputer covered on October 24, the company attributes the campaign to APT41 with medium confidence. BlackX exploits Baton Drop (CVE-2022-21894), the Secure Boot bypass that BlackLotus used, and Kaspersky’s explanation for why patched machines stayed open is that the revocation which closes the hole “does not happen automatically upon patch installation.”

We read Kaspersky’s report, ESET’s earlier research, Microsoft’s revocation guide and certificate-expiry page, the NVD records and CISA’s KEV feed, and we ran Microsoft’s read-only checks on one Windows 11 workstation. That machine had the 2023 Secure Boot certificate but not the revocation, so the 2011 certificate is still trusted, which is the gap the report describes. We found no Microsoft statement about BlackX, and Microsoft’s guide still says the date for automatic enforcement “will be announced at a later date.”

What Kaspersky says it found

Kaspersky says the attackers deployed BlackX after breaking into the victim networks and obtaining administrator privileges. They dropped an installer, inst.exe, run from C:\ProgramData\Intel, together with an RC4-encrypted package named PVMDIJGKAX2 that holds everything the installer needs, so the executable itself contains no malicious strings. The package places files on the system and UEFI partitions that exploit Baton Drop to enroll attacker-controlled Machine Owner Keys, which lets the machine load arbitrary EFI files and so manipulate Secure Boot. Kaspersky calls the exploit implementation “remarkably similar” to the one in BlackLotus.

What runs afterwards is a kernel driver, signed with a certificate issued to Wenjiang District Mingyu Network Technology Service Studio and since revoked by its issuer. The driver disables process, thread and registry callbacks tied to security products, tampers with Event Tracing for Windows providers, and answers attempts to open the bootkit’s files with a handle to calc.exe. Some of its tampering is written to run only when Kaspersky or Avast products are present, and Kaspersky says that code fails to interfere with its own products.

The driver then deploys user-mode payloads for espionage. One is a remote access tool that takes its tasks from Google Drive, OneDrive or Yandex.Disk. The other, which Kaspersky calls OxiDLLRunner, is a DLL that a legitimate googleupdate.exe (original filename jcef_helper.exe) loads by sideloading, a technique we covered in our post on Microsoft’s NeedyMantis report. It decrypts v8_context_snapshot.bin and runs a Rust payload that contacts a server Kaspersky writes as www[.]archivetj[.]com.

Why a fully patched machine was still exposed

Closing this hole takes two things: a fixed boot manager, and a revocation that stops the old, vulnerable ones from loading. ESET’s March 2023 analysis of BlackLotus described the gap: “Although the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list.” Microsoft’s later answer was to untrust the certificate that signed those boot managers rather than list them one by one. Its guide, KB5025885, which covers CVE-2023-24932, says the mitigations in the security updates released on July 9, 2024 and later are “not enabled by default.” Each step sets a value under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot and then starts the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task:

Kaspersky’s reading is that the manual design makes the protection easy to miss. It calls it “extremely unusual for a system administrator to take extra steps after installing an update” and says the instructions are “buried deep on the Microsoft website.” It also suggests that applying the revocation automatically could break dual-boot systems that rely on the 2011 certificate. That is Kaspersky’s guess at Microsoft’s reasons, not Microsoft’s statement, although Microsoft’s guide does say the revocation “could cause issues for some device boot configurations.”

Microsoft’s plan has a later phase that would make the revocation automatic. The guide says the Enforcement Phase “will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins,” and that the updates will be “programmatically enforced after installing updates for Windows to all affected systems with no option to be disabled.” The page we fetched on October 24 still gives no date, and its newest change-log entry, September 30, 2026, adds a known issue about older external boot media without announcing one. Kaspersky says that stage “has not been implemented.” By Microsoft’s own six-month rule, a date announced today could not take effect before late April 2027. That is our arithmetic, not a Microsoft statement.

What the October 19 expiry does and does not change

Microsoft’s certificate-expiry page lists Microsoft Windows Production PCA 2011, the certificate the revocation would untrust, as expiring on October 19, 2026, with Windows UEFI CA 2023 as the replacement for signing the Windows boot loader. Microsoft says devices without the 2023 certificates “will continue to start and operate normally” but “will no longer be able to receive new security protections for the early boot process.” Kaspersky adds the point that matters here: the expiry “does not prevent the vulnerable binaries from loading unless the certificate is blocklisted.” Replacing a certificate and revoking the old one are separate actions. Our June explainer on the 2026 certificate deadline covers the rollover itself.

What we saw on one Windows 11 workstation

At about 19:12 UTC on October 24 we ran Microsoft’s read-only checks on a Windows 11 24H2 workstation, an HP Z2 SFF G1i on build 26100.9711 whose most recent security updates were installed on October 14. Confirm-SecureBootUEFI returned True. The first, third and fourth commands below come from KB5025885 and the second is the same pattern aimed at the DB; none of them changes anything.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows Production PCA 2011'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status

True
True
False
Updated

That is the split Kaspersky describes. The 2023 certificate is in the DB and the servicing status reads Updated, a step Microsoft’s guide says may already be complete on devices its monthly updates mark “High Confidence.” But the 2011 certificate is still trusted and is not in the DBX, so the broad revocation that would untrust every boot manager it signed has not been applied. AvailableUpdates read 0. This is one machine, not a survey. We changed nothing, did not run the revocation, did not test whether BlackX files would load here, and have no reason to think the machine is compromised.

Why the scores and the KEV list would not flag it

NVD carries Microsoft’s CVSS 3.1 scores for both CVEs, and both sit in the Medium band with a local attack vector and a high privilege requirement. Neither CVE is in CISA’s KEV catalog (catalog version 2026.10.23, 1,756 entries).

Microsoft’s guide explains the privilege requirement: “an attacker must gain administrative privileges on a device or gain physical access to the device,” and its mitigations are “preventive and not corrective.” Kaspersky’s account fits, since the attackers installed BlackX after they already had administrator rights. A queue sorted by CVSS score or by KEV listing would rank these flaws low, which is our inference. What a 4.4 or a 6.7 does not capture is what the flaw gives an intruder who already has administrator rights: a way to get a bootkit past Secure Boot, plus a driver that tampers with security tools.

Where the accounts differ

• Whether BlackLotus source code ever leaked. Securelist says the code “has never been published online” and uses that to argue the BlackX authors either reverse-engineered BlackLotus or bought its source. BleepingComputer’s July 2023 report described a partial GitHub leak: Binarly’s chief executive said the code “isn’t complete and contains mainly the rootkit part and bootkit code to bypass Secure Boot,” and the user who posted it says it was modified to remove the Baton Drop vulnerability. BleepingComputer’s October 24 article goes further and says Kaspersky found samples with code “missing from the public repository but present in the BlackX bootkit.” We could not find that sentence in the Securelist text we read on October 24. The accounts fit together only if the leaked code was not the bootkit itself, and the sources do not settle that.
• When Baton Drop was disclosed. Securelist says it “was disclosed back in 2023.” NVD publishes CVE-2022-21894 on January 11, 2022, and ESET’s March 2023 post called BlackLotus’s use of it “the first publicly known, in-the-wild abuse of this vulnerability.” The CVE record is the one to trace patch history by.
• How strong the APT41 link is. Kaspersky builds it from an identifier, “xdd,” that appears in a file path in ESET’s June 16 report on FishMonger (a group Kaspersky says the community assumes to be related to APT41) and repeatedly in BlackX payloads, plus two traits it calls common among Chinese-speaking actors: a legitimate executable abused by DLL sideloading with an encrypted file, and OLLVM obfuscation. ESET’s own wording is hedged: it saw “limited indications that some SprySOCKS attack scenarios may involve a UEFI bootkit component,” and it does not name BlackX. Kaspersky itself says medium confidence.
• The scheduled task. Kaspersky writes that a task named Secure-Boot-Update “is created” when the revocation is applied. Microsoft’s guide has administrators start an existing task of that name, and it was already present, with AvailableUpdates at 0, on the workstation we checked.

What to do now

Microsoft’s guide lists Windows 10, Windows 11 and Windows Server releases from 2012 ESU through 2025. Run the checks above first. If the revocation is not applied, the guide’s route is to install the latest Windows security updates, then evaluate and deploy the steps in order. Its warnings are specific: test on a single device per device class and “Do not deploy broadly before confirming all the device classes in your environment have been evaluated,” keep a copy of the BitLocker recovery key, and rebuild recovery and install media before the revocation, because boot managers signed by the 2011 certificate stop working afterwards. The September 30 change-log entry adds a known issue that older external boot media may not start once the revocation is on, with Microsoft’s install-media steps as the workaround.

The guide is also clear that this is prevention, not cleanup: if a device is already compromised, it says to contact a security provider. For hunting, Kaspersky’s indicators are the inst.exe dropper under C:\ProgramData\Intel, a googleupdate.exe that sideloads a DLL which decrypts v8_context_snapshot.bin, the revoked driver certificate with serial number 0bcdf5e0da32d68900b8b7638459d072, and the domain above. Kaspersky also recommends security products with exploit prevention, and as a vendor of them it has an interest in that advice. A patch that does not undo a compromise is a pattern we noted with the BeyondTrust zero-day in October; here the gap comes earlier, in a protection that is installed but not switched on.

Open questions

• Whether Microsoft will set an enforcement date or change the default. We found no statement from it about BlackX.
• How many organizations Kaspersky saw and how the attackers first got administrator access. The report names three countries, not a victim count or an entry route.
• How many machines outside this campaign are in the state we saw. Our check covers one workstation.
• Where the BlackLotus code behind BlackX came from: reverse engineering or a purchase (Kaspersky’s two options), or a partial leak (BleepingComputer’s 2023 report).
• Whether other groups use the same path. The report describes one campaign.

Sources and method

Kaspersky’s Securelist report (dated October 22, 2026) and BleepingComputer’s October 24 article are the account of the campaign. Microsoft’s KB5025885 (change log through September 30, 2026) and certificate-expiry page are the primary text for the steps, dates and warnings. ESET’s 2023 and 2026 posts and BleepingComputer’s 2023 leak report supplied the history. The NVD records and CISA’s KEV feed were read through their public APIs on October 24.

The pages were fetched between 19:00 and 19:20 UTC on October 24, and the workstation check ran at about 19:12 UTC. We did not install or run any BlackX sample, changed no registry value, and did not reach Kaspersky or Microsoft; we found no statement from either beyond what is cited. The late-April 2027 date and the reading of the Medium scores are our arithmetic and inference.