Adversaries may use port monitors to run an adversary supplied DLL during system boot for persistence or privilege escalation. A port monitor can be set through the <code>AddMonitor</code> API call to set a DLL to be loaded at startup.(Citation: AddMonitor) This DLL can be located in <code>C:\Windows\System32</code> and will be loaded and run by the print spooler service, spoolsv.exe
, under SYSTEM level permissions on boot.(Citation: Bloxham)
Alternatively, an arbitrary DLL can be loaded if permissions allow writing a fully-qualified pathname for that DLL to the Driver
value of an existing or new arbitrarily named subkey of <code>HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors</code>. The Registry key contains entries for the following:
Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
---|---|---|---|---|---|
intel-vt | Intel Virtualization Technology | Win 11, KDP | T1547.010 | Port Monitors |
Comments
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.
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."
References
|