An Overview of Rootkits

- 24 mins
Tech Cybersecurity

This summary on rootkits came from a place of curiosity and interest about cybersecurity which we hoped to share with others. We believe understanding how malwares are developed and deployed is integral not only for every software developer, but everyone using the internet today. My fellow authors and I have distilled key insights into the workings of rootkits in what we hope is an approachable format. Please enjoy.

Authors: Adrian Pikor, Kaleb Hui, Riley Zhang, and Siddhantha Bose

Abstract

A rootkit is a form of malicious software that is designed to gain unauthorized access to computer systems, conceal itself, and execute malicious code. There are various forms of rootkits affecting computers at different levels, ranging from those present in user-space to those deep in the system’s firmware. This paper offers a comprehensive examination of the capabilities of user-level, kernel-level, boot-loader, and firmware rootkits.

The paper explores the methods rootkits use to infiltrate computers, conceal themselves, and evade security measures. Additionally, it will discuss the malicious operations they perform with their unauthorized access to computer resources.

Furthermore, this paper provides strategies used to detect and remove rootkits. It outlines the methodologies and importance of defence against rootkits while discussing the challenges of identifying this form of malware in a system.

By providing insights from academic research and real-world examples, this overview aims to contribute to a deeper understanding of rootkits. Moreover, it will allow security professionals to develop more robust mechanisms to defend against threats posed by rootkits.

1. Introduction

1.1. Definition

A rootkit is a type of malware that puts a great deal of effort into concealing itself and its activities. They also aim to actively control certain key features of the infected system, the specifics of which depend on the type of rootkit. Because of the ability to mask their own presence, rootkits also generally engage in malicious activity that is more long-term than other types of malware [1]. However, rootkits are not generally malicious in isolation. They are used as tools to infiltrate a system to deliver an actual payload, such as software that carries out surveillance, keylogging, or to control the computer itself as part of a botnet. The payload is often another piece of malware, with the rootkit being used as its concealment.

1.2. Common Attack Techniques

All rootkits make some sort of attempt to gain unauthorized access to the underlying system [2]. At a minimum, successful user-level rootkits will gain root/administrative access to the system, and “lower-level” rootkits will invade the operating system kernel itself, the process responsible for booting the operating system, or even the firmware present in the system’s devices. This is generally done by the attacker exploiting a vulnerability to perform privilege escalation, but can be achieved in other ways typical of other malware types such as password cracking or phishing, and can even be introduced via a trojan horse [3]. Rootkits also often leave backdoors into the system to enable easy re-entry at a later point.

Hooking is a crucial technique that rootkit developers use to remain within a system and modify its behaviours [4]. This is where a function is called through a function pointer, which makes it appear as if the original function is being called when it is not. The wrapper function that the function pointer actually points to can technically do anything at all, but for the purposes of a rootkit developer, it would need to still call the original function to make it appear as if nothing has gone awry. This modified wrapper function can then intercept any of the original function’s inputs and outputs, which can give valuable information to the adversary all the while remaining undetected.

1.3. Common Methods of Detection and Defence

Like any other malware, there are some well-known ways to limit the possibility of infection of at least the most common types of rootkits. For one, having up-to-date anti-malware software which performs signature-based detection and behavioural-based detection will provide some standard-level of protection. Also, simply being more aware of possible phishing attempts, not downloading suspicious files by which a trojan horse (which can contain a rootkit) could enter the user’s system, and performing regular scans with security software will limit the chances of infection.

Because rootkits are particularly good at hiding and remaining hidden within a computer system, often the most effective method of removal is to perform a clean reinstallation of the whole operating system, as one cannot necessarily trust that their anti-malware software or any rootkit scanners and removers can do the job, as they can all still be affected by a rootkit operating in user-space. Another common prescription is to assume that the system’s storage devices (hard-drive/SSD) are compromised, and to remove them too.

With a preliminary survey of the rootkit literature already out there, it has been found that research focuses primarily on either one type of rootkit [5], or on novel methods of detecting them [6][7][8], or on stealth techniques specifically [9]. In contrast, this paper aims to provide a holistic overview of the definition and capabilities of rootkits as a whole, as well as investigating the specifics of different types. Some types of rootkits are much more prevalent than others, and as a result, have more studies published about them. By writing this paper, it is hoped that the awareness of less common kinds of rootkits is increased, as they are arguably even more dangerous.

