What Is a Rootkit: Types, How It Works and Detection Methods

A rootkit is malware designed to maintain hidden, privileged access on a compromised system. The word derives from "root" (the administrative account in Unix) plus "kit" (a set of tools), and it describes what it does: a package that combines escalation, persistence and, above all, stealth, so the attacker keeps control of the machine while standard defensive tooling fails to see it.

This guide covers what a rootkit is, the six categories by execution level (user-mode, kernel-mode, bootkit, firmware, hypervisor, container), evasion techniques, public cases, MITRE ATT&CK mapping and which detection, hardening and DFIR response measures work in corporate environments in 2026.

The essentials

• A rootkit is malware whose primary function is to stay hidden on a compromised system while retaining privileged access.
• It is classified by execution level: user-mode (ring 3), kernel-mode (ring 0), bootkit (pre-OS), firmware (BIOS, UEFI, peripherals), hypervisor and container.
• The lower it operates (firmware, hypervisor), the less visibility conventional antivirus and EDR have.
• Serious detection requires memory forensics, boot-time scanning, integrity checking and hardware attestation with TPM.
• When a rootkit is confirmed at kernel, bootkit or firmware level, the response is not to clean it, it is to reimage (and, for firmware, reflash or physically replace hardware).

What a rootkit is and why it is the worst category of malware

A rootkit is a set of malicious tools designed to maintain privileged access over a system while actively hiding its own presence and that of related artefacts (processes, files, network connections, registry keys). The term emerged in Unix in the early nineties, when attackers replaced system binaries such as ls, ps or netstat with modified versions that filtered their own activity from the output.

It is considered the worst category of malware for structural reasons. Ransomware is visible by definition and a trojan touches disk and network in ways observable by a reasonably configured EDR. A well-implemented rootkit eliminates the signals defensive tools depend on. In kernel-mode, the system functions an antivirus calls to enumerate processes return results filtered by the rootkit itself. In firmware, it survives operating system reinstallation and disk replacement. In hypervisor, the entire guest operating system runs inside a virtual machine created by the attacker without knowing it.

A rootkit almost always includes a backdoor and persistence mechanisms, but its defining trait is concealment.

Rootkit types by execution level

User-mode rootkit (ring 3)

These operate with user-level privileges. They modify dynamic libraries, hook user-space API functions, replace binaries or use pre-loading (LD_PRELOAD on Linux, DLL hijacking on Windows) to intercept calls before they reach the operating system. They are the oldest and the easiest to detect with a modern EDR (DLL load telemetry, signed binary hashes, comparison against the OS catalogue). Their value to the attacker is portability: they work without a kernel exploit or a valid driver signature. Examples: Azazel, Vlany, Jynx2.

Kernel-mode rootkit (ring 0)

These load as a kernel module (LKM on Linux, driver on Windows, legacy kext on macOS). They execute with full privilege over the operating system and can modify internal structures, hook system calls and rewrite kernel function tables.

Detection from the compromised host is structurally difficult: the rootkit can lie to the EDR. If the agent enumerates processes, the rootkit excludes its own through a hook. If it reads a file, the rootkit filters the result or returns a falsified hash. Windows requires WHQL signing and, with HVCI enabled, runs drivers in a Hyper-V protected context. Linux loads LKMs only if the kernel permits it, and with kernel.modules_disabled=1 after boot, not even then. These controls raise the bar but techniques like bring-your-own-vulnerable-driver continue to appear.

Bootkit (MBR or UEFI compromise)

These persist in the boot process: classic MBR, VBR, or, in modern systems, in UEFI firmware before the operating system loads. The attacker takes control at the very first moment of boot and launches the operating system from within their own compromised environment.

MBR bootkits are a legacy category (TDL4, Mebroot) without a practical vector against modern Windows with Secure Boot. UEFI bootkits are the current generation: LoJax (APT28, 2018), MosaicRegressor (2020), MoonBounce (2022), BlackLotus (2023, bypassing Secure Boot through CVE-2022-21894). Detection requires Measured Boot with TPM. Reinstalling the operating system is not enough: the bootkit remains in firmware.

Firmware rootkit (BIOS, NIC, GPU, drive controllers)

Implants in motherboard firmware (BIOS or UEFI), network cards, disk or SSD controllers, baseboard management controllers (BMC) and even GPU. Narrow surface, limited actors, radical impact: the malware survives reinstallation, disk replacement and certain hardware swaps.

Stuxnet's firmware component (2010) on Siemens PLC controllers was essentially an industrial firmware rootkit. On endpoints, Kaspersky documented in 2015 Equation Group implants (attributed to NSA) in hard drive firmware from multiple vendors, capable of surviving low-level wipes. Detection requires CHIPSEC and TPM attestation. Remediation means reflashing from a trusted source and, in sensitive cases, physical replacement.

Hypervisor rootkit (Blue Pill type)

