The Evolution of Windows Kernel Threats
Unfortunately, most security products today only secure and have visibility over the higher levels of the software stack. Because of this, malicious actors use rootkits and other threats to go after the kernel level to gain privileged access, install malicious components in infected systems, and fly under the radar for extended periods.
In this report, we examine how these low-level threats have evolved through the years and discuss the three types of low-level threats that affect Windows systems. The categorization of more than 60 of the most noteworthy low-level threats observed in the wild from 2015 to 2022, and where these threats stand in today’s threat landscape, are discussed in full in our research paper, “An In-depth Look at Windows Kernel Threats.”
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:
- Higher development costs for loading kernel rootkits
- Only a few malicious actors had the technical capabilities to include kernel rootkits in their malware arsenal
- Malicious actors had new techniques for bypassing the security defenses Microsoft added to newer Windows versions
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
After analyzing low-level threats discovered in the wild from April 2015 to October 2022, we were able to observe three main clusters of observable techniques. Each analyzed threat includes at least one kernel-level module that bypasses kernel-space access restrictions in their kill chains:
- Threats that disable KMCS using legitimate built-in tools
- Threats that abuse vulnerable drivers (bring your own vulnerable driver or BYOVD attacks)
- Threats that abuse dual-usage drivers
- Threats that target legacy systems
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.
- Threats that use stolen valid code-signing certificates
- Threats that use acquired or purchased code-signing certificates
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.
- Firmware-level attacks
- BIOS implants
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.
- Ransomware Spotlight: Trigona
- Steering Clear of Security Blind Spots: What SOCs Need to Know
- Understanding the Kubernetes Security Triad: Image Scanning, Admission Controllers, and Runtime Security
- Preempting Threats to Connected Cars: The Importance of Cybersecurity in a Data-Driven Automotive Ecosystem
- Your Stolen Data for Sale