So last ransomware we seen in the news actually tried to reboot system and encrypt files before OS is loaded. So unless that new tech gonna protect MBR (which should be protected anyway) - not sure how it going to stop encryption.
Fun fact, if you manage to replace the osk.exe (on screen keyboard) and flip the registry bit that loads it before the login screen, it will be executed as SYSTEM, with full disk and network access. It can also interact with the Winlogon window and stealthily phish the password of any user.
Heck, it can even self-delete before any user logs in.
Why programs before the login screen and the screen itself don't run in a sandboxed account is beyond me.
Every windows user with a laptop is running in local admin mode. I've demonstrated this for german TV by having a file less UAC exploit install osk.exe malware, then have this send the password of the next user logging in via SMS to the "attacker". The deleting itself (and remove any anti virus install).
Fun Fact #2, an easier way is the on screen accessibility tools, which if you replace with cmd.exe via Windows very own Recovery Console (on the OS DVD/USB), you can just click the Accessibility icon on the logon screen and get a SYSTEM level command prompt. It's even documented as a way in (Google is your friend) if you forget your Domain Controller password.
I find it shocking that this even works. However I'd be a liar if I didn't say it saved my arse once.
Except Microsoft leaked their "golden" Secure Boot keys. I don't know all the details of how Secure Boot works, but I am under the impression that if malware gets Administrator access to the system, it can install it's own bootloader using one of the leaked keys. Then bypassing Bitlocker is as easy as presenting a fake BitLocker screen asking the user to enter the key.
Wouldn't secure boot just prevent you from booting into the invalid MBR? At that point your files are already encrypted and your MBR already over-written, Secure boot is just preventing further exploitation.
You can get around UEFI Secure Boot by installing an old signed bootloader with known exploits (if I understand correctly this is why the "Secure Golden Key Boot" exploit of last year[1] cannot be patched without changing public keys in the UEFI firmware). Not only that, the code that is shared by most UEFI implementations is garbage[2] with a large attack surface; exploits against the firmware is a possibility.
The primary function of UEFI Secure Boot is for Microsoft to prevent other operating systems from being installed on as many systems as they can get away with (right now there is no provision that end users should be allowed to disable Secure Boot on ARM devices, for example). The "security" functionality is an unworkable side-effect that provides a convenient fiction to accomplish that goal.