1.5. Adversary Model

There are a variety of types of rootkits, generally classified according to their level of privilege, however they have similar goals. They aim to gain and maintain access to privileged resources while obscuring their presence. A capable adversary will have sufficient knowledge about the layer of the system they are trying to breach as well as those above it to exploit vulnerabilities. We also assume the rootkit will be able to obscure itself from methods of detection specific to the layer it’s working in. Further details of the specific models for each type of rootkit will be discussed throughout the paper.

2. Types of Rootkits

After discussing the various features common to all rootkits, we now move on to investigating different types of them in more detail. We will highlight the specific capabilities they have, and as a result the different ways in which they achieve intrusion, stealth, persistence, and payload delivery.

2.1. User-Level Rootkits

These rootkits have the same privileges as any other user-level application (Ring 3 in the protection ring model of operating system security). They instead rely on other methods of privilege escalation. Once they are able to get root access, they establish methods of retaining it (i.e. provide backdoors). User-level rootkits are one of the most prevalent kinds out there, because creating one requires less knowledge than their counterparts. Their relative simplicity allows malicious parties to quickly exploit new vulnerabilities before they can be patched [10]. However, this simplicity comes with some drawbacks for the adversary. Since they only operate in user-space, the actions they can perform are limited in scope. Moreover, attacks are targeted at the process level, the program has to do this for every single process it wants to attack.

2.1.1. Attack

In Windows, often the mechanism by which user-level rootkits achieve infiltration is by hooking into dynamically linked libraries (DLL’s) that are loaded into a target process, thereby spoofing it. DLL injection takes advantage of Microsoft’s API calls to [11]:

In Linux, once the program has root access it will usually overwrite commands that are used to gain access to the machine such as login, sshd, and inetd. After making the desired changes, rootkits may also attempt to obfuscate their presence, usually by changing certain commands. In Linux, this could be achieved by changing commands like ls, netstat, readdir, du, etc. Further, it may change kill or killall to prevent a user from killing the processes it has infected [13].

2.1.2. Detection and Defences

On top of the usual signature-based detection and behavioural-based detection that anti-malware software uses, we can also perform difference-based detection (e.g. RootkitRevealer in Windows [14]) in which results of lower-level system scans are compared with those of a higher level. If there is a discrepancy, it can be inferred that a user-level rootkit has interfered.

2.2. Kernel-level Rootkits

Another variation of rootkit targets the kernel, a core component of a computer’s operating system that has complete control over the computer’s resources. For this reason, an attack on the kernel can allow attackers access to high-privileged/root-level operations. Since the kernel is deeply embedded in the computer system, attackers can use these privileged operations to hide kernel-level rootkits.

2.2.1. Attack

Kernel-level rootkits are typically developed as drivers or loadable kernel modules (LKM) that will directly add or replace code being run in or by the kernel [15]. Compared to user-level rootkits, the hooks that kernel-level rootkits perform are harder to detect [16][17] because of the fact that anti-malware software is itself user-level software and it will be unaware of the rootkit’s existence. Kernel-level rootkits have evolved over the years and adopted several techniques to avoid detection and attack kernels. This type of rootkit can be injected directly into memory [18] through three common methods: system service hijacking, dynamic kernel object hooking, and direct kernel object manipulation.

System service hijacking is a method of detection avoidance through system calls. A system call is an interface provided by the kernel to the user-space to invoke when they require services or functionalities from the kernel. Within the kernel, there is a table consisting of pointers used to keep track of implemented system calls. Rootkits exploit these system call tables while other rootkits including “Knark” and “Adore” will hijack and modify the actual implementation of specific system calls [19][17]. The rootkit is able to hijack the system call service: rootkits will access memory, find the location of the table, and redirect a pointer from an existing system call implementation to the rootkit’s payload. When the specific system call is invoked, it will instead run malicious operations implemented by the rootkit. After the payload has been executed, it will invoke the original system call to decrease the chances of detection.

