What Is a Rootkit?

A rootkit is a stealthy type of malicious software designed to hide its presence and maintain privileged access on a compromised system. It manipulates core operating system components to evade detection, enabling persistent control, data exfiltration, or staging of further attacks. Rootkits often support advanced threats by disabling logging, hiding files, and masking network activity.

Rootkit Classification and Technical Definition

Rootkit is not a standalone threat vector, as it isn’t used to initiate a cyber attack. On the contrary, it’s a type of post-exploitation malware designed to provide long-term, stealthy access to a compromised system. Attackers use a rootkit to support persistence, privilege escalation, and surveillance. Rootkits manipulate core components of the operating system — such as kernel modules, bootloaders, or firmware — to hide files, processes, and network connections from traditional detection tools.

In the MITRE ATT&CK framework, rootkit activity aligns with techniques like T1542.003 (Bootkit) and T1014 (Rootkit) under the Defense Evasion tactic. Rootkits often serve as a support layer for techniques like T1055 (Process Injection) or T1053 (Scheduled Task/Job) to maintain persistence.

Related Terminology

Synonymous or related terms include bootkit, kernel-mode malware, firmware implant, and hypervisor rootkit. While sometimes used interchangeably, these terms represent variants based on where the rootkit resides: user space, kernel space, boot sector, or hardware abstraction layers.

Evolution of Rootkits

The earliest rootkits emerged in Unix environments during the early 1990s, focused on modifying system binaries like ps and netstat to mask malicious activity. As detection techniques improved, rootkits evolved to intercept system calls directly within the kernel. More recent forms include UEFI rootkits that survive OS reinstalls and cloud-native rootkits that target container orchestration layers.

In the modern cloud and hybrid infrastructure landscape, rootkits now extend to container runtime layers, virtual machines, and serverless function monitors. They're harder to detect due to the shift toward ephemeral workloads and distributed microservices architecture, where traditional endpoint defenses lose visibility.

Types of Rootkits

Rootkits span a hierarchy of control, from user-mode code injection to hypervisor-level subversion. Each type offers a unique blend of stealth, complexity, and persistence, depending on the attacker’s access level and operational goals.

User-Mode Rootkits

User-mode rootkits operate within standard process space and hook system APIs, often by replacing dynamic link libraries (DLLs) or injecting malicious code into legitimate services. These rootkits modify behaviors like file enumeration or process listing, allowing attackers to conceal malware without altering the OS kernel. They’re easier to deploy but more detectable by EDR tools.

Kernel-Mode Rootkits

Kernel rootkits hook or patch system calls at the OS kernel level, offering attackers unrestricted access to hardware, drivers, and security controls. By modifying kernel modules, they can hide files, sockets, and processes from both users and defensive software. They require elevated privileges to install and are more stable on Unix-like systems than on Windows due to tighter driver verification.

Bootkits

Bootkits infect the bootloader (e.g., GRUB, Windows Boot Manager) to compromise the OS at startup. They execute before the OS kernel loads, allowing them to install additional payloads or patch kernel memory dynamically. Bootkits survive OS reinstallations unless firmware is rewritten or disks are wiped clean.

Firmware Rootkits

Firmware rootkits infect components like BIOS, UEFI, or even embedded device firmware (NICs, drives, etc.). Because they reside outside the OS, they’re invisible to endpoint agents and persist across reboots and full disk replacements. Recovery often requires hardware reflashing. Some advanced UEFI rootkits have been linked to state-backed espionage groups.

Hypervisor Rootkits (Virtual Machine-Based Rootkits)

Hypervisor rootkits, such as SubVirt or Blue Pill, exploit hardware virtualization to run the target OS inside a virtualized layer controlled by the attacker. The host OS appears normal, but all activity is monitored and modifiable by the rootkit. These are extremely stealthy and difficult to detect from inside the guest.

Library Rootkits

Library rootkits replace or hijack shared system libraries to alter program behavior. They may tamper with libc (on Linux) or Windows system DLLs to filter outputs, mask files, or redirect syscalls. They’re usually easier to detect via integrity checking but often evade real-time monitoring.

Cloud and Container Rootkits

In cloud-native environments, attackers may embed user-mode rootkit functions into containerized apps, sidecars, or shared images. Some rootkits use Kubernetes daemonsets or tampered init containers to achieve persistence across pods. They may exploit permissive IAM roles to evade security boundaries and obfuscate mining, data exfiltration, or lateral movement.

