Your Baton Drop Patch Never Revoked Anything, and BlackX Boots Anyway

Kaspersky found a UEFI bootkit running under Secure Boot on machines that had every Windows update installed. The flaw it rides, CVE-2022-21894, is four years old and has carried a Microsoft fix since 2022. The fix was never the gap. Installing the update replaces the vulnerable boot manager on disk; it does not revoke the old one, and firmware will happily load the old one if an attacker brings a copy.

The bootkit is BlackX. Kaspersky's GReAT team published the analysis on October 22, 2026, after tracing a campaign against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan to it earlier in the year. The chain is BlackLotus rebuilt: exploit Baton Drop, enroll attacker-controlled Machine Owner Keys, load arbitrary EFI code, then drop a kernel driver that switches off the security software watching from above. Kaspersky attributes the campaign to APT41 with medium confidence, on shared identifiers with ESET's June 2026 FishMonger reporting, DLL sideloading patterns and OLLVM obfuscation.

Who this reaches, and who can stop at the next heading

Here is the part most of the coverage dropped. BlackX arrives after the compromise rather than at the start of it. Kaspersky states that the operators had already breached the networks and held administrator privileges before the installer ran. Nobody is getting owned by this over the internet. What they get instead is a persistence layer that survives an operating-system reinstall and a kernel driver that blinds the tooling you would use to find it.

So the relevance test is narrow and worth running. This reaches you if you run Windows with Secure Boot on hardware whose firmware has not taken the 2023 certificate update, which is most fleets that have never been checked, and disproportionately hardware past its OEM support window. It reaches you harder if your recovery plan for a compromised endpoint is "reimage it," because a reimage leaves the EFI system partition and the firmware variables exactly as the attacker left them.

It does not reach you if your estate has no Windows in it. It also does not reach you in any urgent sense if you can already show that Windows UEFI CA 2023 is in the Secure Boot database on every host and that the Baton Drop revocations applied. If that is you, skip the hunt queries. Read the verification section anyway, so that the claim rests on output rather than on an assumption.

What the bootkit does once it owns the boot chain

The installer runs as C:\ProgramData\Intel\inst.exe with two arguments, the second of which is the RC4 key for an extensionless blob sitting beside it. The executable itself carries no malicious strings and no embedded payload, so static inspection of the binary alone returns nothing interesting. It writes files to both the system partition and the UEFI partition, and the goal of the exploit is narrow: install custom Machine Owner Keys so that arbitrary EFI binaries load as trusted.

The kernel driver is the part that matters for detection. It is signed with a certificate issued to Wenjiang District Mingyu Network Technology Service Studio, serial 0bcdf5e0da32d68900b8b7638459d072, which the issuer has since revoked. Once loaded, it strips the process, thread and registry callbacks that endpoint products register, with some of that logic gated on detecting Kaspersky or Avast specifically. It alters ETW providers so security products cannot read their own telemetry. It also intercepts kernel open requests for the bootkit's files and hands back a handle to calc.exe instead, which means a file-integrity check against those paths returns a clean, signed Microsoft binary.

Above the kernel sit two user-mode payloads. One is a remote access tool that uses Google Drive, OneDrive and Yandex.Disk as its command channel, keying tasks and results off file suffixes 0X01 through 0X06. The other, OxiDLLRunner, is sideloaded by a binary named googleupdate.exe whose original name is jcef_helper.exe (MD5 AF8A983B9ADA07EAE1259BF2953ABD40); it decrypts v8_context_snapshot.bin from the same folder, pivots through shellcode into a Rust payload, and calls out to www[.]archivetj[.]com for plugin DLLs exporting create_plugin. Cloud storage for C2 and a legitimate-looking updater name are both chosen to survive egress filtering and a quick look at the process list.

The revocation nobody turned on

BlackLotus was advertised on a forum for $5,000 in October 2022 and confirmed working by ESET in March 2023. Microsoft shipped patches. The reason a 2026 campaign still gets value out of the same exploit is that the patch and the revocation were decoupled on purpose, because revocation breaks things.

Microsoft's guidance in KB5025885 is explicit about the cost: once the mitigation is enabled it cannot be reverted while Secure Boot stays on, reformatting the disk will not remove revocations that already applied, some firmware refuses to update the Secure Boot DB or DBX at all, and some devices drop into BitLocker recovery. Keep your recovery keys in hand before you start. Those are real consequences, which is why the step is opt-in, which is why almost nobody completed it. Kaspersky's write-up reduces the whole situation to one line: an administrator has to set a flag under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot and make sure the scheduled task named Secure-Boot-Update actually runs. Microsoft's automatic enforcement phase had still not arrived when the report published.

There is a deadline attached that most teams have not connected to this story. Microsoft Windows Production PCA 2011 expired on October 19, 2026, six days ago, joining the two that went earlier in the year. Microsoft's table is short enough to quote in full:

