BlackX UEFI Bootkit Bypasses Secure Boot on Fully Patched Windows Systems

A newly documented BlackX UEFI bootkit has been used to bypass Secure Boot protections on Windows computers that had already received security updates, exposing a dangerous gap between installing patches and completing firmware-level revocation measures.

Kaspersky researchers identified BlackX during an investigation into attacks targeting diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan in early 2026. The malware exploits CVE-2022-21894, also known as Baton Drop, and uses techniques associated with the earlier BlackLotus bootkit.

The technical research, published on October 22, 2026, shows that some affected systems had already received the relevant Windows security updates. However, the required Secure Boot revocation measures had not been applied, leaving vulnerable boot components available for exploitation.

BlackX is not a vulnerability that automatically infects Windows computers through an internet connection. In the observed attacks, the operators first compromised victim environments and obtained administrator privileges before deploying the bootkit.

Once installed, BlackX attempted to interfere with early Windows startup protections, inject a malicious kernel driver and support additional espionage payloads.

Kaspersky suspects a connection to the China-linked APT41 threat group with moderate confidence. The available evidence does not establish definitive attribution.

The campaign demonstrates how sophisticated attackers can exploit unresolved security gaps long after a vulnerability has been publicly documented. For broader context, explore our Nation-State Cyber Warfare and APT Threats Guide.

Key Findings About the BlackX UEFI Bootkit

• Malware: BlackX, a UEFI bootkit that reuses techniques associated with the earlier BlackLotus threat.
• Targets: Diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan during early 2026.
• Exploited vulnerability: CVE-2022-21894, also known as Baton Drop, a Windows Secure Boot security feature bypass.
• Attack prerequisite: Researchers observed deployment after attackers compromised victim networks and obtained administrator privileges.
• Critical security gap: Relevant Windows updates were installed, but necessary Secure Boot revocations remained unapplied.
• Malicious activity: Boot-level manipulation, kernel-driver deployment, attempted security interference and espionage payload delivery.
• Suspected operator: APT41, based on Kaspersky’s moderate-confidence assessment rather than confirmed attribution.

How the BlackX UEFI Bootkit Bypasses Windows Secure Boot

Secure Boot is a security feature implemented in Unified Extensible Firmware Interface, or UEFI, to help ensure that only trusted software executes during a computer’s startup process.

When a compatible system starts, the firmware verifies signatures associated with boot components against trusted and revoked entries maintained in its Secure Boot databases.

Two important databases are involved:

• DB: The allowed signature database containing trusted certificates and signatures.
• DBX: The forbidden signature database containing revoked or explicitly disallowed signatures.

These controls help prevent unauthorized EFI applications and bootloaders from executing before Windows starts.

BlackX exploits a situation in which vulnerable boot components remain usable because the necessary revocation has not been enforced.

In the documented campaign, researchers found that attackers could still exploit the Baton Drop Secure Boot bypass even though relevant operating-system updates had been installed.

This distinction matters because installing a Windows update does not necessarily complete every associated firmware-level security measure.

The bootkit uses the weakness to interfere with the startup sequence and arrange for malicious code to execute inside Windows.

Because this activity occurs before ordinary applications start, it can create detection and remediation challenges for conventional endpoint security tools.

CVE-2022-21894: The Baton Drop Vulnerability Behind BlackX

CVE-2022-21894 is a Windows Secure Boot security feature bypass vulnerability associated with the Baton Drop technique.

The vulnerability gained attention through earlier BlackLotus bootkit research. BlackX demonstrates how similar exploitation techniques can appear in a later, targeted espionage campaign.

Importantly, the vulnerability is not a standalone, unauthenticated remote-code-execution issue that allows any external attacker to compromise a Windows computer directly over the internet.

The observed BlackX operators already had administrator-level access before installing the bootkit.

The subsequent Secure Boot bypass helped them manipulate the boot environment and attempt to establish a more persistent foothold.

The operational risk becomes particularly serious when an attacker already controls a privileged Windows account and the device still trusts vulnerable boot components.

Why Fully Patched Windows Systems Remained Vulnerable

One of the most important findings in Kaspersky’s investigation was that relevant Windows updates had already been installed on affected systems.

Researchers initially considered whether administrators had failed to apply available security patches.

Further investigation revealed a more specific gap: the Secure Boot revocation stage of the mitigation had not been completed.