Kernel-level rootkits can also infiltrate the kernel through object hooking and manipulation. Kernels use virtual file systems to manage files and abstract data. Through object hooking, rootkits can modify file and inode data structures. These structures contain function pointers that also point to operations added by the rootkit. By modifying and removing references to the rootkit’s operations, it becomes harder to detect [21]. Object manipulation also involves altering these data structures. The kernel hosts a separate structure to track all processes. By unlinking specific processes from these data structures, the processes running the rootkit’s payload become invisible to both user mode and kernel [17].

Furthermore, kernel-level rootkits employ anti-analysis techniques. Many malicious packages can obfuscate, pack, or encrypt themselves to conceal their data and unencrypt when deploying malicious payloads later on. In some cases, kernel-level rootkits can detect whether they are inside a virtual machine through sensing memory isolation and avoid performing any malicious operations to prevent being detected [16].

2.2.2. Detection and Defences

Preventing rootkits from reaching the kernel is possible by disabling LKMs or only allowing signed kernel drivers [15]. This greatly reduces untrusted code from reaching the kernel, though rootkits can still be injected directly into a system’s memory, in which case the rootkit will need to be detected and removed through other means.

Due to the complexity of a modern operating system kernel, they are generally very sensitive to changes. Hence, kernel-level rootkits can create system instability if not properly engineered [15]. Any detected anomalies in the system often lead to the rootkit being discovered. Moreover, artificial intelligence models and memory forensic techniques have also been used to detect kernel-level rootkits. Models have been created using datasets containing the behaviour of these rootkits [16][17]. These datasets are compiled by observing the various features of a kernel including system calls, drivers, memory traces, and register usage. Memory forensic techniques such as volatility analysis will scan and analyze kernel memory to detect irregularities or hidden processes caused by rootkits [17].

Kernel-level rootkits can be removed by manually identifying and mapping the hooks and functions affected, and then removing these associated files [22]. However, it turns out that the most efficient and effective way of removal is to perform a clean installation of the operating system [23].

2.3. Bootloader Rootkits

Bootloader rootkits, also known as “bootkits”, are a subtype of kernel-level rootkit that is one of the oldest forms of malware, first used in the 1980s to modify code on floppy disk drives. Nowadays, BIOS bootkits insert malicious code into a computer’s startup code located in the Master Boot Record (MBR) [24]. The MBR is the first sector in a hard drive that initializes the bootup process, and is always the first bit of code run when a computer boots. It is important to note that this code runs before the operating system is even initialised. As a result, a bootkit can “replace” a computer’s bootloader and implement attacks before the operating system even loads. This unique form of attack allows bootkits to circumvent many traditional security features like firewalls and encryption.

2.3.1. Attack

All bootkits are very similar in their execution, being replacements for the MBR to allow an attacker root access to the infected computer. “Stoned Bootkit” is an open source bootkit developed for scientific and research purposes [25]. It consists of a modified MBR and additional plugins and applications accessible from the Windows file system.

For a Windows XP system, the Stoned MBR will place itself at the end of real mode memory, then hooks key boot components in this order: the 13H interrupt call to point to the MBR address location, the Windows bootloader to bypass code integrity verification, OSLOADER to find the size and location of the kernel image, then finally the kernel image itself to call the edited kernel code at startup. To summarize this process, Stoned inserts its own code into multiple locations in memory, then modifies startup functions to point toward the new code. Most Windows XP/Vista/7 bootkits operate in this way, with slight variations. Once Stoned is installed, the user can now run unsigned drivers and boot applications that were previously prevented by Windows Vista’s signed driver policy. Stoned comes with Sinowal, a trojan that steals banking and credit card information, but there are many different pieces of malware that can now be easily run through Stoned. Most bootkits are now obsolete (refer to 2.3.3). However, a recently discovered bootkit called BlackLotus has managed to bypass Secure Boot [26]. It does this by exploiting the vulnerability CVE-2022-21894, called “Baton Drop” [27]. This vulnerability allows a boot setting truncatememory to remove the Secure Boot policy from the memory map of the boot process. BlackLotus disables Hypervisor-Protected Code Integrity (HVCI) and Bitlocker, loads its own boot configuration data with certain options selected, and then enrolls its own signing key with the bootloader to bypass future signature checks.

