A bootkit that lives below the operating system
A newly documented UEFI bootkit dubbed BlackX has been used against diplomatic organizations in Central Asia, according to research published by Kaspersky. The campaign, which targeted diplomatic entities in Tajikistan, Uzbekistan, and Turkmenistan in early 2026, is suspected to be the work of a China-linked state-sponsored group tracked as APT41. The findings, first reported by The Hacker News, highlight how firmware-level threats continue to mature as an espionage tool.
What makes BlackX notable is not simply that it is a bootkit. It is that the implant can run on Windows systems that are fully patched, provided the platform has not applied the firmware revocations that would block it. In other words, an up-to-date operating system is not, on its own, a defense against this class of attack.
Why Secure Boot is not a silver bullet
Secure Boot is designed to ensure that only signed, trusted code executes during the boot process. When a bootkit is discovered, vendors add its certificate or binary to a revocation list, and that update is distributed to endpoints so the malicious component can no longer load. The gap BlackX exploits is the distance between a bootkit being known and the revocation actually reaching a given machine.
That gap can be wide. Firmware updates and Secure Boot database refreshes are frequently managed separately from routine OS patching, and many organizations treat them as low-priority maintenance. A system can therefore show as fully patched in vulnerability dashboards while still trusting a component that attackers control. BlackX appears to have been engineered with this lag in mind.
What the campaign suggests about the operators
The targeting pattern — diplomatic missions across three Central Asian states — fits the profile of state-aligned espionage rather than financially motivated crime. Attribution to APT41 is described as suspected rather than confirmed, which is appropriate given how difficult firmware-level attribution can be. Bootkits leave few artifacts in the operating system, and the tooling is often bespoke.
If the assessment holds, it reinforces a broader trend: advanced persistent threats are investing in implants that survive reimaging of the OS, evade endpoint detection tooling that operates at ring 3, and persist through standard remediation playbooks.
Defensive priorities
Organizations that want to reduce exposure should treat firmware and Secure Boot configuration as part of their attack surface, not as an afterthought.
- Track Secure Boot DBX updates. Ensure revocation updates are deployed alongside regular patching, and verify they have actually applied rather than assuming they have.
- Inventory firmware versions. You cannot manage what you have not enumerated. Maintain visibility into UEFI versions and Secure Boot state across the fleet.
- Harden boot configuration. Enforce Secure Boot where feasible, protect firmware settings with administrative passwords, and enable measured boot or TPM-backed attestation where available.
- Monitor below the OS. Endpoint agents that only observe user-space or kernel activity will miss firmware implants. Consider platform integrity attestation and firmware-level telemetry.
- Plan for reimaging limits. Assume that a compromised bootloader may survive a standard OS reinstall. Incident response plans should account for firmware reflash and, where warranted, hardware replacement.
- Prioritize diplomatic and government endpoints. High-value targets should receive the most aggressive firmware hygiene and the shortest revocation deployment windows.
The bigger picture
BlackX is a reminder that the trust chain is only as strong as its weakest maintained link. Secure Boot works when its revocation data is current, and that maintenance depends on processes many organizations have not fully operationalized. Attackers are aware of this and are building tooling that assumes defenders will be slow.
For defenders in government, diplomacy, and other high-value sectors, the practical takeaway is straightforward: patch the operating system, but do not stop there. Verify the firmware underneath it.