Microsoft has maintained a staged approach to certain Secure Boot changes because revoking trusted boot components without preparing devices can interfere with recovery media, installation environments and other legitimate boot configurations.

As a result, completing the necessary protection may involve additional configuration and verification beyond ordinary Windows patch installation.

In the observed attacks, this distinction allowed the operators to continue exploiting a previously known vulnerability.

For enterprise administrators, the lesson is straightforward: a Windows device showing current operating-system updates is not necessarily fully protected against known Secure Boot bypass techniques.

Secure Boot maintenance can also introduce operational challenges. In a separate issue, our Windows 11 BitLocker recovery loop troubleshooting guide discusses reported boot-recovery problems associated with update KB5094126. That servicing issue is distinct from the CVE-2022-21894 bypass exploited by BlackX, and the guide should not be treated as a BlackX removal procedure.

Microsoft recommends validating Secure Boot updates, firmware compatibility and BitLocker recovery readiness before deploying boot-related changes across managed systems.

October 19, 2026 Certificate Expiration: What Changed?

The Microsoft Windows Production PCA 2011 certificate reached its scheduled expiration on October 19, 2026.

Microsoft is transitioning Windows bootloader signing and related security components to newer certificate authorities, including Windows UEFI CA 2023.

However, certificate expiration does not automatically make an existing Windows installation unbootable.

Microsoft explains that devices with older certificates may continue starting normally and receiving ordinary Windows updates.

The longer-term problem is that devices without the necessary updated certificate configuration may be unable to receive new protections for early boot components.

These protections include certain boot manager updates, Secure Boot database changes and revocation-list updates.

Certificate expiration and explicit revocation are separate security concepts.

Therefore, an expired signing certificate does not prove that every older vulnerable boot component has been rejected by device firmware.

Organizations should verify their transition to newer certificates and confirm the state of relevant Secure Boot revocations using Microsoft’s supported procedures.

BlackX Attack Chain: From Initial Compromise to Boot-Level Persistence

Kaspersky documented a multi-stage operation involving privileged access, encrypted installation components, manipulation of boot files and follow-on espionage payloads.

Stage 1: Initial Network Compromise

The attackers compromised victim networks and obtained administrator privileges on targeted Windows computers before deploying BlackX.

The specific initial-access technique was not established in the public research.

There is no verified basis for attributing the first compromise to a particular phishing message, exposed remote service or zero-day exploit.

Stage 2: Encrypted Bootkit Installation

The operators used an installer named inst.exe together with an extensionless file named PVMDIJGKAX2.

Researchers identified RC4-encrypted installation data associated with these components.

The encrypted package helped conceal the files and strings required for later deployment stages.

Using encrypted installation components can make straightforward file inspection more difficult, although encryption alone does not guarantee successful evasion.

Stage 3: EFI System Partition Manipulation

The installer placed additional files in system and UEFI partitions as part of the Baton Drop exploitation process.

The technique resembled behavior previously documented in BlackLotus.

The attackers attempted to manipulate boot trust using custom Machine Owner Keys, enabling the loading of unauthorized EFI components.

These changes were intended to bypass established startup protections rather than simply install an ordinary Windows application.

Stage 4: Kernel Driver Deployment

After the boot-stage compromise, BlackX attempted to inject a malicious driver into the Windows kernel.

The driver included functionality designed to interfere with security monitoring.

Researchers observed attempts to manipulate process, thread and registry notification callbacks, as well as selected Event Tracing for Windows providers.

These mechanisms can be important to security products that monitor suspicious system behavior.

Stage 5: Espionage Payload Delivery

The attack framework was also designed to launch additional components supporting remote access, information collection and command execution.

These payloads extended the attack from early boot manipulation into ordinary Windows user-mode activity.

However, Kaspersky reported that its protection prevented the observed attack from reaching the intended final outcome, so the presence of these payloads should not be interpreted as proof that every planned espionage action succeeded on the defended systems.

BlackX Malware Components and Indicators

Kaspersky’s technical analysis identifies multiple files, behaviors and infrastructure elements that can support threat hunting.

The reported domain is intentionally defanged to prevent accidental navigation.

These indicators should be treated as investigation leads rather than standalone proof of compromise.

For example, a file named googleupdate.exe is not necessarily malicious because legitimate applications can use similar names.

Security teams should correlate suspicious file paths, digital signatures, hashes, process relationships, boot partition modifications and network telemetry.

Detailed indicators and supporting technical evidence are available in Kaspersky’s original research.

