BlackX reached Windows machines that had their security updates installed. The missing step was deeper in the boot chain: the systems still trusted older, vulnerable boot components. Kaspersky’s October 22 investigation describes how attackers used that gap to establish a foothold before Windows started at diplomatic organizations in Central Asia.
The attacks were observed in early 2026, not first discovered this week. The newly published report matters because it exposes a practical blind spot in patch management: an installed update and an enforced Secure Boot revocation are two different states.
The attackers already had administrator access
The reported targets were diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. BlackX entered the picture after the attackers had compromised networks and obtained administrator privileges. It was a way to deepen an existing intrusion, rather than evidence that merely switching on a patched PC could infect it.
Investigators found an installer named inst.exe and a separate encrypted package. Keeping the bootkit components outside the installer made the installation harder to reconstruct from that executable alone. The package placed files on the system and EFI partitions, then used the Baton Drop vulnerability, CVE-2022-21894, to introduce custom Machine Owner Keys and load attacker-controlled EFI code.
This is the trust boundary a bootkit attacks: code runs during startup, before the operating system can apply its normal view of which programs should be trusted. BlackX resembled BlackLotus, but Kaspersky also found differences in its implementation and payloads. Similarity does not establish that it is the same operation.
A driver helped protect the intrusion
The next stage injected a driver into the Windows kernel. The driver attempted to interfere with security callbacks and event tracing, and protected the bootkit’s files. One particularly revealing trick was to return a handle to calc.exe when a request tried to open a protected malicious file. The file a tool received could therefore differ from the file it intended to inspect.
Kaspersky observed espionage payloads beyond the bootkit. One used cloud storage services for command-and-control tasks; another, OxiDLLRunner, loaded an encrypted Rust payload through DLL sideloading. These were reported campaign components, not proof that every BlackX installation carried every payload. The researchers attributed the campaign to APT41 with medium confidence.
Why the patch did not settle the trust decision
The crucial finding was that the targeted machines were fully patched, according to the investigation. Their remaining exposure involved trust in boot components signed under Windows Production PCA 2011. Installing update files had not, by itself, completed the necessary revocation.
Think of patch inventory and boot trust as separate questions:
- Patch inventory: has Windows received the required updated components?
- Boot trust: will the device still accept the older components the attacker wants to load?
A green answer to the first question does not establish the answer to the second. Microsoft’s maintained BlackLotus-related guidance, KB5025885, describes staged installation, evaluation and enforcement. Revoking old boot managers changes what a device can start, including what it can use for recovery.
Kaspersky also notes that the 2011 certificate’s October 19 expiry did not automatically block the vulnerable binaries. Expiration and placement in the firmware’s forbidden-signature database, DBX, are different mechanisms. The report is about that specific missing trust transition; it does not establish that every updated Windows computer is vulnerable in the same configuration.
Verify the rollout before changing boot policy
For the administrator responsible for a Windows fleet, the next step is to check the actual mitigation state against Microsoft’s current instructions, rather than infer it from an update-success screen. Keep Secure Boot enabled. Microsoft advises testing representative device classes before broad deployment, preparing compatible installation and recovery media, and retaining BitLocker recovery keys.
Those preparations matter because a successful revocation can also reject an older recovery environment. Copying a registry recipe without checking firmware, boot-manager and recovery prerequisites can turn a security rollout into an availability problem. Use the maintained vendor procedure in the references instead of a static command copied from a news article.
Microsoft describes these mitigations as preventive, not corrective. An organization with evidence of an existing boot-chain compromise needs incident-response help; a routine clean endpoint scan alone cannot certify that the startup trust chain is sound. The earlier BlackLotus investigation guidance provides historical context, while the current vendor procedure should govern today’s deployment decision.
References
- Kucherin, G.; Nestor, V.; Berdnikov, V. How APT41 revived the BlackLotus bootkit to attack diplomatic organizations in Central Asia. Securelist, October 22, 2026.
- Microsoft. KB5025885: Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932. Microsoft Support. Accessed October 24, 2026.
