New defense mechanisms in the Windows operating system have forced malware actors to adapt to the different abstraction layers to successfully create and carry out kernel-level attacks.
We discuss the state of Windows kernel threats before and after the introduction of the kernel mode code signing (KMCS) policy below:
The rootkit threat landscape changed dramatically during the KMCS era because of the following:
Figure 1 illustrates the state of kernel threats before the introduction of KMCS and after the first iteration of security enhancements were introduced.
Figure 1. Hardening Window kernel security post-KMCS adoption
The threats in the first cluster use legitimate built-in tools that were mainly intended for debugging and testing to explicitly disable KMCS. These tools provide an interface for temporarily disabling driver verification and enabling test signing to verify the digital signature of the drivers. Inadvertently, these tools have stayed under the radar of monitoring systems.
These threats also use BYOVD, which involves piggybacking the intended kernel code through a vulnerable driver that can be legitimately loaded into a Windows system or a third-party kernel driver. A recent example of this technique was when ransomware actors abused a vulnerable anti-cheat driver for the role-playing game Genshin Impact to disable antivirus processes and services.
The threats in the second cluster comply with Microsoft’s signing requirements, which give them the flexibility to compile and sign the customized kernel drivers that are built for very specific tasks. This required malicious actors to either obtain a valid code-signing certificate by impersonating a legitimate entity and following Microsoft’s cross-signing certificate process (this was back when Microsoft still allowed cross-signing for kernel-mode code) or stealing someone else’s certificate.
An example of an attack that used this technique is when malicious actors abused the Windows Hardware Compatibility Program (WHCP) portal and submitted malicious drivers to target gaming environments.
The third cluster involves using a complex strategy of moving into a lower-level layer in the software stack and operating at a new abstraction layer. By doing so, it would be possible to load the malicious kernel code even before the full kernel and the core component that enforces the code-signing policy are initialized.
The techniques in this cluster later evolved from just infecting MBR/VBR/IPL entries in legacy BIOS-based boot processes to abusing firmware vulnerabilities, which are located one layer closer to the hardware.
As more modern security mechanisms are built into the Windows operating system, the threats that involve low-level components will continue to evolve. However, despite these security advancements, it still only takes one bypass to compromise the whole software stack. This is why it’s important to understand that built-in technologies are not enough to detect and thwart complex low-level threats.
Read our research paper, “An In-depth Look at Windows Kernel Threats,” to get a better understanding of how advanced malicious actors are adapting to the current defense mechanisms found in modern operating systems, how they are evolving their techniques, and what tools from underground marketplaces they use to abuse the Windows kernel.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.