Threat intel
BlackX bootkit beats Secure Boot on fully patched PCs
A BlackLotus copycat hit Central Asian diplomats through a Secure Boot revocation most admins never switched on. How to check the DBX and hunt for it.
Kaspersky's Global Research and Analysis Team (GReAT) published research on October 22 about BlackX, a UEFI bootkit used in early 2026 against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. A bootkit is malware that runs during the boot process, before Windows and its security tools load. BlackX closely copies BlackLotus, the bootkit sold on a hacking forum for $5,000 in 2022, and it bypasses Secure Boot through the same 2022 flaw. Kaspersky attributes the campaign to APT41, a China-linked group, with medium confidence.
The detail that matters for every Windows estate is that the victims were fully patched. Microsoft's fix for this class of attack only takes effect once an administrator revokes the Windows Production PCA 2011 certificate in the firmware's DBX, the list of revoked boot signatures. That step has never been automatic. If you have not done it on purpose, assume your PCs and servers will still load a vulnerable, Microsoft-signed boot manager.
How it works
Secure Boot has the firmware check a signature on each piece of boot code before running it. It trusts anything signed by a certificate in the DB (the allow list) unless the file's hash or signer is in the DBX. Baton Drop, CVE-2022-21894 (CVSS 4.4), is a flaw in older Windows boot managers that lets an attacker strip Secure Boot's protections during boot. Microsoft fixed the code in January 2022, but the old, vulnerable boot managers are still validly signed by PCA 2011. An attacker can copy one onto the EFI System Partition (ESP), the small FAT32 partition the firmware boots from, and the firmware will run it.
BlackX does exactly that. With administrator rights already in hand, the operators ran C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The installer itself holds no malicious strings. Everything it needs sits in PVMDIJGKAX2, an extensionless RC4-encrypted file, and the last argument is the key. It drops files onto the system and EFI partitions that trigger Baton Drop, and the exploit enrolls the attackers' own Machine Owner Key (MOK). A MOK is a key that the shim boot loader, normally used by Linux, trusts in addition to the DB. Once their key is enrolled, the attackers can sign and load any EFI file they like on every boot with Secure Boot still reporting as on.
Kaspersky found the exploit chain "remarkably similar" to BlackLotus but not identical. BlackLotus source code was never published, so the operators either reverse engineered it or bought it.
From there the bootkit injects a kernel driver signed with a certificate issued to Wenjiang District Mingyu Network Technology Service Studio (serial 0bcdf5e0da32d68900b8b7638459d072, since revoked). The driver removes the process, thread and registry callbacks that endpoint security products register, and tampers with Event Tracing for Windows (ETW) providers so those products stop receiving telemetry. It also hides its own files: a request to open one gets a handle to calc.exe instead.
What attackers are doing
The driver launches two espionage payloads. The first is a remote access trojan (RAT) that loads further .NET modules and uses Google Drive, OneDrive or Yandex.Disk as its command channel, reading tasks and writing results as files with suffixes such as 0X01 and SSSR. Its traffic looks like ordinary cloud storage use.
The second, which Kaspersky calls OxiDLLRunner, is an OLLVM-obfuscated DLL sideloaded by a legitimate googleupdate.exe (originally jcef_helper.exe, MD5 AF8A983B9ADA07EAE1259BF2953ABD40). It decrypts v8_context_snapshot.bin from the same folder into shellcode and a Rust implant that talks to www[.]archivetj[.]com and runs plugin DLLs that export create_plugin.
The APT41 link rests on the identifier "xdd" appearing in BlackX payloads, the same name in a kernel implant PDB path that ESET described in June 2026 in its reporting on FishMonger, a group linked to APT41. ESET also suspected an unnamed UEFI bootkit in that campaign. DLL sideloading with an encrypted payload and OLLVM are common among Chinese-speaking actors, but neither proves who ran this. Initial access has not been published.
What to do
1. Find out whether PCA 2011 is revoked. In an elevated PowerShell session, this returns True only when the revocation is in the firmware:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
At fleet scale, look for Event ID 1037 in the System log, source TPM-WMI: "Secure Boot Dbx update to revoke Microsoft Windows Production PCA 2011 is applied successfully." A machine that has never logged it is exposed.
2. Put the 2023 certificate and boot manager in place first. Revoking PCA 2011 on a machine that still boots a PCA 2011 signed boot manager leaves it unbootable. Microsoft's KB5025885 runs the steps through the AvailableUpdates DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot, followed by the scheduled task \Microsoft\Windows\PI\Secure-Boot-Update. Value 0x5944 adds Windows UEFI CA 2023 to the DB and installs the new boot manager (Events 1036 and 1799). Confirm UEFICA2023Status under ...\SecureBoot\Servicing reads Updated. Our October 4 post covers that rollout and the event codes for failures.
3. Apply the revocation. Set AvailableUpdates to 0x80 and run the task. Event 1037 confirms it. Optionally follow with 0x200, which writes a Secure Version Number to the DBX to block older boot managers (Event 1042). Event 1033 means a revoked boot manager is still on the ESP, and the DBX change is held back until it is replaced.
Before step 3, escrow BitLocker recovery keys (manage-bde -protectors -get %systemdrive%), refresh install and recovery media, and update every Windows install on dual boot machines. Microsoft warns the revocation cannot be undone, even by reformatting the disk. Pilot one device per hardware model. Microsoft lists known problems on HP Sure Start devices, VMware VMs with Secure Boot, Apple Boot Camp and systems using Symantec Endpoint Encryption.
4. If you cannot revoke today, reduce who can reach the ESP. BlackX needs local administrator rights, so tighten admin accounts on diplomatic, executive and server hosts and alert on any process other than Windows servicing writing to the ESP.
5. Hunt for compromise. Search endpoints for C:\ProgramData\Intel\inst.exe, a file named PVMDIJGKAX2, googleupdate.exe paired with v8_context_snapshot.bin outside a Chrome or Electron install, the MD5 above, and DNS lookups of archivetj[.]com. Check driver load events (Sysmon Event ID 6) for the Mingyu certificate serial. Mount the ESP with mountvol S: /s from an elevated prompt and look for folders or files that do not belong to Windows. BlackLotus created an ESP:\system32\ folder and dropped grubx64.efi, and BlackX may leave similar traces, although Kaspersky has not published its file list. A grubx64.efi on a Windows only machine has no business there. Because the driver lies about its own files, inspect a suspect disk offline or from trusted boot media rather than trusting the live system.
6. Clean up properly. A confirmed infection means rebuilding: disconnect the host, wipe and reinstall Windows and the ESP from clean media, apply steps 2 and 3 before it rejoins the network, and treat every credential used on it as stolen. Reinstalling Windows without the revocation lets the same bootkit go straight back on.
Patches that need a second step
BlackX worked because a fix existed but stayed switched off. Microsoft's plan includes an Enforcement Phase that revokes PCA 2011 automatically, and as of October 22 it had not started. The certificate's expiry on October 19 does not help either. Kaspersky notes that the vulnerable binaries still load after that date unless PCA 2011 is in the DBX. Keep a short list of fixes that need a registry value, a task or a policy after install, and track their completion separately from patch compliance.
If you want help with the DBX rollout across mixed hardware, our safeguarding and hardening team does this work, and security operations can run the hunt. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Kaspersky Securelist: How APT41 revived the BlackLotus bootkit, NetManageIT summary of the BlackX report, Guardian MSSP: BlackX bypasses Secure Boot, Microsoft KB5025885: Managing boot manager revocations, Microsoft: Secure Boot DB and DBX update events, NVD: CVE-2022-21894, NSA: BlackLotus mitigation guide, Microsoft: Guidance for investigating BlackLotus.