BlackX Bootkit Bypasses Windows Secure Boot on Patched Systems

Key Takeaways

• A new UEFI bootkit, BlackX, has been identified in cyberespionage campaigns targeting diplomatic entities in Central Asia.
• BlackX exploits the Baton Drop vulnerability (CVE-2022-21894) to bypass Windows Secure Boot, even on systems that appear to be fully patched.
• The bypass occurs because applying Windows updates does not automatically revoke vulnerable certificates in the UEFI firmware, a separate critical step.
• The bootkit shares design elements with BlackLotus and installs additional user-mode malware for espionage, utilizing cloud services for command and control.
• Defenders must manually verify Secure Boot revocation status and firmware configurations, beyond just checking Windows update history.

BlackX Bootkit Bypasses Windows Secure Boot on Patched Systems

A sophisticated new UEFI bootkit, dubbed BlackX, has emerged in targeted cyberespionage operations against diplomatic organizations across Tajikistan, Uzbekistan, and Turkmenistan. This advanced malware is designed to circumvent Windows Secure Boot, a fundamental security feature intended to prevent unauthorized software from executing during the system startup sequence.

Intriguingly, the compromised systems had reportedly received regular Windows updates, yet remained vulnerable. This critical finding underscores a significant gap in protection: the installation of operating system updates does not always equate to the full activation of all associated security mechanisms, particularly those residing in the firmware layer.

Unveiling BlackX: Technical Details and Campaign

Analysts at Securelist published their comprehensive findings on October 22, 2026, detailing BlackX’s capabilities. According to their Securelist’s BlackX report, the bootkit leverages the Baton Drop vulnerability, identified as CVE-2022-21894. The researchers also noted architectural similarities between BlackX and the previously identified BlackLotus bootkit.

BlackX’s deployment follows an initial compromise where attackers have already secured network access and administrator-level privileges. Its installer, named inst.exe, works in conjunction with an encrypted file, PVMDIJGKAX2, which contains the necessary components for the malware’s installation. This modular design, as per Securelist, complicates incident response efforts, making it challenging to reconstruct the entire bootkit from the installer alone. The bootkit exploits Baton Drop to load attacker-controlled EFI files, effectively subverting Secure Boot’s integrity checks.

EFI (Extensible Firmware Interface) files are executed very early in the boot process, preceding the loading of the Windows operating system. By injecting malicious code at this stage, a bootkit establishes a persistent foothold that operates beneath the visibility and control of many conventional operating system-level security tools.

Beyond its bootkit capabilities, BlackX deploys a kernel driver that actively works to undermine system security. This driver attempts to disable or interfere with critical security functions, including process, thread, and registry callbacks, as well as Event Tracing for Windows (ETW), which is used by software to monitor system activities. Furthermore, it employs stealth techniques to hide its presence; when requests for specific malicious files are made, the driver reportedly returns a handle to the legitimate calc.exe process instead.

The espionage campaign also involves the delivery of user-mode malware. One notable payload is a remote-access Trojan (RAT) capable of loading additional .NET code and leveraging popular cloud storage services like Google Drive, OneDrive, or Yandex.Disk for command-and-control (C2) communications. Another payload, dubbed OxiDLLRunner by researchers, decrypts a file named v8_context_snapshot.bin and executes a Rust-based payload that connects to a reported C2 domain: www[.]archivetj[.]com.

While not a definitive attribution, the report links this activity to APT41 with medium confidence, based on observed overlaps with previously documented operations and shared technical indicators.

The Critical Gap: Why Patched Systems Remained Vulnerable

The core reason for the continued vulnerability of seemingly patched systems lies in the multi-step nature of Secure Boot protection. Securelist explains that protection against Baton Drop requires more than just installing Windows updates; it specifically depends on the revocation of trust in the “Windows Production PCA 2011” certificate, which was used to sign the vulnerable UEFI components.

Installing an operating system update and applying this certificate revocation are distinct, sequential actions. Microsoft’s own guidance for CVE-2023-24932 reinforces this, detailing multiple steps necessary for complete Secure Boot protection, including updates to certificates, boot managers, and the UEFI revocation list. Microsoft’s Secure Boot revocation guidance explicitly warns that blocking older boot components can impact recovery media and other boot options, emphasizing the need for thorough testing and preparation of recovery strategies before widespread deployment.

This distinction is crucial because Windows might report that all updates are installed, yet the underlying firmware’s forbidden-signature database (DBX) may not have been updated to block the vulnerable certificate. Securelist also clarified that the certificate’s expiration on October 19, 2026, would not automatically prevent vulnerable binaries from loading; active revocation via the appropriate mechanisms is essential.

This situation highlights a broader challenge in maintaining system integrity, echoing previous concerns raised by bootkits like BlackLotus. The effective protection of Secure Boot relies on a comprehensive approach that extends beyond the visible update status of the operating system to include the underlying firmware configuration and revocation mechanisms.

What You Should Do

• Verify Secure Boot Configuration: Do not rely solely on Windows update status. Manually verify that Secure Boot is correctly configured and that the necessary certificate revocations have been applied in your system’s UEFI/BIOS firmware.
• Follow Microsoft’s Guidance: Adhere strictly to Microsoft’s Secure Boot revocation guidance for CVE-2023-24932 and other relevant vulnerabilities. Ensure all steps, including updating certificate trust lists and boot managers, are completed.
• Test Revocation Changes: Before broad deployment, thoroughly test Secure Boot changes and certificate revocations in a controlled environment. Prepare robust recovery options, as blocking older boot components can impact recovery media.
• Monitor for Administrative Activity: Since BlackX requires initial administrator access, strengthen monitoring for suspicious administrative actions, unauthorized modifications to boot-related settings, and any attempts to tamper with security monitoring tools.
• Review Endpoint Alerts: Pay close attention to endpoint security alerts that might indicate attempts to disable or interfere with security callbacks, ETW, or other system integrity mechanisms.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.