TechBriefly report November 4, 2026; BlackLotus technique first documented in active attacks in 2023
BlackX Bootkit Infects Fully Patched Windows Systems: The Updates Meant to Stop BlackLotus Were Installed
Malware tracked as BlackX has infected organizations that had installed all available Microsoft updates intended to block the BlackLotus UEFI bootkit technique, according to a November 4 TechBriefly report. BlackX is a UEFI bootkit: code that runs before Windows has fully loaded and before many security defenses become operational, targeting the chain of trust that Secure Boot relies on. The lineage matters. BlackLotus, first publicly documented in active attacks in 2023, could bypass Secure Boot on fully updated Windows 11 systems. Microsoft patched the underlying vulnerability in 2022, issued a further update in 2023 adding a new certificate that did not trust vulnerable Windows boot managers, and in 2024 provided a way to revoke trust in the digital certificate used to sign older vulnerable boot managers. The organizations affected by BlackX had installed those updates. The available material does not specify how the BlackX infections bypassed the updated protections, and that gap should be read honestly: what is established is infection despite a complete patch record against the predecessor technique, not the mechanism. The open questions sit exactly where defenders would expect, around certificate revocation enforcement and boot manager trust on real fleets.
Executives
A fully patched record is necessary and, in this case, apparently not sufficient. Bootkits sit below the operating system, so they can survive the reinstalls and agent checks that close most incidents, and remediation can mean firmware-level cleanup rather than a ticket. Ask how the organization would even know: which tools in your stack can see below Windows, and what is the rebuild path for a machine whose boot chain is not trusted. Treat the unanswered mechanism as a reason to verify your revocation state, not as a reason to wait.
CIO / CISO
The actionable check is enforcement, not installation. Confirm that Secure Boot is on, that the revocation updates for vulnerable boot managers were actually applied and enforced on each fleet segment, and that dbx revocation lists are current; update packages present but revocation not applied is a known failure mode in this lineage. Add boot integrity signals to your detection review, and pre-agree the response for a suspected bootkit: isolate, preserve the disk and firmware state, and rebuild from trusted media rather than cleaning in place.
Engineers
Inventory at the firmware layer: Secure Boot status, dbx contents, and boot manager versions across a sample of each hardware class, because fleet averages hide the machines that missed enforcement. Watch for unexpected changes to EFI system partition contents and boot configuration. If a machine is suspected, do not trust in-OS scanning results; the malware loads before the scanner does.
Everyone (non-IT)
Keep Secure Boot turned on and keep Windows updated; both still raise the cost of this kind of attack considerably. If a computer starts behaving strangely before Windows even loads, or security software reports problems it cannot fix, that is a case for professional help rather than another scan, because this class of malware hides underneath the tools you would normally use.