How BlackX Attempts to Disable Endpoint Security Tools

BlackX was engineered to interfere with security products after establishing a foothold in the boot process.

Its kernel driver attempted to manipulate operating-system callbacks used to observe process creation, thread activity and registry changes.

The malware also targeted selected Event Tracing for Windows mechanisms.

These techniques can reduce the visibility of suspicious activity when they work as intended.

The researchers identified routines that checked for particular security products and attempted to interfere with their operation.

However, not every tampering attempt succeeded.

Kaspersky reported that its protection blocked the attack and that some product-specific interference routines were ineffective during analysis.

It would therefore be inaccurate to claim that BlackX universally disables all endpoint detection and antivirus solutions.

The supported conclusion is that BlackX was designed to weaken security monitoring, with the success of individual techniques depending on the environment and defensive controls.

BlackX Espionage Payloads Use Cloud Services and DLL Sideloading

Kaspersky identified additional payloads intended to support intelligence collection and remote access.

Cloud-Based Command-and-Control Activity

One payload was a remote access trojan capable of delivering additional .NET components.

Researchers observed versions using Google Drive, OneDrive and Yandex.Disk for command-and-control communication.

Legitimate cloud services can make malicious network activity harder to distinguish from normal enterprise traffic.

However, the use of these services does not indicate that the cloud providers themselves were compromised.

Security analysts must evaluate the associated process behavior, account activity and communication patterns.

OxiDLLRunner and Rust Payload Delivery

Another component identified by Kaspersky was OxiDLLRunner, a malicious DLL associated with a sideloading technique.

In the observed chain, a legitimate executable delivered with the attack was used to load the malicious DLL.

OxiDLLRunner decrypted and launched a Rust-based payload capable of communicating with command-and-control infrastructure and retrieving additional components.

The combination of boot-level manipulation, kernel interference and user-mode payload delivery illustrates the layered nature of the campaign.

Is China-Linked APT41 Behind the BlackX Attacks?

Kaspersky suspects that the BlackX operation may be connected to the China-linked APT41 threat ecosystem.

Its attribution assessment carries moderate confidence.

Researchers noted similarities with activity previously associated with FishMonger and related threat-tracking clusters.

The investigation identified technical overlaps, including a shared string and similarities in malicious DLL execution techniques.

These observations are relevant for intelligence analysis, but they do not independently prove who developed or deployed BlackX.

The targeting of diplomatic organizations is consistent with an espionage objective, but victim selection alone is not sufficient for definitive attribution.

Security reporting should therefore describe APT41 as a suspected connection rather than a confirmed operator.

BlackX vs BlackLotus: What’s Different?

BlackX and BlackLotus share important technical characteristics.

Both rely on the Baton Drop Secure Boot bypass and attempt to interfere with trusted early boot execution.

BlackLotus became widely known through earlier research into bootkits capable of bypassing Windows Secure Boot protections.

BlackX appears to reuse or adapt key ideas from that earlier malware while incorporating different components for kernel interference and espionage payload delivery.

Researchers have not established whether BlackX operators reverse-engineered BlackLotus or acquired relevant source code through another channel.

What is clear is that previously known boot-level attack techniques remain relevant when required security mitigations are incomplete.

How to Check Windows Secure Boot Status Safely

Administrators should begin with non-destructive checks before making firmware-level changes.

Check Whether Secure Boot Is Enabled

On a supported Windows system, open PowerShell with administrator privileges and run:

Confirm-SecureBootUEFI

A result of True indicates Secure Boot is enabled.

A result of False indicates it is disabled.

Systems using unsupported hardware or boot modes may return an error.

Important: This command does not prove that the required Secure Boot certificate updates or revocations have been applied.

Check Windows System Information

Run the following command:

msinfo32

Review the Secure Boot State field in System Information.

This provides a useful initial status check but does not independently validate the full firmware trust configuration.

Review Certificate and Revocation Status

Enterprise administrators should consult Microsoft’s current Secure Boot certificate management documentation.

Microsoft provides supported methods for checking whether updated 2023 certificates have been applied and for reviewing relevant servicing events and deployment status.

Administrators must distinguish between the certificate authority trusted by the device and the revocation entries required to block vulnerable boot components.

Avoid Unverified Firmware Changes

Do not blindly delete Secure Boot keys, disable protection or apply unknown registry commands to a production device.

Incorrect firmware changes can create boot failures, BitLocker recovery prompts or other operational problems.