Firmware-Level Persistence Frameworks

Toolkits like LoJax or MoonBounce represent advanced rootkit deployments that persist in the UEFI/BIOS, load early-stage payloads, and reestablish malware even after OS remediation. These frameworks often include encrypted payloads, obfuscation layers, and C2 resilience.

Each rootkit type represents a step further from visibility and control, shifting detection efforts from endpoint processes toward firmware integrity, boot-chain validation, and hypervisor-level telemetry. Effective defense requires a combination of endpoint monitoring, boot-time integrity checks, hardware attestation, and supply chain validation.

Rootkit Installation and Execution Flow

Rootkits require an initial compromise to gain execution privileges, typically through phishing, software vulnerabilities, or privilege escalation exploits. Once the attacker obtains access, they deploy the rootkit to embed persistent, stealthy control over the system.

On Windows, a kernel-mode rootkit may hook system calls in the SSDT (System Service Descriptor Table) or modify kernel modules. On Linux, rootkits like Reptile or Adore-NG load malicious kernel modules that override default functions like readdir() to hide files and directories. In both cases, the attacker alters the OS’s core behavior, ensuring their presence remains hidden from users and security tools.

Firmware rootkits — such as those targeting UEFI or BIOS — write malicious code directly into firmware volumes. These rootkits survive OS reinstallation and often deploy new payloads at boot time. Hypervisor rootkits manipulate virtualization layers, allowing attackers to intercept or spoof OS-level instructions without the guest OS detecting anything abnormal.

Infrastructure Targeted

Attackers choose the rootkit variant based on the target environment. In traditional infrastructure, kernel and firmware rootkits dominate. In cloud-native environments, attackers favor user-mode rootkits embedded in container runtimes or daemon processes. Public reports have highlighted the use of rootkits in container escape exploits, targeting Kubernetes nodes with elevated privileges to mask malicious containers.

Some rootkits exploit weaknesses in the software supply chain. Attackers inject malicious drivers or modules into legitimate software updates or open-source libraries. Once installed, these components behave normally while concealing unauthorized operations — such as hidden network listeners or reverse shells.

Tooling and Deployment Methods

Attackers often rely on custom droppers to load rootkits, but public tools like Azazel, Diamorphine, Rootkit Hunter (rkhunter) (for detection), and Suterusu (for process hiding) are well-known. Toolkits like Cobalt Strike, Metasploit, and PowerSploit may stage rootkit deployment in post-exploitation workflows.

For cloud targets, attackers script deployments using compromised CI/CD pipelines, embedding rootkits in system startup scripts, containers, or AMI images. Some inject mining payloads into base images while using rootkit functionality to mask CPU spikes.

Rootkits don't exfiltrate data. Rather, they enable long-term control, evasion, and persistence, which makes them central to multistage intrusions like espionage, ransomware staging, or cryptojacking operations.

Integration in the Attack Lifecycle

As post-exploitation tools, rootkits enable deeper system control. Cybercriminals deploy rootkits after gaining access — typically through phishing, software exploits, or credential abuse — to maintain control while remaining invisible to defenders.

Position in the Kill Chain

Rootkits are rarely involved in initial access. Instead, they appear after privilege escalation, where an attacker has obtained administrative or kernel-level access. Once installed, the rootkit cloaks malicious processes, tampered files, network traffic, or registry entries, allowing for long-term persistence.

In campaigns involving espionage, cryptojacking, or data exfiltration, rootkits support lateral movement by hiding C2 tools, tunneling utilities, and credential dumpers. In ransomware operations, they delay detection and block defensive tooling until encryption executes.

Dependencies and Prerequisites

Rootkit deployment requires high privileges. That’s why most rootkits are paired with:

• Kernel exploits (e.g., CVE-2022-0847 in Linux “Dirty Pipe”)
• Bootloader manipulation (for bootkits)
• Firmware flashing (for UEFI/BIOS-level rootkits)
• Misconfigured hypervisors (for VM-based rootkits)
• Trusted software abuse (e.g., signed drivers or system daemons)

Attackers may also exploit legitimate driver frameworks or load unsigned kernel modules to introduce malicious code. Prevalent tactics include sideloading DLLs, manipulating LKM (Loadable Kernel Modules), or exploiting vulnerable third-party monitoring agents.

Role in Adversary Workflows

