Kaspersky’s latest report has a punchline that should irritate anyone who lives in a patch dashboard. Diplomatic networks in Tajikistan, Uzbekistan, and Turkmenistan got a UEFI bootkit called BlackX in early 2026, on Windows systems that were already patched. Secure Boot showed up in the screenshots. The revocation list didn’t. Your cybersecurity program can pass every Windows update audit and still boot an implant before the kernel exists.

The kill list is still sitting in a change ticket

BlackX is interesting for a boring reason. Kaspersky says a suspected APT41 cluster used it against diplomatic entities in Central Asia, and the bootkit loaded on machines that had taken the Windows patches people put on quarterly slides. Secure Boot was in the picture. The forbidden-signature database that would have retired the abused boot credentials lagged behind. That is how you get a bypass headline without a cinematic firmware zero-day in every paragraph.

Microsoft has shipped this lesson before. A bootloader can be signed, later revoked, and remain a valid boot path on every laptop that never absorbed the dbx update into NVRAM. Operators learn it during the last bootkit panic, then lose it on the next imaging wave. You can hear the ticket. “Secure Boot is enabled.” Someone closes it. Nobody asks which revocation generation is actually in firmware, whether the OEM applies Microsoft’s forbidden-signature payload, or whether the last in-place upgrade skipped the variable write because a field engineer didn’t want to brick a loaner pool.

That fear is rational. dbx updates have a well-earned reputation for fighting ugly OEM firmware. Teams slip them. Attackers read the same notes. A China-linked operator doesn’t need a brand-new Secure Boot break if last year’s revoked credential still works in SPI flash you never touched.

You treated Secure Boot as a boolean in the gold image. The control is a moving trust store. If the store is stale, the checkbox is theater.

Your cybersecurity stack clocks in after the implant

Host threat detection, EDR, the whole threat-protection stack, even a tidy firewall, all assume a kernel that still works for you. A UEFI implant doesn’t need a noisy brute-force against your VPN concentrator. It can sit under the OS, rearrange the boot path, and wait for a diplomat to type. Defense in depth that begins at the Windows logon is a layer cake with no floor.

Your endpoint agent is a very expensive spectator until Winload runs.

Incident response gets worse from there. Disk images miss SPI. A standard reimage refreshes C: and leaves the implant to greet the new gold build like an old friend. If the playbook says pull the laptop, image it, reload, courier it back to the mission, you just quality-assured the persistence. Cyber security teams already file this under “we know.” Firmware is in the benchmark PDF. Measured boot is in last year’s architecture review. Then procurement buys a stack of business laptops, IT clones an image from 2024, and the revocation state is whatever the factory shipped plus one Windows update that never wrote the variable.

Security hardening at the OS line still matters. It doesn’t inspect the code that ran first. If you only hunt in process lists and Sysmon, you’re looking at the apartment after someone moved into the foundation.

The dashcam already had a second job

The FCC this week banned a wireless video transmitter and a dashboard camera built on HiSilicon silicon. Those chips come from a Huawei subsidiary that markets them as designed for the surveillance market. Argue the geopolitics on your own time. The purchase-order lesson is simpler. The plastic housing doesn’t evaluate trust. The die inside already had an assignment.

Put that next to BlackX and the week stops looking like two unrelated headlines. Trust below the OS is where programs go to nap. Firmware revocation. OEM certificate stores. Cheap radios with extra missions. Different SKUs, same habit: you deployed the control, so you called it done.

Dark Reading’s latest on help-desk fraud fits the same groove if you squint. Operators still reset access because the caller had the travel dates and a polite, AI-smoothed story. No implant required. People keep confusing the existence of a process with the enforcement of one. Firmware just makes the failure quieter, because there’s no ticket titled “someone asked nicely for MFA.” There’s only a laptop that boots.

Prove the kill list landed, then keep proving it

You don’t need another logo for this. You need evidence the boot chain you think you run is the boot chain that actually runs. Start with the machines that would ruin a quarter if they lied to you: executive laptops, jump boxes, anything in a diplomatic, legal, or industrial overlay, and the admin endpoints that can push policy everywhere else.

• Export a fleet report that shows Secure Boot enabled and the current dbx or forbidden-signature generation, not a boolean. Treat an unknown revision as failed.
• Map OEM models that actually apply Microsoft’s revocation payload versus models that swallow the Windows update and leave NVRAM untouched. Those second models are your real exception list.
• On high-value endpoints, inspect boot order, unexpected EFI applications, firmware write-protect status, and whether USB or network boot is still allowed “just in case.” Disable the just-in-case path.
• If you suspect pre-OS persistence, take the device off the network. Collect EFI variables and a firmware image, not only a disk image. Treat cached credentials, VPN profiles, and disk-encryption recovery material as exposed until you prove otherwise.
• Set a firmware administrator password that isn’t the OEM blank, store it next to your other break-glass secrets, and record who can use it during incident response.
• Put dbx and firmware updates on the same ring-based calendar as OS patching. Canary a model family, then roll. Security hardening that never leaves a change ticket is fan fiction.
• Require TPM measured-boot attestation before a laptop gets a fresh ticket-granting ticket or a token for a sensitive app. A host that can’t prove its boot measurements doesn’t get new credentials.

Write the firmware steps into the incident response plan in language a night-shift analyst can follow: who dumps SPI, who opens the OEM case, who has authority to scrap a board instead of reimaging it. Inventory the “harmless” peripherals the same way you inventory servers. If a chip vendor markets the silicon for surveillance, it doesn’t belong on a desk that sees diplomatic mail, plant networks, or customer data. A cybersecurity program that can’t attest the boot chain is guessing, and your defense in depth story has to name both the boot measurements and the bill of materials or it’s a story you tell auditors.

Sources

• BlackX UEFI Bootkit Bypasses Secure Boot on Patched Windows Systems Missing Revocations
• FCC bans two devices with surveillance chips linked to Huawei
• Trust Is Not What It Seems And Fraudsters Are Counting on It