BlackX Bootkit Revives BlackLotus Tactics — Why Secure Boot Isn’t Enough

Hackers have resurfaced techniques associated with the BlackLotus bootkit in a new implant named BlackX, using a boot‑level exploitation chain to bypass Windows Secure Boot and deploy espionage malware against diplomatic organizations in Central Asia. The campaign, observed in early 2026, targeted agencies in Tajikistan, Uzbekistan, and Turkmenistan. Researchers tied the campaign to APT41 with medium confidence and highlighted a protection gap: affected machines were fully patched, yet vulnerable boot components remained trusted because revocation steps had not been completed.

How BlackX Mirrors BlackLotus

Kaspersky researchers noted that BlackX’s exploitation chain closely resembles the original BlackLotus approach, even though the implementation details and subsequent payloads differ. BlackX leverages a known vector—Baton Drop (tracked as CVE‑2022‑21894)—to manipulate the Windows startup trust chain after attackers obtain administrative privileges. The bootkit is therefore used to extend and persist an existing compromise rather than serve as the initial intrusion method.

Installation and Evasion Techniques

The BlackX installer separates the executable from an encrypted package containing components and strings, leaving the installer itself without embedded malicious payloads. This design hinders recovery and analysis if responders cannot retrieve the companion package. Components are written to both the system and UEFI partitions, and Baton Drop is used to install custom Machine Owner Keys that allow attacker‑controlled EFI files to load during boot.

After achieving foothold in the boot process, the bootkit injects a signed malicious driver into the Windows kernel. Although the signing certificate has been revoked, affected systems continued to trust vulnerable components because certificate revocation had not been fully enacted on those devices. The injected driver attempts to disable security callbacks and interfere with Event Tracing for Windows providers to reduce visibility into malicious activity; some of these interference routines failed during lab testing, and file redirection behavior in some cases pointed protected requests to a legitimate Windows executable.

Espionage Payloads and Command Channels

BlackX delivered at least two user‑mode payloads. One is a remote‑access Trojan capable of loading additional .NET code and communicating via popular cloud storage services such as Google Drive, OneDrive, or Yandex.Disk. Using trusted cloud platforms as command channels has appeared in other reporting linked to APT41 and illustrates how normal business traffic can carry attacker instructions.

The other observed payload, OxiDLLRunner, loads an obfuscated DLL through a legitimate executable, decrypts a neighboring data file that contains shellcode and a Rust executable, and then contacts command infrastructure to retrieve additional DLL plugins. These plugins execute in separate threads, allowing operators to expand functionality post‑compromise. Researchers cited shared development identifiers, overlaps with previously reported FishMonger activity, DLL sideloading patterns, and OLLVM obfuscation as reasons for a medium‑confidence attribution to APT41, while noting these clues do not definitively prove authorship.

The Secure Boot Protection Gap

Investigators stressed that installing OS updates alone did not mitigate risk in this campaign. The protection gap stemmed from continued trust in vulnerable components signed under Windows Production PCA 2011; installing updates did not automatically activate the required revocation on affected systems. Certificate expiration (for example, on October 19 in a prior case) likewise does not automatically block existing binaries from starting. Kaspersky and Microsoft advisories both emphasize that devices may continue to boot normally after certificate expiration unless revocation and forbidden‑signature lists are applied.

Revocation measures require careful compatibility planning because older recovery media and bespoke boot configurations can rely on certificates that revocation would remove. Administrators should therefore verify boot‑trust revocations explicitly rather than relying solely on update status.

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

The source explicitly cautions that IP addresses and domains are intentionally defanged (e.g., [.] ) to prevent accidental resolution or hyperlinking. Re‑fanging should be done only within controlled threat‑intelligence platforms such as MISP, VirusTotal, or your SIEM. The reporting also recommends giving SOC teams the alert context needed to stop incidents quickly and integrating threat intelligence from broad SOC networks.

Practical checks drawn from the reporting

• Verify that boot‑trust revocations and forbidden‑signature databases have been applied and are effective on devices; do not assume OS updates alone provide full protection.
• Plan revocation rollouts carefully to avoid breaking legitimate recovery media and custom boot configurations.
• Feed the provided IoCs into controlled threat intelligence tools and SIEMs, and treat cloud storage command channels and DLL sideloading patterns as suspicious in post‑compromise investigations.

Conclusion

BlackX demonstrates that bootkits remain a potent tool for persistence and stealth when attackers can manipulate the boot trust chain. Even patched systems can be vulnerable if revocation and forbidden‑signature lists are not enforced. The investigation underscores the need for SOCs and administrators to verify boot trust configurations explicitly, to treat cloud‑based command channels with scrutiny during incident response, and to incorporate vetted IoCs into controlled intelligence platforms.