Increasingly, malware authors are crafting attacks to inject malicious code into operating system (OS) kernels, where it is essentially invisible to many security systems. Instead of exclusively relying on user-mode components, we now see advanced attacks targeting the kernel.

While it may not be surprising that most signature-based detection technologies miss kernel-based malware, many behavior-based malware tracking tools, such as some sandboxes, can’t detect kernel-based malware using traditional hooking mechanisms. Once in the kernel, very few security technologies have visibility into kernel-mode malware behavior. Additionally, these components have equal or even higher privileges than most security tools. Thus, attackers can essentially take safe refuge in the kernel, acting on nefarious intentions with little concern for getting caught.

What Makes Kernel-Based Malware So Pernicious?

As my Lastline Labs colleague discussed in a post a few months ago, and as I briefly discussed in my recent South by Southwest talk, attacks against Windows users with components executing in the kernel of the OS are particularly pernicious because their kernel components run with the highest level of permissions available on the system. This often puts traditional AV systems at a lower permission level than the malware itself. As a result, malware in the kernel can operate undetected, executing system calls and connecting to command-and-control (C&C) servers with full authorization as a privileged application.

In addition to enjoying supreme permissions, kernel-based malware is impervious to traditional hooking mechanisms used by first-generation sandboxes during analysis of unknown or suspicious code. Most sandboxes intercept API function invocations using hooks into user-mode libraries loaded by a program undergoing dynamic analysis. Traditional sandboxes intercept and in some cases tamper with parameters passed to functions that are used to perform malicious behavior. Somewhat more advanced sandboxes also block a program’s system calls in an attempt to analyze evasive malware that bypasses user-mode functions and targets the OS kernel directly. This interception of code to detect and analyze suspicious behaviors fails to extract or record malicious functions when they are loaded into the kernel. Once there, the malicious components are indistinguishable from trusted OS code since the malware behaviors no longer rely on user-mode APIs or system calls.

When attempting to detect kernel malware, it is important not to limit hooking mechanisms to API or system calls, which I’ve argued in some of my previous scientific work as far back as a decade ago. In fact, kernel-bound malware is based on the context of untrusted operations (e.g., new drivers), and determining whether code belongs to the original kernel or is in user space requires further analysis.

The research community has taken notice of kernel-based malware such as Equation, Regin, Dark Hotel and Turla/Uroburos. But not all kernel-based malware is created equal. For example, in many cases, kernel hardening has made it necessary for attackers to reboot the target system in order to turn off default protections that prevent injection of code into the kernel. Rebooting can draw unwanted attention and may raise suspicions enough to thwart an attack. However, new, more advanced kernel-mode malware like Turla does not require a reboot to circumvent standard kernel protections.

Taking a closer look at Turla gives us insights into a new breed of more sophisticated kernel-based malware.

Turla’s One-Two Punch Into the Kernel

Turla is able to bypass signature verification for drivers and defeat PatchGuard to infiltrate Windows OS kernels. This one-two punch means new kernel hardening approaches implemented by Microsoft in modern versions of the Windows OS are insufficient to prevent injection of Turla malware into the kernel. First, Turla gets past driver signature verification by loading a vulnerable version of a signed VirtualBox driver. This lets a user-mode application write to arbitrary memory locations in the kernel. Second, Turla essentially intercepts PatchGuard alerts to prevent the triggering of the infamous “blue screen of death.” And like other kernel-based malware, Turla can defeat traditional sandboxes by bypassing hooking mechanisms that operate in the kernel.

A Closer Look at Kernel Rootkits

Kernel-based attacks typically use kernel rootkits to hide the user-mode components of malware and avoid detection. An attacker first exploits a user system by loading malware into the kernel, which then intercepts user-mode application system calls, filtering any data returned by the program that might trigger detection. As an example, security tools might monitor for new files generated in a directory so the kernel-based malware removes malicious files before returning a directory listing. This kernel rootkit can also filter and conceal registry modifications, running processes or other events generated by the attacker. In this way, kernel-based malware can be used to cover tracks and conceal threats both within the kernel and in user-mode components alike. However, knowing this is the case, if filtering code is loaded into the kernel, one can be alerted to the very high likelihood of malicious intent.

By analyzing any new code loaded into the OS kernel using full-system emulation, one can catch the kernel-based attack in the act. Whenever a critical function or memory location is hooked or modified, the analysis can assume that an attack is potentially underway. Taking a closer look, security analysts would then be able to gain insight into the behaviors of previously invisible kernel-based attackers before they quietly execute and cover up nefarious schemes from a privileged position.