UEFI rootkits: BlackX, firmware implants and the limits of a clean rebuild

Executive summary

UEFI rootkit investigations must establish where malicious code persists, how it reaches the operating system and which parts of the machine an apparent clean-up actually replaced. The recent BlackX disclosure provides the current campaign lead, while documented firmware implants show why a bootkit on disk and a rootkit in motherboard flash require different investigations. Likely (B2): recovery that does not identify and address the demonstrated persistence layer will leave a material assurance gap, based on the distinct mechanisms documented by Microsoft and ESET. This investigation examines the implants and the evidence needed to find and remove them; our separate EDK II PXE vulnerability analysis remains supporting reading.

The current intelligence: BlackX and the attribution boundary

Kaspersky’s 22 October 2026 report describes BlackX against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan in early 2026. Deployment followed network compromise and administrator access; the initial intrusion route is unspecified. An installer and encrypted companion file deliver components to system and UEFI partitions. Baton Drop, CVE-2022-21894, enables attacker-controlled Machine Owner Keys and subsequent EFI execution. The bootkit introduces a kernel driver that targets security callbacks and Event Tracing for Windows; Kaspersky says tested interference with its own products failed. File-access redirection to calc.exe also obscures protected artefacts. Follow-on payloads include a remote-access trojan using Google Drive, OneDrive or Yandex.Disk, and OxiDLLRunner, which loads a Rust payload. Kaspersky assesses APT41 involvement with medium confidence, citing an xdd identifier overlap, side-loading and obfuscation; that assessment is not independent confirmation.

Selected source-reported hunting pivots:

Artefact	Meaning
`inst.exe` with `PVMDIJGKAX2`	Installer and encrypted companion; collect together
`v8_context_snapshot.bin`	Encrypted payload companion
`www[.]archivetj[.]com`	Reported command-and-control destination
`0bcdf5e0da32d68900b8b7638459d072`	Driver-signing certificate serial; revoked at reporting

These are investigation pivots, not standalone verdicts. Preserve surrounding files, execution history and connection context before interpreting a filename hit. A legitimate filename copied into a detection rule should not become an automatic quarantine decision. The operational question is whether the boot path, the privileged driver and the downstream activity can be tied together on the same host.

What the FishMonger comparison actually supports

ESET’s 16 June 2026 SprySOCKS analysis attributes Windows variants to FishMonger with high confidence. Its telemetry concerns 2023–2024 activity, principally against government organisations in Honduras, Taiwan, Thailand and Pakistan. Its WIN_DRV variant uses kernel drivers to hide connections, processes, files and registry keys; Windows Filtering Platform traffic diversion enables a passive backdoor without exposing its real listening port. Crucially, ESET describes only limited indications of a possible UEFI bootkit, potentially involving CVE-2023-24932. A driver’s debug path includes C:\Users\xdd\Desktop. The June publication date does not make these observations a June 2026 intrusion, and possible bootkit involvement does not identify the bootkit conclusively.

TIR therefore keeps three propositions separate: a confirmed analysis of a particular malware sample; the research publisher’s campaign attribution; and a proposed relationship between separately reported samples. Strong evidence for the first does not automatically establish the other two. Read the current APT41 profile for the broader actor context. The APT28 profile is relevant to LoJax below, not an alternative name for the BlackX operator.

What persists: firmware, boot files and the operating system

Unified Extensible Firmware Interface (UEFI) is the platform interface involved in starting the operating system. MITRE distinguishes modification of system firmware, T1542.001, from a bootkit, T1542.003. On UEFI systems, the latter can involve files in the EFI system partition (ESP), a partition on storage. Firmware implants can instead modify code in the platform’s firmware. Both execute below ordinary applications, but their storage locations are different.

Use a persistence map in the incident record rather than the single label “UEFI malware”. The following is a TIR investigation model, not a claim that every case uses all four layers:

Layer to examine	Evidence to request	Recovery question
Motherboard firmware, including serial peripheral interface (SPI) flash	Acquired image, acquisition method, firmware version and model-matched reference	Was the affected firmware actually restored and verified?
Boot configuration and trust state	Boot entries, authorised keys and relevant revocation state	Can the same unwanted component still be authorised or selected?
EFI system partition	Full partition image, file metadata, signatures and comparison with approved media	Was this partition included in the rebuild?
Windows and downstream access	Driver and process evidence, external telemetry, credentials and access history	Were payloads and independent re-entry routes addressed?

