Kernel-mode malware is among the most difficult to detect and remove. In this post—condensed from a SANS webcast featuring SANS analyst Jake Williams and VMRay Sr. Threat Researcher Tamas Boczan present an introduction into kernel-mode rootkits, explaining why attackers use them, how they bypass mitigations built into Windows and break down why the most traditional sandbox technologies are ill-equipped to detect them.
All About Rootkits
Jake kicks off the discussion with a brief history of kernel-mode malware and why they matter, outlining the efforts that Microsoft has undertaken to ‘kill the rootkit’, and why the majority of sandboxes are unable to effectively and consistently detect them. As Jake explains, “kernel-mode malware is something that we definitely don’t talk about enough and it’s a spot where the majority of sandboxes today have a huge blindspot.”
Jake has been at this long enough to remember teaching rootkit classes and using Direct Kernel Object Manipulation (DKOM) techniques to modify structures that track and overwrite core operating functions such as process lists and open file handles. As to why rootkits matter in the first place, Jake breaks it down by saying that rootkits “hide data from investigators by intercepting API calls, enabling them to change the behavior of our existing programs which is especially problematic for security and monitoring tools – after all what are we trying to hide from in the first place if it’s not monitoring tools?”
Jake goes on to explain that intercepting information in kernel-mode can be a double-edged sword, as while it makes it easier for malware to hide what they’re up to (i.e., hiding a process), anti-virus and endpoint protection tools also accomplish their task by being “on the lookout for these notify calls as well”.
One Hook to Rule Them All
The ability for attackers to run code in the kernel space is especially powerful as the code runs at the highest privilege level on the system. As Jake explains, if a user-mode rootkit tried to hide a malicious behavior, it would need to hook every process and hide the behavior from each. With kernel-mode rootkits, the rootkit only needs to install a single hook to get notified whenever a process would discover the malicious behavior, and hide it from all easily. Says Jake, “this is where the ‘Power, Unlimited Power’ thing comes from. It’s one hook to rule them all versus having to use lots of hooks.”
Microsoft recognizing the consequences that this type of root-level vulnerability could reap on organizations began making it more difficult to load the rootkit starting with Windows Vista and Server 2008, requiring that kernel modules be digitally signed before loading on to 64 bit systems. To further limit potential rootkit vulnerabilities, Microsoft also introduced a feature called kernel patch protection, (aka ‘patch guard’) which has raised the bar significantly in terms of detecting rootkit operations.
While these enhancements have ostensibly made it more difficult for malware authors to penetrate and modify the kernel, Jake cautions that it’s far too early to declare the death of the kernel-mode rootkit. “Surprising nobody, malware authors have quickly adapted using exploits in digitally-signed device drivers to load their kernel modules.”
Kernel-Mode Rootkits vs. Sandboxes
For the final section of his presentation, Jake looks at what all of this means for malware analysts and how they can use sandbox technologies to analyze kernel-mode rootkits in their operating environment. As Jake points out, most malware analysts employ a sandbox to triage the deluge of malware samples that are collected to filter out the interesting stuff.
Says Jake, “so what should we be deep diving on? If you’ve got something loading a kernel module in 2020 on a modern windows system, well that’s interesting and something you should be looking at.” One problem that Jake identifies in this area is the use of kernel-mode rootkits versus sandboxes.
As Jake explains, most sandboxes are based on user-mode hooking, and therefore have no visibility into what happens in the kernel, and are unable to analyze rootkits. In short, Jake sums it by saying that “most malware sandboxes just aren’t designed to deal with kernel-mode malware”. VMRay’s monitoring approach is special in this sense – since it operates in the hypervisor-layer, it monitors the system from below kernel-mode and has no problem monitoring the Windows kernel.
In the second half of the webinar, Tamas Boczan, VMRay’s Sr. Threat Researcher takes a closer technical look at how kernel-mode attacks are on Windows in the wild and how researchers can analyze these attacks faster with the help of a sandbox.
In Search of Infinite Power
Tamas begins his section of the webinar by examining the motivation of an attacker who is attempting to gain access to the kernel mode. “Basically this means that kernel mode is the one that has full access to every resource of the system and if the attacker manages to secure kernel-mode access and manages to evade detection such as the ones outlined by Jake, then they basically gain infinite power over the system itself.”
Tamas goes on to explain that this power is used to achieve two goals: the first of which is to implement the payload itself as a driver to gain lower-level access, enabling an attacker to implement some features in an easier fashion. The second and more common goal is to keep the payload in user-mode, but use kernel privileges to hide it from users of the system and from endpoint defense products. Tamas adds that the rootkit is used “to hide artifacts such as processes, files, and registry keys can be completely hidden from the user-mode by editing structures in the kernel mode.”
Analyzing ZeroCleare
After detailing why developing drivers is a challenging endeavor as well as the difficulty in executing malicious drivers, Tamas provides a detailed overview of how certain strains of malware accomplishes this using some real-world examples.
The first analysis that he offers is of ZeroCleare, a disk wiper malware that was employed in a series of targeted attacks against companies and organizations in the Middle East that surfaced in late 2019 (you can read a complete behavioral analysis of ZeroCleare which was published on the VMRay blog in January). The goal of a wiper malware is straightforward and implied in its name: to destroy the data housed on a disk and cause service disruption.
Tamas describes how ZeroCleare used three of five shortcuts that were in use by other developers. Developers misused a third-party driver instead of writing their own, bypassed digital signature enforcement with an open-source tool, and kept the kernel-mode component’s functionality restricted to actions that do not trigger Patchguard.
Drilling down into how ZeroCleare uses the Turla Driver Loader, Tamas explains that “the entire kernel mode is running on a single privilege level. So that means that any single vulnerability in a driver means that the entire kernel mode is vulnerable. So all the attacker has to do is find any vulnerability in any driver or any code running with kernel privileges and then they can gain kernel-mode access”. He goes on to explain that finding a reliable and portable unpatched vulnerability is still challenging, which is why the Turla Driver Loader introduces its own vulnerability in the kernel by installing a vulnerable driver.
Analyzing Glupteba
Tamas then follows this with an example of another malware, which uses kernel-mode rootkits: Glupteba. It includes three rootkits that are designed to hide the malware from user mode so it can deliver its malicious payload undetected. Unlike ZeroCleare, Glupteba uses the inverse of the five shortcuts. As Tamas explains, “So instead of misusing third-party drivers, it implements its own drivers but keeps these drivers very simple. And instead of bypassing digital signature enforcement, it turns off digital signature enforcement. And now it needs to care about Patchguard because it’s a classic old school rootkit which Patchguard protects against.” Tamas goes on to explain how the malware disables Patchguard with an open-source tool that modifies to bootloader.
Victory: Detection & Analysis
Tamas concludes his analysis by offering some guidance for how to best use a sandbox for detecting and analyzing kernel-mode attacks, emphasizing the importance of detecting the malware before it has a chance install new drivers, turning off digital signature enforcement, and to not trust anything after a rootkit has been installed. “So if we have successfully detected that a rootkit was installed at a certain point in time, then any data that was generated by user mode after that time is useless because it is controlled by the attacker… of course, if we are analyzing a driver, then it’s easier to do it from the hypervisor.”
To learn more about kernel-mode malware, view the full webcast:“Power! Unlimited Power! Understanding the Techniques of Kernel-Mode Code”
