It's quite a painful split that Microsoft is in given their commitment to backwards compatibility.
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...
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.
> 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
> 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.
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.
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 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.
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.
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.
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.
SCHiM|3 years ago
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...
formerly_proven|3 years ago
KB5012170
So if they don’t blacklist vulnerable ntldrs, it’d be clear evidence of unequal treatment.
aaronmdjones|3 years ago
holdenc137|3 years ago
E.g. instead of 'BlackLotus' => 'LameEffort-12'
gpderetta|3 years ago
croes|3 years ago
https://www.lumen.com/en-us/security/black-lotus-labs.html
2OEH8eoCRo0|3 years ago
mistrial9|3 years ago
AaronFriel|3 years ago
aspyct|3 years ago
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?
shakna|3 years ago
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...
msm_|3 years ago
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.
mjg59|3 years ago
georgyo|3 years ago
The article says it can run on windows 11, which does imply it also tricks the TPM but I would love confirmation.
bayindirh|3 years ago
> 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...
mjg59|3 years ago
stavros|3 years ago
resoluteteeth|3 years ago
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.
r9295|3 years ago
jhoelzel|3 years ago
-shocked Pikachu face-
M95D|3 years ago