This map prevents two costly shortcuts. A disk replacement is not evidence that motherboard firmware changed. Conversely, a disk-resident bootkit is not evidence that a motherboard replacement is required. Ask the responder to name the affected object and show the before-and-after evidence. Where that object cannot be inspected reliably, record the uncertainty and choose a recovery action that resolves it, rather than closing the incident on the strength of a routine malware scan.

An exploit, an installed implant and a functioning command channel are also separate observations. The first demonstrates an opportunity; the second establishes a persistence mechanism; the third may show operational use. Our PXE article addresses the first category. It does not establish that BlackX or any of the firmware implants below used that vulnerability.

Firmware rootkits: four cases with different evidential limits

LoJax: firmware as a mechanism for returning malware to disk

ESET’s LoJax research confirmed at least one malicious UEFI module installed in SPI flash, alongside tools for reading, modifying and writing firmware. The tooling used the legitimate signed RwDrv.sys driver from RWEverything; writing depended on vulnerable or misconfigured platform protections. The module placed a Windows agent on disk during boot. ESET connected the activity to Sednit, which it identifies with APT28, and described broader campaign targets in the Balkans and Central and Eastern Europe. That geography is not a count of verified firmware infections. The implant can survive operating-system reinstallation or hard-drive replacement because its modified firmware sits outside that storage. ESET’s 9 October 2018 correction states that Secure Boot would not prevent this firmware implant. Its recovery advice was a clean, motherboard-specific SPI reflash or motherboard replacement.

Test a reinfection hypothesis against recovered firmware and the reboot timeline. Reappearance of a file alone has several possible explanations, including another compromised management system or stolen administrative credentials. A rootkit conclusion needs evidence locating the source of that reappearance. A confirmed firmware implant warrants a different response from an endpoint alert without firmware evidence.

MosaicRegressor: selective firmware installation within a wider framework

Kaspersky’s MosaicRegressor investigation found four added firmware components: two DXE drivers and two UEFI applications, derived from leaked VectorEDK code with modifications. DXE is the driver execution environment stage of UEFI. The chain placed IntelUpdate.exe in Windows’ Startup folder; the technical analysis describes a setupinf.log marker check, qualifying any claim of unconditional redelivery at every boot. Its firmware foothold was distinct from the wider modular espionage framework. The researchers observed several dozen framework victims during 2017–2019, but only two also had the UEFI implant in 2019. Targets included diplomatic entities and non-governmental organisations with North Korea-related activity. That victim connection is not attribution to North Korea; the researchers instead discussed indications of a Chinese-speaking operator. A possible Winnti-related connection had low confidence. The firmware installation route was unresolved.

A framework downloader does not establish firmware infection. Do not clear firmware solely because most victims in the public report lacked that component. Use the wider framework to identify a hunting population, then verify the deeper persistence condition on individual systems. Report confirmed firmware infections separately from systems awaiting acquisition or examination.

MoonBounce: altering an existing firmware component

Kaspersky’s MoonBounce analysis describes modification of CORE_DXE, rather than simply adding an unfamiliar module. Hooks in boot services including AllocatePool, CreateEventEx and ExitBootServices carried execution through the Windows loader to a kernel component and an in-memory user-mode stage in svchost.exe. The next payload could not be retrieved. Its technical account dates detection to spring 2021, while the introduction describes becoming aware through scanner logs at the end of 2021; neither dates initial compromise. Only one firmware-infected case was detected. Among the wider observed targets was an organisation controlling transport-technology enterprises; the report does not explicitly identify it as that firmware case. Kaspersky assessed APT41 or a closely affiliated actor, with medium-to-high confidence, but could not reconstruct the initial firmware infection. Remote installation was an assumption, not an observed installation chain.

This case changes what “compare the firmware” should mean. Counting module names or looking only for an extra executable is an inadequate examination plan when the hypothesis is modification inside an expected component. Request code comparison against a matching reference, accounting for vendor customisation. A familiar module name should be treated as an identifier, not a clean bill of health.

CosmicStrand: a firmware-to-kernel chain with an unresolved entry route

Kaspersky’s CosmicStrand report identifies changes to CSMCORE in firmware images associated with ASUS and Gigabyte H81-based motherboards. A modified entry point redirects execution to added code; boot-manager, loader and kernel hooks carry it into Windows. The final server-delivered payload was not recovered. Initial infection was not established, and a suggestion that a second-hand motherboard arrived compromised remained unconfirmed. Victims in China, Vietnam, Iran and Russia appeared to be private individuals; Kaspersky could not link them to an organisation or sector. Kaspersky attributed the work to an unknown Chinese-speaking actor, not a named APT group. Apparent infrastructure activity in late 2016–mid-2017 and 2020 does not provide a continuous victim-level dwell-time measurement. A sample SHA-256 reported for the modified firmware driver is 951F74882C1873BFE56E0BFF225E3CD5D8964AF4F7334182BC1BF0EC9E987A0A; its absence cannot clear other builds or variants.

