The BlackX bootkit targeted diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan, reaching beneath Windows to load a malicious kernel driver. Affected machines had Windows updates installed. However, they still trusted vulnerable boot components because the additional Secure Boot revocations had not taken effect.
The attacks occurred in early 2026. Technical details became public on October 22. Its connection to the China-linked APT41 group carries medium confidence. Before installing the bootkit, the attackers had already compromised the networks and obtained administrator privileges. Boot-level persistence extended an existing intrusion.
Administrator Access Came Before The Bootkit
Installation began with an executable and a separate encrypted file containing the components it needed. Because the installer kept those components outside its own binary, examining that executable alone could miss much of the package.
The installer placed files on both system and UEFI partitions. It used Baton Drop, tracked as CVE-2022-21894, to manipulate Secure Boot. The exploit sought to enroll custom Machine Owner Keys, or MOKs, allowing arbitrary EFI files to load.
That sequence separates the first break-in from the bootkit deployment. Although the published analysis describes the installation stage, it does not establish how the attackers first entered each network. A phishing email, stolen password or exposed service cannot fill that gap without evidence.
Installed Updates Left Older Boot Components Trusted
BlackX resembles BlackLotus, a bootkit previously associated with the same vulnerability. However, replacing a vulnerable component does not necessarily prevent an attacker from bringing an older, signed copy back onto a machine.
The relevant trust change involves revoking the Windows Production PCA 2011 certificate. Once that certificate enters the firmware’s forbidden-signature database, DBX, boot managers signed by it lose their trusted status. Until then, an installed Windows update and an enforced revocation describe different machine states.
Microsoft’s current guidance for the related CVE-2023-24932 boot-manager changes separates update installation from enabling and verifying the mitigations. The guidance explains the compatibility problem behind that staged process. Revocations can stop older installation or recovery media from booting.
The campaign exploited a gap in boot-trust enforcement on machines with installed updates. Its technical report describes patched targets whose additional revocations were absent.
The Driver Targets Security Monitoring
After the boot-stage exploit, BlackX injects a malicious driver into the Windows kernel. Its signing certificate had already been revoked by the time the technical report appeared. This is a separate certificate from the one involved in boot-manager trust.
Its routines target process, thread and registry callbacks used by security software. They also tamper with Event Tracing for Windows, or ETW, to obstruct access to event output. Some routines check for particular security products and condition their interference on finding them.
The test results do not support a claim that the driver defeats every endpoint tool. Dynamic analysis found that the targeted interference failed against the tested protection product.
The driver intercepts attempts to open the bootkit’s files. Instead of returning the requested malicious file’s handle, it returns one for the calculator executable. That behavior redirects a file request; it does not establish that a calculator window opens.
Cloud Storage Carries Commands And Files
Two user-mode payload types accompanied the bootkit in observed attacks. One is a remote-access trojan that can load additional .NET payloads and use legitimate cloud storage for command and control.
The trojan interprets file suffixes as instructions or results. Different suffixes identify executable tasks, command output, upload requests, downloaded files and transfer status. A separate marker identifies initial system information.
As a result, cloud file exchange becomes an operating channel for the intrusion. A file can represent work for the infected endpoint, while a later upload can carry its response. This protocol supports remote execution and file movement, but the public report does not inventory every document taken from the diplomatic targets.
A Separate Loader Leads To Rust Code
The second observed payload, OxiDLLRunner, follows a different route. A legitimate executable loads the malicious DLL through sideloading. The DLL then decrypts a nearby file and transfers execution to its contents.
Those contents begin with shellcode followed by a Rust payload. Its design includes communication with a command server and receipt of further DLL plugins. The plugins expose a named entry point that the payload can run in separate threads.
Although both payload types sit downstream of BlackX, their communication methods differ. The cloud-storage protocol belongs to the remote-access trojan; the Rust component describes another plugin-loading path. Combining them into one universal sequence would assign capabilities to the wrong component.
Attribution Rests On Several Technical Clues
The assessment linking the operation to APT41 draws on recurring development artifacts and similarities with earlier activity. Its supporting clues include a repeated developer identifier, DLL sideloading patterns and the use of OLLVM obfuscation.
However, those clues carry different weight. A shared identifier can connect development artifacts, while a loading technique or obfuscator can appear in unrelated operations. The resulting attribution therefore remains medium confidence, rather than a confirmed identification of the operators.
Published details name the three targeted countries and their diplomatic sector. They do not provide a complete victim count or identify each affected agency. The initial network entry method remains outside the documented bootkit chain.
Conclusion: Boot Trust Requires Its Own Verification
BlackX exposed a measurable gap between software maintenance and boot trust. The targeted machines had Windows updates, yet still accepted older vulnerable boot components. Consequently, a compliance report that records installed updates alone cannot establish whether Secure Boot rejects those components. Defenders need evidence of the effective trust policy on the device.
The attackers already held administrator privileges before installing the bootkit. That makes two separate response questions essential. How did they gain control, and what allowed them to extend it below Windows? Although the initial entry remains unknown, the documented boot chain gives defenders a concrete verification task. Closing that gap also requires investigating the access that preceded it.
Why This Threat Matters
- Patch status leaves a blind spot. Updating Windows and enforcing firmware revocations describe different states. Therefore, verify the resulting trust decision.
- Privilege precedes persistence. Administrator control came before bootkit deployment, so responders must investigate the earlier intrusion alongside boot changes.
- Kernel interference changes the evidence. The driver targets callbacks and
ETW, although the published test did not demonstrate universal defeat of security tools. - Familiar services can carry hostile work. Legitimate cloud file exchange supported command delivery and results, making application context essential during traffic review.
- Payloads need separate investigation. The trojan using cloud storage and
OxiDLLRunnerrepresent distinct paths, so findings from one should not automatically describe the other.
Where Defensive Control Must Operate
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, fits the loader and subsequent payload stages on supported, managed Windows endpoints. It provides process and behavior telemetry for investigating suspicious execution. Execution Governance restricts unknown code’s access to real endpoint resources before trust is established, under applicable policies. Consequently, the installer and additional untrusted payloads offer earlier control points than an established malicious kernel component.
However, suspected kernel tampering calls for evidence beyond the affected host’s own event stream. Validate deployed agent and policy behavior against relevant loader and DLL activity. Endpoint controls complement Secure Boot enforcement. They do not establish that firmware revocations took effect or that an existing bootkit has disappeared.
Verify Revocations And Recovery Together
Use current vendor guidance to stage revocations, test firmware compatibility and update recovery media before broad enforcement. Then verify the effective DBX state on representative machines and retain evidence of the result. For suspected victims, preserve boot and endpoint artifacts and trace the earlier administrator access. Applying a trust policy change is a preventive step. Incident response must separately establish whether the device still hosts malicious components before returning it to service.
