Why this matters now
Kaspersky's research, published on October 22, 2026, describes BlackX, a UEFI bootkit deployed in early 2026 against diplomatic agencies in Tajikistan, Uzbekistan, and Turkmenistan. Kaspersky attributes the campaign with medium confidence to APT41, also known as Brass Typhoon. The uncomfortable detail is not the target list. It is that the victims were fully patched.
BlackX exploits Baton Drop (CVE-2022-21894), a Secure Boot bypass from 2022. The fix for Baton Drop only blocks the vulnerable boot files once an administrator manually applies Microsoft's revocation mitigations under KB5025885, which add the "Windows Production PCA 2011" certificate to the Secure Boot forbidden list (DBX). Those protections are not enabled by default, so patching the operating system without the revocation step leaves the exact door BlackX walks through still open.
A bootkit matters more than ordinary malware because it loads before Windows does. By the time your endpoint agent starts, the attacker has already had a chance to interfere with it. BlackX is closely related to BlackLotus, the bootkit advertised on underground forums in October 2022 and confirmed by ESET in March 2023. Kaspersky found BlackX code that is missing from the BlackLotus source code leaked in July 2023, which means the operator either reverse-engineered BlackLotus or bought its source. Either way, a four-year-old bypass is doing new espionage work in 2026.
No hashes, file paths, or IP addresses for BlackX have been published yet, so this is a behaviour hunt, not an indicator hunt. Hunt the steps no legitimate boot process should take: boot-configuration tampering, unsigned drivers loading, security products being interfered with, and cloud-storage connections coming from processes that have no business making them.
The technique, step by step
In MITRE ATT&CK terms, this is T1542.003, Pre-OS Boot: Bootkit. The chain Kaspersky describes breaks down into four stages.
Stage 1: Secure Boot bypass
BlackX abuses CVE-2022-21894 to bypass Secure Boot, the UEFI feature that is supposed to guarantee only signed, trusted code runs before the operating system. Once that check is defeated, the attacker's code runs with the firmware's trust.
Stage 2: Custom key enrollment and pre-OS persistence
BlackX enrolls custom Machine Owner Keys (MOK) and loads arbitrary EFI files before Windows starts. Persistence here lives in firmware variables, not in the registry, a scheduled task, or a startup folder, which is why operating-system reinstalls and disk wipes do not remove it.
Stage 3: Kernel driver and security-product interference
After the pre-OS stage, BlackX drops a kernel driver designed to interfere with security products from Kaspersky and Avast. A driver that loads this early can blind, tamper with, or sit underneath the very tools you would normally rely on to detect it.
Stage 4: Cloud-service command and control
Follow-on espionage tooling uses cloud services such as Google Drive and OneDrive for command and control. Traffic to those services blends into normal business traffic, which is exactly the point: blocking the domains outright would break legitimate work, so the hunt has to focus on which process is talking, not just where it is talking to.
Hunt 1: Boot-configuration tampering
Legitimate administrators do touch boot configuration during imaging and repair, but they do it rarely, from known hosts, and usually during maintenance windows. An attacker preparing or maintaining a bootkit touches it from a compromised host, often right after initial access. Hunt for boot-configuration tools and for EFI files appearing where they should not.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("bcdedit.exe", "bcdboot.exe", "mountvol.exe", "bootsect.exe")
| where InitiatingProcessFileName !in~ ("setup.exe", "dism.exe", "tiworker.exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
The Splunk equivalent, using Sysmon process-creation events, looks like this:
index=* EventCode=1 (Image="*\\bcdedit.exe" OR Image="*\\bcdboot.exe" OR Image="*\\mountvol.exe")
| stats count, values(CommandLine) as command_lines, values(ParentImage) as parents by host, User
| sort -count
Triage every hit against your imaging and patching schedule. A hit from an IT deployment host during a rollout is expected. A hit from a user's laptop at 2 a.m., or from a process chain starting in a browser, Office, or scripting host, is not.
Hunt 2: Unsigned drivers and security-product interference
BlackX's kernel driver is the stage where endpoint telemetry has the best chance of seeing something. Hunt for drivers that load unsigned or untrusted, and correlate them with security-product services stopping, drivers unloading, or protection settings changing around the same time.
DeviceImageLoadEvents
| where Timestamp > ago(30d)
| join kind=leftouter (
DeviceFileCertificateInfo
| where IsSigned == false or IsTrusted == false
| project SHA1, IsSigned, IsTrusted, Signer
) on SHA1
| where IsSigned == false or IsTrusted == false
| where FolderPath !contains "Windows\\System32\\DriverStore"
| project Timestamp, DeviceName, FileName, FolderPath, SHA1, InitiatingProcessFileName, Signer
| sort by Timestamp desc
In Splunk, Sysmon EventCode 7 (image loaded) carries signature status directly:
index=* EventCode=7 (Signed=false OR SignatureStatus="Unavailable")
| stats count, values(ImageLoaded) as drivers, values(Image) as loaders by host
| sort -count
Pair any unsigned-driver hit with a hunt for security-product tampering in the same hour: antivirus services stopping, protection drivers unloading, or configuration-change events in the Defender Operational log. A single unsigned vendor driver after a hardware change is usually benign. An unsigned driver plus a security product going quiet on the same host is a firmware-compromise lead until proven otherwise.
Hunt 3: Cloud-service C2 from the wrong process
BlackX's follow-on tooling uses Google Drive and OneDrive for command and control. The domains themselves are legitimate, so filter on the process instead: browsers and the official OneDrive sync client are expected; everything else needs an explanation.
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl contains "drive.google.com" or RemoteUrl contains "onedrive.live.com" or RemoteUrl contains "sharepoint.com"
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "onedrive.exe", "groove.exe")
| where ActionType == "ConnectionSuccess"
| summarize count(), make_set(RemoteUrl), make_set(InitiatingProcessFileName) by DeviceName, AccountName
| sort by count_ desc
The Splunk equivalent uses network-connection telemetry keyed on the initiating process:
index=* (DestinationHostname="*drive.google.com" OR DestinationHostname="*onedrive.live.com" OR DestinationHostname="*sharepoint.com")
| search NOT (Image="*\\chrome.exe" OR Image="*\\msedge.exe" OR Image="*\\firefox.exe" OR Image="*\\onedrive.exe")
| stats count, values(Image) as processes, values(DestinationHostname) as destinations by host, User
| sort -count
Baseline this per host first. Developers syncing through backup tools and third-party clients will generate noise; the signal is a system process, a scripting host, or an unsigned binary opening a Drive or OneDrive session for the first time, especially on a host that also appears in Hunts 1 or 2.
Hunt 4: EFI files and Secure Boot variable drift
The EFI System Partition is not normally mounted on Windows and is not reliably visible to endpoint telemetry, so do not treat a clean result here as proof of a clean machine. This hunt is a spot check, not a clearance, and it works best when you can compare against a known-good gold image.
DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName endswith ".efi"
| where ActionType in~ ("FileCreated", "FileModified")
| where FolderPath !contains "Windows\\System32"
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessFileName
| sort by Timestamp desc
Alongside the query, check the fleet's Secure Boot posture directly. On a sample of hosts, confirm Secure Boot is enabled and that the KB5025885 revocations are actually applied, meaning the "Windows Production PCA 2011" certificate is present in the Secure Boot forbidden list (DBX). A host that is patched but missing the revocation is still vulnerable to Baton Drop, and that gap is itself the finding: it is the population BlackX preys on.
Triage: what a hit means
Start with the benign explanations, because boot-adjacent telemetry is noisy. Firmware updates, hardware refreshes, and OS imaging all touch boot configuration. Vendor driver updates can load newly signed drivers. Dual-boot tools and disk utilities legitimately use bcdedit. IT deployment hosts will light up Hunt 1 during rollouts.
Escalate when hits stack on one host: boot-configuration tampering plus an unsigned driver plus a security product going quiet, or any of those plus a first-seen cloud-storage connection from a non-browser process. Escalate immediately if a host shows EFI files appearing outside expected paths, or if Secure Boot variables differ from your gold image without a corresponding change ticket.
Do not close a stacked lead with an operating-system reinstall. If a bootkit is confirmed or strongly suspected, treat it as a firmware compromise: reflash the UEFI firmware from the vendor, reset Secure Boot keys to factory defaults, apply the KB5025885 revocations, and only then reimage the machine. Reinstalling Windows over a compromised firmware hands the machine straight back to the attacker.
Remediation
First, close the hole fleet-wide: apply the KB5025885 Secure Boot revocation mitigations so the "Windows Production PCA 2011" certificate lands in the DBX forbidden list, and verify enforcement rather than assuming the patch did it. Microsoft's revocations are the control that actually blocks Baton Drop; operating-system patching alone is not.
Second, make Secure Boot posture a monitored control, not a one-time project. Report on Secure Boot state and DBX revocation status per host, and alert on drift. A host that slips back to an unrevoked state, whether through a firmware rollback, a repair, or a replacement motherboard, is a host that is vulnerable again.
Third, for any host where the hunts stack up, isolate it, capture firmware variables and a full disk image before remediation, and follow the firmware-compromise path above: vendor firmware reflash, Secure Boot key reset, revocations applied, then a clean reimage. Preserve evidence before wiping, because a bootkit investigation is worthless if the firmware state is destroyed by the fix.
The lesson of BlackX is a short one. "Fully patched" describes the operating system. The boot chain underneath it has its own patch state, its own revocation list, and its own manual steps, and attackers have noticed that most fleets never finish them.
