BlackLotus malware can bypass secure boot(theregister.com) |
BlackLotus malware can bypass secure boot(theregister.com) |
The exploit can still be deployed by malicious actors on patched devices because they can bring old vulnerable signed bootloaders. And roll back any applied patches.
These old signed bootloaders could technically by revoked, but if Microsoft does that then all old backups, possibly going back years, will no longer boot when restored. I can imagine there's many hundreds of thousands of backups that would then be silently broken. Imagine you find that out when you restore after a disaster...
KB5012170
So if they don’t blacklist vulnerable ntldrs, it’d be clear evidence of unequal treatment.
E.g. instead of 'BlackLotus' => 'LameEffort-12'
Cybersecurity has become big business since then though, and as such a much more carefully PRed rubber tile community, sadly.
Is that something attackers can install/activate remotely through some kind of RCE, or does it need me to run an executable manually?
In other words, is it still enough to be careful with social engineering, or are we more screwed than that?
Right now, we don't know how it gets its way to the target.
But, we do know that it comes in the form of an installer, which then requires a system reboot to enable persistence, and then another reboot to do its actual job.
> In all subsequent boots, the self-signed UEFI bootkit is executed and deploys both its kernel driver and user-mode payload, the HTTP downloader. Together, these components are able to download and execute additional user-mode and driver components from the C&C server and protect the bootkit against removal
[0] https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bo...
This piece of malware is not related to distribution, and must be executed manually (or, more likely, executed by a different malware sample serving as a loader). So you can use it in a social engineering attack, deploy it org-wide after exploiting AD, install it using some kind of RCE, etc.
The article says it can run on windows 11, which does imply it also tricks the TPM but I would love confirmation.
> The next feature deactivated by the installer is BitLocker Drive Encryption. The reason for this is that BitLocker can be used in a combination with Trusted Platform Module (TPM) to ensure that various boot files and configurations, including Secure Boot, haven’t been tampered with since BitLocker drive encryption was configured on the system. Considering that the installer modifies the Windows boot chain on a compromised machine, keeping BitLocker on for systems with TPM support would lead to a BitLocker recovery screen at the next bootup and would tip the victim off that the system had been compromised.
[0]: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bo...
So how do you remove it?
No it doesn't. It's using a legitimate but vulnerable version of the windows bootloader which hasn't been added to the UEFI revocation list yet. It's not doing anything with firmware.
Downgrading UEFI firmware would be far more complicated.
-shocked Pikachu face-
So far I am contemplating building a throne from them.
That's not very reassuring. Privilege escalation on Windows is a well studied subject:
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/mas...
Obviously requires admin permissions on a running host, but if you're injecting into the bootloader you're already admin (or you can get it easily).
Half the problem I find with these security products is knowing what their actual abilities are and inabilities. I've assumed wrongly in the past that some security products are doing things when in fact they are not, and thats obviously an area for exploitation.