Hackers have revived techniques associated with the BlackLotus bootkit to bypass Windows Secure Boot and deploy espionage malware against diplomatic organizations in Central Asia.

The new bootkit, named BlackX, appeared in attacks targeting agencies in Tajikistan, Uzbekistan, and Turkmenistan in early 2026.

Investigators linked the campaign to APT41 with medium confidence, leaving attribution short of confirmation. The finding was not simply another case of missing security updates.

Investigators found that affected computers were fully patched, but vulnerable boot components remained trusted because additional certificate revocation steps had not been completed.

Earlier reporting on Windows boot manager downgrades explains how older, signed components can undermine protections on otherwise updated systems.

Researchers from Securelist identified BlackX during their investigation and detailed its operation in an October 22 technical report.

Hackers Revive BlackLotus Techniques

Kaspersky researchers Georgy Kucherin, Vladimir Nestor, and Vasily Berdnikov found that its exploitation chain closely resembles BlackLotus, although its implementation and later payloads differ.

BlackX exploits Baton Drop, tracked as CVE-2022-21894, to manipulate the startup trust chain. Attackers deploy it after compromising a network and obtaining administrator privileges.

It is therefore a tool for extending an existing compromise, rather than the initial route into a victim’s environment. The report does not establish how those networks were first breached.

Installation separates the executable from an encrypted package containing the required components and strings. This arrangement leaves the installer without embedded malicious payloads, making recovery and analysis harder when responders cannot retrieve its companion file.

BlackLotus advertisement (Source - Securelist) — BlackLotus advertisement (Source – Securelist)

The package writes components to system and UEFI partitions, then exploits Baton Drop to install custom Machine Owner Keys. These keys enable attacker-controlled EFI files to load.

The bootkit subsequently injects a signed malicious driver into the Windows kernel. Its signing certificate has since been revoked. The driver attempts to disable security callbacks and interfere with Event Tracing for Windows providers, reducing visibility into malicious activity.

However, researchers found that its Kaspersky-specific interference routines failed during testing. It also redirects requests for protected bootkit files toward a harmless Windows executable.

Espionage Payloads and the Secure Boot Protection Gap

BlackX delivers two observed user-mode payloads. One is a remote-access Trojan capable of loading additional .NET code and exchanging instructions through Google Drive, OneDrive, or Yandex.Disk.

Similar Google Drive command channels have appeared in separate APT41-linked reporting, illustrating how trusted cloud platforms can carry attacker instructions alongside ordinary business traffic. This similarity alone does not prove attribution.

The second payload, OxiDLLRunner, uses an obfuscated DLL loaded through a legitimate executable. It decrypts a nearby data file containing shellcode and a Rust executable.

That payload contacts command infrastructure and receives additional DLL plugins, which execute in separate threads. The design gives operators a way to extend functionality after establishing access.

Researchers based their APT41 assessment on shared development identifiers, overlaps with previously reported FishMonger activity, DLL sideloading patterns, and OLLVM obfuscation.

These clues support their medium-confidence judgment, but do not establish who wrote BlackX. They suggested its developers might have reverse-engineered BlackLotus or purchased its source code; neither explanation was confirmed.

The protection gap involved continued trust in vulnerable components signed under Windows Production PCA 2011. Securelist reported that installing updates did not automatically activate the required revocation on affected systems.

Certificate expiration on October 19 also did not independently block existing binaries. Microsoft’s certificate expiration advisory likewise explains that existing devices continue starting normally after expiration.

Administrators should verify boot-trust revocations rather than relying only on update status. Previous UEFI Secure Boot vulnerabilities demonstrate why forbidden-signature databases matter.

Revocation changes require compatibility planning because older recovery media and boot configurations may depend on certificates being removed.

Indicators of compromise (IoCs):-

Type	Source-reported value	Context
Installer	`C:\ProgramData\Intel\inst.exe`	Installation executable
Encrypted package	`PVMDIJGKAX2`	Bootkit components
RC4 key	`Q46F6MDLI3RX2KV1`	Package decryption
Certificate serial	`0bcdf5e0da32d68900b8b7638459d072`	Revoked driver certificate
Loader names	`googleupdate.exe`; `jcef_helper.exe`	Renamed legitimate executable
Loader MD5	`AF8A983B9ADA07EAE1259BF2953ABD40`	Legitimate loader hash
Encrypted payload	`v8_context_snapshot.bin`	Rust payload container
C2 domain	`www[.]archivetj[.]com`	Rust payload communications
Development marker	`xdd`; `C:\Users\xdd\Desktop`	Attribution overlap
.NET entry point	`TEST.Class1.RunCMD(argument_array)`	Task execution
Plugin export	`create_plugin`	DLL execution
Cloud suffixes	`0X01`–`0X06`; `SSSR`	Tasks, results, system information
File redirection	`calc.exe`	Bootkit protection behavior

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.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Hackers Revive BlackLotus Techniques to Bypass Windows Secure Boot and Deploy Malware appeared first on Cyber Security News.