How Do Rootkits & Other Low-Level Malware Still Manage to Load on Systems Protected by Secure Boot (and TB/MB)?

Question

Let me try asking my question this way...

Let's say that I'm a offensive cyber Bad Guy working for a foreign state-sponsored Advanced Persistent Threat unit. My unit is charged with, say, stealing high-value intellectual property from American companies. (The specific context doesn't really matter; the "scenario" is just to help me demonstrate what question I'm trying to ask.)

My team is preparing ... let's say, to target a set of known R & D executives at various U.S. companies with a spearfishing campaign. (Again, scenario specifics don't really matter.) My team has some pdf reader exploits read to go, and some Windows privilege escalation exploits to follow on and get whatever malware payload we decide to implant to kernel-level privileges.

(Another team is responsible for hacking the Mac users amongst our targets. :) )

Anyway, let's say I'm charged with putting together a malware payload that will work on all modern versions of Windows. Of course, I'll want to install a module that will covertly listen for commands and exfiltrate information via whatever routes I like. Probably I'll put a keylogger in there right away, too. Certainly a component that can load and install whatever other modules & tools I might decide to upload after initial penetration is complete and I want to get on with the business of seeing what's interesting inside the target's network and finding some juicy IP to steal. The usual stuff.

However, I also need to hide all that stuff from anti-malware software, system management software, manual inspection (using TaskManager, Sysinternals tools, etc.), possibly even a HIDS. I would also like my malware to, the maximum extent possible, persist. I'd really like it to survive, for example, installation of Windows updates & upgrades, attempts to remove the malware (if it should be detected), even the holy grail: a wipe & OS reinstall.

Now if we're talking about attacking a PC with traditional BIOS and running Windows 7 or earlier I have a ton of options. I can use any one of many rootkits to get my malware to load with the lowest levels of the Windows kernel, bypassing Windows's defenses and subverting the detection capabilities of security software before it even loads. I can use a bootkit to attack the Master Boot Record and load parts of my malware before the Windows bootloader even starts. If I'm working for a genuinely advanced Advanced Persistent Threat unit I may even have multiple BIOS implant options for stuff from multiple BIOS makers. Plenty of options.

However, I also need my malware to evade detection and persist on newer Windows PCs that have UEFI, and are running Windows 8.1 or Windows 10.

And this is where I hit a big problem. Because Windows 8.1 & 10 have a group of protections specifically designed to stop low-level malware from loading before the OS and anti-malware software does:

The countermeasures

Windows 8.1 supports four features to help prevent rootkits and bootkits from loading during the startup process:

-Secure Boot. PCs with UEFI firmware and a Trusted Platform Module (TPM) can be configured to load only trusted operating system bootloaders.

-Trusted Boot. Windows checks the integrity of every component of the startup process before loading it.

-Early Launch Anti-Malware (ELAM). ELAM tests all drivers before they load and prevents unapproved drivers from loading.

-Measured Boot. The PC’s firmware logs the boot process, and Windows can send it to a trusted server that can objectively assess the PC’s health.

(There are question answers here and here that are also helpful in explaining how Secure Boot, Trusted Boot, ELAM, and Measured Boot work, though they don't address my question here.)

At the end of that TechNet post describing the protections and how they work Microsoft was not shy in boasting about them:

Secure Boot, Trusted Boot, and Measured Boot create an architecture that is fundamentally resistant to bootkits and rootkits. In Windows 8.1, these features have the potential to eliminate kernel-level malware from your network. This is the most groundbreaking anti-malware solution that Windows has ever had: It’s leaps and bounds ahead of everything else. With Windows 8.1, you can truly trust the integrity of your operating system.

So, as a Bad Guy who still very much wants to get my malware implanted deep within a target's PC --ie. kernel-level, bootloader-level, or UEFI-level-- so it will evade detection and persist for as long as possible, what methods and approaches exist to do so on a system that is protected by Secure Boot/Trusted Boot/etc. ? In other words, what options does a bad guy have to get around those safeguards and get his malware components to still load early on in boot?

Bonus question: What are some key countermeasures that a defender might want to think about in terms of blocking those attacker methods to circumvent those boot protections?

Notes:

• I use Windows here because of its predominance in work/enterprise client environments and because it's the ecosystem I'm most familiar with professionally. I'm well aware that these protections now exist on many other platforms, however. Feel free to talk about these boot protections and attacker methods to bypass them more generally if you want.

• For the sake of simplicity, let's assume my APT unit isn't quite as advanced as the folks at Ft. Meade or the security researchers who manage to hide malware in the firmware of non-UEFI system parts like networking cards, video cards, etc.

• This question talks a bit about how secure the businesses processes are that Microsoft uses to validate the identity of a developer and non-maliciousness of a component before it will sign that component so it can load during boot. A very interesting question/answer, but not one that really gets at what I'm trying to get at.

• "Informative" Microsoft chart:

Answer 1

One simple answer is bugs in the code that implements those security features. For example, the recently-released CVE-2015-2552 allows loading unsigned (well, test-signed, which is almost the same thing) drivers on a system that has Secure Boot enabled. There have also been a number of bugs in UEFI implementations (and other low-level code) that allowed people to bypass certain checks or even disable Secure Boot entirely, possibly while the OS still thinks it's enabled (these have mostly been found on devices like phones and tablets, where owners would like to install custom OS images but the OEM doesn't wish to allow this, but are potentially applicable on PCs too).

