The BlackX UEFI bootkit explained: why fully patched Windows PCs still loaded it, and how to check and apply…
EXPLAINER · MONDAY, OCTOBER 26, 2026
The BlackX UEFI bootkit explained: why fully patched Windows PCs still loaded it, and how to check and apply the Secure Boot revocation Microsoft leaves off by default
On October 22, 2026, Kaspersky reported BlackX, a UEFI bootkit it ties to APT41 with medium confidence, on fully patched Windows machines at diplomatic agencies in Central Asia. The fix that would have blocked it ships turned off. This page gives Microsoft's own commands to check a PC, the order to apply the fix in, and what can stop a PC from booting.
In one minute
- Kaspersky found a UEFI bootkit it calls BlackX on machines at diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. It ties the attack to APT41 with medium confidence.
- BlackX uses Baton Drop (CVE-2022-21894), the same Secure Boot bypass as the BlackLotus bootkit that ESET confirmed in 2023. Attackers installed it after they already had admin rights.
- The machines were fully patched. Microsoft's fix (KB5025885, CVE-2023-24932) works by putting the old "Windows Production PCA 2011" certificate in the firmware's blocked list, but that step is off by default and has to be turned on by hand.
- A PC can show "Updated" for the new 2023 certificate and still trust PCA 2011. Microsoft's revocation is a separate step (AvailableUpdates 0x80), and the certificate rollout value (0x5944) does not include it.
- The certificate expired on October 19, 2026. Kaspersky says that does not stop old files from loading unless the certificate is blocklisted.
- The revocation cannot be undone while Secure Boot is on. Back up BitLocker keys, make new recovery media, and test one PC per model first.
What Kaspersky found
Kaspersky's GReAT team says it found the attack in early 2026. The targets were diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan.
- The attackers first broke into the network and got admin rights. Then they dropped two files: an installer, inst.exe, and an RC4-encrypted file named PVMDIJGKAX2 that holds everything the installer needs.
- The installer exploits Baton Drop (CVE-2022-21894) to bypass Secure Boot. Kaspersky says the exploit is "remarkably similar" to the one in BlackLotus, and its goal is the same: install the attackers' own Machine Owner Keys (MOK), so the firmware will load any EFI file they sign.
- The bootkit then loads a kernel driver. The driver turns off security tools' callbacks, tampers with ETW so those tools lose their data, and hides the bootkit's files by handing back a handle to calc.exe when something tries to open them.
- The driver also installs spy tools: a RAT that uses Google Drive, OneDrive or Yandex.Disk for its commands, and a loader Kaspersky calls OxiDLLRunner that talks to a command server.
Kaspersky ties the attack to APT41 with medium confidence. One reason: the name "xdd" shows up in BlackX and in a PDB path ESET reported in June 2026 for the FishMonger group, which is thought to be linked to APT41. BlackLotus source code was never published, so Kaspersky says the attackers either reverse-engineered it or bought it.
NVD lists Microsoft's scores for both CVEs as Medium: 4.4 for CVE-2022-21894 and 6.7 for CVE-2023-24932. Both need high privileges. That fits this attack: the bootkit is how attackers stay on a machine they already own, not how they get in.
Why patched was not enough
Kaspersky first thought the victims had skipped updates. They had not: "the targeted machines were fully patched."
The fix only works once the "Windows Production PCA 2011" certificate is revoked. That is the certificate that signed the old, vulnerable boot files the exploit needs. Installing the monthly update does not revoke it. Kaspersky says an admin has to set a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and run a scheduled task named Secure-Boot-Update.
Kaspersky calls this "the patch for the Baton Drop vulnerability." Microsoft tracks the revocation under a later CVE, CVE-2023-24932, in KB5025885, and says the same thing in its own words. The mitigations ship in the July 9, 2024 updates and later, but "these mitigations are not enabled by default."
Microsoft has a plan to make this automatic, called the Enforcement Phase. KB5025885 says it "will not begin before January 2026" and that Microsoft will give "at least six months of advance warning" in that article. The article still names no date. Kaspersky says the phase has not happened yet.
Kaspersky's reason the fix is manual: doing it automatically could break dual-boot systems that still rely on PCA 2011. Its point is that admins rarely take extra steps after an update installs cleanly, and these steps are hard to find.
"Updated" is not the same as revoked
This is the easy trap in 2026. Microsoft is replacing its 2011 Secure Boot certificates, and many PCs are getting the new 2023 certificate on their own. That rollout is not the revocation.
- Microsoft's registry guide (KB5068202) tells fleets to set AvailableUpdates to 0x5944. It describes that value as: "Deploy all needed certificates and update to the PCA2023 signed boot manager." When it finishes, UEFICA2023Status reads Updated.
- The step that blocks PCA 2011 is a different value, 0x80, in KB5025885. The step that sets the firmware's minimum boot manager version (the SVN) is 0x200.
- Do the bit math: 0x5944 does not contain the 0x80 bit or the 0x200 bit. So a PC can trust the new 2023 boot manager and still trust every old boot manager signed with PCA 2011.
- KB5025885 also says Step 1 "may already be complete if the device was marked High Confidence" in the monthly updates. That note is about the certificate step only. None of the Microsoft pages we read says the automatic rollout adds PCA 2011 to the blocked list.
So a dashboard that shows UEFICA2023Status = Updated across the fleet does not prove the fleet is safe from BlackX. Check the blocked list (DBX) itself.
Check a machine
All three checks come from KB5025885, word for word. Run them in PowerShell as Administrator. They only read.
Run in an Administrator PowerShell window. These three lines only read; they change nothing.
1. Is the new "Windows UEFI CA 2023" certificate in the allowed list (DB)? Want: True
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
2. Did the certificate and new boot manager update finish? Want: Updated
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status
3. Is the old "Windows Production PCA 2011" certificate in the blocked list (DBX)? Want: True
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011' How to read the answers:
- Check 3 says True: PCA 2011 is blocked. Old PCA 2011 boot managers will not load from this PC's firmware.
- Check 3 says False: PCA 2011 is still trusted. This is the state Kaspersky found on the victims' machines, even if checks 1 and 2 look good.
- Check 1 False, or check 2 not Updated: start at step 1 below. Windows will refuse the revocation until both are done.
You can also look in Event Viewer, in the System log, for events from the source TPM-WMI. Microsoft lists one success event per step:
- 1036: the 2023 certificate was added to the DB.
- 1799: the boot manager signed with the 2023 certificate was applied.
- 1037: the DBX update that blocks PCA 2011 was applied.
- 1042: the DBX was updated with the newest SVN, which blocks older boot managers.
Microsoft says not to use the WindowsUEFICA2023Capable registry value for status. Use UEFICA2023Status. If UEFICA2023Error is not zero, the update hit an error, and the event log has the details.
Apply the fix in Microsoft's order
Microsoft says to install the latest monthly updates first, on every supported PC, whether or not you plan to turn on the fix. Then go one step at a time. Test on one PC of each model before you go wide.
Step 0. If the PC uses BitLocker, save the 48-digit recovery password first. Run this in an Administrator command prompt and write down the number:
manage-bde -protectors -get %systemdrive% Step 1. Add the 2023 certificate and the new boot manager. In an Administrator PowerShell window, run each line on its own:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
- Then run check 1. It should say True. A restart might be needed if Virtual Secure Mode features are on, such as Credential Guard, Device Guard or Windows Hello.
- Microsoft's registry guide adds detail for testing one PC: AvailableUpdates should quickly change to 0x4100. Reboot, run the task again, and it should become 0x4000. The task also runs on its own every 12 hours, and the boot manager may not change until a restart.
Step 2. Run check 2. It should say Updated. Do not go on until it does.
Step 3. Make recovery media, then block PCA 2011. Microsoft says to create a recovery flash drive first, on a PC that already has step 1. Use "Create a Recovery Drive", then, with the drive mounted as D:, run these as Administrator:
COPY D:\EFI\MICROSOFT\BOOT\BCD D:\EFI\MICROSOFT\BOOT\BCD.BAK bcdboot c:\windows /f UEFI /s D: /bootex COPY D:\EFI\MICROSOFT\BOOT\BCD.BAK D:\EFI\MICROSOFT\BOOT\BCD
- On a PC with more than one copy of Windows, update every copy to the July 9, 2024 updates or later first. Microsoft warns that a copy without them might not start after the revocation.
- Then block PCA 2011:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
- Confirm with check 3 (True) or event 1037.
Step 4. Set the SVN, the minimum boot manager version the firmware will run. Microsoft calls this step optional:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
- Confirm with event 1042. Each time Microsoft raises the SVN later, boot media needs updating again.
Microsoft's text says Command Prompt for steps 3 and 4. But Start-ScheduledTask is a PowerShell command, and Microsoft's own registry guide runs the same pair of lines from an Administrator PowerShell prompt. Use PowerShell for all four steps.
The steps are locked in order. Windows will not add PCA 2011 to the DBX if the 2023 certificate is missing from the DB (event 1797), or if the PC's default boot manager is still signed with PCA 2011 (event 1798). Those two checks look only at the PC's own DB and default boot manager. Microsoft warns separately that old media, PXE boot and Windows copies without the updates can still fail to start.
What can stop a PC from booting
KB5025885's warning is plain: once the fix is on, "it cannot be reverted if you continue to use Secure Boot on that device. Even reformatting of the disk will not remove the revocations." Here is what Microsoft lists as risks and known issues:
- Old boot media. After the revocation, recovery disks, install USB sticks and PXE boot files signed with PCA 2011 will not start. Microsoft also says that on a PC with updates from April 2026 or later, turning on the revocation applies SVN 5.0, which can make older external boot media fail.
- BitLocker. Some PCs go into BitLocker recovery. Have the key first. Event 1032 means Windows held an update back because of the BitLocker setup; KB5016061 says to suspend BitLocker for two restarts.
- Firmware that fails the update. Not every firmware can write the DB or DBX. Microsoft says to contact the PC maker.
- HP PCs with Sure Start: blocked until HP's latest firmware is installed.
- Arm64 PCs with Qualcomm firmware: blocked until a fixed firmware is detected. Arm64 PCs without Qualcomm firmware need the SkipDeviceCheck value set to 1 under the SecureBoot key.
- VMware: an x86 VM with Secure Boot on "will fail to boot after applying the mitigations."
- Symantec Endpoint Encryption: the fix cannot be applied.
- Windows Server 2012 and 2012 R2 with TPM 2.0: blocked until the updates released on or after April 8, 2026.
- A Secure Boot reset. If the firmware's Secure Boot settings are reset to defaults after the fix, the PC will not boot. Microsoft ships a repair app for this, securebootrecovery.efi, in the July 9, 2024 updates.
If a PC will not boot, Microsoft's recovery steps are: turn Secure Boot off, reset the Secure Boot keys to factory defaults (pick "Reset" over "Clear" if both exist), restore the boot files or reinstall Windows, then turn Secure Boot back on. The PC is open to bootkits while Secure Boot is off.
Why the October 19 expiry does not help
Microsoft lists October 19, 2026 as the expiry date of "Microsoft Windows Production PCA 2011". Its replacement is "Windows UEFI CA 2023".
Expiry is not revocation. Kaspersky says the expiry "does not prevent the vulnerable binaries from loading unless the certificate is blocklisted."
Microsoft's own October 22, 2026 note (KB5132953) agrees in effect. It says the expiry does not stop PCs from starting, and that the last boot managers signed with PCA 2011 are now "frozen" and will get no more security fixes. Microsoft will even keep those frozen boot managers on install media, and plans a script to boot them on older firmware. So old PCA 2011 boot files are not going away on their own. Only the DBX entry blocks them.
Kaspersky's indicators
Kaspersky's post has no separate indicator list or hash for the installer. These are the indicators named in its text. The domain is written with brackets so it is not a live link.
- Installer command line: C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The last argument is the RC4 key.
- Encrypted package: PVMDIJGKAX2, a file with no extension.
- Kernel driver signing certificate: issued to 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio), serial 0bcdf5e0da32d68900b8b7638459d072. Kaspersky says the issuer has revoked it.
- Sideloading host: googleupdate.exe, which is really the legitimate jcef_helper.exe (MD5 AF8A983B9ADA07EAE1259BF2953ABD40). It loads the OxiDLLRunner DLL, which decrypts v8_context_snapshot.bin from the same folder.
- Command server for the Rust payload: www[.]archivetj[.]com.
- The RAT reads and writes files on Google Drive, OneDrive or Yandex.Disk with the suffixes 0X01 to 0X06, plus SSSR for first system info.
If you think a PC is already infected, the revocation will not clean it. Microsoft says these mitigations are "preventive and not corrective" and to contact your security provider. Microsoft's 2023 hunting guide for BlackLotus is a starting point: it looks at recently changed, locked files in the EFI system partition, a staging folder under ESP:\system32\, HVCI being turned off in the registry, and Measured Boot logs. BlackX is a different build, so some of those signs may not match.
Who is affected
| Case | Status | | --- | --- | | Windows PCs with Secure Boot on and monthly updates installed, where check 3 says False | Exposed. This is the state Kaspersky found on the victims' machines. An attacker who gets admin rights can still use old PCA 2011 boot files. |
| PCs where UEFICA2023Status says Updated (from 0x5944 or the automatic High Confidence rollout) but check 3 says False | Still exposed. The new boot manager is in place, but PCA 2011 is still trusted. The rollout value does not include the 0x80 revocation. | | PCs where check 3 says True, or event 1037 is logged | The PCA 2011 route Kaspersky describes is closed. A PC that was infected before the fix is not cleaned by it. |
| VMware x86 VMs with Secure Boot, HP PCs with Sure Start, Arm64 PCs with Qualcomm firmware, PCs with Symantec Endpoint Encryption | Microsoft lists known issues: the fix is blocked, cannot be applied, or (on VMware) stops the VM from booting. Check each issue before you apply. | | Any machine before an attacker has admin rights or physical access | Not reachable this way. Microsoft says the attack needs admin or physical access, and Kaspersky says BlackX was installed after the network was already broken into. |
What to do
- Run the three read-only checks on one PC of each model you own. Check 3 is the one that matters for BlackX.
- Do not treat UEFICA2023Status = Updated as proof of safety. Report on the DBX check (or event 1037) instead.
- Before you block PCA 2011: save BitLocker recovery keys, make new recovery media, update every Windows copy on multi-boot PCs, and read Microsoft's known issues for your hardware and VMs.
- Apply the steps in order (0x5944, confirm Updated, 0x80, then 0x200) on one PC per model first, then roll out.
- Search your logs and endpoints for Kaspersky's indicators, especially C:\ProgramData\Intel\inst.exe and the archivetj domain.
What is still unknown
- Kaspersky publishes no hash for inst.exe or the bootkit files, and no full indicator list. The only hash in the post is for the legitimate jcef_helper.exe that the attackers abuse.
- The attribution to APT41 is Kaspersky's own, at medium confidence.
- Whether Microsoft's automatic "High Confidence" certificate rollout ever adds PCA 2011 to the DBX. The pages we read describe it as a certificate update only, and the 0x5944 value does not include the 0x80 bit.
- When the Enforcement Phase will start. KB5025885 names no date as of October 26, 2026, and promises at least six months of warning in that article first.
- Whether Microsoft's 2023 BlackLotus hunting signs catch BlackX. Kaspersky says BlackX's driver returns a calc.exe handle when its files are opened, which may not produce the same error Microsoft's guide looks for. Nobody we read has tested this.
- How the attackers got admin rights on the victims' networks. Kaspersky's post does not say.
- No statement from Microsoft about BlackX had been published on the pages we read as of October 26, 2026.
Sources
- [Georgy Kucherin, Vladimir Nestor and Vasily Berdnikov, "How APT41 revived the BlackLotus bootkit to attack diplomatic organizations in Central Asia" (Kaspersky Securelist, October 22, 2026)](https://securelist.com/uefi-bootkit-blackx/121539/) — the original report
- [Microsoft, KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932](https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d)
- Microsoft, KB5068202: Registry key updates for Secure Boot, Windows devices with IT-managed updates
- Microsoft, KB5016061: Secure Boot DB and DBX variable update events
- Microsoft, KB5062710: Windows Secure Boot certificate expiration and CA updates
- Microsoft, KB5084464: A Closer Look at the High Confidence Database
- [Microsoft Incident Response, "Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign" (April 11, 2023)](https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/)
- NVD, CVE-2022-21894 (Baton Drop)
Today's full edition: AI News Report · every headline, every morning.