Rootkits: Kernel Mode

We have learned in part one of this series about the Rootkits and how they operate in User Mode; in this part of the series we will up the ante and look at the other part where rootkits operate, i.e. Kernel Mode.

Kernel Mode Rootkit

To get familiar with this, let's say you suspect a system to be rootkit infected (only at user mode) and runs file integrity tools like Tripwire to find the User Mode rootkit. How much you can rely on the results of tripwire providing the system calls from tripwire to underlying kernel is legit i.e. imagine if the system calls from tripwire are returned from a kernel mode rootkit? Not only kernel mode is infected, but rootkits operating at user mode will be hidden. This means that attackers now do not have to modify the individual applications but instead the file supporting all of them i.e. kernel.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Before we get into how Kernel Mode rootkits operate, let's review the concept of kernel functions, where it lives and how it handles requests.

The kernel sits between individual applications and underlying Hardware. Kernel mode and user mode processes runs at different level or as they call it rings with ring 0 being the most sensitive level and user mode resides in ring 3, which is the least sensitive level. The applications that reside in ring 3 cannot directly access more secure ring i.e. kernel in ring 0. Instead, they rely on system calls which they execute using subsystem libraries like ntdll.dll, so the flow is like User Mode -> System Libraries -> System Call Table -> Kernel where system call table is used to map the code branch for each system call inside kernel.

Now as we have refreshed the concept of Kernel and system calls, let focus back onto the Kernel Mode Rootkit. To implement Kernel Mode rootkit, attacker will alter the kernel.

• Since the System Call Table is used to map the kernel code, what the attacker gets hold of in this system is the call table. The attacker can use insmod to do that, and then map malicious instructions. So the flow would be User Mode -> System Libraries -> Altered System Call Table.
• The attacker can then insert malware (methods to be discussed later) and then execute the evil kernel code. So the flow will be like: User Mode -> System Libraries -> Altered System Call Table > Evil Kernel Code.

This all looks like below

Now we need to know how this system call table can be altered and malicious kernel code can be inserted. This can be done in the following ways:

• Device drivers and Kernel Modules

  The Linux kernel is designed to load an external kernel module to support some functionality and inject code directly at kernel level. Windows device drivers work the same way. Thus, these options give a great way for attackers to inject malicious code into the kernel. Vendors like Microsoft have made this a bit tougher with the inclusion of mandatory code signing of device drivers. However, what if attacker stole the signing keys: Stuxnet worm.

• Changing Kernel File

  This technique is useful in those conditions when the above techniques are not breaking in i.e. neither the linux kernel is configured to load external modules nor the signing keys can be compromise to forge the windows device drivers. Kernel File alteration can be done either in memory or in hard disk.

  • Memory: In Linux the kernel file that holds the image of the kernel's own memory space and the live running code resides in /dev/kmem. Thus altering this will lead to kernel mode rootkit. In windows kernel in memory can be attacked using system memory map object. Note that changing these files in memory does not even require for the system reboot.
  • Hard Disk: If the kernel in memory cannot be altered, the attacker can alter the kernel file on the hard disk. In Linux the file which holds the kernel on hard disk is vmlinuz. This file can be read and write by root only so if an attacker can obtain this file can be changed. I windows also, earlier ntoskrnl.exe and win32k.sys can be altered to inject evil instructions in the kernel. Windows negate this attack by making an integrity check of the ntoskrnl.exe on every system reboot using a program called as NTLDR. However, attacker can get around this by altering the NTLDR program itself. Important points to note for changing the kernel in hard disk are:
    • For the new evil code to execute, system requires a reboot.
    • Changing the kernel file and code does not require shifting from ring 3 to ring 0. It just requires privileges of root to alter and execute.

• User Mode process in Ring 0

  Another way to alter the kernel is to write a user process and run it in kernel mode i.e. in ring 0.Once this process is running it will alter the system call table to point to the evil kernel code. However, this type of attack is very difficult to execute since it requires careful handling of the kernel memory structures.

Defense

The defensive measures are almost same as is described for the User Mode Rootkit like hardening systems implement File integrity Checker tools, implement HIPS to see the system calls made by the application etc.

Eradication

If the system is infected with a Kernel Mode rootkit then the best option are:

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

• Completely wipe and reform the drive.
• Reinstall from scratch the OS, applications etc.
• Change all the root level passwords.
• Apply all the patches.

Therefore, in this article we have learned about how can a Kernel Mode rootkit can infect the systems. Combining this article with the Part 1 of this series, reader will now have a basic understanding of how rootkits works at user mode and kernel mode.