In advanced persistent threat (APT) campaigns, rootkits typically support the persistence and obfuscation phases. For instance, state-sponsored actors have used UEFI rootkits (LoJax, CosmicStrand) to re-infect systems after OS reinstalls. Criminal groups use kernel-mode rootkits to mask data theft tooling or hide cryptominers in virtual machines.

Rootkits also interact tightly with credential theft techniques. They may suppress logs, intercept authentication tokens, or hide memory dumps containing credentials. By maintaining stealth, rootkits buy attackers the dwell time needed for full compromise or monetization.

Rootkits as Attack Enablers

• Credential access: Suppresses monitoring tools while password scrapers operate.
• Data staging: Conceals large outbound transfers, often in the context of insider threat or espionage.
• Lateral movement: Hides PsExec or RDP-related activities on pivot hosts.
• Defense evasion: Subverts EDR agents, logging services, and system watchdogs.

Integration with Other Threats

Rootkits often work in tandem with:

• Wipers: Mask destructive behavior during staging (e.g., HermeticWiper with bootkits).
• Cryptojacking: Throttle visibility of mining processes, especially in cloud VMs.
• Loader frameworks: Serve as persistent loaders for RATs, infostealers, or ransomware droppers.

Embedded into multistage attack chains, rootkits leverage their invisibility to reduce detection and extend campaign longevity. Effective detection demands not just endpoint monitoring, but boot integrity, memory forensics, and behavior analytics at the system and hypervisor levels.

Cyberattacks Involving Rootkits in the News

Real-world examples of rootkit-based intrusions illustrate the range of threat actors, targets, and consequences — ranging from espionage and credential theft to ransomware staging and supply chain manipulation.

RESURGE Malware Exploiting Ivanti Connect Secure Appliances

In March 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) reported that the RESURGE malware was actively exploited in the wild, targeting a vulnerability in Ivanti Connect Secure appliances (CVE-2025-0282). The malware incorporated rootkit capabilities, enabling it to survive reboots and maintain persistent access, alongside functionalities of a dropper, backdoor, bootkit, proxy, and tunneler. The attacks were attributed to Chinese nation-state hackers.

Lazarus Group Exploiting Windows Zero-Day with FudModule Rootkit

In early 2024, the North Korean Lazarus Group exploited a Windows Ancillary Function Driver for WinSock zero-day vulnerability (CVE-2024-38193) to deploy an enhanced version of their FudModule rootkit. The FudModule rootkit included capabilities to suspend protected processes of security software like Microsoft Defender and CrowdStrike Falcon, facilitating stealthy operations. The attacks were linked to campaigns targeting cryptocurrency professionals.

Kinsing Malware Leveraging Apache ActiveMQ Vulnerability

In November 2023, the Kinsing malware exploited a critical vulnerability (CVE-2023-46604) in Apache ActiveMQ to compromise Linux systems. The attackers deployed rootkits alongside cryptocurrency miners, disabling security features and deleting logs to maintain persistence and evade detection. The attacks were widespread, affecting numerous servers globally.

CosmicStrand UEFI Rootkit

In 2022, Kaspersky researchers uncovered CosmicStrand, a persistent UEFI firmware rootkit embedded in the motherboard firmware of consumer-grade PCs. Attributed to Chinese-speaking threat actors, CosmicStrand hijacked the Windows boot process before the OS or security tools loaded. It allowed attackers to implant additional payloads post-boot, enabling full access without writing to disk. Victims included organizations across China, Iran, Vietnam, and Russia, though many appeared to be targeted for espionage. The case highlights the extreme stealth and durability of firmware-based rootkits and their use in advanced, long-term surveillance operations.

FiveSys Driver-Signed Rootkit

Microsoft and Bitdefender reported a signed Windows rootkit known as FiveSys in 2021. Distributed via gaming cheat tools, it passed Windows Driver Signature Enforcement using a stolen certificate. FiveSys rerouted traffic through a custom proxy, enabling man-in-the-middle capabilities for data theft and C2 communication. Although it lacked persistence beyond reboot, its ability to bypass Microsoft’s signing policy underscored the dangers of trust exploitation and certificate abuse. The rootkit remained undetected for months and circulated widely in Eastern Europe and Asia.

TrickBot Rootkit Module: “TrickBoot”

