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.

More from Malware

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

RansomExx Upgrades to Rust

IBM Security X-Force Threat Researchers have discovered a new variant of the RansomExx ransomware that has been rewritten in the Rust programming language, joining a growing trend of ransomware developers switching to the language. Malware written in Rust often benefits from lower AV detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language. For example, the sample analyzed in this report was not detected as malicious in the…

Raspberry Robin and Dridex: Two Birds of a Feather

IBM Security Managed Detection and Response (MDR) observations coupled with IBM Security X-Force malware research sheds additional light on the mysterious objectives of the operators behind the Raspberry Robin worm. Based on a comparative analysis between a downloaded Raspberry Robin DLL and a Dridex malware loader, the results show that they are similar in structure and functionality. Thus, IBM Security research draws another link between the Raspberry Robin infections and the Russia-based cybercriminal group 'Evil Corp,' which is the same…