[Doe-_]

What makes you think that? Secure Boot prevents this rootkit from running and is the recommended mitigation:

> Bootkitty is signed by a self-signed certificate, thus is not capable of running on systems with UEFI Secure Boot enabled unless the attackers certificates have been installed.

> To keep your Linux systems safe from such threats, make sure that UEFI Secure Boot is enabled

In fairness, the blog post confusingly says this in the next bullet point:

> Bootkitty is designed to boot the Linux kernel seamlessly, whether UEFI Secure Boot is enabled or not, as it patches, in memory, the necessary functions responsible for integrity verification before GRUB is executed.

However, this would still require Rootkitty to have gained execution already, which it wouldn't be able to if Secure Boot was enabled and the malicious actor's certificates weren't installed.

[B1ack3at_]

Hello, I am the Bootkitty developer. The reason our bootkit is self-signed is because it uses the LogoFAIL vulnerability to register a MOK on the system to bypass secureboot, which is why our signature is included. I will leave an analysis article about LogoFAIL at the link below. https://www.binarly.io/blog/logofail-exploited-to-deploy-boo...

[joe_the_user]

Secure boot prevents this proof of concept but it doesn't prevent all UEFI boot kits and this particular kit will likely evolve.

On window: It took several years until the first two real UEFI bootkits were discovered in the wild (ESPecter, 2021 ESET; FinSpy bootkit, 2021 Kaspersky), and it took two more years until the infamous BlackLotus – the first UEFI bootkit capable of bypassing UEFI Secure Boot on up-to-date systems – appeared (2023, ESET).

Per article.