In 2020, Eclypsium and Advanced Intelligence identified TrickBoot, a module within the TrickBot malware framework that scanned for vulnerable firmware interfaces. While not a full rootkit on deployment, it enabled attackers to enumerate firmware-level write protections and identify targets for potential firmware tampering. TrickBoot marked an evolution in TrickBot’s capabilities — shifting from banking trojan to a modular toolkit with pre-UEFI manipulation potential. It indicated growing cybercriminal interest in rootkit-adjacent techniques traditionally seen in nation-state toolkits.

Necurs Rootkit and Botnet Infrastructure

Necurs operated for nearly eight years as one of the most pervasive spam botnets, responsible for up to 90% of global email spam at its peak. At its core was a kernel-mode rootkit that intercepted file and registry queries, blocked AV updates, and concealed its services. The rootkit allowed Necurs to persist through reboots and reinfect systems after partial cleanup. Attackers frequently paired it with malware like GameOver Zeus and Locky ransomware. Microsoft and its partners dismantled the infrastructure in 2020, disrupting one of the longest-running rootkit-backed botnets in the wild.

Rootkit Detection and Indicators

Unlike most malware, rootkits’ core function is to stay hidden — often by modifying system-level behavior and concealing both their presence and that of other malicious components. Detecting them requires visibility below the surface of conventional logs and endpoint telemetry.

Behavioral Red Flags in Rootkit Infections

Rootkits often disable or tamper with native logging mechanisms. When expected audit trails disappear or fail to generate during known system events, this can signal the presence of a kernel-level or bootkit-class rootkit. Behavioral red flags include unexplained system slowdowns, persistent abnormal CPU usage, and kernel panics or crashes with no corresponding logs.

On Windows, monitor for:

• Hidden or unregistered drivers in kernel mode
• Processes that vanish from tasklist or task manager but consume resources
• Registry keys that return errors or inconsistent values when queried through different APIs

On Linux and Unix systems:

• Files that appear in raw disk dumps but not in directory listings
• Processes that don’t appear in ps but are visible in /proc
• Unexpected entries in system call tables or signs of LD_PRELOAD abuse

Indicators of Compromise (IOCs)

• File hashes: Rootkit installers or payloads often have consistent MD5/SHA-256 fingerprints. These can be fed into threat intelligence platforms or EDR solutions for correlation.
• Network anomalies: Rootkits with C2 functionality may use uncommon ports, custom protocols, or domain generation algorithms to evade detection.
• Memory-resident artifacts: Use forensic memory analysis tools to detect injected code, overwritten syscall tables, or anomalous kernel modules.
• Persistence indicators: Modified GRUB entries, altered bootloader binaries, or changes to Windows boot configuration data (BCD) may indicate bootkits.

SIEM and XDR Monitoring Recommendations

SIEMs should flag inconsistencies in logs sourced from different layers (e.g., differences between file system activity seen in application logs vs. what the OS reports). Monitor for tampered drivers, unsigned kernel modules, and system boot sequence alterations.

In XDR platforms, enable deep telemetry for:

• Kernel module load events
• Hooking or patching behavior on core system libraries
• Drivers communicating with user-space processes in uncharacteristic ways

Advanced XDR deployments should correlate raw disk activity with process lineage and flag deviations from baseline kernel behavior. Be alert to processes spawning from non-standard directories or communicating with external IPs from a signed but suspicious driver.

Detection isn’t guaranteed. Rootkits, by design, defeat traditional visibility. Detection success hinges on integrating low-level system auditing, memory analysis, and behavioral correlation rather than relying solely on signature-based methods.

For effective detection, extend monitoring into early boot stages and kernel execution, and continuously validate the integrity of system-critical binaries. Rootkit discovery rarely comes from a single alert — it emerges from piecing together silent failures and data inconsistencies that point to deeper tampering.

Memory Forensics: The Last Line of Rootkit Detection

When rootkits bypass disk-based indicators and evade runtime telemetry, memory analysis becomes essential. Volatile memory holds the manipulated kernel objects, injected code, and rogue handles that file- or log-based tools miss. Analysts use tools to acquire snapshots and run plugins that scan for discrepancies in EPROCESS lists, DKOM artifacts, or unlinked drivers.

Memory analysis doesn’t just identify the presence of malicious code — it also validates the integrity of the kernel. For instance, comparing syscall tables in memory against expected system images reveals overwritten handlers. Similarly, enumeration of loaded kernel modules via memory traversal can uncover rootkits that unlink themselves from traditional enumeration APIs.