Use approved vendor and Microsoft procedures, and test security updates on representative devices before broad deployment.

BlackX UEFI Bootkit Mitigation: Enterprise Security Checklist

The most effective defensive approach combines patch management, Secure Boot configuration verification, privileged-access protection and incident monitoring.

1. Inventory Windows Secure Boot Configuration

Identify systems using UEFI Secure Boot and maintain records of firmware versions, Windows update status and relevant certificate configurations.

Devices with similar Windows patch levels may have different Secure Boot trust states.

2. Review Microsoft’s Revocation Guidance

Verify whether devices have completed the required mitigations associated with CVE-2022-21894 and related boot-level vulnerabilities.

Do not assume that installing a cumulative Windows update automatically completed every relevant revocation measure.

3. Prepare Recovery Media Before Changes

Check recovery media, firmware compatibility, bootloader configuration and BitLocker recovery readiness before deploying boot-related security changes.

Test changes across representative hardware and operating-system combinations.

4. Protect Administrative Privileges

BlackX was deployed after attackers obtained administrator privileges.

Limit unnecessary local administrator access and monitor privilege escalation, credential misuse and unauthorized configuration changes.

5. Investigate Suspicious EFI Modifications

Unexpected changes to EFI system partitions or boot-related components should receive appropriate security investigation.

Do not remove suspected bootkit files from a compromised live system without a validated incident-response plan.

6. Correlate Endpoint and Network Telemetry

Review suspicious installer activity, unexpected kernel drivers, anomalous DLL loading and cloud-service communications inconsistent with approved business processes.

Combine endpoint evidence with the indicators and behavioral information documented in Kaspersky’s research.

7. Maintain a Trusted Recovery Procedure

If boot-level compromise is suspected, involve qualified incident responders and use trusted recovery or reimaging procedures appropriate to the affected environment.

A bootkit incident may require more extensive remediation than deleting an ordinary malicious application.

Confirmed vs Unknown: BlackX UEFI Bootkit Campaign

Confirmed by Kaspersky’s Research

• BlackX was identified during attacks involving diplomatic organizations in Central Asia.
• The documented campaign occurred in early 2026.
• Attackers obtained administrative access before deploying the bootkit.
• BlackX exploited CVE-2022-21894 using techniques resembling BlackLotus.
• Some targeted systems had relevant Windows updates installed but lacked required Secure Boot revocation measures.
• The malware attempted to manipulate the boot process and deploy a malicious kernel driver.
• Researchers analyzed additional espionage payloads and command-and-control mechanisms.
• Kaspersky attributed the campaign to APT41 with moderate confidence.
• Kaspersky reported that its defenses blocked the observed attack.

Not Established by the Available Evidence

• The exact initial-access method used against the targeted organizations.
• That every fully patched Windows device is vulnerable to BlackX.
• That BlackX can compromise a remote system without prior privileged access.
• That the malware successfully disables every endpoint security product.
• That every identified espionage capability was successfully used against victims.
• The total number of compromised devices worldwide.
• Definitive attribution to APT41.
• The exact means through which BlackX operators obtained or recreated BlackLotus techniques.
• That Windows BitLocker recovery loops are evidence of BlackX infection.

CyberUpdates365 Analysis

The BlackX campaign highlights a significant challenge in enterprise vulnerability management: a system may show the latest Windows updates while important boot-level protections remain incomplete.

Traditional patch dashboards are designed to identify missing operating-system updates.

However, Secure Boot protections also depend on firmware trust databases, certificate transitions and revocation decisions.

In the documented campaign, the gap between installing an update and completing the associated mitigation created an opportunity for attackers to reuse a previously known vulnerability.

The Microsoft Windows Production PCA 2011 certificate expiration adds another important dimension.

Organizations must understand that a certificate’s expiration date does not automatically revoke every older boot component or complete the transition to newer signing authorities.

Microsoft has also warned that devices lacking newer Secure Boot certificates may continue running normally while gradually losing the ability to receive certain future boot-level protections.

For enterprise teams, the practical lesson is that patch compliance and boot-chain security must be measured separately.

Security teams should maintain visibility into certificate status, firmware compatibility and relevant revocation deployments.

Operational safety is equally important.

Improper Secure Boot maintenance can create startup or BitLocker recovery problems, which is why Microsoft recommends supported deployment methods and compatibility testing.

These boot-servicing problems must not be confused with the BlackX attack itself.

The campaign also reinforces the importance of preventing privileged access.

