T1014 Rootkit Mappings

BitLocker uses TPM (Intel PTT) to bind the volume encryption keys for full disk encryption (FDE), Intel AES-NI to accelerate the encryption/decryption process, and Intel BootGuard to ensure operating system components are not compromised during boot. BitLocker also can add pre-boot authentication (like PIN) to access the decryption keys used for FDE. BitLocker relies on Intel BootGuard and the TPM (Intel PTT) to ensure none of the boot components or the OS components are tampered with before releasing the BitLocker key. BitLocker is a Windows security feature that provides encryption for entire volumes, addressing the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices. BitLocker also uses Intel PTT to check integrity of early boot components, configuration data as well as OS components preventing attacks that perform modifications of those components. BitLocker relies on Intel BootGuard and the TPM (Intel PTT) to ensure none of the boot components or the OS components are tampered with before releasing the BitLocker key.

Windows Secure Boot leverages Intel PTT (TPM) to safeguard settings stored in UEFI, while Intel Boot Guard prevents unauthorized modifications to UEFI firmware. It verifies the signatures of the UEFI firmware, bootloader, and boot drivers before loading the operating system. When the PC starts, the firmware checks the signature of each piece of boot software, including Unified Extensible Firmware Interface (UEFI) firmware drivers (also known as Option ROMs), Extensible Firmware Interface (EFI) applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system. Rollback protection also prevents the system from rolling back to older versions of firmware. Secure Boot employs Intel PTT (TPM) to thwart attacks that attempt to alter the signature policy at the boot level in real-time or modify components involved in the boot process before the boot process. Intel Boot Guard ensures the integrity of the boot-level code before it is executed on the processor, preventing the system from proceeding with malicious boot code. Secure Boot is able to address threats pre-os that change the signature of the loaded boot component.

System Guard Secure Launch uses a technology called Dynamic Root of Trust Measurement (DRTM). It leverages Intel PTT (TPM) and TXT to provide secure methods to boot a system and verify the integrity of the operating system and loading mechanisms. System Guard Secure Launch ensures that the system can freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path. This has the benefit of allowing untrusted early code to boot the system but then being able to securely transition into a trusted and measured state. The ability to transition in real-time to a secure state justified the score of significant for this feature and its corresponding protection (E.g., bootkit, rootkit, firmware corruption, etc.).

Memory integrity is a Virtualization-based security feature that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS (VBS uses Intel VT-x). Memory integrity also restricts kernel memory allocations that could be used to compromise the system. Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI). VBS provides an isolated environment that acts as a root-of-trust for the OS and its core components. It is enabled by Intel VT-x, VT-x2 with Extended Page Tables, SMMUs (Intel VT-d) and Secure Boot (Intel Boot Guard). Memory Integrity protects against behaviors that involve exploitation of kernel components including core drivers in memory, changing security configurations and running untrusted code (based on signatures). "HVCI protects modification of the Control Flow Guard (CFG) bitmap for kernel mode drivers. Protects the kernel mode code integrity process that ensures that other trusted kernel processes have a valid certificate." "Hypervisor-protected code integrity introduces a new rule that no kernel memory pages are both writeable and executable, which eliminates an entire category of attacks that dynamically generate code. Additionally, HVCI comes enabled with a code integrity security policy that blocks drivers known to be used in kernel tampering, including Mimikatz, the old vulnerable VBox driver, and the Capcom driver commonly used in rootkits. Ultimately, HVCI provides optimal protection for the kernel against tampering and escalation of privilege attacks. ... With HVCI enabled, attempts to modify the process structures will fail, preventing the protected process flag from being removed, which prevents process memory inspection or module injection into LSA." Windows Kernel Data Protection uses VBS (Intel PTT, Intel VT-x, Intel VT-d, Intel VT-rp, and Intel BootGuard) to protect kernel data, kernel data structures, and OS drivers from tampering attacks. With KDP, software running in kernel-mode can protect read-only memory statically (a section of its own image) or dynamically (pool memory that can be initialized only once). KDP only establishes write protections in VTL1 for the GPAs backing a protected memory region using the SLAT page tables for the hypervisor to enforce. This way, no software running in the NT kernel (VTL0) can have the permissions needed to change the memory. The goal of using KDP is to protect internal policy state after it has been initialized (i.e., read from the registry or generated at boot time). These data structures are critical to protect as if they are tampered with a driver that is properly signed but vulnerable could attack the policy data structures and then install an unsigned driver on the system. With KDP, this attack is mitigated by ensuring the policy data structures cannot be tampered with. The score of significant highlights this real-time protection of the kernel data, data structures, and drivers from tampering attacks.

Memory integrity is a Virtualization-based security feature that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS (VBS uses Intel VT-x). Memory integrity also restricts kernel memory allocations that could be used to compromise the system. Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI). VBS provides an isolated environment that acts as a root-of-trust for the OS and its core components. It is enabled by Intel VT-x, VT-x2 with Extended Page Tables, SMMUs (Intel VT-d) and Secure Boot (Intel Boot Guard). Memory Integrity protects against behaviors that involve exploitation of kernel components including core drivers in memory, changing security configurations and running untrusted code (based on signatures). "HVCI protects modification of the Control Flow Guard (CFG) bitmap for kernel mode drivers. Protects the kernel mode code integrity process that ensures that other trusted kernel processes have a valid certificate." "Hypervisor-protected code integrity introduces a new rule that no kernel memory pages are both writeable and executable, which eliminates an entire category of attacks that dynamically generate code. Additionally, HVCI comes enabled with a code integrity security policy that blocks drivers known to be used in kernel tampering, including Mimikatz, the old vulnerable VBox driver, and the Capcom driver commonly used in rootkits. Ultimately, HVCI provides optimal protection for the kernel against tampering and escalation of privilege attacks. ... With HVCI enabled, attempts to modify the process structures will fail, preventing the protected process flag from being removed, which prevents process memory inspection or module injection into LSA." Windows Kernel Data Protection uses VBS (Intel PTT, Intel VT-x, Intel VT-d, Intel VT-rp, and Intel BootGuard) to protect kernel data, kernel data structures, and OS drivers from tampering attacks. With KDP, software running in kernel-mode can protect read-only memory statically (a section of its own image) or dynamically (pool memory that can be initialized only once). KDP only establishes write protections in VTL1 for the GPAs backing a protected memory region using the SLAT page tables for the hypervisor to enforce. This way, no software running in the NT kernel (VTL0) can have the permissions needed to change the memory. The goal of using KDP is to protect internal policy state after it has been initialized (i.e., read from the registry or generated at boot time). These data structures are critical to protect as if they are tampered with a driver that is properly signed but vulnerable could attack the policy data structures and then install an unsigned driver on the system. With KDP, this attack is mitigated by ensuring the policy data structures cannot be tampered with. The score of significant highlights this real-time protection of the kernel data, data structures, and drivers from tampering attacks.