Adversaries may modify code signing policies to enable execution of unsigned or self-signed code. Code signing provides a level of authenticity on a program from a developer and a guarantee that the program has not been tampered with. Security controls can include enforcement mechanisms to ensure that only valid, signed code can be run on an operating system.
Some of these security controls may be enabled by default, such as Driver Signature Enforcement (DSE) on Windows or System Integrity Protection (SIP) on macOS.(Citation: Microsoft DSE June 2017)(Citation: Apple Disable SIP) Other such controls may be disabled by default but are configurable through application controls, such as only allowing signed Dynamic-Link Libraries (DLLs) to execute on a system. Since it can be useful for developers to modify default signature enforcement policies during the development and testing of applications, disabling of these features may be possible with elevated permissions.(Citation: Microsoft Unsigned Driver Apr 2017)(Citation: Apple Disable SIP)
Adversaries may modify code signing policies in a number of ways, including through use of command-line or GUI utilities, Modify Registry, rebooting the computer in a debug/recovery mode, or by altering the value of variables in kernel memory.(Citation: Microsoft TESTSIGNING Feb 2021)(Citation: Apple Disable SIP)(Citation: FireEye HIKIT Rootkit Part 2)(Citation: GitHub Turla Driver Loader) Examples of commands that can modify the code signing policy of a system include <code>bcdedit.exe -set TESTSIGNING ON</code> on Windows and <code>csrutil disable</code> on macOS.(Citation: Microsoft TESTSIGNING Feb 2021)(Citation: Apple Disable SIP) Depending on the implementation, successful modification of a signing policy may require reboot of the compromised system. Additionally, some implementations can introduce visible artifacts for the user (ex: a watermark in the corner of the screen stating the system is in Test Mode). Adversaries may attempt to remove such artifacts.(Citation: F-Secure BlackEnergy 2014)
To gain access to kernel memory to modify variables related to signature checks, such as modifying <code>g_CiOptions</code> to disable Driver Signature Enforcement, adversaries may conduct Exploitation for Privilege Escalation using a signed, but vulnerable driver.(Citation: Unit42 AcidBox June 2020)(Citation: GitHub Turla Driver Loader)
View in MITRE ATT&CK®Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
---|---|---|---|---|---|
intel-ptt | Intel Platform Trust Technology | Win 11, Secure Boot | T1553.006 | Code Signing Policy Modification |
Comments
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.
References
|
intel-vt | Intel Virtualization Technology | Win 11, VBS, Memory Integrity | T1553.006 | Code Signing Policy Modification |
Comments
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."
The Vulnerable Driver Blocklist uses Virtualization Based Security (VBS) Memory Integrity feature or HVCI, which in turn rely on Intel PTT, Intel VT-x, Intel VT-d and Intel BootGuard to create an isolated virtual environment for the kernel such that attacks from vulnerable drivers are prevented. It uses a deny list approach along with code signing checks to ensure vulnerable drivers are not modified and to prevent attacks against them.
"... the vulnerable driver blocklist is also enforced when either memory integrity (also known as hypervisor-protected code integrity or HVCI), Smart App Control, or S mode is active."
"The blocklist is updated with each new major release of Windows, typically 1-2 times per year..."
"Memory integrity and virtualization-based security (VBS) improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS."
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.
References
|
intel-vt | Intel Virtualization Technology | Win 11, KDP | T1553.006 | Code Signing Policy Modification |
Comments
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."
The Vulnerable Driver Blocklist uses Virtualization Based Security (VBS) Memory Integrity feature or HVCI, which in turn rely on Intel PTT, Intel VT-x, Intel VT-d and Intel BootGuard to create an isolated virtual environment for the kernel such that attacks from vulnerable drivers are prevented. It uses a deny list approach along with code signing checks to ensure vulnerable drivers are not modified and to prevent attacks against them.
"... the vulnerable driver blocklist is also enforced when either memory integrity (also known as hypervisor-protected code integrity or HVCI), Smart App Control, or S mode is active."
"The blocklist is updated with each new major release of Windows, typically 1-2 times per year..."
"Memory integrity and virtualization-based security (VBS) improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS."
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.
References
|