BlackX UEFI Bootkit Bypasses Secure Boot on Fully Patched Windows Systems in APT41-Linked Espionage Campaign
A newly discovered UEFI bootkit known as BlackX has been deployed in a targeted cyberespionage campaign against diplomatic organizations in Central Asia, exploiting a years-old Windows Secure Boot vulnerability to establish persistent access and interfere with endpoint security defenses. The malware demonstrates how incomplete firmware-level security mitigations can leave systems vulnerable even when administrators have installed the latest operating system updates.
Security researchers at Kaspersky identified BlackX during investigations into attacks targeting diplomatic agencies in Tajikistan, Uzbekistan, and Turkmenistan in early 2026. The operation has been attributed with medium confidence to APT41, a Chinese state-linked threat group associated with long-running espionage campaigns and sophisticated intrusions against government and enterprise networks.
The bootkit exploits CVE-2022-21894, commonly known as Baton Drop, a vulnerability previously used by the BlackLotus bootkit to bypass Microsoft's Secure Boot protections. Although Microsoft addressed the underlying issue years ago, Kaspersky discovered that the affected organizations were running fully patched Windows systems that had not completed the additional certificate revocation procedures required to prevent exploitation.
The findings expose an important distinction between installing security updates and fully enforcing the protections those updates are intended to provide. In this case, attackers were able to take advantage of trusted but vulnerable boot components that remained accepted by the system's firmware, allowing malicious code to execute before Windows loaded and before conventional endpoint defenses could establish control.
BlackX Revives a Secure Boot Bypass Previously Used by BlackLotus
BlackX shares significant technical similarities with BlackLotus, a UEFI bootkit that first attracted attention in October 2022 when it was advertised on underground hacking forums for approximately $5,000. At the time, the possibility of a commercially available tool capable of bypassing Secure Boot raised concerns about the accessibility of sophisticated firmware-level attacks.
In March 2023, researchers at ESET confirmed that BlackLotus was capable of exploiting Baton Drop to undermine Secure Boot protections. The discovery demonstrated that a vulnerability in the Windows boot process could allow malicious components to execute despite mechanisms designed to verify the integrity of software loaded during system startup.
Secure Boot is intended to establish a chain of trust between a computer's firmware and the operating system. Before executing boot components, the firmware verifies their digital signatures against trusted certificates and checks whether they have been explicitly revoked. This process helps prevent unauthorized bootloaders and other malicious code from gaining control before the operating system starts.
Baton Drop undermines that protection by allowing an attacker with sufficient privileges to exploit vulnerable Windows boot components that retain valid signatures. The attack can effectively downgrade the boot process to a trusted but vulnerable state, creating an opportunity to introduce attacker-controlled components while circumventing the intended security restrictions.
BlackX adapts this technique to establish its own execution environment during system startup. Kaspersky found that its implementation of the exploit closely resembles the approach used by BlackLotus, including mechanisms for introducing custom Machine Owner Keys and loading unauthorized EFI components.
The similarities suggest that the BlackX developers either reverse-engineered BlackLotus or obtained access to its source code through private channels. While an incomplete version of the BlackLotus source code appeared publicly in July 2023, Kaspersky identified code similarities involving components absent from that leak, making simple reuse of the public repository an insufficient explanation.
The relationship between the two malware families illustrates how offensive techniques can move between financially motivated cybercriminal operations and state-linked espionage campaigns. Rather than developing an entirely new firmware exploitation technique, a sophisticated threat actor may adapt existing malware to meet its operational requirements.
Diplomatic Organizations Targeted After Initial Network Compromise
Kaspersky identified BlackX in attacks against diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan, countries whose geopolitical relationships and government communications make them potentially valuable intelligence targets.
The available evidence indicates that attackers deployed the bootkit after compromising the victims' networks and obtaining administrator-level privileges. This is a critical distinction: BlackX is not described as an unauthenticated remote exploit capable of compromising an arbitrary Windows computer directly over the internet.
Instead, the bootkit functions as a post-compromise persistence and defense-evasion mechanism. Once attackers obtain sufficient control over a Windows system, they can use the Secure Boot bypass to install components that execute during the earliest stages of startup, potentially making subsequent detection and removal more difficult.
During the observed intrusions, the attackers deployed an installer named inst.exe alongside an encrypted file containing the components and configuration data required for installation. The encrypted material was stored separately from the executable, reducing the amount of suspicious content directly visible in the installer.
The installer used RC4 encryption to recover the embedded components before writing malicious files to the Windows system and EFI partitions. This separation between the loader and encrypted payload helped conceal the bootkit's functionality from straightforward static analysis.
Once installed, BlackX modified the boot environment to exploit Baton Drop and load its malicious components. The resulting execution chain allowed the attackers to introduce a Windows kernel driver with capabilities extending beyond those available to ordinary user-mode malware.
The choice of diplomatic targets and the use of a sophisticated bootkit indicate an operation focused on maintaining access to sensitive systems rather than conducting indiscriminate financial theft. However, Kaspersky has not publicly established the full extent of information collected from the affected organizations.
A Malicious Kernel Driver Targets Endpoint Security Controls
One of BlackX's most significant capabilities is its ability to introduce a malicious Windows kernel driver into the operating system after bypassing Secure Boot.
Kernel drivers operate with extensive privileges and can interact with operating system components that ordinary applications cannot access directly. These capabilities make them valuable to legitimate security products, but they also provide attackers with powerful opportunities to interfere with monitoring, manipulate system behavior, and conceal malicious activity.
The BlackX driver was signed using a certificate associated with an organization identified as Wenjiang District Mingyu Network Technology Service Studio. Kaspersky reported that the certificate had been revoked by its issuer by the time the researchers published their analysis.
The driver's primary purpose is to interfere with security-related mechanisms. It attempts to disable process, thread, and registry callbacks that endpoint protection products use to observe potentially malicious activity. By disrupting those callbacks, the malware seeks to reduce the visibility of subsequent operations.
BlackX also tampers with Event Tracing for Windows (ETW), a Windows telemetry framework widely used by security products and diagnostic tools. Interfering with ETW providers can prevent certain security events from reaching monitoring systems, potentially limiting the information available to endpoint detection and response platforms.
Some of the driver's tampering routines specifically check for Kaspersky or Avast products before attempting to interfere with them. However, Kaspersky reported that the procedures targeting its own security solutions were ineffective during dynamic testing. The presence of those routines demonstrates attacker intent, but it does not establish that BlackX successfully disabled every targeted security product.
The driver includes an additional mechanism intended to protect the bootkit's files from inspection. When applications attempt to open certain protected malicious files, the driver intercepts the operation and substitutes a handle associated with the legitimate Windows Calculator executable.
This unusual behavior can frustrate attempts to inspect suspicious files through ordinary system interfaces. It also illustrates the degree of control available to malware operating inside the Windows kernel, where it can manipulate interactions between user applications and lower-level operating system resources.
Cloud Storage Services Used for Command-and-Control Communications
Beyond its firmware and kernel components, BlackX deploys additional malware designed to support espionage activities on compromised systems.
Kaspersky identified a remote access trojan that uses legitimate cloud storage platforms as command-and-control infrastructure. Observed variants communicated through Google Drive, Microsoft OneDrive, and Yandex.Disk, allowing attackers to exchange commands and files through services commonly used in legitimate enterprise environments.
This approach can complicate network-based detection because connections to major cloud storage providers may appear routine. Organizations frequently allow these services for business operations, making it difficult to distinguish authorized activity from malicious communications using destination-based filtering alone.
The remote access trojan interprets files stored in cloud accounts according to specific filename extensions. These files can contain commands, executable .NET modules, instructions to upload local files, or requests to download additional content.
The malware can load and execute .NET payloads, enabling attackers to extend its functionality without necessarily replacing the original implant. It can also transfer files between compromised systems and the associated cloud storage environment, creating opportunities for data collection and exfiltration.
The use of legitimate cloud services does not make the communications harmless. Instead, it represents a form of command-and-control infrastructure abuse in which trusted platforms are used to carry malicious instructions and stolen information.
For defenders, detecting this activity may require examining authentication patterns, application behavior, unusual cloud storage access, and unexpected data transfers rather than relying exclusively on known malicious domains.
The technique is particularly relevant in diplomatic and government environments, where attackers may attempt to blend malicious network traffic into ordinary collaboration and file-sharing activity.
OxiDLLRunner Provides a Second Espionage Payload
Kaspersky also identified a separate payload named OxiDLLRunner, which uses DLL sideloading and multiple layers of obfuscation to execute additional malicious components.
The attack chain involves a legitimate executable presented as googleupdate.exe, which loads a malicious DLL through Windows' normal library-loading behavior. This technique allows attacker-controlled code to execute within the context of a trusted application without requiring the legitimate executable itself to be modified.
The malicious DLL uses Obfuscator-LLVM, commonly known as OLLVM, to complicate reverse engineering. It decrypts a file named v8_context_snapshot.bin, which contains shellcode and a Rust-based payload.
Once executed, the Rust component communicates with an attacker-controlled server at archivetj[.]com to retrieve additional DLL plugins. The downloaded modules expose a function named create_plugin, which the malware invokes to execute the supplied functionality.
This modular architecture gives attackers flexibility to deploy different capabilities depending on their objectives. Rather than embedding every function in the initial malware package, operators can deliver additional components after establishing a foothold.
The use of Rust is also notable because the language has become increasingly common in modern malware development. Its cross-platform capabilities, performance characteristics, and compiled output can complicate some traditional analysis workflows, although the programming language itself does not inherently make malware undetectable.
Together, the cloud-based remote access trojan and OxiDLLRunner provide complementary mechanisms for maintaining access, receiving instructions, executing additional code, and potentially transferring sensitive information.
Kaspersky Links the Operation to APT41 With Medium Confidence
Kaspersky attributes the BlackX campaign to APT41 with medium confidence, based on technical similarities between the malware and activity previously associated with China-linked espionage operations.
APT41, also tracked under names including Brass Typhoon, Wicked Panda, and Barium, has been associated with a broad range of cyber operations involving government agencies, technology companies, and other strategically significant organizations.
One of the strongest connections identified by Kaspersky involves the string xdd, which appears in BlackX components and in a kernel implant previously described by ESET during its investigation of FishMonger activity.
In June 2026, ESET reported that FishMonger, a threat actor often associated with APT41, had used a kernel implant containing a development path beginning with C:\Users\xdd\Desktop. The same identifier appeared repeatedly in BlackX, suggesting a possible relationship between the tools or their developers.
Kaspersky also highlighted the use of DLL sideloading, encrypted payloads, and OLLVM obfuscation, techniques that have appeared in other operations attributed to Chinese-speaking threat actors.
However, these characteristics are not exclusive to a single group. Malware techniques, development tools, and infrastructure patterns can be shared, copied, or deliberately imitated by unrelated operators.
ESET acknowledged similarities between the BlackX findings and its earlier FishMonger research but cautioned that it could not confirm a direct connection without comparing the underlying malware samples.
The attribution should therefore be treated as a supported intelligence assessment rather than definitive proof of responsibility. Kaspersky's medium-confidence designation reflects the available evidence and the limitations of identifying threat actors through technical artifacts alone.
Fully Patched Windows Systems Remained Vulnerable
Perhaps the most consequential finding in the BlackX investigation is that the affected Windows systems had already received the relevant security updates.
Kaspersky initially suspected that the victims had failed to install patches addressing Baton Drop. Further investigation showed that the underlying problem was more complicated: the operating systems were patched, but the additional Secure Boot revocation measures had not been activated.
Microsoft's mitigation strategy involves revoking trust in older Windows boot components signed under the Windows Production PCA 2011 certificate. Those components can be abused in downgrade scenarios because they remain legitimately signed even though they contain vulnerabilities that have since been corrected.
To fully address the threat, the relevant revocation information must be applied to the firmware's Secure Boot forbidden signature database, commonly known as DBX.
However, Microsoft did not initially enforce every revocation automatically through ordinary Windows Update installation. The process required additional administrative actions, partly because revoking older boot components can interfere with recovery media, dual-boot configurations, and other systems that depend on legacy boot signatures.
This compatibility concern created a security gap. Administrators could install the latest Windows updates and reasonably believe their systems were protected, while the firmware continued trusting boot components that attackers could exploit.
BlackX operators took advantage of that gap by reintroducing vulnerable signed boot code and using it to bypass Secure Boot protections.
The incident demonstrates that a vulnerability can remain operationally exploitable long after its original patch is released when remediation depends on separate trust revocation procedures.
It also highlights a broader problem in enterprise patch management: software inventory and update compliance reports may not accurately reflect the security state of firmware-level trust databases.
Expired Certificates Do Not Automatically Eliminate the Threat
The BlackX findings also coincide with the October 19, 2026, expiration of the Windows Production PCA 2011 certificate, a development associated with Microsoft's broader transition toward newer Secure Boot certificates.
However, Kaspersky warned that certificate expiration alone does not prevent vulnerable boot components from loading.
Secure Boot verification depends on the firmware's configured trust databases and revocation information. An expired certificate may remain accepted under certain boot verification conditions unless the relevant signing authority or vulnerable component has been explicitly revoked.
Consequently, administrators should not assume that the passage of a certificate expiration date automatically eliminates exposure to Baton Drop or similar downgrade attacks.
Microsoft has provided guidance for deploying updated Secure Boot certificates and applying revocation mitigations, including procedures involving Windows registry configuration and the Secure-Boot-Update scheduled task.
These operations require careful planning because changes to firmware trust databases can affect boot compatibility. Organizations should verify that recovery environments, installation media, and any legitimate alternative operating systems remain compatible before enforcing revocations.
The BlackX campaign demonstrates why these procedures are security-critical rather than optional administrative housekeeping.
A fully updated Windows installation may still permit a dangerous boot chain if firmware trust settings continue accepting vulnerable components.
Why UEFI Bootkits Present a Serious Enterprise Threat
UEFI bootkits occupy a particularly sensitive position in the operating system startup process. By executing before Windows loads, they can influence the environment in which the operating system and its security components initialize.
This early execution can allow attackers to manipulate kernel behavior, interfere with defensive controls, and establish persistence that is difficult to detect through ordinary user-mode security tools.
Unlike conventional malware that relies on startup folders, scheduled tasks, or registry autorun entries, a bootkit can operate through components associated with the firmware and boot process. Removing visible malicious applications may therefore be insufficient if the underlying boot environment remains compromised.
However, the presence of a bootkit does not necessarily mean that the physical firmware chip itself has been permanently modified. In the BlackX case, the observed installation involved malicious components written to system and EFI partitions and changes to the trusted boot process.
This distinction matters for incident response because different persistence mechanisms require different remediation procedures.
Organizations investigating suspected bootkit infections should assess the integrity of the EFI System Partition, boot configuration, Secure Boot trust databases, and kernel drivers. They should also determine whether the attacker maintained other access mechanisms elsewhere in the network.
Because BlackX was deployed after attackers had already obtained administrator privileges, incident responders must address the original compromise as well as the bootkit itself.
Reinstalling Windows or restoring a clean boot environment may remove certain malicious components, but the effectiveness of remediation depends on whether all persistence mechanisms and compromised credentials have been identified.
Security Teams Must Verify Secure Boot Revocations, Not Just Windows Updates
The BlackX campaign provides several practical lessons for organizations responsible for Windows endpoint and firmware security.
First, administrators should verify that the complete Microsoft Secure Boot mitigation process has been applied, including the relevant certificate and boot component revocations. Installing the latest cumulative Windows updates is necessary but may not be sufficient.
Second, organizations should review systems that have been exposed to privileged compromise, particularly those belonging to high-value users or sensitive departments. BlackX requires an attacker to obtain elevated access before deploying the bootkit, making the protection of administrator credentials and privileged sessions a critical defensive measure.
Third, security teams should monitor for suspicious changes to EFI partitions, unexpected kernel drivers, abnormal boot configuration modifications, and unauthorized changes to Secure Boot trust databases.
Fourth, the use of legitimate cloud storage platforms for command-and-control activity demonstrates the importance of behavioral monitoring. Connections to Google Drive, OneDrive, or Yandex.Disk should be evaluated in context, especially when they originate from unusual processes or systems that do not normally use those services.
Finally, organizations should consult the indicators of compromise and technical analysis published by Kaspersky when investigating potential exposure. Those artifacts can help identify known BlackX components, although the absence of matching indicators does not guarantee that a system is uncompromised.
Secure Boot revocation changes should follow Microsoft's documented procedures and compatibility guidance rather than being applied through untested modifications to firmware databases.
BlackX Exposes a Critical Gap Between Patching and Protection
The discovery of BlackX illustrates how sophisticated threat actors can revive older exploitation techniques when defensive mitigations remain incomplete.
The attackers did not need to discover a new Secure Boot vulnerability. Instead, they adapted a technique previously demonstrated by BlackLotus and exploited the continued acceptance of vulnerable signed boot components on systems that administrators had otherwise kept updated.
The campaign also demonstrates the growing convergence of different offensive capabilities. BlackX combines firmware-level persistence, kernel driver manipulation, cloud-based command-and-control communications, DLL sideloading, encrypted payloads, and modular malware delivery within a single espionage operation.
Its suspected connection to APT41 highlights the continued interest of state-linked actors in techniques capable of maintaining access to sensitive government systems while reducing the effectiveness of endpoint monitoring.
For defenders, the most important finding is that compliance with ordinary patching procedures does not always guarantee that the underlying security boundary has been restored. Firmware trust databases, certificate revocations, and boot configuration settings must be included in security assessments when vulnerabilities affect the operating system's chain of trust.
BlackX demonstrates that a vulnerability can remain exploitable years after a patch becomes available when the final security mitigation depends on administrative actions that have not been completed.
As attackers increasingly combine conventional network intrusions with lower-level persistence mechanisms, organizations must extend vulnerability management beyond software version numbers and verify that the protections intended to prevent exploitation are actually enforced.
The BlackX campaign is a reminder that Secure Boot is only as strong as the trust decisions configured beneath it, and that a fully patched operating system can remain vulnerable when its firmware continues accepting components that should no longer be trusted.