
New BlackX UEFI Bootkit Bypasses Windows Secure Boot Even After Security Updates - Cyber Press
A new UEFI bootkit named BlackX has been identified that bypasses Windows Secure Boot protections on fully patched systems, researchers reported on October 22.
The BlackX campaign was identified in early 2026 and primarily targeted diplomatic agencies in Tajikistan, Uzbekistan, and Turkmenistan.
The malware closely resembles BlackLotus, a bootkit advertised for $5,000 in October 2022, and exploits a vulnerability tracked as CVE-2022-21894.
Researchers believe the developers either reverse-engineered BlackLotus or purchased its unpublished source code.
Technical Details
The BlackX installer, named inst.exe, relies on an RC4-encrypted file named PVMDIJGKAX2 to store its components and strings.
By keeping these resources outside the executable, the attackers make it harder for incident responders to collect and analyze the complete malware package.
After gaining administrator privileges, the bootkit places files on both system and UEFI partitions and exploits the Baton Drop vulnerability to install custom Machine Owner Keys.
These keys allow attacker-controlled EFI files to load, effectively bypassing Secure Boot protections.
The central weakness was incomplete Secure Boot revocation, not missing Windows updates.
Payloads and Impact
The bootkit injects a malicious driver into the Windows kernel, which attempts to disable security callbacks for processes, threads, and registry activity.
To protect its files, the driver intercepts file-opening requests and returns a handle to calc.exe instead.
The malware also deploys espionage payloads, including a remote access trojan that uses Google Drive, OneDrive, or Yandex.Disk for command communications.
A second payload, OxiDLLRunner, uses DLL sideloading through a legitimate executable named googleupdate.exe to launch a Rust implant communicating with www[.]archivetj[.]com.
That implant can receive DLL plugins exporting a function called create_plugin and execute them in separate threads.
Mitigation and Next Steps
Kaspersky found that vulnerable boot components remained trusted through the Windows Production PCA 2011 certificate.
Installing patches alone did not activate the revocation needed to block those components on affected machines.
Microsoft’s guidance explains that administrators must first deploy updated trust certificates and boot managers before revoking older trust.
Otherwise, recovery drives, installation media, and network boot services using older signed components may stop working.
Kaspersky reported that automatic enforcement remained unimplemented when its findings were published.