REVISITING A PRIOR ISSUE
by DRP; Cybersecurity Lab Engineer
In season 1 of Mr. Robot, the much-exalted series, one of the female lead actors asks innocently during one of the conversations “What is a rootkit?” (eps1.0_hellofriend.mov, ~ 32-minute mark). Although this is known and appreciated in various levels, not all have been exposed to this issue.
The attacks used have various levels of complexity with the implementation. These range from the simple phishing attack with an embedded link to the malicious site to the more sophisticated, complex attacks involving multiple steps, access to hardware or other steps which normally could be carried out only by someone with significantly more experience. This form is not the easiest, however, would be seated in the middle portion of the spectrum, as averaged across the OS spectrum.
As difficult it is to perpetuate, this may be more difficult to detect by the non-IT personnel. Generally, the users will have a vendor’s AV package, update it regularly, and run a scan periodically. As these have the full faith and credit placed in them by the users, these may be missing the rootkits, if present on the system. These have tended to be difficult to detect for many reasons. The primary issue has been these are active prior to the system’s OS booting. This allows the rootkit to customize certain aspects to make it recognizable as an authorized part of the system and to avoid being noticed, or other attributes. This coding and functionality allow the rootkit to be hidden so the user is inclined to believe the system has not been breached.
The broad, general definition is a software tool that is placed on the target system to allow the attacker access in some form at a later date. Due to their function, these are not coded to propagate on their own. To code, these also require a certain level of expertise. The person trying to code for this would need to do more than watching a few YouTube videos or visit two or three DIY websites. Coding an effective rootkit requires time. There are many uses for these. The coder may create and deliver to the target a rootkit to accumulate data from the user’s computer(s) and the user’s accessing the system. This data could then be exfiltrated and later sold on the dark web or used by the attackers themselves. Depending on the data, this could provide the affected users with years of headaches. This could also cause the system(s) to malfunction or BSOD. For the enterprising attacker, this could be used to originate spam, as it is send across the globe. This allows the attacker root access to the system. This is particularly useful over the long- and short-term.
Methods of Infection
As with many of the other malware infection and attack vectors, there are a number of ways the user may infect their system. The user could be fortunate enough to receive malware with the rootkit present and download it. This may be provided to the user with the usual email attachment, that has been used with so many other malware examples. The user while perusing through the internet and open a malicious site and inadvertently infect their system. These are a few examples, which could be mitigated with user training and awareness.
The varied functionality has driven the number of rootkit types. Each type is used for the different types of targets. These may be application level, kernel level, or generally BIOS level kits. The ones mostly used at this point are the application and kernel level rootkits. With the application level rootkits, the executable files may be replaced with unauthorized files. With the kernel level rootkits, the attacker modifies the code or puts alternative code in place of the authorized code. With the Linux systems, this may be done with loadable kernel modules.
The BIOS level rootkit is more advanced than the prior two methodologies. This is widely used, due to its increased functionalities. This is however more difficult to install. As these are saved onto a memory chip, the rootkit is more difficult to remove.
Over the years, there have been many different samples of the rootkit to become known in the industry. With such significant functionality, it is natural for this to be well-used with the different industries. This was the first rootkit was coded in 1990 by Lane Davis and Steven Dake, targeting the UNIX OS. One of the first malicious rootkits was the NTRootkit, targeting Windows systems. The Mac platform was not left alone. The first Mac OS X rootkit was noted in 2009. This was coded to originate hidden system calls and kernel threads.
As a rule of thumb, the rootkit is generally coded by the attackers for a malicious purpose. This has been repeated for years with other malware also. The attackers are not going to code this for something to do. Curiously one of the highest profile instances was with a corporation coding this for one of their products sold to consumers. This was intended to infect their clients starting in 2005 with the Sony BMG copy protection issue. Sony BMG happened to include a rootkit on their CDs which unbeknownst tot he user was engineered to limit the user’s access to the CD. This was rather significant and placed an unwanted spotlight directly on Sony for a long time. Other well-known examples have been the t0rnkit in 2000, Zeus, Stuxnet, and Flame in 2002.
Although difficult to detect, this is not impossible and merely takes a bit more effort and time. The user or IT staff member tasked to assist the user may use an OS that is trusted and not infected for the search, use behavior-based detection methods, scanning the system for the rootkits signature (if known), and analyzing a memory dump of the suspected systems.
Once found, the usual next step is to remove the issue. As easy as this appears, the process itself is much more complicated, and in certain cases impossible, as the rootkit is placed in the kernel. The user may have the pleasure of reinstalling their system’s OS.
Although rootkits have the potential to give the IT Department a rather powerful and extensive headache, there are training topics, much like the ones for other malware, that are available to increase awareness and mitigate the potential for infection, and hours of clean-up.
About the Author
DRP began coding in the 1980’s. Presently DRP is a Cybersecurity Lab Engineer at a Tier One supplier to the automobile industry. DRP is presently completing the PhD (Information Assurance and Security) with completing the dissertation. DRP’s interests include cryptography, SCADA, and securing communication channels. He has presented at regional InfoSec conferences.