What happened
Kaspersky says it blocked BlackX attacks against diplomatic organisations in Central Asia during early 2026. On October 21, 2026, Kaspersky publicly disclosed BlackX and its Secure Boot bypass. BlackX used CVE-2022-21894, known as Baton Drop, to bypass Secure Boot where required revocations were not fully applied. The vulnerable signing certificate expired on October 19, 2026, but the cited research says expiry alone does not stop the affected binaries unless the certificate is blocklisted.
On October 24, 2026, BleepingComputer reported the campaign’s operational artefacts and revocation gap. The published host artefacts are C:\ProgramData\Intel\inst.exe and the encrypted extensionless file PVMDIJGKAX2. The published command is C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1, with Q46F6MDLI3RX2KV1 used as the RC4 decryption key. BlackX installs Machine Owner Keys to permit arbitrary EFI loading and deploys a driver intended to interfere with Kaspersky and Avast security products.
The disclosed installation sequence begins after the attacker has breached the network and obtained administrator privileges. The cited sources did not publish file hashes, network infrastructure or the campaign’s initial-access method. The reporting identifies diplomatic targets in Tajikistan, Uzbekistan and Turkmenistan, but does not establish broad enterprise deployment outside that scope. Attribution posture: Kaspersky attributes the campaign with moderate confidence to APT41; no government attribution is cited.
Why this matters now
Secure Boot status can create false assurance when revocation data has not been fully applied. BlackX exploited that gap to load before Windows and interfere with security products, placing persistence below many endpoint detection and operating-system controls. A normal patch-compliance report may therefore show a protected device while the vulnerable boot chain remains usable.
The campaign was targeted rather than broadly distributed, but the operational lesson applies to high-value Windows estates in government, defence, regulated research and executive environments. Systems holding sensitive diplomatic, intellectual-property or privileged-administration data merit validation based on revocation state, EFI contents and authorised keys rather than a single configuration flag.
Initial access was not disclosed and administrator privilege was required before installation. Leadership should therefore avoid treating BlackX as an unauthenticated mass-compromise event. The Monday decision is to identify systems where an existing privileged intrusion could survive reboots, evade normal rebuild assumptions or undermine endpoint telemetry.
The decision for security leaders
Require endpoint engineering to produce revocation-state evidence for high-value Windows systems. A report showing Secure Boot enabled or the operating system patched is not sufficient proof that vulnerable boot components are blocked.
Establish a firmware-aware response path before a detection occurs. Standard disk reimaging may not answer whether EFI contents, authorised keys or boot configuration were modified, and premature rebuilding can destroy evidence needed to scope persistence.
Prioritise systems where administrator compromise would have strategic impact, including diplomatic, defence, research and privileged-management endpoints. Broader fleet validation can follow, but the first pass should reflect consequence rather than device count.
Evidence of closure
- Firmware assessment confirms current revocation databases and no unauthorised Machine Owner Keys.
- Disk and EFI-partition scans find none of the published BlackX artefacts.
- Privileged-access review explains every boot-policy or EFI modification.
- Each confirmed host has a documented clean-device rebuild and credential-reset disposition.
The Security.io assessment
BlackX is a confirmed targeted campaign, not evidence of indiscriminate exploitation across general Windows fleets. The medium-confidence attribution comes from Kaspersky’s technical assessment and has not been independently endorsed by a cited government authority.
The enterprise significance lies in control assurance. Baton Drop is old, but the campaign demonstrates that incomplete revocation activation can preserve exploitability after conventional patching. Security leaders should separate operating-system update status from boot-chain trust and compromise status.
The available artefacts support a focused hunt, but the absence of hashes, infrastructure and initial-access details limits negative assurance. A clean filename search cannot close the issue on its own; organisations need EFI inspection, key validation and review of privileged boot-configuration changes.
Questions for the morning meeting
- Can endpoint management prove Secure Boot revocation state rather than merely report Secure Boot as enabled?
- Which high-value systems permit administrators to modify EFI partitions or Machine Owner Keys?
- Does incident response have firmware-aware acquisition and recovery capability?