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

A newly identified UEFI bootkit called BlackX has been used in cyberespionage operations targeting diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan.

The malware attacks Secure Boot, the firmware feature intended to prevent untrusted code from running before Windows starts.

Researchers report that the affected machines had received Windows updates, but a crucial Secure Boot revocation step had not been fully applied on firmware, leaving the systems vulnerable.

Securelist published the findings on October 22, 2026. According to the report, BlackX exploits Baton Drop (tracked as CVE-2022-21894) and reuses design elements from the BlackLotus bootkit.

The report highlights why installing an update does not always mean the protection it provides is active in firmware. Securelist’s analysis describes the BlackX malware and the campaign in detail.

BlackX is deployed after attackers obtain access to a victim network and administrative privileges. The installer, named inst.exe, uses an encrypted file called PVMDIJGKAX2, which contains the components required to install the bootkit.

Securelist notes that this packaging can complicate incident response because not all bootkit components are necessarily recoverable from the installer alone. The bootkit uses Baton Drop to load attacker-controlled EFI files and undermine Secure Boot protections.

EFI binaries run during system startup, before Windows loads. By inserting itself into that early phase, a bootkit can execute malicious code before many operating-system security controls are active.

Hackers Use New BlackX Bootkit

Securelist says the campaign’s kernel-mode driver attempts to weaken security monitoring by disrupting process, thread and registry callbacks and by tampering with Event Tracing for Windows (ETW), which many security products use to collect system activity.

The driver also attempts to hide files: when certain file requests occur, it reportedly returns a handle to the legitimate calc.exe process instead of the requested malicious file.

The bootkit also drops user-mode espionage payloads. One is a remote-access Trojan that can load additional .NET modules and use Google Drive, OneDrive or Yandex.Disk for command-and-control communications.

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

Securelist links the activity to APT41 with medium confidence, citing overlaps with previously reported activity and shared technical details. That assessment is not definitive attribution.

Why Patched Systems Were Still at Risk

The problem was not simply missing Windows updates. Securelist explains that protection against Baton Drop depends on revoking trust in the “Windows Production PCA 2011” certificate that was used to sign vulnerable UEFI components.

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

Microsoft warns that blocking older boot components can affect recovery media and other boot options, so administrators should test changes and prepare recovery procedures before broad deployment.

The distinction matters because Windows may report that updates are installed even when the firmware’s forbidden-signature list has not been updated. Securelist reported that the certificate’s expiration on October 19, 2026, did not by itself prevent vulnerable binaries from loading; the certificate must be explicitly blocked by the relevant revocation mechanism.

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

BlackX is not the first instance that highlights trust in legacy boot components. Previous coverage of BlackLotus showed how downgrade techniques can leave a Windows device exposed despite appearing up to date. That history 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 applied. Organizations should review Microsoft’s deployment guidance, verify that the necessary revocations have taken effect, and check boot and recovery media for compatibility.

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

Indicators of Compromise (IoCs)

Note: IP addresses and domains are intentionally defanged (for example, [.]) 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 and integrate threat intelligence feeds with data from your SOCs and monitoring systems.