Two Bootkits in Four Years Rode the Same 2022 Bug. It Is Still Not in KEV, Because the Fix Can Brick the Machine.
Yesterday we wrote about a certificate authority whose private keys turned out to be small integers, and the part that bothered us was not the keys. It was that the browsers on our own laptop were protected within hours while the command-line tools on the same laptop still trusted the forged certificates days later. The fix was a revocation, and the revocation did not reach everything.
Today the same shape showed up a layer lower, in firmware, and it has been sitting there since 2022.
What happened
On October 22, Kaspersky published research on a UEFI bootkit it calls BlackX, used against diplomatic entities in Tajikistan, Uzbekistan and Turkmenistan. A bootkit runs before Windows does, which means it starts before the operating system's defenses exist and survives a reinstall.
It gets there through CVE-2022-21894, known as Baton Drop, a Secure Boot bypass in the Windows boot manager. That is the same flaw BlackLotus used in 2023. BlackX has a different kernel driver and different payloads, but the door it walks through is four years old and was patched in January 2022.
Two caveats worth stating before anyone forwards this. The APT41 attribution is medium confidence, resting on shared identifiers and tactics, and we are repeating it as the researchers framed it rather than endorsing it. And this is not a worm: in every observed case the operators had already compromised the environment and obtained administrator privileges before deploying the bootkit. Nobody is getting this by opening an email.
Kaspersky also notes limited indications that some versions may carry a component exploiting CVE-2023-24932, a second Secure Boot bypass. Limited indications is what they said, and it is what we will say.
Why a four-year-old patched bug still works
Here is the mechanism, and it is the whole point of this post.
The January 2022 patch did not close Baton Drop by changing code. It closed it by making a trust decision: stop trusting the Windows Production PCA 2011 certificate, which signs the vulnerable boot managers. That decision lives in a firmware blocklist called the DBX.
Installing the patch does not update the DBX. An administrator has to trigger the revocation separately. Until somebody does, a signed, vulnerable boot manager still loads, because the firmware still trusts the certificate that signed it. A fully patched Windows machine with an untouched DBX is exactly as exploitable as it was in 2022.
There is a detail here that looks like it should save you and does not. That certificate expired on October 19, 2026, five days ago. Expiry does not help. The firmware will still load binaries signed under it unless the certificate is actually blocklisted. An expired key that was never revoked is still a working key at this layer.
The reason it is manual is a good reason
It would be easy to write this as vendor negligence. It isn't, and the real explanation is more useful.
If firmware stops trusting the old certificate before a machine has an updated boot manager installed, that machine does not boot. Not "degrades" — does not boot, and the person holding it cannot fix it from the operating system, because there is no operating system yet. Multiply that by a fleet and you have an outage that looks exactly like a ransomware event. Microsoft's own guidance says it in order: deploy the updated trust certificates and boot managers first, then revoke the older trust.
So the revocation is manual because automating it is genuinely dangerous. That is a real engineering constraint, not an excuse.
But it produces the gap. The safest thing to automate is a code fix. A trust fix has to be distributed to every store that holds trust — browser, operating system, language runtime, firmware — and each of those stores updates on its own schedule, by its own mechanism, often by hand. Code ships. Trust propagates, slowly, unevenly, and sometimes not at all.
That is the same sentence we wrote yesterday about a Mac's curl, and it was true four layers up.
And it is not in KEV
We pulled CISA's catalog directly this morning: version 2026.10.23, 1,756 entries.
[CVE-2022-21894](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2022-21894) is not in it. Neither is CVE-2023-24932.
The bug underneath two publicly documented bootkits, four years apart, both used in real intrusions against real targets, has never appeared on the federal known-exploited list.
We do not think that is an oversight either, and the likely reason completes the argument. A KEV entry carries a required action and a deadline. The required action here is "update your firmware blocklist," which, done in the wrong order, bricks the fleet. It is hard to write that as a three-day mandate. Our October 15 Collabora post hit a version of this from the other side, and earlier today the entry we had asked for arrived — nine days after the advisory, forty-two days after a fix existed. This one has not arrived in four years, and the reason is that the fix is not safely mandatable.
Which leaves the same conclusion as this morning, stated harder: a patch queue sorted by KEV membership will never surface this. Not late. Never.
What we can and cannot see
Nothing. We want to be exact about that.
This is a post-compromise, firmware-layer implant on Windows endpoints. Our instruments are an edge shield, honeypot canaries and an origin honeypot — they watch requests arriving at web infrastructure. There is no request for them to see here, and we hold no indicators for BlackX. Our exploit-path checker has no fingerprint for either CVE, and neither CVE appears anywhere in our indicator corpus.
This is also, as far as our own blog index goes, the first thing we have ever published about Secure Boot or firmware bootkits. We searched our corpus before writing: zero posts matching Secure Boot, zero matching bootkit, zero matching UEFI, against fifty-nine that match firmware. That is a real hole in our coverage and this post is us starting to close it, not us claiming expertise we have been building for years.
Everything above is other people's research, read and cited. No lead claim, no receipt of ours.
What to actually do
For most readers this is not Tuesday's problem. It needed prior administrative compromise and it was pointed at diplomatic targets. The structural lesson is everyone's problem, though, and the check is free.
Find out whether your DBX has been updated. On Windows this is readable; the revocation state is a property of the machine, not of the patch level. Treat "we are fully patched" as not answering the question.
Do it in Microsoft's order. Updated boot managers and trust certificates first, revocation second. Reversing that order is how you turn a security task into an outage.
Stop reading certificate expiry as protection. Expired and revoked are different states, and at the firmware layer only one of them stops a binary loading.
Apply the same question everywhere you hold trust. Yesterday it was a Mac's system curl trusting keys the browser had already rejected. Ask it of your language runtimes, your appliances, your container base images and your EDR's signer allow-list. The question is not "is it patched," it is "did the revocation arrive here."
For the small organizations we usually write for: if you run a handful of Windows machines and nobody has ever touched firmware settings, your DBX is almost certainly untouched. You are not a diplomatic mission, and a targeted bootkit is not your likeliest threat by a wide margin. Knowing that the box has a four-year-old open door is still worth five minutes, and the five minutes costs nothing.
The thing to carry
Patch state is not trust state. When the fix is "stop trusting this," shipping the update is the easy half, and the half that gets counted. The half that matters is whether the revocation reached the store — the browser, the runtime, the firmware — and nothing in a patch report tells you that.
Two layers, two incidents, one week, same failure. We expect to find more of these, because we now know what to look for, and we spent today learning we had never looked here before.
If you check your DBX because of this, or if we have something wrong about the mechanism, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=two-bootkits-in-four-years-rode-the-same-2022-bug-it-is-still-not-in-kev-because-the-fix-can-brick
Comments