There's the option of simply working around Secure Boot. For example, all Win8.x PCs are required to allow the user to disable Secure Boot and/or add their own signing keys (doing either one will allow the attacker to replace trusted components of the boot process with the attacker's code). This typically requires physical access to the PC, but that's often possible via, for example, an "evil maid" attack. A boot password (or at least a password on the firmware setup utility) could prevent this, but could be defeated by a hardware keylogger.

Another possibility is to go lower than the EFI. If the attacker can modify the firmware running on (for example) the hard disk - which has been demonstrated to be possible in at least some cases - then the attacker can do all kinds of things. For example, spyware that can access all saved data in a way that software scans - no matter how low-level (even raw block device access) - can never detect. Signature checking might be vulnerable to a time-of-check-time-of-use vulnerability, where the data is hashed (for the signature check) in one pass, but then read off the disk again for the actual execution; a "drivekit" could exploit this if it is able to tell which reads are for signature checking and which are for execution. Similar attacks could be carried out against things like the network card, though the hard disk is an especially interesting target as it both has room to store lots of malicious code, and sees nearly all data that the computer ever accesses.

There are also ways to achieve a lot of attacks without needing to be absolutely persistent on a single machine. For example, if I can slipstream malware into your install media, re-installing the OS won't help you. If the malware spreads through infected flashdrives or other peripherals / accessories, then it may persistently spread throughout an organization without any clear exploit vector (think Stuxnet). Alternatively, a worm in a multi-host network can infect new (or rather, newly-reformatted) machines as soon as they connect to the network, so long as at least one infected machine is present on the network and the exploit remains exploitable. Even if such malware is detected, actually eradicating it can be quite difficult.

Questions, corrections, clarifications, and additional ways that such an attack might be achieved are all welcomed.

Answer 2

You can persist by compromising the UEFI firmware, and doing so is extremely easy (for a state-sponsored attacker). On most consumer-grade machines there are no signature checks on the firmware images and you can thus install malicious firmware, and since Secure boot is enforced by that firmware, you can thus bypass Secure boot. Personally I only know of Dell Latitude and Lenovo Thinkpads that allow requiring the firmware images to be signed by the manufacturer, and even then it is disabled by default which means you may already be running a compromised firmware.

TPM-backed features are based on a chain of trust which starts with the firmware and is extended all the way up to the OS. If you own the firmware you can easily provide fake data to the TPM to make the PCRs match the correct values even though the system is compromised. This could be mitigated by either having a small part of the firmware read-only so it cannot be compromised via software (and as a result will not lie to the TPM about the hashes of the next components which can be compromised), or to give the TPM direct access to the firmware memory chips so it can measure them on its own before even executing the potentially malicious code in them.

Answer 3

Much of the computer security enhancements are there to make it difficult for general attackers to gain access to computers while still allowing western governments to crack in to them easily. So a lot depends on if your pretend attacker has access to special cracking knowledge known by western governments.

1) Windows has so many holes that it doesn't matter if the kernel is securely loaded using UEFI. A rootkit can load at any time and be just as effective. It may even just stay in user space and work fine. Microsoft is rumored to give the US government early notice of security flaws well before fixes are released.

2) If you're using a different operating system then secure boot has to be turned off anyway.

3) TPMs have private keys that are likely saved by the manufacturers and given to the government. From the little that I've read I've learned that knowing the private key ruins the security of a TPM.

4) Antivirus software only detects what is known by it. Most new pieces of malware won't be detected at all. So this is not a concern for a directed attack.

5) A big problem is that old signed drivers with security vulnerabilities in them are still allowed to load. You don't even need to disable driver signing or do any of that. Just find some old driver and use it.

6) I would imagine (haven't researched) that the same situation could exist with old signed kernels. Can you load an old signed kernel with a security vulnerability in it and gain access at boot using that, and then go back and load the real kernel?

7) It's fairly inexpensive to make your own closed source driver and have it signed by Microsoft.

8) Once you exploit the Windows kernel ring 0 you have equal access to the system as Windows for the time being. Can you switch Windows in to developer mode to allow unsigned drivers to load? Can you disable some of those features such as Trusted Boot and ELAM? Can those things be done while while leaving Secure Boot enabled? Can you flash/modify the BIOS (system firmware)? Can you change data in option ROMs? You have full access to the hard drive now. You can put firmware malware in it which will persist across all system reinstalls. Just some things to think about.

Answer 4

if the boot and hardware is what you need access to and assuming you could get physical access to the computer with money backing you...(and apologize my noobness) then here is my thought process. Make the computer think it's a piece of hardware. A typical ram for example is 2gb or more, could you write the basic lowest level code on to a ram chip, as hard coded? Then get access to the computer and replace one of the ram chips...how you do that is back to you spy background.
The code I think would only have to make a basic shell, "this person is the super super user... Then there is root the su, but the susu, is better, if root has access then susu has more access." Once done then you can build from there.