2.3.2. Detection and Defences

Bootloader rootkits have fallen out of favour in recent times due to the many strategies against them. Most modern anti-viruses can scan the MBR which overcomes the main advantage bootkits have to avoid detection. The main reason bootkits are rare nowadays is due to Secure Boot, a feature first supported by Windows 8 which checks for a digital signature only present in trusted software. This is made possible by the UEFI technology standard, which defines an interface to what are known as boot services and runtime services. The former are only available during the booting stage, while the latter are available both during booting and operating system runtime [28].

Once a computer is infected with a bootkit, it’s very difficult to identify it (unless it purposely reveals its presence). However, there are several clues that a computer has been infected. First, one can check if new boot files have been added recently, as it suggests that they have been tampered with [29]. A user can also check for modified registry keys, as many bootkits edit the registry to hide their presence or disable security. For example, BlackLotus sets the Enabled flag of the registry key HypervisorEnforcedCodeIntegrity to 0, which disables HVCI. One more detection opportunity is to look for custom directories that have been secretly made by the bootkit. Both Stoned and BlackLotus create their own directories in /system32/ that remain after the bootkit takes hold. The last solution to remove a bootkit is to reinstall the operating system and reformatting of hard drives, which should reliably remove all traces of a bootkit [30]. However, this solution will not defend against the final type of rootkit we will cover.

2.4. Firmware Rootkits

Firmware rootkits are even more deeply embedded than bootloader rootkits, often residing at the level of the computer’s motherboard firmware, which is responsible for setting up the environment that the entire booting process runs in. These types of rootkits can even exist in places such as the hard-drive/SSD, network card, and even within devices completely external to the computer system, such as routers [31]. Due to their location, firmware rootkits are some of the most difficult to detect. Depending on the type of device that is being targeted, the memory where these rootkits are installed may not be visible from the operating system, thus requiring manual inspection at worst. Also, because rootkits in user-space and kernel-space are significantly more common, security efforts are generally allocated towards the detection and removal of these types rather than those in firmware.

2.4.1. Attack

The deployment of firmware rootkits is usually more complex than that of “higher-level” rootkits, as the malware developer must have a deep, low-level understanding of the system and its constituent components, and it must somehow get the rootkit into the firmware image of a device in the first place. As a result, however, this makes firmware rootkits one of the most dangerous types, as a successfully engineered and deployed implementation can be devastating because of what it has access to.

A prominent example that made headlines in the security community is the dubbed “CosmicStrand” UEFI firmware rootkit, an early variant of which was discovered in 2017 [32]. It infected the UEFI firmware present on certain motherboards, which means that this rootkit runs even before the OS bootloader has started running. In particular, the CosmicStrand rootkit was found to infect ASUS and Gigabyte motherboards using the H81 chipset, which suggests a common vulnerability present on all of them. It is also possible that these motherboards had been infected physically in an “evil maid attack”, whereby a person physically compromises the device by installing the malicious firmware image manually. An earlier report on this rootkit performed by Qihoo360 [33] suggested the possibility of third-party resellers of these types of motherboards introducing a backdoor into their firmware, enabling the entrance of the rootkit.

The rootkit begins its attack immediately upon start-up of the UEFI execution context, where a variety of boot services can be called. One of those functions is HandleProtocol, the details of which are not important. By this point, the firmware is already compromised by the rootkit which has infected a particular driver called CSMCORE. The infected version of this driver sets up a hook into the HandleProtocol function. The redirected function first calls the normal implementation of this function (original_HandleProtocol) in order to mask the subsequent behaviour, which then checks the return address and a specific argument to the call to attempt to determine what had called it. If it finds that the caller is what it needs, it launches further malicious processing via the HandleProtocol_hook_logic function. This hook logic call then finds the information necessary to carry out the next hook at a particular point in the UEFI execution, where the boot manager has just been loaded but is not yet running. At this point, the rootkit is able to modify the boot manager to further conceal its existence and to allow it to persist.

The rootkit continues this process all the way until the operating system has fully booted, whereby it is finally able to launch kernel-injected shellcode that contacts a remote command-and-control server to retrieve the actual payload.

2.4.2. Detection and Defences

