A sophisticated UEFI bootkit called BlackX has been observed in targeted cyberespionage campaigns against diplomatic organizations in Central Asia. Even on systems that showed up-to-date Windows patches, attackers found a path to run code before Windows started by exploiting gaps in how Secure Boot protections were deployed. The discovery highlights a subtle but critical distinction between installing updates and fully activating the firmware-level protections those updates are intended to enable.
How BlackX works
BlackX is deployed after attackers obtain administrator-level access to a victim’s network. Its installer, identified as inst.exe, works with an encrypted companion file (PVMDIJGKAX2) that contains the components required to place the bootkit into the early boot sequence. Because the malicious payloads include EFI files that load before the OS, BlackX can execute code before many Windows defenses are active.
The bootkit uses a technique tracked as Baton Drop (CVE-2022-21894) to load attacker-controlled EFI binaries and to interfere with Secure Boot enforcement. Its kernel driver also attempts to blunt host defenses by disrupting process, thread, and registry callbacks, and by interfering with Event Tracing for Windows (ETW). In some cases the driver returns handles to legitimate processes (for example, calc.exe) instead of revealing malicious files, making detection and recovery more difficult.
BlackX’s architecture resembles earlier bootkits such as BlackLotus in key ways, and it also delivers user-mode espionage tooling. Observed payloads include a remote-access Trojan capable of loading additional .NET code and using cloud storage (Google Drive, OneDrive, Yandex.Disk) for command-and-control, as well as a component named OxiDLLRunner that decrypts v8_context_snapshot.bin and runs a Rust-based payload that contacts a reported C2 domain.
Why patched systems were still at risk
The root cause for many of the compromised hosts was not a lack of Windows updates but an incomplete application of Secure Boot revocation mechanisms. Secure Boot protections against Baton Drop depend on a revocation — effectively blocking trust in the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. Installing an OS update is only part of the process; administrators must also ensure that the firmware’s forbidden-signature list (UEFI revocation list) and related certificate updates have been applied and are enforced at the firmware level.
Microsoft’s deployment guidance for related issues (for example, CVE-2023-24932) shows that protections require multiple coordinated steps: updating certificates, boot managers, and the UEFI revocation list. The guidance also warns that blocking older boot components can affect recovery media and other boot options, so changes must be tested and recovery plans prepared. In practice, Windows can report that updates are installed while the firmware’s forbidden-signature list remains unchanged, leaving systems exposed even when they appear “patched.”
Attribution and campaign context
Researchers linked the activity to APT41 with medium confidence based on technical overlaps with previously observed activity, though that assessment is not definitive. The campaign targeted diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan, and it illustrates a targeted, post-compromise persistence strategy: get admin access, implant a boot-time component, and then use both kernel and user-mode tools for espionage while evading or disrupting logging and monitoring.
Indicators of compromise (IoCs):-
| Type | Indicator |
|---|---|
| Installer file | inst.exe |
| Encrypted file | PVMDIJGKAX2 |
| Installer path and command line | C:ProgramDataIntelinst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1 |
| Delivered executable name | googleupdate.exe |
| Original filename | jcef_helper.exe |
| MD5 | AF8A983B9ADA07EAE1259BF2953ABD40 |
| Related payload file | v8_context_snapshot.bin |
| Reported command-and-control domain | www[.]archivetj[.]com |
| Driver certificate serial number | 0bcdf5e0da32d68900b8b7638459d072 |
Defender checklist
- Verify firmware-level Secure Boot configuration and confirm that certificate revocations have taken effect in the UEFI revocation list, not just at the OS-update level.
- Follow Microsoft’s current deployment guidance for Secure Boot revocation, and test changes against an organization’s recovery media and boot options before broad rollout.
- Inspect boot and recovery media for compatibility and ensure they aren’t using legacy, vulnerable boot components that could be abused by a downgrade or Baton Drop technique.
- Investigate any suspicious administrative activity and changes to boot-related settings following detection of unusual network or endpoint behavior.
- Look for signs of tampering with ETW, callback chains, or other telemetry sources that could indicate kernel-level interference designed to blind defenders.
- Integrate IoCs into threat intelligence platforms and endpoint detection tools, and correlate with administrative logs to identify potential post-compromise persistence.
Conclusion
BlackX serves as a stark reminder that endpoint patch status alone isn’t a guarantee of protection. Boot-time threats operate earlier than most OS defenses and exploit gaps between the installation of updates and the activation of firmware-enforced revocations. Organizations should treat Secure Boot deployment as a coordinated firmware-plus-OS exercise: verify revocations are effective at the firmware level, test recovery scenarios, and investigate any signs that kernel or boot components have been altered after administrative access was obtained.
Licensed under CC BY-ND 4.0 International
