Hackers Use New BlackX Bootkit to Bypass Windows Secure Boot on Fully Patched Systems

A new UEFI bootkit called BlackX has been used in cyberespionage attacks against diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan.

The malware targets Secure Boot, a feature designed to help stop untrusted software from running before Windows starts.

Researchers say the infected computers had received Windows updates, but a key Secure Boot protection had not been fully applied.

Securelist analysts reported the findings on October 22, 2026. They say BlackX uses Baton Drop, a vulnerability tracked as CVE-2022-21894, and shares parts of its design with the BlackLotus bootkit.

The findings show why an installed update does not always mean that the protection it is meant to provide has been fully activated. Securelist’s BlackX report describes the malware and the campaign in detail.

BlackX is installed after attackers have already gained access to a victim’s network and administrator-level rights. Its installer, inst.exe, works with an encrypted file named PVMDIJGKAX2, which contains components needed to install the malware.

Securelist says this design can make it harder for incident responders to recover all the bootkit’s parts from the installer alone. The bootkit uses Baton Drop to load attacker-controlled EFI files and interfere with Secure Boot.

EFI files run during the computer’s startup process, before Windows loads. By gaining a place in that early sequence, a bootkit can give malicious code a chance to run before many operating-system security tools are active.

Hackers Use New BlackX Bootkit

Readers can learn more about related boot-time risks in this Cybersecurity News report on managing UEFI Secure Boot settings.

Securelist says the campaign’s kernel driver attempts to weaken security tools by disrupting process, thread, and registry callbacks, and by interfering with Event Tracing for Windows (ETW), which software can use to collect system activity.

It also tries to hide its files: when certain file requests are made, the driver reportedly returns a handle to the legitimate calc.exe process instead of to the requested malicious file.

The bootkit also delivers user-mode malware for espionage. One payload is a remote-access Trojan that can load additional .NET code and use Google Drive, OneDrive, or Yandex.Disk for command-and-control communication.

Another, named OxiDLLRunner by the researchers, decrypts a file called v8_context_snapshot.bin and runs a Rust payload that contacts a reported command-and-control domain.

The report links the activity to APT41 with medium confidence, based on overlaps with previously reported activity and shared technical details. That assessment is not definitive attribution.

Why patched systems were still at risk

The issue was not simply that the targeted computers lacked Windows updates. Securelist says the protection against Baton Drop depends on revoking trust in the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components.

Installing an update and applying that revocation are separate steps in the process described by the researchers. Microsoft’s guidance for CVE-2023-24932 also describes multiple steps for deploying Secure Boot protections, including updating certificates, boot managers, and the UEFI revocation list.

Its instructions warn that blocking older boot components can affect recovery media and other boot options, so administrators should test changes and prepare recovery options before applying them broadly. See Microsoft’s Secure Boot revocation guidance.

The distinction matters because Windows may report that updates are installed even when the firmware’s forbidden-signature list has not yet been updated as intended.

Securelist reported that the certificate’s expiration on October 19, 2026, did not by itself stop vulnerable binaries from loading; the certificate must be blocked by the relevant revocation mechanism.

Administrators should therefore verify their devices’ Secure Boot configuration and revocation status, following Microsoft’s current instructions and accounting for their organization’s boot and recovery needs.

BlackX is not the first bootkit story to raise questions about trust in old boot components. Cybersecurity News has previously covered BlackLotus and how a downgrade technique could leave a Windows device exposed despite an up-to-date status.

That background helps explain why Secure Boot protection depends on more than the visible update state of Windows. The main lesson for defenders is to confirm that Secure Boot protections are active in firmware, not only that Windows updates have been installed.

Organizations should review Microsoft’s deployment guidance, verify that the necessary revocations have taken effect, and check boot and recovery media for compatibility.

Since BlackX was installed after attackers obtained administrator access, teams should also investigate suspicious administrative activity and boot-related changes, and review endpoint alerts for signs that security monitoring has been tampered with.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.