Are you able to give a hacker your {hardware} and nonetheless belief that laptop later? Sure – and here is how.
Think about that malware with root-level privileges has been discovered on a machine that you simply handle. You would possibly instantly re-image the affected machine, however are you able to be sure that the attacker’s modifications haven’t endured in low-level firmware or by way of a malicious kernel-mode driver? This text explains fashionable and antiquated protections which try to forestall attackers who’ve already achieved root-level entry from persisting by way of kernel-mode drivers or firmware implants. A lot of the knowledge comes from the wonderful Rootkits and Bootkits e-book.
Following, I’ll describe a sequence of take a look at steps which permit safety engineers to find out what assault vectors can be found to an attacker who’s trying to persist their root stage privileges past the capabilities supplied by user-mode exploits.  
TLDR: Right here’s a CSV of take a look at instances to guage a system’s vulnerability to rootkits and bootkits.
{Hardware} Root of Belief
Strategies invented to mitigate this menace are categorized beneath {hardware} roots of belief, which try to create a safe basis for all safety primitives required to guard the integrity and confidentiality of a tool positioned on this hostile atmosphere.
Firmware configuration evaluation is important when evaluating gadgets from firms who ship customized {hardware} instantly into prospects’ palms and later ingest the possibly malicious {hardware}. One instance is Amazon Snowball, which is used for big scale information switch by way of a bodily system’s cargo. If this system can’t be licensed in addition securely, the place the low-level firmware is understood to be uninfected, future buyer information or your entire information middle could possibly be susceptible to compromise.
Rootkits vs. Bootkits
Rootkits
Rootkits are persistence mechanisms that permit an attacker code execution inside kernel area. This may be achieved by way of an LKM (Loadable Kernel Module), an exploit inside an current kernel-mode driver, or vulnerabilities within the interface the kernel exposes to UserLAnd processes. A rootkit permits an attacker to keep up root-level entry to a system and grants permissions past these supplied to the foundation consumer by permitting the direct modification of kernel area reminiscence constructions. These embrace a bunch of scarcely documented and delicate system configuration constructions that management core safety capabilities inside the working system.
Bootkits
A Bootkit differs from a rootkit in that it infects the firmware of the host as an alternative of merely infecting kernel area. Bootkits hijack a portion of the boot course of in an effort to inject malicious code earlier inside the system start-up earlier than safety protections are enabled. By attacking the system very early inside the boot course of, they’ll be certain that they’ve the chance to subvert all future makes an attempt to confirm the integrity of the system.
This subject reinforces the necessity for a {hardware} root of belief. If an attacker can infect any portion of the boot course of, defenders want a secure area the place keys will be saved and cryptographic operations will be carried out with robust integrity ensures.
A devoted {hardware} module that has been audited for bodily safety is required to supply this area. This piece of {hardware} is named a TPM (Trusted Platform Module), and is the strongest protection towards devoted bootkit infections.
Earlier than we dive into the small print of how one can correctly configure a system to benefit from a TPM, let’s first perceive the boot course of and its vulnerabilities.
What’s BIOS and why will we care?
As rootkit mitigation methods get extra refined, the extent of effort related to writing refined rootkits rises. This drives attackers deeper into system internals to search out softer targets. If defenders need to have the ability to comply with them and shield methods towards an infection, we now have to know the BIOS (Primary Enter Output System.
The BIOS started as a mechanism to organize the system for higher-level working system abstractions. On the most elementary stage, with out added safety protections, the BIOS follows these steps.

BIOS Initialization – {hardware} self-tests, skipped if heat boot
MBR (Grasp Boot File) -> Discover OS on the laborious drive
VBR (Quantity Boot File) -> Discover Lively Partition inside drive -> Run Preliminary Program Loader (EFI executable)
bootmgr (Home windows Bootloader) -> Learn BCD (Boot config information containing kernel code signing coverage)
winload.exe -> Hundreds OS Kernel module, deps, and ELAM (Early Launch Anti-Malware) modules
Kernel Picture Begins -> Boot-start drivers
First Consumer-Mode Course of

Every of those layers will depend on the earlier layer. As an attacker, if you happen to compromise an earlier layer, you possibly can at all times compromise the layers that happen additional down the stack, which rely on that layer.
What safety mechanisms exist?
For a whole checklist of take a look at instances, check out the CSV of take a look at instances. Along with this exhaustive checklist, the next part will present extra particulars and context about finishing these checks and what every safety mechanism accomplishes.
ELAM (Early Launch Anti-Malware) Module
This safety module was launched beginning with Home windows 8. The intent of this safety is to defeat rootkits, nevertheless it can not shield towards bootkits. This mechanism permits safety software program to register a kernel-mode driver, which is assured to launch very early within the boot course of, earlier than any non-ELAM drivers. When any future drivers are loaded, the ELAM-loaded driver has a chance to examine it and whether it is malicious, forestall it from being loaded.

Solely a subset of knowledge is on the market to ELAM drivers.
The identify of the picture
The registry location the place the picture is registered as a boot-start driver
The writer and issuer of the driving force’s certificates
A hash of the picture and the hashing algorithm
A certificates thumbprint and the thumbprint algorithm

ELAM drivers don’t get entry to the contents of the driving force, so numerous bypasses are potential primarily based on the superficial stage of inspection. Because the ELAM module is loaded after the home windows bootloader, any bootkit compromise which happens earlier within the boot course of will be capable to nullify this safety.
Take a look at Steps: Confirm ELAM Coverage Registry
The ELAM module makes use of a coverage written to a registry worth at:
HKLMSystemCurrentControlSetControlEarlyLaunchDriverLoadPolicy
This registry worth will be seen utilizing commonplace registry instruments resembling regedit.exe. This coverage worth determines what occurs when an invalid driver is discovered by the ELAM module. The coverage decides if the ELAM module masses solely recognized good drivers, good drivers and unknown drivers, or good drivers, unhealthy important drivers, and unknown drivers. This last possibility permits loading recognized unhealthy important drivers to make sure system stability and is the default on most methods.
It’s value checking if the default has been modified since this safety is rendered ineffective if an attacker is ready to exchange a necessary driver with a malicious one.
Kernel Mode Signing Protections
This safety was launched with Home windows Vista. The intent is to make sure that all kernel modules are signed by recognized events to lift the fee related to creating malicious kernel-mode drivers. It’s necessary to notice that that is totally different from the PnP Gadget Set up Signing Coverage. This latter signing coverage requires a separate test when testing as coated within the following part.
When kernel-mode drivers are loaded into the system, all drivers are verified towards a recognized good checklist. It ought to be famous that on 32-bit Home windows, solely boot-start drivers are verified, however all others are left unprotected. Which means any driver which has been marked for early startup won’t be verified on 32-bit Home windows methods.
The logic answerable for executing this signature verification is saved within the ci.dll file. In Home windows Vista and Home windows 7, a single variable within the kernel picture (nt!g_CiEnabled) managed if the code verification logic occurred.
That is set in a kernel-mode reminiscence construction, which any kernel module can alter. If code execution was ever discovered inside signed third social gathering kernel modules, it could possibly be leveraged to load arbitrary Loadable Kernel Module rootkits! Take a look at Steps: Confirm Home windows Model
This safety subject was patched in Home windows Eight and the variable was deprecated in favor of Safe Boot. If a mission requires a {hardware} root of belief and needs to implement kernel-mode driver signing to mitigate rootkits and subsequent bootkit an infection, safety engineers ought to advocate that the system be up to date to make the most of Home windows Eight or later.
Moreover, the system ought to use a 64-bit model of Home windows. If a 32-bit model is used, solely boot begin drivers will likely be verified permitting attackers to put in malicious drivers which don’t designate themselves as boot-start drivers.
Take a look at Steps: Test Boot Configuration Information Registry
To test if the kernal driver signature verification is enabled, view the registry information at:
HKEY_LOCAL_MACHINEBCD000000
Test the next parameters as they’ve direct impacts on the safety posture of the BIOS boot course of:
BcdLibraryBoolean_DisableIntegrityCheck, BcdOSLoaderBoolean_WinPEMode, BcdLibraryBoolean_AllowPrereleaseSignature
Confirm that these three boolean values are configured appropriately and will not be disabling essential safety mechanisms.
PnP Gadget Set up Signing Coverage
The Plug and Play Gadget Set up Signing Coverage gives a separate set of protections for Kernel-Mode Signing. The necessities enforced by the PnP coverage solely apply to Plug and Play system drivers.
The objective of this safety is to confirm the identification and integrity of the writer of the PnP driver. To confirm these drivers, the safety mechanism checks that the driving force is signed both by a Home windows {Hardware} High quality Lab (WHQL) or a trusted third social gathering.
If these necessities will not be met, a warning immediate will likely be proven to the consumer who should manually settle for to proceed with the boot course of. This coverage is barely enforced throughout PnP driver set up, not throughout future runs. This isn’t an inherent vulnerability, however relatively an additional set of verification because the mechanisms described within the Kernel-Mode Signing Protections will nonetheless apply to PnP drivers.
Take a look at Steps: Test the “Disable PnP Signing Registry”
Test the next registry entry to see if PnP Signing has been disabled to permit for kernel module debugging
HKLMSYSTEMCurrentControlSetControlCIDebugFlag
If this registry is ready to 0x00000001, a debugger will likely be launched when an improperly signed PnP driver is loaded. An attacker with native entry to the system can then press “g” on the debugger immediate to load the malicious driver.
Be sure that this registry worth is as an alternative set to 0x00000010 which signifies that any debuggers ought to be ignored and the driving force ought to be rejected.
Safe Boot
Safe Boot was an overhaul of the BIOS startup course of to include additional safety measures. This alters the circulation of early boot as follows:

BIOS Initialization — {hardware} self-tests, skipped if heat boot
UEFI
bootmgr -> winload.exe
Kernel Picture Begins -> Boot-start drivers
ELAM Drivers
Kernel-mode boot-start drivers
First Consumer-Mode Course of

In principle, when Safe Boot is enabled, all UEFI drivers should have a digital signature in an effort to be loaded by the system. In observe, there are a variety of configurations that may considerably weaken or disable this safety. Earlier than we cowl these, you will want context on UEFI.
Common Extensible Firmware Interface
UEFI differs from the everyday BIOS course of in a number of key methods. There isn’t any longer an MBR and VBR to find the code. As an alternative, the GPT (GUID Partition Desk) is configured as a particular partition inside the bootloader which factors to the FAT32 EFI system partition. It incorporates a polyglot MBR entry inside the GPT entry to forestall previous methods which solely acknowledge MBR from nuking this new format.
The trail to this bootloader partition is managed by an NVRAM variable (hints for exploitation later). The bootloader right here is answerable for discovering the OS kernel loader and transferring management to it. This code is saved in SPI flash saved instantly on the motherboard and is loaded into RAM throughout startup.
The OS Loader consists of a number of recordsdata saved inside the EFI system partition. It’s necessary to notice that it’s inside this bootloader that management shifts from code saved on SPI flash to code saved on the HDD. That is the placement the place attackers with bodily entry to laborious drive reminiscence have a chance to strike. If Safe Boot is disabled, any code will be modified right here as patchguard isn’t current till the home windows kernel has been initialized.
As soon as the management has been transferred from the OS Loader to winloader, boot companies will likely be eliminated; nevertheless, all runtime companies are enabled. Understand that the OS Loader exposes a set of runtime companies by way of the hal.dll module to kernel modules after boot. Errors inside this module are sometimes used as an insertion level for bootkits. These companies embrace the flexibility to learn/write NVRAM variables, carry out firmware updates by way of capsule replace, and reboot / shutdown services.
The UEFI Spec
The UEFI Spec defines four distinct phases of boot

SEC – Safety boot: finds the loader for PEI and runs from SPI Flash
PEI – Pre-EFI Initialization: configures reminiscence, does fundamental {hardware} issues, runs in tmp reminiscence then transitions to perm reminiscence
DXE – Driver Execution Atmosphere: Initializes System Administration Mode (additionally known as ring -2) and DXE service executables. It additionally gives boot and runtime companies
BDS – Boot Drive Choice: discovers the HW system from which the OS will likely be loaded utilizing the GPT

Take a look at Steps: SPI Flash Bits
A lot of configurations can considerably weaken the safety of UEFI Safe Boot. The next reminiscence bits are saved inside SPI flash and management essential items of safe boot. Be aware: at all times test that instantly writing to SPI flash by way of kernel modules is restricted to forestall attackers from altering these variables.

BIOSWE – BIOS Write Allow Bit (Zero is locked, 1 is unlocked)
BLE – BIOS Lock Allow Bit (1 is locked, Zero is unlocked)
SMM_BWP – System Administration Mode BIOS Write Safety Bit (1 is locked, Zero is unlocked)
PR(0-5) – SPI Protected Ranges which selectively forestall writing to the BIOS

All these variables are initially set throughout the driver execution atmosphere part. To confirm these variables, I strongly advocate utilizing the CHIPSEC kernel module supplied by Intel. A information describing how one can set up this device is included within the assets part on the finish of this weblog.
To test the BIOS write safety bits as soon as the CHIPSEC kernel driver is put in, run the next command in a root terminal:
chipsec_main.py -m frequent.bios_wp
If the PR ranges are all 0’s, they aren’t being utilized in any respect and ought to be set to guard delicate reminiscence areas inside the BIOS.
How would possibly an Attacker Infect UEFI Firmware?
There are a lot of some ways an attacker would possibly go about infecting firmware, however following is a listing of the most typical/apparent strategies:

Modify unsigned UEFI possibility ROMS which is probably not verified primarily based on configuration
Add/Modify a DXE driver
Exchange/Modify the boot supervisor (Use fallback boot supervisor)
Modify the fallback bootloader EFI/BOOT/bootx64.efi
Add a secondary boot loader
Bypass SPI Write Safety and set delicate reminiscence bits to disable protections
From consumer area with root privileges, use a signing bypass to insert kernel code, use the {Hardware} Abstraction Layer interface to entry System Administration Mode. Then discover a solution to bypass SPI protections to write down on to one of many early boot phases listed above

Again to Safe Boot
There are three types of safe boot.
OS Safe Boot
This type of safe boot happens inside the OS Boot Loader and solely verifies the OS Kernel and Boot begin Drivers.
UEFI Safe Boot
This safe boot is carried out inside UEFI firmware. The verification itself takes place within the Driver Execution Atmosphere part whereas UEFI apps and drivers are being loaded. Infections can nonetheless happen throughout the PEI or SEC part of the BIOS.
Moreover, if an attacker is ready to compromise the platform picture itself, they’ll be capable to bypass this safety.
Platform Safe Boot — Using a TPM
This type of safe boot verifies all platform initialization firmware and runs inside a Trusted Platform Module.
Initially, Safe Boot Driver verification occurred in DXE, then in PEI, however now it ought to happen in both a TPM (Trusted Platform Module), or inside area programmable fuses that are solely accessible by way of Intel ME firmware. Take a look at Steps: Vital Key Places
The signatures are saved inside a database which resides both inside SPI flash or an NVRAM variable, relying on the implementation. There may be additionally a separate Dbx Database, which incorporates a listing of blacklisted public keys and hashes which will likely be explicitly denied.
These databases are protected by a platform key or the seller key NVRAM variable (KEK). This NVRAM variable ought to be securely saved inside the TPM and signed by the platform key. Throughout a safety engagement, it’s essential to confirm that the platform and vendor key are solely managed by the suitable events. The checklist of permitted signers within the database ought to be restricted to solely the signers required for system operation. Ideally this could be restricted to the mission proprietor.
Moreover, the Dbx database ought to explicitly deny recognized unhealthy signers.
Take a look at Steps: Safe Boot Insurance policies
The sections above element how the system ought to behave in principle, however in observe it’s depending on the safe boot coverage. This coverage might specify that some media resembling PCDOption Roms are trusted by default.
Run the next PowerShell command in an administrative terminal to test if Safe Boot is enabled for the system beneath take a look at:
Affirm-SecureBootUEFI
Run the next PowerShell command in an administrative terminal to test if the manufacturing Safe Boot Coverage is enabled for the system beneath take a look at.
Get-SecureBootPolicy
The command will return a price of {77FA9ABD-0359-4D32-BD60-28F4E78F784B} whether it is operating utilizing a manufacturing coverage. Another worth signifies a debug or producers coverage is in use and ought to be investigated additional.
On non-windows machines, working system kernel image-specific strategies will should be used to test the safe boot coverage in use. In Rootkits and Bootkits, the authors discovered that the Intel EDK2 supply code had a number of coverage values which didn’t confirm pictures situated on detachable media or possibility ROMS.
These implementation particulars are the place attackers with a robust data of system internals could possibly subvert an in any other case safe system.
Virtualization Primarily based Safety:
Beginning with Home windows 10, the code integrity mechanisms have been moved outdoors of the system kernel with the Digital Safe Mode and Gadget Guard options. These two methods benefit from {hardware} assisted reminiscence isolation to run the working system and demanding system drivers in hypervisor protected containers. The objective is to make sure that even when the runtime kernel is contaminated, the firmware and working system are secure from additional exploitation.
Digital Safe Mode eliminates the specter of a professional kernel module having an RCE vulnerability which compromises your entire system as attackers can not escalate their privileges outdoors of the safe container.
Gadget Guard builds on this expertise by combining Digital Safe Mode with platform and UEFI safe boot. The target is to implement system integrity from the beginning of the boot course of and forestall bootkits from having any an infection level. Platform and UEFI safe boot occurs as described above. Nonetheless, as soon as the boot supervisor transfers management to the working system kernel, system guard wraps delicate system parts such because the operating kernel in a protecting hypervisor digital container.
The trade-off for gaining these implausible safety traits is that each one drivers developed for system guard should comply with extra guidelines as described beneath:

Drivers can solely allocate non-paged reminiscence from the no executable pool.
Drivers can not have writable and executable sections
Drivers can not have dynamic or self-modifying code
Drivers can not load any information as executable

Verified and Measured Boot
Fashionable TPMs present methods which allow a system to confirm that it’s in a recognized secure state earlier than unsealing secrets and techniques which have been sealed contained in the TPM. This method verifies that the platform picture has not been altered.
Measured Boot works by storing hashes of boot parts contained in the TPM PCRS (Platform Config Registries) and checking them at runtime.
TPM Attestation is a technique to show the identification of a system. It proves {that a} TPM is holding a sure key with out revealing that key. It’s typically used to limit an endpoint to speaking with solely a sure recognized variety of gadgets.
Intel Boot Guard – a Platform Safe Boot implementation
Intel Boot Guard is an implementation of verified and measured boot. It’s necessary to notice that it has its personal coverage distinct from common safe boot which must also be evaluated.
Boot Guard verifies the BIOS picture to make sure that it hasn’t been contaminated by a bootkit. It makes use of the {hardware} root of belief (both TPM or fuses) to avoid wasting a hash of the right BIOS content material and TPM verification code.
This technique reduces the earlier reliance on the integrity of SPI flash reminiscence and strikes all belief instantly into {hardware}, hardened for this goal.
Afterword
Early boot methods are sometimes uncared for throughout evaluations of {hardware} gadgets. In menace fashions that contain prospects with remoted entry to the goal system, it’s essential to make sure that assault vectors involving firmware implants are mitigated. Use your new BIOS superpowers to drop some Ring-2 kits and safe some {hardware}!
If this information was useful to you, or you probably have feedback about this text, please be at liberty to achieve out. I wish to hear what you suppose! If you wish to see extra content material like this, view the archive, subscribe to my publication or assist me on Ko-Fi.
Additional Studying and Assets:
Notes on Safe Boot and assaults
https://elinux.org/pictures/9/97/Protecting_your_system.pdf
https://i.blackhat.com/asia-19/Fri-March-29/bh-asia-Matrosov-Fashionable-Safe-Boot-Assaults.pdf
http://weblog.frizk.internet/2017/08/attacking-uefi.html
https://medium.com/@matrosov/uefi-vulnerabilities-classification-4897596e60af
http://www.c7zero.data/stuff/DEFCON22-BIOSAttacks.pdf
https://www.blackhat.com/displays/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf
https://www.blackhat.com/docs/eu-14/supplies/eu-14-Kovah-Analyzing-UEFI-BIOSes-From-Attacker-And-Defender-Viewpoints.pdf
https://habr.com/en/publish/446238/https://github.com/ValdikSS/Tremendous-UEFIinSecureBoot-Disk
https://github.com/theopolis/uefi-firmware-parser
https://github.com/LongSoft/UEFITool/releases/tag/0.27.0
Windows Process Injection: KnownDlls Cache Poisoning
TPM particular assaults (attestation bypass, and many others.)
https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Seunghun-Lastly-I-Can-Sleep-Tonight-Catching-Sleep-Mode-Vulnerabilities-of-the-TPM-with-the-Napper.pdf
https://github.com/kkamagui/napper-for-tpm/#6-test-results
https://github.com/nccgroup/TPMGenie
PXE Particular assaults
https://weblog.netspi.com/attacks-against-windows-pxe-boot-images/

Misc BIOS Issues:
https://github.com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered
https://github.com/bootkitsbook/
https://01.org/linux-uefi-validation
https://www.blackhat.com/docs/asia-17/supplies/asia-17-Matrosov-The-UEFI-Firmware-Rootkits-Myths-And-Actuality.pdf
https://threatvector.cylance.com/en_us/dwelling/gigabyte-brix-systems-vulnerabilities.html

Instruments
https://github.com/LongSoft/UEFITool
https://github.com/chipsec/chipsec