What is a rootkit?
A rootkit is a suite of software designed to grant a cyberattacker privileged access while disguising the invasion to evade detection. The word “rootkit” derives from “root,” the most privileged account in Unix and Linux operating systems and “kit,” the software used to gain unauthorized root-level access. Though rootkits are mainly malicious, they also have legitimate uses. Red-teaming operations, removal of stolen data, and covert threat or suspicious activity monitoring are some legitimate use cases for rootkits.
So how does a rootkit attack work? A hacker deploys rootkit software that contains a dropper, the rootkit itself, and a loader. The rootkit is typically attached to or presented as legitimate software or hidden in a document (e.g., a PDF or RTF). Other common rootkit attack vectors are untrusted websites and software, phishing emails, outdated software, compromised servers, and backdoors.
Once unsuspecting users install the “trusted software,” click on the phishing link, or open the malicious document, the dropper and loader install the rootkit automatically. Alternatively, the compromised software grants the hacker access to install the rootkit themselves.
Rootkit infection grants malicious actors remote root-level access: access to and control over virtually every part of the OS while effectively concealing malware payloads, starting from installation and spanning through the entire lifespan of the rootkit in the target system.
The goal of a rootkit attack is usually to compromise or modify data, hardware, firmware, ports, virtual machines, system configurations, codebases, and other OS components. With uncontrolled access to these resources, hackers can steal or expose personal and financial information, ransom systems, inject other malware, eavesdrop on conversations, engineer DDoS attacks, and more. Stuxnet, Flame, and Machiavelli are prominent examples of rootkit attacks.
Types of rootkit attacks
Rootkits are classified by the system components they infect. Where a rootkit strikes typically determines how much access hackers have, how much damage they can do to infected systems, and how easy it is to detect and halt the attacks. Let’s look at six common rootkit types and the level of access they allow:
Kernel-mode rootkit
One of the most dangerous types of rootkit, kernel mode rootkits are also (thankfully) difficult to build. However, once deployed, they are hard to detect.
Runs with ring 0 privileges; targets the OS at the kernel level
Exploits loadable kernel modules (LKMs) or device drivers to distort or delete the entire OS codeModifies system calls (syscalls), syscall handlers, and syscall instructions to interrupt communication and increase memory consumption
Examples: Spicy Hot Pot, Adore, Zero Access, Knark, FudModule, and Da IOS
Firmware rootkit
Firmware rootkits are usually embedded in unified extensible firmware interfaces (UEFIs) and load right before the system boots up.
Targets the serial peripheral interface (SPI) flash, basic input/output systems (BIOS, which directs systems’ booting operations), firmware images, and other related firmware
May go undetected because firmware code is rarely scanned for integrity
Examples: LoJax, MoonBounce, and MosaicRegressor
Hardware rootkit
Hardware rootkits are firmware-based rootkits that are embedded on the hard disk to install other malware (e.g., keyloggers).
Typically found on the EFI system partition level (ESP level) or in routers, hard drives, CPUs, or GPUs
Can be easily expunged by reformatting the hard drive, unlike SPI-level firmware rootkits, which usually survive hard disk formatting and restarts
Examples: FinSpy, Cloaker, and VGA
Virtual rootkit/Virtual machine–based rootkit (VMBR)
VMBRs are a ring-1 rootkit, like hardware and firmware rootkits.
Infects virtual machines (VMs), which run multiple OSes on a single host
Loads under the host OS kernel, impersonates it, puts it and its components in a newly created VM, then boots up the OS to perform malicious activities (e.g., intercepting hardware-to-host OS communication)
Difficult to detect
Examples: CloudSkulk and BluePill
Bootkit/Bootloader rootkit
This type of rootkit boots up alongside a machine’s OS by attaching to the master boot record (MBR), which loads the machine’s OS, or the volume boot record (VBR), which initiates the boot process.
Hacks the MBR in order to compromise the boot process
Remains in control of the machine after booting, attacks full disk encryption systems, and acquires kernel-level control
Examples: ESPecter, Stoned Bootkit, and Rovnix
User-mode/Application rootkit
A user-mode/application rootkit attaches to popular apps and programming interfaces.
Secures unauthorized access, intercepts syscalls, and disrupts kernel functions
Easy to detect with rootkit scanners or strong antivirus because it runs in ring 3 and tampers with app behavior
Examples: Hacker Defender, r77, and Aphex
Memory rootkit
A memory rootkit runs in the RAM.
Consumes compromised system’s resources and impedes memory performance
Easy to detect and eliminate
Detecting and preventing rootkits
Detection mechanisms
Because rootkits vary in terms of the system components they affect and their level of sophistication, there’s no one-size-fits-all rootkit detection mechanism or software. Let’s look at the specific use cases for each type of detection mechanism:
| Detection Mechanism | Description |
|---|---|
| Signature-based detection | Uses static-signature repositories containing known rootkits to scan syscall tables, file directories, firmware, and other system components for rootkit presence. For example, kernel-mode rootkits embedded through the LKM can be detected using a module static analysis. May not be very effective for zero-day attacks since it utilizes knowledge of known rootkits only. |
| Behavior-based detection | Uses common rootkit patterns to investigate abnormal or unauthorized behavior that are indicative of malicious presence on a system, such as using rule-based invariants to detect behavioral deviations. |
| Learning-based detection | Automates detection with machine learning; an algorithm processes behavior and communication patterns of malicious and benign apps for early detection of known and unknown rootkits. |
| Cross view–based detection | Compares two different views of a system: system state and system utilities views. Discrepancies may signal rootkit presence. |
| Integrity check | Utilizes pre-calculated hash functions to compare system files for unauthorized code alteration. |
Adapting best practices to prevent rootkit attacks for cloud environments requires a nuanced approach, given the shared responsibility model in cloud computing. The cloud provider is responsible for securing the infrastructure, while customers are responsible for securing their data and applications. Here's how the best practices can be specifically tailored to cloud environments:
Prevention in Cloud Environments
Consistent Software Updates and Patch Management: Utilize cloud services for automatic software updates and patch management to keep operating systems, applications, and cloud infrastructure components up-to-date.
Cloud-Native Security Tools: Leverage cloud provider's native security tools and services that offer antivirus and anti-malware capabilities, ensuring they're configured for automatic updates and regular scans.
Identity and Access Management (IAM):
Utilize the cloud provider’s IAM services to manage access to cloud resources securely.
Implement principle of least privilege for all cloud accounts and services.
Employ multifactor authentication for accessing cloud environments.
Secure Configuration and Hardening:
Follow cloud provider’s best practices for securing and hardening cloud environments.
Disable unnecessary services and APIs.
Use security groups and network ACLs to control inbound and outbound traffic.
Encryption and Secure Data Storage: Use encryption for data at rest and in transit. Ensure that cloud storage services are configured with appropriate access controls.
Implement Cloud Security Posture Management (CSPM): Use CSPM tools to automatically detect and remediate misconfigurations and non-compliance with security policies.
Detection in Cloud Environments
Cloud Monitoring and Logging:
Enable cloud provider’s logging and monitoring services (e.g., AWS CloudTrail, Azure Monitor, Google Cloud Operations Suite) to detect unusual activities that could indicate a rootkit.
Implement a centralized logging solution for better visibility across cloud and on-premises environments.
Anomaly Detection:
Utilize cloud-based intrusion detection and prevention systems that offer anomaly detection capabilities.
Leverage machine learning and AI-driven security solutions provided by cloud services to detect unusual behavior patterns.
File Integrity Monitoring (FIM): Use FIM solutions that are compatible with cloud environments to monitor changes to critical files and configurations.
Network Traffic Analysis: Employ cloud-native or third-party network traffic analysis tools to monitor for suspicious network activities indicative of rootkit communication.
Response in Cloud Environments
Cloud-Specific Incident Response Plan: Adapt your incident response plan to include cloud-specific processes and procedures, leveraging cloud provider tools for isolation and mitigation.
Snapshot and Backup: Regularly create snapshots and backups of cloud workloads and data. In case of a rootkit infection, these can be used to restore to a known good state.
Automate Response Actions: Utilize cloud services to automate response actions such as isolating infected instances, revoking access, and deploying clean instances.
Post-Incident Cloud Forensics: Take advantage of cloud-native forensic tools and capabilities to analyze rootkit attacks, maintaining chain of custody and leveraging cloud logs for investigation.
Implementing these practices requires understanding the specific features and services offered by your cloud provider, as well as staying informed about the latest cloud security trends and threats. Collaboration with the cloud provider and continuous security assessments are key to protecting cloud environments from rootkit and other sophisticated attacks.
Preventing rootkit attacks with Wiz
Wiz CNAPP provides a comprehensive security solution that can assist in detecting and preventing rootkit attacks through various methods:
Runtime Analysis: Wiz can analyze running processes and loaded libraries within your cloud environment. This can help detect anomalies that might indicate a rootkit hiding processes or modifying system behavior through techniques like Dynamic linker hijacking.
Drift Detection: For containerized workloads, Wiz can detect changes in loaded libraries after the initial deployment. This helps identify if a rootkit has been injected into the container and altered its runtime behavior.
File Integrity Monitoring: Wiz can monitor the integrity of system files. Rootkits often tamper with system files to achieve persistence or hide their activity. By comparing file hashes to a known good baseline, Wiz can identify such modifications.
Cloud Workload Protection Platform (CWPP) Features: As a CWPP solution, Wiz offers advanced threat detection capabilities that can unearth hidden activities. This includes looking for suspicious system calls, network connections, and process behavior that might indicate a rootkit at work.
Wiz’s CNAPP helps you assess security risks (such as out-of-date software, misconfigurations, and anomalies) across all cloud workloads, libraries. and dependencies. Get a free demo of Wiz’s all-in-one cloud security solution today to see how we can help you secure everything you build and run in the cloud.
A single platform for everything cloud security
Learn why CISOs at the fastest growing companies choose Wiz to help secure their cloud environments.