• Microsoft Corporation KEK CA 2011, expired June 24, 2026. Lives in KEK; signs updates to DB and DBX. Replaced by Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011, expired June 27, 2026. Lives in DB; signs third-party boot loaders, option ROMs and EFI applications. Replaced by two separate certificates, Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023, so a system can trust option ROMs without trusting third-party boot loaders.
• Microsoft Windows Production PCA 2011, expired October 19, 2026. Lives in DB; signs the Windows boot loader. Replaced by Windows UEFI CA 2023.

Expiry does not stop anything booting, because UEFI firmware ignores certificate expiry dates. What it stops is servicing. Microsoft's own wording is that devices without the 2023 certificates keep running and keep taking normal Windows updates, but no longer receive Windows Boot Manager updates, Secure Boot database updates, or new DBX revocation lists. A machine in that state cannot be given the Baton Drop revocation at all. The window to close this gap is the window in which your firmware can still take a DB update.

Verify the boot chain before you hunt for the bootkit

Run this per host, or wrap it in whatever you use for fleet queries. It answers four questions in order: is Secure Boot on, did the 2023 certificates land in DB and KEK, what does the servicing stack think the state is, and did Windows log a servicing failure. Event ID 1801 is the error that says the updated certificates have not applied; 1808 is the informational event that says the required certificates are in place.

# 1. Secure Boot actually enabled, not just present in firmware
Confirm-SecureBootUEFI

# 2. Are the 2023 certificates enrolled? Both must come back True.
$db  = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes)
$kek = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes)
[pscustomobject]@{
  WindowsUEFICA2023 = $db  -match 'Windows UEFI CA 2023'
  KEK2KCA2023       = $kek -match 'KEK 2K CA 2023'
}

# 3. What the servicing stack believes. UEFICA2023Error non-zero means the
#    firmware rejected the update and the OEM owns the next step.
$sb = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
Get-ItemProperty $sb -Name AvailableUpdates -ErrorAction SilentlyContinue |
  Select-Object AvailableUpdates
Get-ItemProperty "$sb\Servicing" -ErrorAction SilentlyContinue |
  Select-Object UEFICA2023Status, WindowsUEFICA2023Capable, UEFICA2023Error

# 4. Servicing events. 1801 = not applied. 1808 = applied.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1801,1808} `
  -MaxEvents 20 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, @{n='Msg';e={$_.Message -replace "`r`n",' '}}

Hosts that come back with WindowsUEFICA2023 = False are the inventory that matters. Sort them by model, because the failures cluster by firmware, and expect a tail of machines where the OEM has no fix and replacement is the only honest answer. Then go looking for the campaign itself. These are Defender XDR and Sentinel advanced hunting queries built from Kaspersky's indicators rather than generic bootkit advice.

// a) The installer and its RC4-keyed data blob
DeviceProcessEvents
| where Timestamp > ago(365d)
| where FolderPath startswith @"C:\ProgramData\Intel\"
    or ProcessCommandLine has @"\ProgramData\Intel\inst.exe"
| project Timestamp, DeviceName, AccountName, FolderPath, ProcessCommandLine, SHA256

// b) googleupdate.exe that is really jcef_helper.exe, sideloading from its own folder
DeviceImageLoadEvents
| where Timestamp > ago(365d)
| where InitiatingProcessFileName =~ "googleupdate.exe"
| where InitiatingProcessFolderPath !startswith @"C:\Program Files (x86)\Google\"
| project Timestamp, DeviceName, InitiatingProcessFolderPath, FileName, FolderPath, SHA256

// c) The encrypted sidecar outside any browser install
DeviceFileEvents
| where Timestamp > ago(365d)
| where FileName =~ "v8_context_snapshot.bin"
| where not(FolderPath has_any (@"\Google\Chrome\", @"\Microsoft\Edge\",
                                @"\BraveSoftware\", @"\Slack\", @"\Discord\"))
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName, SHA256

// d) The Rust payload's C2
DeviceNetworkEvents
| where Timestamp > ago(365d)
| where RemoteUrl has "archivetj.com"
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP

One caveat on query (c): the driver's handle-redirection trick means a live host can lie to anything that opens the bootkit's files. Telemetry already shipped to the SIEM is trustworthy; an answer you collect from the suspect machine itself is not. If a host hits on any of these, pull its disk and its EFI system partition offline rather than triaging in place.

Read the 2023 certificate status off every host you own

Do the inventory this week. Run the first code block across the fleet, count how many hosts lack Windows UEFI CA 2023, and treat that number as your real exposure to every boot-level flaw that gets found from here on, because those machines can no longer be given a revocation. Then schedule the enrollment properly: BitLocker keys exported first, a pilot ring, and recovery media rebuilt afterwards, since outdated recovery media stops booting once the revocations apply. The irreversibility is the reason to plan it rather than the reason to keep postponing it.

For the machines that will never take the update, the decision is a budget one and belongs to whoever signs for hardware. A device that cannot receive Secure Boot servicing is a device whose pre-boot defenses are frozen at their 2011 state, and the gap only widens. If you want help sizing that replacement list, or you have a host that hit on one of the queries above and need the forensic sequence for a machine whose kernel is lying to you, book a session with us. We build and test endpoint incident response playbooks for teams who have to do this without a dedicated DFIR bench.