BlackX, an APT41-linked UEFI bootkit, used Baton Drop (CVE-2022-21894) to beat Secure Boot on patched Windows. How to check the DBX revocation.
Every Windows update was installed and Secure Boot (the check that lets only trusted startup code run) was switched on, yet a spy tool still loaded before Windows did. Kaspersky found it on government machines in Central Asia, and the gap it used is just as common on ordinary business PCs: a fix that was downloaded but never switched on.
Run read-only checks on every Windows PC, server and Secure Boot virtual machine you manage to see whether the DBX blocks the old certificate and whether any of Kaspersky's indicators turn up. Run them as administrator in PowerShell through your RMM (remote monitoring and management) tool.
New-Item -ItemType Directory -Path C:\IR -Force
reg export HKLM\SYSTEM\CurrentControlSet\Control\Secureboot C:\IR\secureboot.reg /y
wevtutil epl System C:\IR\System.evtx
False means the machine is exposed. The command comes from Microsoft's KB5025885. If it errors as unsupported, Secure Boot is off. That is a bigger gap, because a bootkit then needs no bypass at all.[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
Updated means the earlier steps aren't finished.(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status
Test-Path C:\ProgramData\Intel\inst.exe
Get-ChildItem C:\ -Recurse -Force -Filter PVMDIJGKAX2 -ErrorAction SilentlyContinue
Get-ChildItem C:\ -Recurse -Force -Filter googleupdate.exe -ErrorAction SilentlyContinue | Get-FileHash -Algorithm MD5 | Where-Object Hash -eq 'AF8A983B9ADA07EAE1259BF2953ABD40'
Get-ChildItem C:\Windows\System32\drivers -Filter *.sys | Get-AuthenticodeSignature | Where-Object { $_.SignerCertificate.SerialNumber -eq '0BCDF5E0DA32D68900B8B7638459D072' }
Get-DnsClientCache | Where-Object Entry -like '*archivetj*'. If the client's firewall or DNS filter sends its logs to a Linux syslog server, search there too:find /var/log -type f -exec zgrep -li archivetj {} +
Get-LocalGroupMember Administrators, list domain admins on a domain controller with Get-ADGroupMember 'Domain Admins', and question every name you don't recognise.Indicators from Kaspersky. The BlackX driver hides the bootkit's files from Windows, so a clean result in steps 4 and 5 does not prove a machine is clean. Treat any hit as a confirmed infection.
The fix is to apply Microsoft's manual revocations from KB5025885 in order: add the 2023 certificate first, then block PCA 2011 in the DBX, then apply the version-number (SVN) update. Microsoft designed the steps so they cannot be deployed in the wrong order.
manage-bde -protectors -get %systemdrive% and make a FAT32 recovery USB first. Microsoft warns that some devices enter BitLocker recovery and that old boot media may stop working.Updated. A restart may be needed.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"
True. This step is permanent ("even reformatting of the disk will not remove the revocations"), so test it on one device of each model first. Microsoft lists known issues on HP Sure Start devices, VMware VMs with Secure Boot and Symantec Endpoint Encryption.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"
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"
Any Windows PC or server using Secure Boot whose DBX doesn't yet block the Windows Production PCA 2011 certificate can still be made to load old, flawed boot managers, however up to date Windows itself is.
Kaspersky attributes BlackX, with medium confidence, to China-linked APT41. It hit diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan in early 2026. BleepingComputer reports that all the victims ran fully patched Windows.
Because the Baton Drop patch only updates Windows. Blocking the old certificate in the firmware is a separate step, and Kaspersky says "the user has to trigger it manually". Think of it as changing the office locks but leaving the old master key on the front desk's approved list. Anyone holding that key can still get in.
The expiry date has fooled people. The PCA 2011 certificate expired on 19 October 2026, but Kaspersky's report is blunt: "this certificate expired, but this does not prevent the vulnerable binaries from loading." Only the DBX block stops them. Microsoft does plan an "Enforcement Phase" that will apply the revocation automatically, but KB5025885 gives no date for it, so for now your clients' machines are protected only if you take the steps yourself.
BlackX came at the end of the break-in, not the start. Kaspersky says the attackers already had administrator rights when they installed it, and doesn't say how they got in. That earlier path is where your clients' real exposure sits. KinoSec runs autonomous pentests against your clients' web apps, external networks and Active Directory. It chains findings the way an attacker would to show whether someone outside could reach admin rights, and it writes up each finding with remediation you can hand to your client. It won't read a laptop's DBX. The PowerShell checks above do that, and their results belong in your patch-compliance report next to the pentest report.
BlackX is a UEFI bootkit, malware that runs in a PC's startup code before Windows loads. Kaspersky disclosed it on 22 October 2026 and attributes it, with medium confidence, to China-linked APT41. It uses Baton Drop (CVE-2022-21894) to get past Secure Boot and then loads a driver that tampers with security tools.
Run Test-Path C:\ProgramData\Intel\inst.exe on each machine, an installer path that Kaspersky lists. Then run the file, driver and domain searches in steps 4 to 6 of "How do I check whether my clients' PCs are exposed to BlackX?". Because the BlackX driver hides the bootkit's files, treat any hit as a confirmed infection and a clean result as unproven.
Yes, some devices can fail to boot or ask for the BitLocker recovery key. Microsoft's KB5025885 says to back up the key with manage-bde -protectors -get %systemdrive% and to make a FAT32 recovery USB first. Test on one device of each model, because the change can't be undone.
Reinstalling does not undo the revocation: Microsoft says "even reformatting of the disk will not remove the revocations". Microsoft also says its mitigations are "preventive and not corrective", so a machine that is already infected needs incident response and a rebuild, not just the revocation steps.