June 4, 2015 By Engin Kirda 3 min read

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

X-Force Threat Intelligence Index 2024 reveals stolen credentials as top risk, with AI attacks on the horizon

4 min read - Every year, IBM X-Force analysts assess the data collected across all our security disciplines to create the IBM X-Force Threat Intelligence Index, our annual report that plots changes in the cyber threat landscape to reveal trends and help clients proactively put security measures in place. Among the many noteworthy findings in the 2024 edition of the X-Force report, three major trends stand out that we’re advising security professionals and CISOs to observe: A sharp increase in abuse of valid accounts…

Hive0051’s large scale malicious operations enabled by synchronized multi-channel DNS fluxing

12 min read - For the last year and a half, IBM X-Force has actively monitored the evolution of Hive0051’s malware capabilities. This Russian threat actor has accelerated its development efforts to support expanding operations since the onset of the Ukraine conflict. Recent analysis identified three key changes to capabilities: an improved multi-channel approach to DNS fluxing, obfuscated multi-stage scripts, and the use of fileless PowerShell variants of the Gamma malware. As of October 2023, IBM X-Force has also observed a significant increase in…

New Hive0117 phishing campaign imitates conscription summons to deliver DarkWatchman malware

8 min read - IBM X-Force uncovered a new phishing campaign likely conducted by Hive0117 delivering the fileless malware DarkWatchman, directed at individuals associated with major energy, finance, transport, and software security industries based in Russia, Kazakhstan, Latvia, and Estonia. DarkWatchman malware is capable of keylogging, collecting system information, and deploying secondary payloads. Imitating official correspondence from the Russian government in phishing emails aligns with previous Hive0117 campaigns delivering DarkWatchman malware, and shows a possible significant effort to induce a sense of urgency as…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today