BlackLotus UEFI Bootkit Bypasses Windows Secure Boot, Deploys Malware

Key Takeaways

• A new bootkit, dubbed BlackX, is actively exploiting a vulnerability (CVE-2022-21894) to bypass Windows Secure Boot.
• The attacks target diplomatic organizations in Central Asia, specifically in Tajikistan, Uzbekistan, and Turkmenistan.
• BlackX leverages techniques reminiscent of the notorious BlackLotus bootkit to deploy espionage malware.
• Crucially, fully patched systems remain vulnerable if certificate revocation lists for older, signed boot components are not manually updated.

Hackers Exploit Secure Boot Flaw with New BlackX Bootkit

Cybersecurity researchers have uncovered a sophisticated bootkit, named BlackX, that is actively circumventing Windows Secure Boot protections. This advanced malware campaign, observed in early 2026, has been deployed against diplomatic entities across Central Asia, including Tajikistan, Uzbekistan, and Turkmenistan, for espionage purposes.

Investigators have drawn a medium-confidence link between the BlackX campaign and the notorious state-sponsored hacking group APT41. A critical aspect of this discovery is that the targeted systems were found to be fully updated, yet remained susceptible. The vulnerability stems from the continued trust in older, signed boot components, where necessary certificate revocation steps had not been fully implemented. This highlights a significant blind spot where standard security updates alone are insufficient to ensure protection.

Researchers from Securelist identified BlackX during their investigation, subsequently publishing a detailed technical report on October 22 outlining its intricate operations.

Reviving BlackLotus Tactics

Kaspersky researchers Georgy Kucherin, Vladimir Nestor, and Vasily Berdnikov noted that BlackX’s exploitation chain bears a strong resemblance to the infamous BlackLotus bootkit. While the core techniques are similar, BlackX differentiates itself through its specific implementation and subsequent malware payloads.

BlackX exploits a vulnerability known as Baton Drop, tracked as CVE-2022-21894. This flaw allows attackers to manipulate the startup trust chain after they have already gained administrator privileges on a compromised network. Therefore, BlackX is not an initial access vector but rather a powerful tool for escalating and extending an existing compromise. The initial method of network infiltration remains undisclosed in the report.

The installation process for BlackX involves separating the executable from an encrypted package containing essential components and strings. This design choice complicates recovery and analysis for incident responders, as the absence of the companion file renders the installer benign.

Once installed, the package writes components to both system and UEFI partitions. It then exploits Baton Drop to install custom Machine Owner Keys (MOKs), enabling the loading of attacker-controlled EFI files. Subsequently, the bootkit injects a malicious driver, signed with a certificate that has since been revoked, directly into the Windows kernel. This driver attempts to disable security callbacks and interfere with Event Tracing for Windows (ETW) providers, aiming to obscure malicious activities. Interestingly, researchers observed that its Kaspersky-specific interference routines failed during testing. Additionally, the bootkit redirects requests for its protected files to a harmless Windows executable, further hindering detection.

Espionage Payloads and the Secure Boot Gap

BlackX deploys two primary user-mode payloads. The first is a remote-access Trojan (RAT) capable of loading additional .NET code and communicating with its command and control (C2) infrastructure via legitimate cloud services such as Google Drive, OneDrive, or Yandex.Disk. The use of Google Drive for C2 channels has been previously observed in other APT41-linked campaigns, though this similarity alone does not definitively confirm attribution.

The second payload, OxiDLLRunner, utilizes an obfuscated DLL loaded through a legitimate executable. This component decrypts a nearby data file containing shellcode and a Rust executable. The Rust payload then establishes contact with C2 infrastructure to receive additional DLL plugins, which execute in separate threads. This modular design allows operators to dynamically extend the malware’s capabilities post-compromise.

The assessment linking BlackX to APT41 is based on several factors, including shared development identifiers, overlaps with previously documented FishMonger activity, consistent DLL sideloading patterns, and the use of OLLVM obfuscation. While these clues support a medium-confidence attribution, they do not definitively identify the creators of BlackX. Researchers speculated that the developers either reverse-engineered BlackLotus or acquired its source code, though neither hypothesis was confirmed.

The fundamental protection gap exploited by BlackX lies in the continued trust placed in vulnerable components signed under Windows Production PCA 2011. Securelist reported that installing routine updates did not automatically trigger the necessary revocation on affected systems. Furthermore, the certificate’s expiration on October 19 did not independently block existing binaries. Microsoft’s certificate expiration advisory also clarifies that existing devices will continue to boot normally after expiration.

This situation underscores the critical need for administrators to proactively verify boot-trust revocations, rather than solely relying on system update statuses. Past UEFI Secure Boot vulnerabilities have repeatedly demonstrated the importance of meticulously maintaining forbidden-signature databases. It is also crucial to plan for compatibility during revocation changes, as older recovery media and boot configurations may depend on certificates that are being removed.

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.

What You Should Do

• Manually Verify Revocation Status: Do not rely solely on Windows updates. Administrators must actively check and ensure that all necessary certificate revocations for vulnerable boot components, particularly those signed under Windows Production PCA 2011, have been applied.
• Update Forbidden Signature Databases: Ensure that your UEFI/Secure Boot forbidden signature databases (DBX) are current and properly configured to block known vulnerable bootloaders and certificates.
• Implement Strong Endpoint Detection and Response (EDR): Utilize EDR solutions capable of detecting anomalies at the kernel level and monitoring for suspicious boot processes, even on otherwise “patched” systems.
• Review Boot Configuration Policies: Regularly audit and enforce strict boot configuration policies to prevent unauthorized modifications to the boot chain.
• Backup and Recovery Planning: Incorporate UEFI/Secure Boot revocation planning into your disaster recovery strategy, considering that older recovery media might rely on certificates that have been revoked.
• Monitor for Initial Compromise: Since BlackX is a post-exploitation tool, focus on strengthening defenses against initial network breaches, including robust phishing protection, vulnerability management, and strong authentication.

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.