Retain board identity and firmware provenance alongside the image. A motherboard brand in a research report is not an affected-product list for every model that brand sells. Procurement history cannot substitute for device analysis. Avoid turning an unresolved entry route into a confirmed supply-chain incident: that would change both the incident scope and the organisations being implicated without sufficient support.

Why patched systems can still have a vulnerable boot path

ESET’s BlackLotus analysis of 1 March 2023 documented a disk-resident UEFI bootkit using CVE-2022-21894. Its chain brought vulnerable signed binaries, enrolled an attacker’s Machine Owner Key, and subsequently loaded a kernel driver and an HTTP downloader. The driver protected bootkit files; the downloader could obtain further payloads. ESET found mechanisms to disable BitLocker, hypervisor-protected code integrity and Windows Defender. It had not established the exact distribution channel. The weakness was not that a digital signature ceased to exist: vulnerable signed components could still be accepted when the necessary revocations were absent.

The EU Vulnerability Database record, EUVD-2022-27050, identifies CVE-2022-21894 as a Secure Boot security-feature bypass. It should not be confused with CVE-2023-24932, the separate identifier in Microsoft’s subsequent mitigation guidance. Neither identifier names a firmware implant or establishes which actor is present.

Microsoft’s KB5025885, checked for this article on 29 October 2026, still describes mitigations that are not enabled by default and an enforcement phase whose date remains to be announced. Installing an update and enforcing its boot-manager revocations are therefore distinct tasks in that guidance. Microsoft warns that older recovery and installation media can become unusable after revocation. This is a deployment dependency to plan and test, not a reason to assume an installed update finished the work.

Microsoft’s enterprise deployment guidance separates four mitigations: install the newer trusted certificate, update the boot manager, revoke the older certificate, and apply the Secure Version Number update. It requires the first two before the latter two. It identifies System event 1037 as evidence of successful revocation and provides a check of the forbidden-signature database, DBX. The documents disagree on verification: the enterprise page says it lacks a method to confirm the Secure Version Number setting, but KB5025885 lists event 1042 for its application, added to the KB on 2 June 2026. Use that SVN-specific evidence; event 1037 alone does not prove all four steps succeeded.

The practical change is to make boot trust an explicit acceptance criterion. Require evidence of the intended certificate and revocation state, the boot manager in use, and a successful recovery-media test on representative hardware. Maintain a record of exceptions with an owner and a planned resolution. A patch-compliance percentage that cannot answer those questions is measuring a different condition.

The problem also extends beyond one Windows bootkit. ESET’s July 2026 shim research identified eleven old Microsoft-signed shim bootloaders at version 0.9 or earlier. Systems trusting the relevant third-party UEFI certificate could accept them when the relevant revocations were absent, regardless of the installed operating system. Microsoft revoked these eleven binaries in its 9 June 2026 DBX update. This was vulnerability research, not proof that all eleven shims were used in attacks. It demonstrates why assessment must include what the platform will still authorise, rather than only the loader normally selected for everyday startup.

Detection: build a case across the boot and runtime boundary

Microsoft’s BlackLotus investigation guidance describes correlated evidence from ESP modifications, staging artefacts, registry changes, event logs, network behaviour and measured-boot logs. Examples include recently modified or locked boot files, changes disabling hypervisor-protected code integrity, and Defender service termination with System event 7023. These are BlackLotus findings, not validated BlackX signatures. Microsoft explicitly warns that isolated artefacts can be low fidelity. Its confirmed-case remediation includes reformatting both the operating-system and EFI partitions, or restoring a known-clean backup that includes the EFI partition.

For this article, TIR recommends the following investigation sequence. It is a proposed collection plan, not a tested detection rule or a claim that a listed signal uniquely identifies an implant:

Establish the boot inventory. Record device model, firmware version, boot mode, selected bootloader, ESP contents and relevant trust configuration. Preserve the original values before a repair changes them. Record which values were read from the suspect operating system and which were collected independently.
Join privileged execution to boot changes. Compare approved maintenance with unexpected administrative processes, boot-file changes, driver activity and subsequent restarts. An approved firmware update is a plausible benign explanation; a change outside that process deserves investigation, not an automatic attribution.
Correlate endpoint and external observations. Compare apparent periods of endpoint quiet with network, identity and management-system records. Missing endpoint events can reflect sensor failure or retention gaps as well as interference. Investigate the disagreement instead of choosing whichever source makes the incident look simpler.
Acquire the relevant layer. Preserve the ESP for a boot-file hypothesis. Escalate to qualified firmware acquisition and model-specific comparison for a firmware hypothesis. An acquisition result should include coverage and limitations, not just the name of the scanner that produced it.
Test the proposed explanation. Specify which evidence would distinguish a local implant from remote redeployment, a legitimate update or an unrelated kernel driver. Document excluded and unresolved explanations alongside the preferred one.

