BlackLotus malware can bypass secure boot(theregister.com)
theregister.com
BlackLotus malware can bypass secure boot
https://www.theregister.com/2023/03/01/blacklotus_malware_eset/
33 comments
Didn’t Microsoft do this already? I recall a Windows update blacklisting vulnerable Linux bootloaders in UEFI.
KB5012170
So if they don’t blacklist vulnerable ntldrs, it’d be clear evidence of unequal treatment.
KB5012170
So if they don’t blacklist vulnerable ntldrs, it’d be clear evidence of unequal treatment.
I bet they are a lot more inclined to blacklist old Linux bootloaders than Windows ones, precisely because of this backup restore thing that the OP mentioned. They'll get the support burden if nothing else.
They won't boot immediately, but they can be trivially made to boot again by simply updating the Microsoft bootloader files on the EFI System Partition. You can even script this for PXE execution.
Perhaps we could ever so slightly dissuade malware actors by assigning less desirable names.
E.g. instead of 'BlackLotus' => 'LameEffort-12'
E.g. instead of 'BlackLotus' => 'LameEffort-12'
Especially because Black Lotus Labs exist and researches malware.
https://www.lumen.com/en-us/security/black-lotus-labs.html
https://www.lumen.com/en-us/security/black-lotus-labs.html
I'm glad we are locking down our machines and relinquishing control to Microsoft for singing so that we can still be owned.
they sell you the tools you need to work, each day. Just sign in!
In one of my grumpier moments, I complained that we were "just digital sharecroppers." Looking back, I'm also grateful for the Microsoft ecosystem that has given me about 25 years of employment as a developer.
How is that malware deployed to a machine?
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?
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?
> At this point, we have not been able to identify, from our telemetry, the exact distribution channel used to deploy the bootkit to victims. The low number of BlackLotus samples we have been able to obtain, both from public sources and our telemetry, leads us to believe that not many threat actors have started using it yet. [0]
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...
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...
Thanks :)
> Is that something attackers can install/activate remotely through some kind of RCE, or does it need me to run an executable manually?
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.
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 initial infection requires the ability to execute code as admin under Windows, but the writeup notes that it attempts to bypass UAC to gain that even as an unprivileged user (albeit one who is permitted to run code as admin). If you run as a user who doesn't have admin access you should be protected, even if we don't know the initial infection vector.
> If you run as a user who doesn't have admin access you should be protected,
That's not very reassuring. Privilege escalation on Windows is a well studied subject:
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/mas...
That's not very reassuring. Privilege escalation on Windows is a well studied subject:
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/mas...
By passing secure boot is pretty bad, but the article doesn't mention anything about the TPM. Even if you trick uefi to execute this exploit, surely the TPM will have different measurements and not release the encryption key.
The article says it can run on windows 11, which does imply it also tricks the TPM but I would love confirmation.
The article says it can run on windows 11, which does imply it also tricks the TPM but I would love confirmation.
From the official analysis [0]:
> 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...
> 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...
> [0]: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bo...
So how do you remove it?
So how do you remove it?
Disable-Bitlocker should do the trick: https://learn.microsoft.com/en-us/powershell/module/bitlocke...
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).
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).
So doesnt things like windows defender offline scans and other offline scans where the HD bitlocker codes is typed in manually not detect the rootkit?
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.
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.
Bitlocker? If you're Admin in Windows you can just unencrypt your drive
It doesn't trick the TPM, but as mentioned in the other comment, it does disable Bitlocker before compromising the boot chain so that won't be obvious from an end-user perspective. Remote attestation would still demonstrate that the boot chain had changed, and something like https://www.osfc.io/2022/talks/user-friendly-lightweight-tpm... would let you use your phone to determine that before logging in.
Oh wow, it installs its own legitimate but vunerable firmware. I don't know why this tickles me so much, but it does.
> Oh wow, it installs its own legitimate but vunerable firmware.
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.
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.
Very interesting, thanks for sharing
You mean the thousands of computers that have to be thrown away to use windows 11 are using it for profit and not security??
-shocked Pikachu face-
-shocked Pikachu face-
Not yet. You can still disable secure boot and install Linux.
At some point in the future, it may become the same as phones. Locked bootloader/UEFI and only able to boot Windows.
While true, this is going to be a tough topic to bring up at the clients office.
So far I am contemplating building a throne from them.
So far I am contemplating building a throne from them.
Can you please elaborate what does it mean to be the same as phones? I guess you meant the sandbox env?
I think what he was saying is that, by locking down the bootloader, we could see devices that are locked to windows or apple forever. Just like iphones are
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...