Demonstrated by Joanna Rutkowska in 2006 with Blue Pill. The attacker inserts a minimal hypervisor underneath the running operating system, so the system continues running as a guest inside a virtual machine created by the attacker. From outside the guest, the hypervisor has full visibility and control over memory, execution and devices. Modern virtualisation extensions (Intel VT-x, AMD-V) make it technically possible. Its use in publicly documented real campaigns is scarce, but it remains a vector worth considering against nation-state actors.

Container rootkit (eBPF abuse)

Emerging category in modern Linux. eBPF allows programs to be loaded into kernel space with controlled privileges, and since 2021 attackers have used it to hook syscalls, filter network traffic and hide processes without loading a traditional kernel module, keeping persistence in containerised environments and Linux cloud. Documented families: BPFDoor (attributed to actors of Chinese origin), Symbiote, Boopkit. Detection requires telemetry on eBPF program loading and restrictions on which unprivileged accounts can load them.

Common evasion techniques

• Syscall hooking. The rootkit replaces pointers in the system call table (SSDT on Windows, syscall table on Linux) so calls go through its code first, filtering any query about processes, files, connections or registry keys.
• DKOM (Direct Kernel Object Manipulation). Direct modification of kernel structures without going through official APIs. The classic example is unlinking a process from the EPROCESS list on Windows: it keeps running because the scheduler uses a different structure, but tools that enumerate via the official list do not see it.
• Hiding processes via /proc filter. On Linux, user-mode rootkits intercept calls to /proc so the malicious PID does not appear. Kernel-mode rootkits achieve the same by modifying the VFS layer or hooking getdents.
• Network filter drivers. Malicious drivers (NDIS on Windows, netfilter hooks on Linux) filter traffic before it reaches user space, hiding C2 connections from any tool that enumerates sockets.
• Inline hooking. Replacement of the first bytes of critical functions with a jump to the rootkit's code. Harder to detect than table hooking.

Famous rootkits (with context, without glamour)

• Stuxnet (2010). State-sponsored operation against Natanz. It combined a Windows component with a kernel rootkit signed using certificates stolen from Realtek and JMicron, plus a component on Siemens PLCs acting as an industrial rootkit.
• TDL/TDSS (2008 to 2012). Bootkits that infected millions of Windows machines. TDL4 overwrote the MBR and loaded the rootkit before the operating system. Modern Windows with Secure Boot removed its practical vector.
• Necurs (2012 to 2019). Botnet on a kernel-mode rootkit serving as a platform for banking trojans, ransomware and spam. Microsoft and partners coordinated its takedown in 2020.
• Equation Group (2015). Implants in hard disk firmware from multiple vendors, capable of surviving complete wipes. Attributed to NSA in technical reports from Kaspersky.
• LoJax (2018). First UEFI rootkit documented in a real campaign, attributed to APT28. ESET showed how the module persisted in SPI flash, surviving reinstallation and disk replacement.
• Triangulation (2023). Exploit chain on iOS disclosed by Kaspersky after detecting implants on its own staff's devices. Four zero-days, memory manipulation outside the sandbox and rootkit-equivalent persistence.

What they share: actors with time, resources and specific targets. Rootkits at this level are reserved for operations where deep persistence justifies the cost and the risk of burning the capability.

Detecting rootkits with EDR and forensics

Detecting rootkits from the compromised host is structurally weak: the rootkit can lie to the very tools looking for it. What works combines several layers:

• Memory forensics. Physical memory capture (FTK Imager, WinPmem, LiME) and analysis with Volatility. Memory exposes real kernel structures, scheduler-side process lists and SSDT hooks.
• Boot-time scanning. Analysis from external media (WinPE, Linux live USB) before the rootkit loads.
• Integrity checking. Comparison of hashes for binaries, drivers, kernel and firmware against known-good values. WHQL on Windows, package validation and IMA on Linux.
• EDR anomaly detection. New drivers outside patch windows, kernel table modifications, processes without an official entry but with observable network activity, discrepancies between tasklist and the agent.
• Network analytics off-host. NetFlow, Zeek and taps detect connections the compromised host claims do not exist.
• TPM attestation and Measured Boot. Detect changes in bootloader, kernel and early drivers.

Difference between rootkit and backdoor

A single implant combines several categories. A rootkit almost always includes a backdoor (concealing access without having access makes no sense). A backdoor does not need to be a rootkit: a forgotten admin account, a residual SSH key or an undocumented service are backdoors with no deep-concealment component.

Prevention and hardening

• Secure Boot. Blocks unsigned bootloaders and, properly configured, eliminates most known UEFI bootkits. Keep revocation lists current (Microsoft revoked the version used by BlackLotus).
• Driver and kernel signing enforcement. On Windows, mandatory WHQL signing. On Linux, kernel lockdown with lockdown=integrity or lockdown=confidentiality.
• HVCI on Windows. Hypervisor-protected Code Integrity runs drivers in a Hyper-V protected context. Combined with Credential Guard in Device Guard.
• Lockdown Mode on macOS. Optional mode available from macOS Ventura, targeted at high-risk user profiles.
• TPM attestation. Remote verification that the components loaded during boot match the expected values.
• Least privilege on accounts. Restrict accounts able to load drivers or kernel modules to a small, audited group.