Map observed evidence to ATT&CK at the correct layer: T1542.003 for malicious boot-partition persistence, and T1542.001 for demonstrated system-firmware modification. Do not add the firmware technique merely because a product uses the word UEFI. A technique label is an index into the evidence, not additional evidence of its own.

Verify that firmware scanning is actually operating

Microsoft’s Defender firmware-scanning documentation describes runtime SPI inspection, periodic scanning and suspicious-driver triggers. It requires Defender Antivirus to be the active primary antivirus, with real-time protection and behaviour monitoring enabled. Passive Defender Antivirus with endpoint detection and response (EDR) block mode does not supply this scanner. Consequently, the presence of a Defender endpoint record does not establish that the device has firmware-scanning coverage. The documentation describes UEFI alerts and related device evidence that analysts can investigate.

As a collection check, select a representative device from each relevant hardware and security-policy group. Record whether the required protection mode is active, whether the product supports the device, whether scans actually complete and where the resulting evidence is retained. Treat unsupported, failed and never-scanned devices as separate coverage gaps. A dashboard with no firmware alerts is ambiguous until those denominators are known. These are TIR verification recommendations, not measured detection rates for a product.

ESET’s firmware-analysis research describes similarity-based prioritisation of firmware executables and distinguishes malicious implants from vendor recovery functionality and legitimate operating-system persistence modules. For analysts, that is a reason to preserve the unusual component and its context for comparison. An anomaly score or a module absent from a small reference set should initiate examination; neither is sufficient to declare an APT compromise. Build reference sets from matching hardware and approved firmware releases, and document the provenance of exceptions rather than suppressing them solely because they have appeared before.

Dwell time, strategic access and verified recovery

The public cases support a serious persistence problem; they do not support a single average dwell time for UEFI malware. An implant capable of surviving a reinstall is a capability finding. A source’s first and last observations form an observation span. The age of a sample, a debug path or an infrastructure registration is a different measurement again. None alone establishes uninterrupted access to a particular victim.

For each affected host, record the earliest evidenced installation or execution, first detection, containment, last observed malicious action and completion of the recovery checks. Mark unknowns as unknown. If a report says an attack was discovered in early 2026, do not silently turn that into an infection date of 1 January or assume access continued until October’s disclosure. Re-entry after remediation should be investigated as a separate event unless the evidence demonstrates that the original foothold survived.

Likely (B2): a demonstrated boot-level foothold increases the work required to establish recovery, because the investigation must cover components outside an ordinary application or operating-system clean-up. That is an assessment of assurance requirements, not a claim of measured additional months of access. Diplomatic targeting does not, by itself, demonstrate preparation to disrupt critical national infrastructure. Such a judgement would require evidence about the affected dependencies, access to operational systems, tasking or demonstrated effects.

NIST’s Platform Firmware Resiliency Guidelines organise firmware resilience around protection, detection and recovery. Apply that structure to the incident rather than reducing the response to a patch instruction. TIR recommends closing a confirmed case only when the record answers these questions:

Scope: Which firmware, boot, operating-system and identity components were compromised, examined or left unexamined?
Restoration: What trusted reference or approved recovery process was used, and what did it actually replace?
Verification: Which comparisons, boot checks and external observations support recovery, and who assessed their limitations?
Re-entry: Which exposed credentials, provider relationships or other footholds were addressed independently of the implant?
Monitoring: What follow-up observations would reopen the incident, and who owns that review?

Preserve evidence before destructive recovery where operationally possible, and use the device vendor’s supported process for firmware restoration. Do not assume a routine firmware update rewrites every region implicated by the investigation. If the required layer cannot be restored or verified, escalate the device disposition decision with that specific limitation. Replacing hardware can be a risk decision; it should not be advertised as the inevitable response to every bootkit alert.

Our BeyondTrust/Bomgar and SolarWinds comparison provides related reading on trusted access and recovery scope. The comparison is operational: examine where authority or persistence remains after the visible payload is removed. It does not establish a shared actor, a shared implant or a common intrusion chain.