Compared to other rootkit types, firmware rootkits can be the most difficult to deal with once detected, as the typical remedies do not work due to their depth in the system. Depending on the level of concealment achieved by the rootkit, there may be very little trace of its existence evident in user-space or in the kernel. Generally, this type of rootkit can only be detected through analysis of side-channels, such as network traffic into and out of the system, timing of CPU instructions, memory access patterns, and so on [34]. Defence against these types of rootkits generally amounts to the same advice discussed in section 1.3. Some things that can be done to avoid firmware rootkit infection were already mentioned in section 2.4.2 - maintain physical security of the system, and avoid purchasing computer products from untrusted sources.

3. Conclusion

Rootkits present many challenges in the cybersecurity space due to their diverse methods of infiltration, concealment, and persistence. Many of the rootkits mentioned in this paper can be bought or downloaded online and used by anyone, even with little real knowledge about how they work. It is also becoming increasingly difficult for cybersecurity analysts to catch and neutralize new types of rootkits being actively developed. As research suggests, the lower the level at which rootkits operate, the harder they are to detect due to the amount of privileges they have within the system. In order to detect and remove them, various techniques are employed ranging from using anti-malware to completely reinstalling the OS of a computer in response to deeply-embedded rootkits.

In Appendix A, we compiled a table of the many capabilities, similarities, and differences between all four types of rootkits covered in this paper. Although rootkits will not be a source of any large-scale cyber attack in the near future, it is important to realize their effectiveness and to keep up with rootkit development. By creating robust code, enhancing detection capabilities, and continuously developing new strategies to remove rootkits, computer systems and their data can be more secure from the threats of rootkits.

4. References