MITRE ATT&CK mapping

Rootkits appear across several techniques in MITRE ATT&CK:

• T1014 Rootkit. Explicit technique under the Defense Evasion tactic. Covers the use of rootkits to hide attacker artefacts on the compromised system.
• T1542 Pre-OS Boot. Covers bootkits and firmware rootkits. Sub-techniques: System Firmware (T1542.001), Component Firmware (T1542.002), Bootkit (T1542.003), ROMMONkit (T1542.004), TFTP Boot (T1542.005).
• T1601 Modify System Image. Modification of operating system or firmware images on network devices. Sub-techniques: Patch System Image (T1601.001), Downgrade System Image (T1601.002).

Other commonly associated techniques: T1547 Boot or Logon Autostart Execution, T1556 Modify Authentication Process, T1112 Modify Registry, T1574 Hijack Execution Flow.

If you find a rootkit: DFIR protocol

Finding a confirmed rootkit shifts the response priorities. General rule: the lower it operates (firmware, bootkit, kernel), the less reliable any information obtained from the host itself.

1. Isolate without powering off. Disconnect from the network to stop exfiltration and lateral movement, but do not power down. Memory is the most valuable forensic source.
2. Full forensic imaging. Memory capture (FTK Imager, WinPmem), bit-for-bit disk image with write blocker, recent network captures from non-compromised infrastructure.
3. Do not trust tools running on the host. Analysis is performed on the forensic image from a clean system. Tools on the compromised host may be returning information filtered by the rootkit.
4. Reimage from firmware when the scope is bootkit or firmware. Reinstalling the operating system is insufficient. The correct process includes reflashing firmware from a trusted source and, in sensitive cases, physically replacing the component.
5. Mass rotation of credentials and secrets. Any credential, certificate or secret within reach of the host is treated as compromised. Full rotation, not partial.
6. Lateral threat hunting. Active hunting for the same TTPs across the rest of the fleet: new drivers, firmware modifications, created accounts, persistence, beaconing.
7. Eradication validation. Enhanced telemetry for months, retesting, TPM attestation if available, network log review to confirm the pattern has stopped.

Frequently asked questions

Does antivirus detect rootkits

Modern antivirus suites include anti-rootkit engines and detect known families, but their capability drops once the rootkit operates below the level where the antivirus runs. No conventional antivirus covers firmware rootkits. Serious detection combines antivirus, EDR, memory forensics and TPM attestation.

Is operating system reinstallation enough to remove a rootkit

It depends on the type. For user-mode and kernel-mode rootkits without a firmware component, a clean reinstallation from trusted media removes the implant. For UEFI bootkits, firmware rootkits and BMC rootkits, firmware must be reflashed from a verified source and, in serious cases, physical replacement should be considered.

How is a firmware rootkit removed

Identify the affected component (BIOS, UEFI, NIC, drive controller, BMC) and reflash with the official vendor image from a clean machine. Validate with CHIPSEC and hash comparison. When trust in the asset is critical, physical replacement offers more certainty than reflashing.

Is Linux safer against rootkits than Windows

Not by default. Linux has had significant families (malicious LKMs, eBPF rootkits, Symbiote, BPFDoor). The real difference depends on hardening: kernel lockdown, restricted module loading after boot, IMA, AppArmor or SELinux. A hardened Linux system is highly resistant; one with accessible root offers no advantage over a Windows system with HVCI active.

Do rootkits exist on macOS

Yes, although the surface is narrower. Kernel extensions are on a multi-year deprecation path, replaced by system extensions in user space. System Integrity Protection and, on Apple Silicon, the sealed system volume make installing classic rootkits difficult. Even so, campaigns such as XCSSET or Operation Triangulation on iOS confirm that resourced actors reach the platform.

Do we have to notify the regulator if we find a rootkit

It depends on the applicable regime. In the EU, NIS2 obliges essential and important entities to report significant incidents (early warning within 24 hours, notification within 72). GDPR requires notification of personal data breaches within 72 hours when there is risk to data subjects. A rootkit on systems handling personal data or essential services usually triggers regulator communication, subject to legal analysis of scope.

Related resources

• What is a backdoor: types and detection methods
• What is the kernel in cybersecurity
• Types of malware: classification and real examples
• What is MITRE ATT&CK: tactics and techniques
• What is EDR: endpoint detection and response
• What is threat hunting: methodology and examples
• What is Mimikatz: credential dumping and defence

Rootkit DFIR response with Secra

At Secra we work with defensive teams that suspect deep compromise and need to validate whether implants remain at kernel, bootkit or firmware level. The services include kernel-level threat hunting over available telemetry (EDR, SIEM, TPM attestation), memory forensic analysis with Volatility, firmware integrity review with CHIPSEC and post-incident hardening covering Secure Boot, HVCI, kernel lockdown and remote attestation.

If your organisation has had alerts on unsigned drivers, anomalous low-level behaviour or needs to validate that a recent compromise has not left a residual rootkit, contact us for an initial assessment.