Fully patched machines still got a bootkit: BlackX, the BlackLotus copycat, and the patch nobody switched on
Summary
In early 2026, Kaspersky GReAT identified an APT campaign against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan that involved a UEFI bootkit they named BlackX. On examination, it turned out to be a copycat of BlackLotus, the bootkit advertised for $5,000 on a cybercrime forum back in 2022.
BlackX exploits Baton Drop (CVE-2022-21894) to bypass Secure Boot — a vulnerability Microsoft patched back in 2023.
And here is what makes the report worth reading: the infected machines were fully patched. Kaspersky checked and ruled out the "negligent victim" theory. The problem is the patch itself: it does not activate on its own. An administrator has to take extra manual steps after installing the update, and almost nobody does.
Priority actions:
- Check whether the Secure Boot revocation is actually enabled across your fleet — specifically the registry flag under
HKLM\SYSTEM\CurrentControlSet\Control\Securebootand theSecure-Boot-Updatescheduled task. Having the patch is not the same as being protected. - Treat every patch that requires manual steps as not applied until proven otherwise. This is not a one-off: Kaspersky points out that the 2025 ToolShell patch also had to be applied manually.
From BlackLotus to BlackX
In October 2022, GReAT was tracking a forum advertisement: a UEFI bootkit that could bypass Secure Boot, for $5,000, named BlackLotus. The price was so low relative to the advertised capability that the security community initially took it with a grain of salt, and no samples existed in the wild to verify the claim.
About half a year later, in March 2023, ESET confirmed the advertisement was genuine: they tracked down samples and confirmed the bootkit does exploit Baton Drop to bypass Secure Boot. Because the vulnerability was still exploitable at that point, Microsoft had to ship several security updates.
After those updates, BlackLotus went quiet. No publicly known attacks used it — until early 2026, when GReAT came across a very similar sample, this time in the hands of an APT group.
One detail is worth pausing on: the BlackLotus source code was never published. Kaspersky compared the exploitation code in both bootkits and found the implementation "remarkably similar" but not identical. That means the group behind BlackX either reverse-engineered BlackLotus or bought its source from cybercriminals.
In Kaspersky's own words, this is rare: "we rarely see APT actors borrow ideas or code from cybercrime actors".
How BlackX is deployed
The bootkit is not the way in. The attackers had already compromised the network and obtained administrator privileges before installing it — the initial access method is not identified in the report.
The installation package is two files:
inst.exe # installer
PVMDIJGKAX2 # extensionless RC4-encrypted file holding every file and string the install needs
The command line:
C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1
The last argument is the RC4 decryption key.
A detail that matters for incident responders: inst.exe contains no malicious strings and no embedded blobs. Everything lives in PVMDIJGKAX2. If you collect only the executable and not the data file, you cannot recover the bootkit components.
The installer drops files to both the system and UEFI partitions in order to exploit Baton Drop. The goal of the exploit matches BlackLotus exactly: install the attacker's Machine Owner Keys (MOK), which allows loading arbitrary EFI files and manipulating Secure Boot.
The kernel driver: making EDR go quiet
The UEFI payload delivered during exploitation has the classic bootkit objective — injecting a malicious driver into the Windows kernel.
This driver differs from the BlackLotus one and is signed with a certificate belonging to an organization named 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio), serial 0bcdf5e0da32d68900b8b7638459d072. At the time of Kaspersky's publication the certificate had been revoked by its issuer.
The driver does three things:
- Disables process, thread and registry callbacks belonging to security solutions — the EDR loses its data sources rather than crashing.
- Tampers with ETW providers so security products cannot read their own output.
- Protects the bootkit's files: it intercepts kernel requests to open them and returns a handle to
calc.exeinstead of the real file handle. The third trick is notable for not blocking access outright. A forensic tool opening the file gets a perfectly valid handle — it just points at the wrong thing.
One curiosity: some of the tampering routines only run if a Kaspersky or Avast product is installed. During dynamic analysis, Kaspersky found these routines to be useless — they fail to interfere with Kaspersky products at all.
Two user-mode payloads
Beyond crippling security software, the driver also deploys a user-mode payload. GReAT observed two, both for cyberespionage.
A RAT using cloud storage as C2
The first payload is a RAT capable of loading further-stage .NET payloads. It uses cloud storage services as its C2 channel — observed versions used Google Drive, OneDrive and Yandex.Disk.
Once connected, the RAT iterates over the files available there and interprets them by filename suffix:
| Suffix | Meaning | Direction |
|---|---|---|
0X01 |
A .NET file; the task is to parse it and run TEST.Class1.RunCMD(argument_array) |
Input |
0X02 |
Result of the TEST.Class1.RunCMD(argument_array) call |
Output |
0X03 |
Task to upload a file to the drive | Input |
0X04 |
The uploaded file | Output |
0X05 |
Task to download a file to the infected machine | Input |
0X06 |
File download status | Output |
SSSR |
Initial system information | Output |
OxiDLLRunner
The second payload is a malicious DLL obfuscated with OLLVM, which Kaspersky named OxiDLLRunner.
The load chain:
googleupdate.exe # clean file, actually jcef_helper.exe
-> sideloads OxiDLLRunner (malicious DLL, OLLVM-obfuscated)
-> decrypts v8_context_snapshot.bin in the same folder
-> jumps to the start of the decrypted content: shellcode, then a PE file
-> Rust payload, C2 www[.]archivetj[.]com
-> receives DLLs exporting create_plugin, each run in its own thread
Both googleupdate.exe and the data file are delivered by the bootkit. The filename is chosen to look like an ordinary Google update process.
Why fully patched organizations were still infected
This is the most important part of the report, and it is not about malware.
GReAT initially assumed the victims got infected through negligence: Baton Drop was disclosed and patched back in 2023, so surely the machines lacked updates. The investigation proved that wrong — the targeted machines were fully patched.
The problem lies in the design of the patch.
The Baton Drop patch works by revoking the "Windows Production PCA 2011" certificate used to sign the vulnerable UEFI components. But that revocation does not happen automatically when the patch is installed. The user has to trigger it, in two steps:
- A registry flag is set in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot - A scheduled task named
Secure-Boot-Updateis created Microsoft designed it this way deliberately, and for an entirely legitimate reason: applying it automatically could break dual-boot systems that rely on the "Windows Production PCA 2011" certificate to load.
But this deployment practice creates a different problem. As Kaspersky writes, it is extremely unusual for a system administrator to take extra steps after installing an update: normally, installing is the whole job unless something fails. The activation instructions are buried deep in Microsoft's documentation, and GReAT assesses they are quite hard for an average IT administrator to notice.
Two further details make the picture worse:
- Microsoft's deployment plan mentions an "Enforcement Phase" that would revoke the certificate automatically without user interaction. As of Kaspersky's publication (October 22, 2026), that stage has not been implemented.
- On October 19, 2026, the "Windows Production PCA 2011" certificate expired. But expiry does not prevent the vulnerable binaries from loading unless the certificate is blocklisted in DBX. Kaspersky assesses that the threat actor took into account how few organizations realized they had to activate the patch manually, and that this is precisely why they invested the effort to understand BlackLotus and build a copycat.
Attribution
Kaspersky attributes this campaign to APT41 with medium confidence, on three grounds:
- In June 2026, ESET published a post on the FishMonger threat actor (assumed by the community to be related to APT41), describing a kernel implant with a PDB path starting with
C:\Users\xdd\Desktopand suggesting the possible use of an unspecified UEFI bootkit component, potentially exploiting CVE-2023-24932. Kaspersky observed the identifierxddused multiple times in BlackX payloads, and assesses that BlackX is the bootkit ESET referred to. - The payloads are loaded through DLL sideloading from a legitimate executable plus an encrypted file — a pattern common among Chinese-speaking threat actors.
- OxiDLLRunner is obfuscated with OLLVM, an obfuscator commonly used by those actors. Per The Hacker News, FishMonger — also tracked as Aquatic Panda and Earth Lusca — is assessed to operate under the APT41 umbrella and targeted government entities in Honduras, Taiwan, Thailand and Pakistan between 2023 and 2024. ESET said at the time it had only "limited indications" of a bootkit component, which it suspected exploited CVE-2023-24932, a bypass for the very mitigations Microsoft introduced to fix CVE-2022-21894.
Assessment
A patch that requires manual steps is nearly invisible security debt. Every compliance dashboard will report these machines as patched. Every management report will say 100% compliance. All of it is literally true. The gap between "the patch is installed" and "the machine is protected" shows up in none of the metrics a SOC normally tracks.
Microsoft's decision was not wrong, but the consequences are real. Automatically revoking the certificate could leave large numbers of dual-boot machines unable to start — an operational risk far more severe than a vulnerability that requires admin rights to exploit. The problem is that the transition period has now run from 2023 to today, and the Enforcement Phase still has not arrived.
A bootkit is a persistence mechanism, not an entry point. Microsoft's 2023 statement, which The Hacker News revisits, still holds for BlackX: it can only be deployed to a device where the attacker already has privileged or physical access. In other words, if you find the bootkit, the breach happened earlier — and what needs investigating is the initial access step this report could not identify.
The driver's goal is to silence the EDR, not to crash it. Disabling callbacks and tampering with ETW means the security console stays green and the agent still reports online, there is simply nothing left to report. That is the most dangerous failure mode a monitoring system has: it does not throw an error.
C2 over Google Drive, OneDrive and Yandex.Disk is about as hard to block as it gets. In an organization already on M365, OneDrive traffic is normal traffic. Detection has to come from process behavior — which process is talking to cloud storage, and what business does it have doing so — rather than from the destination.
The "the driver tried to fight Kaspersky and failed" detail says quite a lot. This group was capable enough to rebuild a UEFI bootkit from scratch, yet the anti-security-product component was not tested properly. That is a familiar pattern: uneven capability across components of the same toolkit, usually a sign of multiple people or multiple code sources.
Relevance for Vietnam
- The victim list Kaspersky published does not include Vietnam — only Tajikistan, Uzbekistan and Turkmenistan. That said, the APT41/FishMonger targeting profile per ESET and The Hacker News covers government bodies in Southeast Asia (Thailand appears on the 2023–2024 list), so this is a topic to track rather than distant news.
- The Secure Boot revocation is almost certainly not enabled across most Windows fleets in Vietnam. This is checkable with a script today, and the result is usually a surprise. If you do only one thing after reading this, do that.
- If an EDR's callbacks are disabled, you will not get an alert about it. Operations teams need an active way to verify agent integrity (telemetry heartbeats per event type, not just an agent heartbeat), because this technique is not unique to BlackX.
- C2 over OneDrive and Google Drive blends completely into Vietnamese enterprise traffic, given how widely M365 and Google Workspace are already used. The workable detection angle is the source process, not the destination domain.
- A
googleupdate.exerunning outside the real Google directory is a cheap, effective indicator, applicable to many other sideloading campaigns beyond BlackX.
Recommendations
- Check Secure Boot revocation status across the whole fleet, not just patch status: the registry flag under
HKLM\SYSTEM\CurrentControlSet\Control\Secureboot, the presence and run result of theSecure-Boot-Updatescheduled task, and most importantly whether the "Windows Production PCA 2011" certificate is actually in the UEFI DBX. Microsoft's official guidance is KB5025885. - Plan a controlled rollout rather than enabling it everywhere at once. Scope out dual-boot machines, hosts with old boot media, specialized appliances and VMs built from old templates — exactly the group Microsoft worried about when it chose not to automate this.
- Monitor writes to the EFI System Partition. Mounting the ESP and writing EFI files essentially never happens in normal operations, which makes it a very low-noise signal.
- Alert on drivers signed with revoked or expired certificates being loaded, and cross-check against Microsoft's driver blocklist. The serial in this post is one concrete entry to add.
- Watch for processes with familiar names running from the wrong path, particularly
googleupdate.exeoutside a real Google installation directory, and processes loading a DLL from the same folder as an unfamiliar data file. - Build an active check that the EDR is still receiving data, broken down by telemetry type (process, thread, registry, ETW) rather than by agent online status.
- Review every patch in your organization that requires manual activation. Baton Drop is not the only one — Kaspersky points to the 2025 ToolShell patch as another. Each entry on that list needs an owner and a verified outcome, not just a line saying "installed".
IOCs
Taken from the Kaspersky GReAT report. The report does not publish a full indicator table; the items below come from the technical narrative.
C2 infrastructure
www[.]archivetj[.]com # C2 of the Rust payload loaded by OxiDLLRunner
Google Drive / OneDrive / Yandex.Disk # C2 of the .NET RAT (legitimate services, not blockable by domain)
Driver signing certificate
Organization: Wenjiang District Mingyu Network Technology Service Studio
Serial: 0bcdf5e0da32d68900b8b7638459d072
Status: revoked
Files and paths
C:\ProgramData\Intel\inst.exe # installer, contains no malicious strings
C:\ProgramData\Intel\PVMDIJGKAX2 # extensionless RC4-encrypted file
googleupdate.exe # abused clean file (original: jcef_helper.exe)
# MD5 AF8A983B9ADA07EAE1259BF2953ABD40
v8_context_snapshot.bin # encrypted shellcode + Rust PE payload
Strings and behavioral patterns
Command line: inst.exe <encrypted_file> <rc4_key> # the RC4 key sits on the command line
Observed key: Q46F6MDLI3RX2KV1
String: xdd # matches PDB path C:\Users\xdd\Desktop (ESET/FishMonger)
C2 suffixes: 0X01 0X02 0X03 0X04 0X05 0X06 SSSR # filenames on cloud storage
Export: create_plugin # in the plugin DLLs received from C2
Behavior: opening a bootkit file returns a handle to calc.exe
Items to check on your own machines (not IOCs, but more important)
HKLM\SYSTEM\CurrentControlSet\Control\Secureboot # registry flag that triggers the revocation
Scheduled task: Secure-Boot-Update # the task that performs it
DBX: "Windows Production PCA 2011" # is it actually blocklisted yet
References
- Kaspersky GReAT (Georgy Kucherin, Vladimir Nestor, Vasily Berdnikov) — New BlackX UEFI bootkit exploiting Baton Drop (Oct 22, 2026): https://securelist.com/uefi-bootkit-blackx/121539/
- The Hacker News — BlackX UEFI Bootkit Bypasses Secure Boot on Patched Windows Systems Missing Revocations: https://thehackernews.com/2026/10/blackx-uefi-bootkit-bypasses-secure.html
- Microsoft — KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932: https://support.microsoft.com/help/5025885
- ESET (March 2023) — confirmation and analysis of the BlackLotus bootkit
- ESET (June 2026) — FishMonger campaign report, source of the
xddindicator and the suspected UEFI bootkit component
The image in this post is served from Securelist's CDN. Download and self-host it before publishing.
Comments
Join the discussionNo comments yet. Be the first to comment.