In environments with APTs, memory acquisition should be routine during incident triage. Correlating memory findings with XDR or SIEM outputs helps distinguish between legitimate but stealthy behavior (e.g., signed drivers with custom hooks) and genuine subversion. While high-effort, memory forensics delivers unique visibility into the systems rootkits target by design.

Prevention and Mitigation

Rootkits are designed to outlast standard detection and remediation. Effective prevention starts at the architectural level and extends through endpoint hardening and policy design. No single control is sufficient. Resilience requires overlapping layers that address execution, persistence, and visibility gaps.

Reduce the Attack Surface at the Kernel and Boot Layers

Disallow unsigned kernel modules and enforce secure boot policies to prevent unauthorized code from running in early system stages. On Windows systems, enable Driver Signature Enforcement. In Linux environments, disable dynamic kernel module loading where practical. Harden bootloaders and restrict access to recovery partitions.

Harden Endpoint Defenses with Integrity and Control Mechanisms

Deploy endpoint protection that includes kernel-level monitoring. Use file integrity monitoring (FIM) to baseline and track changes in sensitive system directories and boot records. Block direct memory access (DMA) from untrusted devices to prevent low-level injection. Limit administrator privileges and enforce just-in-time elevation for critical operations.

Implement Segmentation and Access Control

Apply network segmentation to isolate endpoints from critical infrastructure. Use microsegmentation in data center and cloud environments to limit lateral movement. Enforce least privilege across all identity and access management layers, with MFA on privileged accounts and service management consoles.

Monitor for Persistence Indicators and Behavioral Drift

Rootkits often establish long-term footholds. Monitor for signs of unauthorized persistence, such as unexpected services, scheduled tasks, or altered startup configurations. Profile normal system and kernel behavior to detect outliers in syscall frequency, CPU usage, and low-level logging changes.

Control Third-Party Software and Supply Chain Risk

Block unauthorized software installation via application allowlisting. Regularly audit drivers, kernel modules, and low-level packages, especially those from less-vetted vendors. In developer environments, scan build pipelines for potential rootkit loaders injected during compilation or packaging.

What Doesn’t Work

Signature-only antivirus is insufficient. Rootkits evade detection by intercepting the very functions those tools rely on. Simply reinstalling the OS may not help if firmware or bootloaders are compromised. Endpoint detection that excludes kernel or memory-space inspection will consistently miss rootkit behavior.

Rootkit prevention demands security teams think beneath the surface, deep into the code that governs visibility. Without a hardened foundation, no control further up the stack can be trusted to report the truth.

Responding to Rootkit-Related Attacks

Once embedded, rootkits corrupt the very mechanisms relied on to detect and remove them. A tailored incident response strategy with an emphasis on containment and reestablishing system trust is vital.

Immediate Containment

Immediately isolate affected systems from the network to prevent lateral movement or further compromise. Suspend operations on suspected endpoints, but do not power them down unless memory capture is impossible. Volatile artifacts may reside in RAM or kernel-space processes that disappear upon shutdown.

Preserve forensic integrity by collecting full disk images, memory snapshots, and system logs from the suspected systems. Avoid standard cleanup procedures until rootkit presence is confirmed and forensic evidence secured.

Rebuild Trust from the Ground Up

Don’t assume successful disinfection. Rootkits operate below the visibility of standard tools and may subvert file system, logging, and monitoring operations. Perform bare-metal recovery using known-good, cryptographically verified installation media.

Reflash BIOS or UEFI firmware if tampering is suspected. In cloud environments, terminate and rebuild affected instances from trusted golden images. Avoid snapshot reuse unless full image integrity has been independently verified.

Internal Communication and Containment Expansion

Inform the incident response team, IT leadership, and internal security operations. Begin lateral scoping by examining peer systems, shared service accounts, and remote access tooling. Rootkits may coexist with credential theft or command-and-control infrastructure that signals broader compromise.

Communicate with affected business units, especially if critical systems or endpoints require extended downtime for secure remediation.

Post-Incident Analysis and Reinforcement

Conduct a full root cause analysis to determine how the rootkit was introduced. Common vectors include infected drivers, malicious USB devices, compromised build artifacts, or downstream malware loaders.

Update EDR/XDR signatures, kernel integrity baselines, and access controls based on findings. Validate that FIM, UEFI/TPM attestation, and secure boot configurations are now enforced.

Consider engaging an external IR firm for cases involving nation-state-level tradecraft, UEFI compromise, or when multiple systems exhibit symptoms inconsistent with user-space malware alone.

Rootkit FAQs