[1] P. C. van Oorschot. Computer Security and the Internet: Tools and Jewels from Malware to Bitcoin, 2nd ed. Ottawa, Canada: Springer Nature Switzerland AG, 2021. [2] MalwareBytes Inc. Rootkit [Online]. Available: https://www.malwarebytes.com/rootkit [3] Microsoft Corporation, “Understanding Anti-malware Technologies,” [Online]. Available: https://web.archive.org/web/20100911033147/http://download.microsoft.com/download/a/b/e/abefdf1c-96bd-40d6-a138-e320b6b25bd3/understandingantimalwaretechnologies.pdf [4] NetSPI LLC. (2013, Jul. 8). Function Hooking Part I: Hooking Shared Library Function Calls in Linux [Online]. Available: https://www.netspi.com/blog/technical/network-penetration-testing/function-hooking-part-i-hooking-shared-library-function-calls-in-linux/ [5] M. Nadim, W. Lee, D. Akopian. (2023, April). “Kernel-level Rootkit Detection, Prevention and Behavior Profiling: A Taxonomy and Survey”. arXiv [Online]. Available: https://arxiv.org/abs/2304.00473 [6] J. Joy, A. John, J. Joy. (2011). “Rootkit Detection Mechanism: A Survey”. DOI: 10.1007/978-3-642-24037-9_36. [7] A. Kakareka, “Detecting System Intrusions” in Network and System Security, edition 2, J. R. Vacca, Elsevier Inc., 2014, pp. 1-27. [8] M. Nadim, D. Akopian and W. Lee, “A Review on Learning-based Detection Approaches of the Kernel-level Rootkit,” 2021 International Conference on Engineering and Emerging Technologies (ICEET), Istanbul, Turkey, 2021, pp. 1-6, DOI: 10.1109/ICEET53442.2021.9659710. [9] Sahu, Aniket et al. “A Survey on Rootkit Techniques.” (2021). [10] Positive Technologies, “Rootkits: Evolution and detection methods,” ptsecurity.com, https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/ (accessed Nov. 23, 2023). [11] “Rootkits: User mode,” Infosec, https://resources.infosecinstitute.com/topics/general-security/rootkits-user-mode-kernel-mode-part-1/ (accessed Nov. 23, 2023). [12] “DLL injection,” DLL Injection - Red Team Notes, https://www.ired.team/offensive-security/code-injection-process-injection/dll-injection (accessed Nov. 23, 2023). [13] J. Hannel, “Linux RootKits For Beginners – From Prevention to Removal.” GIAC Security Essentials Certification, Jan. 23, 2003 [14] M. Russinovich, “Rootkitrevealer - Sysinternals,” RootkitRevealer - Sysinternals | Microsoft Learn, https://learn.microsoft.com/en-us/sysinternals/downloads/rootkit-revealer (accessed Nov. 23, 2023). [15] A. Kakareka, “Chapter 1 - Detecting System Intrusions,” in Network and System Security, Second Edition, J. Vacca, Ed. Syngress, 2014, pp. 1-27. [16] M. Nadim, D. Akopian and W. Lee, “A Review on Learning-based Detection Approaches of the Kernel-level Rootkit,” 2021 International Conference on Engineering and Emerging Technologies (ICEET), Istanbul, Turkey, 2021, pp. 1-6, doi: 10.1109/ICEET53442.2021.9659710. [17] M. Nadim, W. Lee, D. Akopian, “Characteristic Features of the Kernel-level Rootkit for Learning-based Detection Model Training” in Proc. IS&T Int’l. Symp. on Electronic Imaging: Mobile Devices and Multimedia: Technologies, Algorithms & Applications, 2021, pp 34-1 - 34-6, https://doi.org/10.2352/ISSN.2470-1173.2021.3.MOBMU-034 [18] A. Lineberry, “Malicious Code Injection via /dev/mem”, Mar 2009. [19] D. Zovi, “Kernel Rootkits”, Jul 2001. [20] M. Hodges (2019). Linux Rootkit [Online]. Available: https://github.com/rootfoo/rootkit (Accessed Oct. 22, 2023) [21] Jakobsson, M. and R. Zulfikar, Eds. 2008. Crimeware: Understanding New Attacks and Defenses, Upper Saddle River: Addison-Wesley Professional, 2008 [22] SANS Institute. Rootkits Investigation Procedures [Online]. Available: https://www.sans.org/media/score/checklists/rootkits-investigation-procedures.pdf (Accessed Nov. 20, 2023) [23] Lynn Erla Beegle. (2007). “Rootkits and Their Effects on Information Security, Information Systems Security”. Vol. 16, issue 3, pp. 164-176, doi: 10.1080/10658980701402049 [24] X. Li, Y. Wen, M. H. Huang and Q. Liu, “An Overview of Bootkit Attacking Approaches,” in 2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks, Beijing, China, 2011, pp. 428-431, doi: 10.1109/MSN.2011.19. [25] P. Kleissner. “Stoned bootkit”, in Black Hat USA 2009, Las Vegas, USA, 2009. [26] M. Smolár. (2023, Mar. 01). BlackLotus UEFI bootkit: Myth confirmed [Online]. Available: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/ [27] Rairii. (2023, May 09). baton drop (CVE-2022-21894): Secure Boot Security Feature Bypass Vulnerability [Online]. Available: https://github.com/Wack0/CVE-2022-21894 [28] UEFI Forum, Inc. (2021). Services - Boot Services. [Online]. Available: https://uefi.org/specs/UEFI/2.9_A/07_Services_Boot_Services.html [29] Microsoft Corporation. (2023, Apr. 11). Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign [Online]. Available: https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/ [30] Positive Technologies. (2022, Aug. 03). Bootkits: evolution and detection methods [Online]. Available: https://www.ptsecurity.com/ww-en/analytics/bootkits-evolution-and-methods-of-detection/ [31] Kaspersky Lab. What is Rootkit – Definition and Explanation [Online]. Available: https://www.kaspersky.com/resource-center/definitions/what-is-rootkit [32] Kaspersky Lab. (2022, Jul. 5). CosmicStrand: the discovery of a sophisticated UEFI firmware rootkit [Online]. Available: https://securelist.com/cosmicstrand-uefi-firmware-rootkit/106973/ [33] Qihoo 360. (2017, May 3). Spy Tracker: Analysis of the world’s first UEFI motherboard BIOS Trojan [Online]. Available: https://bbs.360.cn/thread-14959110-1-1.html [34] Positive Technologies. (2021, Nov. 3). Rootkits: evolution and detection methods [Online]. Available: https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/

Related Posts

Siddhantha Bose

Siddhantha Bose

Living, learning, and meeting people along the way

comments powered by Disqus