Kernel Mode Threats & Practical Defenses: Part 1
Recent advancements in OS security from Microsoft such as PatchGuard, Driver Signature Enforcement, and SecureBoot have helped curtail once-widespread commodity kernel mode malware including TDL4 and ZeroAccess. However, advanced attackers have found ways of evading these protections and continue to leverage kernel mode malware to stay one step ahead of the defenders. Kernel mode threats generally have total control over the affected machine, can re-write the rules of the operating system, and can easily tamper with security software.
APT groups realize these benefits and are exploiting them to stay ahead of defenders. In this first of a two-part series stemming from our recent Black Hat talk on kernel mode threats, we will dive deep into the evolution of kernel mode threats and the current state of these attacks. Through thoughtful integration of extant, in the wild exploits and tactics, attackers have access to a range of capabilities that enable more sophisticated and hard to detect kernel mode attacks. Our next post will focus on defending against these attacks, but first it is essential to understand the state of the art of kernel mode threats. Through these two posts, we hope to increase the community’s exposure to these threats and ultimately improve the industry’s defensive posture.
Evolution of Kernel Threats and Platform Protections
Early Kernel Malware
Over 10 years ago, the first truly widespread kernel malware came onto the scene. There were no operating system defenses for these threats at the time, so they flourished. Rustock, TDSS, and ZeroAccess malware families had millions of infections at their peaks. They all shared a similar technique for gaining ring0 execution by infecting existing drivers on disk. They also commonly included rootkit features for hiding files, processes, and network connections from users and security software.
In response to the widespread malware of the late 2000s, Microsoft responded with two technologies that sought to mitigate them. The first was PatchGuard. PatchGuard is designed to detect rootkit-style techniques, such as hooking, and then subsequently crashes the machine. PatchGuard is not perfect and can be bypassed, but it is continually evolving, making it a moving obstacle for attackers.
Microsoft also created another protection - Driver Signature Enforcement or DSE. DSE requires that all drivers are signed by a valid signature before they can be loaded. DSE prevents drivers that have been infected with malware (breaking the digital signature in the process) from loading on the system. It also prevents directly loading unsigned malicious drivers. Both defenses became more important as the market share for 64 bit windows increased.
To evade DSE (and in some cases PatchGuard), malware authors began leveraging Bootkits to get their malware loaded into kernel mode. Bootkits tamper code associated with the early operating system boot process, such as the MBR, VBR, or other OS specific bootloader code.
This includes the original proof of concept eEye BootRoot, along with widespread threats such as Sinowal, TDL4, and XPaj. One interesting aspect of XPaj was its ability to bypass PatchGuard by performing hooks early in the boot process, even before PatchGuard itself was initialized. This meant PatchGuard would implicitly trust the hooks as part of the legitimate code.
The security industry responded to bootkit malware by creating Secure Boot. This technology is baked into the Unified Extensible Firmware Interface (UEFI) specification, and was implemented by Microsoft starting in Windows 8. Secure Boot works by having the UEFI runtime (which is a replacement for legacy BIOS) validate the digital signature of the OS boot loader before executing it.
Any modifications by malware would result in an unbootable PC. Microsoft expanded this approach with Trusted Boot, which works similarly to Secure Boot but continues this signature validation phase throughout the entire boot process. The downside to Secure Boot is that it doesn't protect from compromised firmware, because the firmware is allowed to run before Secure Boot checks. However, technologies like Intel's Boot Guard counter firmware attacks by moving the "root of trust" all the way to an immutable section of the CPU.
Bring Your Own Vuln
While DSE, PatchGuard, and Secure Boot have dramatically reduced the landscape of commodity kernel mode threats, nation-state level threats continue to find creative ways to circumvent these platform protections. APT-level kernel mode malware often installs a legitimate, signed vulnerable driver which is then exploited to gain kernel code execution, thereby side-stepping DSE. Threats such as Uroburos, Derusbi, and Slingshot have all employed this approach. Another notable technique, leveraged by Derusbi and other groups, is to steal legitimate certificates and use them to sign malware drivers.
Even more advanced nation-state level threats, such as Duqu, do not bother with installing and exploiting a vulnerable driver. Instead, they exploit the kernel directly with an 0day. To further evade detection, Duqu hooks the import address table of an installed Kaspersky driver, and tricks the driver into thinking its malicious user process was a trusted Kaspersky process. The Kaspersky driver would then whitelist it completely, as well as prevent it from being terminated by the local users or other malware. For actual persistence, Duqu dropped a driver implant to disk in the network DMZ. This driver was signed with a stolen Foxconn certificate. This implant serves as a gateway into the entire network as it could redirect network traffic to any internal destination.
DOUBLEPULSAR is also worth a strong mention. It is a very lightweight kernel mode implant that lives only in memory; it has no reboot persistence. It is typically loaded onto a system using a remote ring0 exploit such as ETERNALBLUE. DOUBLEPULSAR allows attackers with stealthy remote access onto the system by hooking a function pointer in the SMBv1 driver (srv.sys). At the time, this function pointer was not monitored by PatchGuard. From there it allows attackers to load more kernel mode code, or inject a full featured payload into user mode. It became a widespread threat after it was leaked and picked up by other adversaries, such as in the WannaCry and NotPetya attacks.
To mitigate from attackers who exploit their way to kernel mode, MS released Virtualization Based Security or VBS. With VBS, the kernel is sandboxed by the hypervisor and no longer has complete control over the system.
Hypervisor Code Integrity (HVCI) extends VBS and requires all kernel code be signed. Furthermore, kernel memory is no longer allowed to be both writable and executable (known as W^X). HVCI stops many kernel mode threats such as Turla Driver Loader (discussed in our next post) and DOUBLEPULSAR. Credential Guard also leverages the hypervisor to protect credentials from tools like mimikatz.
The mitigations discussed thus far are only a prominent subset of the kernel mitigations that Microsoft has implemented in the last 10 years, and they have significantly increased investment against these threats in more recent OS versions (especially Win10). However, market share remains a major concern. A large user base is still running Win7, and many organizations that have upgraded to Win10 are not yet leveraging the most advanced kernel protections. Because these protections are still not widely implemented, attackers will continue to pursue low cost kernel attacks.
So what can be done to protect against kernel mode threats? In our next post, we will present our latest research on offensive tradecraft, which directly informs how we protect against these threats. This includes the role of red and blue exercises, hunting, and real-time protections. Although kernel mode threats will continue to evolve, the state of the art in malware detection has also advanced to hinder these new kernel mode threats. Next, we will equip you with new detections and insights to stay a step ahead of evolving kernel mode threats.