In the observed incidents, the attackers had already compromised the target environments before installing BlackX.

That means hardening administrative accounts and detecting unusual privileged activity remain essential even when firmware protections are correctly configured.

Finally, threat-actor attribution should not overshadow the defensive implications.

Kaspersky’s moderate-confidence APT41 assessment may help intelligence teams understand the broader campaign, but organizations should address the underlying Secure Boot exposure regardless of the operator’s identity.

The central lesson is that a fully updated Windows installation is not necessarily a fully remediated boot environment. Patch status, Secure Boot trust and revocation state must be validated together.

Research Evidence

• Research organization: Kaspersky Global Research and Analysis Team.
• Technical report date: October 22, 2026.
• Campaign period: Early 2026.
• Targeted region: Central Asia.
• Documented countries: Tajikistan, Uzbekistan and Turkmenistan.
• Malware: BlackX UEFI bootkit.
• Related malware: BlackLotus.
• Exploited vulnerability: CVE-2022-21894, Baton Drop.
• Observed access prerequisite: Prior network compromise and administrator privileges.
• Security weakness: Incomplete Secure Boot revocation mitigation.
• Relevant Microsoft certificate: Windows Production PCA 2011.
• Certificate expiration: October 19, 2026.
• Observed components: Installer, encrypted payload data, boot-level modifications and malicious driver.
• Espionage capabilities: Remote access, cloud-based communications and additional payload delivery.
• Suspected threat actor: APT41, moderate confidence.
• Defensive priority: Validate Windows updates, Secure Boot revocations and privileged-access protections.

Frequently Asked Questions

What is the BlackX UEFI bootkit?

BlackX is a boot-level malware framework documented by Kaspersky in October 2026. It was identified in targeted attacks against diplomatic organizations in Central Asia and uses techniques associated with BlackLotus.

Which CVE does BlackX exploit?

BlackX exploits CVE-2022-21894, also known as Baton Drop, a Windows Secure Boot security feature bypass vulnerability.

Can BlackX affect fully patched Windows computers?

Yes, under specific conditions. Kaspersky found affected systems with relevant Windows updates installed but missing the required Secure Boot revocation mitigation.

Does BlackX require administrator privileges?

In the documented attacks, the operators first obtained administrative privileges before deploying the bootkit. BlackX was not identified as the initial compromise method.

Is BlackX related to BlackLotus?

Yes. Both use similar Secure Boot exploitation techniques, including Baton Drop. However, their components and documented campaigns differ.

Is APT41 confirmed to be behind BlackX?

No. Kaspersky assessed a possible connection to APT41 with moderate confidence. Definitive attribution has not been established.

Did the October 2026 Secure Boot certificate expiration fix this issue?

No. Certificate expiration and revocation are separate processes. Organizations must verify appropriate certificate updates and revocation protections rather than relying on the expiration date alone.

How can administrators protect systems against BlackX?

Follow Microsoft’s supported Secure Boot mitigation guidance, verify certificate and revocation status, restrict administrative privileges, monitor suspicious boot modifications and maintain trusted recovery procedures.

Final Takeaway

The BlackX UEFI bootkit campaign demonstrates how attackers can reuse a known Secure Boot bypass when required revocation measures remain incomplete.

Kaspersky found that the relevant Windows security updates were installed on affected systems, yet vulnerable boot components remained exploitable because the full mitigation had not been completed.

The operators used this weakness after gaining administrative access and attempted to establish boot-level persistence while delivering additional malicious components.

Although Kaspersky suspects APT41 involvement, the attribution remains a moderate-confidence assessment.

For Windows administrators, the immediate priority is to verify operating-system patch deployment, Secure Boot certificate status and relevant revocation protections while reducing exposure from privileged accounts.

Want to understand how advanced attackers turn security weaknesses into persistent enterprise access?

Our separate investigation examines how China-linked hackers exploited a BeyondTrust zero-day to compromise enterprise environments.

Read: China-Linked Hackers Exploit BeyondTrust Zero-Day →

Official Sources

• Kaspersky Securelist — Original BlackX UEFI Bootkit Technical Research
• Kaspersky — BlackX Campaign Announcement, October 22, 2026
• Microsoft — Windows Secure Boot Certificate Expiration and CA Updates
• Microsoft — October 2026 Windows Production CA 2011 Expiration and Bootloader Guidance
• Microsoft Learn — Update Secure Boot Certificates for Windows Devices