Last updated: 26 October 2026. Sources are listed at the end.
Kaspersky has published research on BlackX, a UEFI bootkit that loads before Windows on machines that are fully patched. The catch is simple. Those machines never applied the manual Secure Boot revocations that Microsoft has asked admins to enable since 2023. As a result, an old and well-known flaw still works on them.
Kaspersky’s report appeared on 22 October 2026, and The Hacker News covered it on 23 October. The researchers say the targets were diplomatic organisations in Tajikistan, Uzbekistan and Turkmenistan in early 2026. They attribute the activity to the China-linked group APT41 with medium confidence.
If you run Windows laptops or servers with Secure Boot on, this matters to you too. The weakness BlackX abuses is a configuration gap, not a missing patch. So your monthly update dashboard can look green while the gap stays open.
The short answer
- Check that Secure Boot is on, then check whether “Microsoft Windows Production PCA 2011” sits in your DBX (the revocation list). The commands are below.
- If it is not revoked, plan the KB5025885 revocation steps. Test on one device per hardware model first, because the change cannot be undone while Secure Boot stays on.
- Back up BitLocker recovery keys and build fresh recovery media before you revoke anything.
- Also confirm the 2023 Secure Boot certificates are in place, since the 2011 certificates expired in June and October 2026.
- Remember that installing BlackX needs administrator rights. Tight admin control is still your best first defence.
What the BlackX UEFI bootkit is and how it beats Secure Boot
Secure Boot checks signatures on everything that runs before Windows. Firmware trusts code signed by certificates in its allow list, called the DB. It refuses anything that matches the deny list, called the DBX.
In January 2022, Microsoft fixed CVE-2022-21894, a Secure Boot bypass nicknamed “Baton Drop”. However, the vulnerable boot managers were still signed by Microsoft. So an attacker with admin rights could simply copy an old, signed boot manager onto the disk. The firmware still trusted it, and the old bug came back. Microsoft tracked that downgrade route as CVE-2023-24932, the BlackLotus bypass.
The real fix is to stop trusting the old signing certificate altogether. That means adding “Microsoft Windows Production PCA 2011” to the DBX. Microsoft made this an opt-in step in KB5025885. According to Kaspersky, the automatic “Enforcement Phase” had still not started when it published. Kaspersky also notes that the certificate expired on 19 October 2026. However, expiry alone does not stop old binaries from loading. Only a DBX entry does that.
BlackX, in Kaspersky’s analysis, is an updated version of BlackLotus. That UEFI bootkit went on sale in late 2022, and ESET confirmed it in March 2023. Its full source code was never public, so The Hacker News notes the BlackX authors either reverse-engineered it or got it elsewhere.
The infection chain, as Kaspersky describes it
- The attackers first gain administrator access. Kaspersky does not say how they got in.
- They drop
inst.exeand an RC4-encrypted file calledPVMDIJGKAX2intoC:\ProgramData\Intel\. - The installer runs with the RC4 key
Q46F6MDLI3RX2KV1as an argument. In addition,inst.exeitself holds no malicious strings, which helps it avoid detection. - It writes files to the system and EFI partitions and exploits Baton Drop. The goal is to enrol custom Machine Owner Keys (MOK), which then let arbitrary EFI files load.
Kaspersky’s report does not name the exact boot manager or EFI component used. So treat any blog that names a specific file as guesswork.
What happens after boot
Once the UEFI bootkit runs, it injects a kernel driver into Windows. That driver carries a signature from a certificate issued to “Wenjiang District Mingyu Network Technology Service Studio”. The issuer has since revoked it. The driver tries to blind security tools by disabling process, thread and registry callbacks and tampering with ETW. It also hides the bootkit’s own files by handing back a handle to calc.exe when something tries to open them.
Two user-mode payloads follow. First, a remote access tool uses Google Drive, OneDrive and Yandex.Disk as its command channel. It can run .NET code, upload and download files, and collect system details. Second, a DLL called OxiDLLRunner gets sideloaded by a legitimate googleupdate.exe. It decrypts v8_context_snapshot.bin and runs a Rust payload that contacts www[.]archivetj[.]com for plugins.
How solid is the APT41 link?
Kaspersky says “medium confidence”, and that wording matters. The main clue is a shared “xdd” string. It appears in BlackX and in a June 2026 ESET report on FishMonger, a group widely placed under the APT41 umbrella. The researchers also point to DLL sideloading with an encrypted companion file and OLLVM obfuscation. Those traits are common among Chinese-speaking actors, but they are not unique to them.
Kaspersky did not publish a victim count. We found no public report of BlackX outside Central Asia so far.
Am I affected by the UEFI bootkit gap?
| Machine state | Risk from BlackX-style bypass |
|---|---|
| Secure Boot off, or legacy BIOS | Secure Boot gives no protection at all; fix this first |
| Secure Boot on, PCA 2011 not in DBX | Exposed: the gap Kaspersky describes |
| Secure Boot on, PCA 2011 in DBX, 2023 CA in DB | Protected against this downgrade route |
| Above, plus SVN update applied (event 1042) | Also blocks older 2023-signed boot managers |
Run these in an elevated PowerShell window. They only read state. They come from Microsoft’s documentation, and we syntax-checked them in PowerShell 7.4.
# True = Secure Boot on; False = off; "not supported" = legacy BIOS
Confirm-SecureBootUEFI
# Is the new Windows UEFI CA 2023 in the DB? Want: True
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
# Is the old PCA 2011 revoked in the DBX? Want: True
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
# Certificate servicing status. Want: Updated
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023StatusYou can also open msinfo32 and look at “Secure Boot State” in System Summary. That confirms only whether Secure Boot is on. It says nothing about revocations.
Next, check the Secure Boot servicing events. Microsoft’s KB5016061 lists them under the System log with the TPM-WMI source.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1036,1037,1042,1795,1796,1797,1798,1799,1801,1808} -MaxEvents 50 -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -like '*TPM-WMI*' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List| Event ID | Meaning (per KB5016061) |
|---|---|
| 1036 | DB update applied |
| 1037 | DBX update revoking PCA 2011 applied |
| 1042 | SVN update applied, older boot managers blocked |
| 1795 / 1796 | Firmware or update error; Windows retries after restart |
| 1797 / 1798 | DBX update blocked: 2023 CA or 2023-signed boot manager missing |
| 1799 | Boot manager signed with Windows UEFI CA 2023 installed |
| 1801 | Certificates updated but not yet applied to firmware |
| 1808 | Device has the updated Secure Boot CA/keys |
If you never see event 1037, your machines most likely still trust PCA 2011.
How to apply the revocations safely
Plan this carefully, because a mistake can leave a machine unbootable. Microsoft’s KB5025885 gives the full process. These are the main points.
- Back up BitLocker keys first. Microsoft suggests
manage-bde -protectors -get %systemdrive%from an elevated prompt. Some devices may enter BitLocker recovery. - Then pick one test device per hardware model. Some firmware rejects DB or DBX updates, so check vendor BIOS updates first.
- Next, add the 2023 certificates to the DB (step 1 in the KB). Confirm event 1036 and the
Trueresult above. - After that, create a recovery USB drive. Older install and recovery media will not boot once PCA 2011 is revoked.
- Finally, apply the DBX revocation (step 3 in the KB) and confirm event 1037.
These commands come from KB5025885 and change firmware variables. So run them only on a test device you have prepared.
# Step 1: add 2023 certificates to DB (from KB5025885)
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"
# Step 3: revoke Windows Production PCA 2011 (irreversible while Secure Boot stays on)
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"Microsoft lists an optional SVN step (value 0x200). It also warns that on April 2026 or later updates, revoking PCA 2011 applies SVN 5.0. That can break boot media built with updates from January 2025 or earlier. Meanwhile, for fleets, Intune or Group Policy beats running these commands by hand.
The 2026 certificate expiry
Microsoft’s certificate expiry page lists these dates. Microsoft Corporation KEK CA 2011 expired on 24 June 2026. Microsoft UEFI CA 2011 expired on 27 June 2026. Microsoft Windows Production PCA 2011 expired on 19 October 2026.
Machines without the 2023 replacements keep booting. However, Microsoft says they can no longer receive new boot-level protections, including DBX updates. In other words, a device stuck on 2011 certificates cannot get the next revocation either.
Linux and dual-boot machines
BlackX targets Windows. Still, Linux servers rely on the same firmware lists. These checks are read-only, apart from refresh, which only downloads metadata:
mokutil --sb-state
mokutil --dbx | head -20
fwupdmgr refresh
fwupdmgr get-devices
fwupdmgr get-updatesfwupd treats the UEFI dbx as an updatable device, so a pending dbx update shows up in get-updates.
How to check for a UEFI bootkit infection
Kaspersky did not publish a formal IOC table. The indicators below appear in its report.
- Files:
C:\ProgramData\Intel\inst.exeandC:\ProgramData\Intel\PVMDIJGKAX2 - Installer argument (RC4 key):
Q46F6MDLI3RX2KV1 - C2 domain:
www[.]archivetj[.]com - Sideloading host:
googleupdate.exewith original namejcef_helper.exe, MD5AF8A983B9ADA07EAE1259BF2953ABD40(a legitimate file abused for sideloading) - Payload file:
v8_context_snapshot.binalongside that executable - Driver signing certificate serial:
0bcdf5e0da32d68900b8b7638459d072 - Payload string:
xdd
Get-Item "C:\ProgramData\Intel\inst.exe", "C:\ProgramData\Intel\PVMDIJGKAX2" -ErrorAction SilentlyContinue
Get-CimInstance Win32_Process -Filter "Name='googleupdate.exe'" | Select-Object ProcessId, ExecutablePath, CommandLineAlso search DNS and proxy logs for archivetj. Unexpected traffic to Google Drive, OneDrive or Yandex.Disk from servers deserves a look too.
Microsoft’s 2023 BlackLotus guidance adds generic checks. For example, look for mismatched timestamps on EFI partition files and HVCI being switched off. Also compare the Measured Boot logs in C:\Windows\Logs\MeasuredBoot across reboots. Those are BlackLotus indicators, not confirmed BlackX ones. Finally, if you find an infection, Microsoft advises isolating the device and reformatting both the OS and EFI partitions.
Is there an India angle?
Kaspersky reports no Indian victims. However, APT41 has history here. In 2020, the US Justice Department charged APT41 members and said they compromised government networks in India. So Indian ministries, missions and their suppliers should treat this as relevant.
Under CERT-In’s April 2022 Directions, covered entities must report qualifying incidents within six hours. In addition, DPDP Rule 7 will require a detailed report to the Data Protection Board within 72 hours once it applies in May 2027, so build that step into your response plan now.
Quick checklist
- ☐ Run
Confirm-SecureBootUEFIon every Windows machine - ☐ Check the DB for Windows UEFI CA 2023 and the DBX for PCA 2011
- ☐ Search the System log for events 1036, 1037, 1042 and 1795–1808
- ☐ Back up BitLocker recovery keys
- ☐ Build new recovery media before revoking PCA 2011
- ☐ Test KB5025885 steps on one device per model, then roll out
- ☐ Review who holds local admin rights
- ☐ Hunt for the Kaspersky indicators listed above
- ☐ Run
mokutil --sb-stateandfwupdmgr get-updateson Linux hosts
A UEFI bootkit gap like this one rarely shows up in normal patch reports. If you want a second pair of eyes, our VAPT services include firmware and endpoint configuration checks. For Linux fleets, start with our Linux server hardening checklist. You may also find our Black October 2026 fact check useful for separating real threats from noise.
Sources
- Kaspersky Securelist: How APT41 revived the BlackLotus bootkit (22 Oct 2026)
- The Hacker News: BlackX UEFI Bootkit Bypasses Secure Boot (23 Oct 2026)
- Microsoft KB5025885: Managing Windows Boot Manager revocations (CVE-2023-24932)
- Microsoft KB5016061: Secure Boot DB and DBX variable update events
- Microsoft: Windows Secure Boot certificate expiration and CA updates
- Microsoft Learn: Confirm-SecureBootUEFI
- Microsoft Security Blog: Investigating attacks using CVE-2022-21894 (BlackLotus)
- US Department of Justice: APT41 actors charged (16 Sep 2020)
Worried about targeted attacks on your business? Our VAPT services find weaknesses before attackers do, and our OSINT investigations show what is exposed about your organisation online. Contact us for a quote.
