This chapter covers rootkits and bootkits, two of the most stealthy and persistent malware types that target the operating system at its deepest levels. For the SY0-701 exam, understanding how these threats subvert system integrity is critical for Objective 2.4 (Explain the importance of threat actors and attack vectors) within the Threats, Vulnerabilities, and Mitigations domain. Rootkits and bootkits represent advanced persistence mechanisms that can survive reboots and evade traditional antivirus, making them a key topic for security professionals to detect and defend against.
Jump to a section
Imagine a large cargo ship that undergoes a routine inspection before departure. The crew checks the manifest, verifies cargo, and scans for stowaways. A rootkit is like a stowaway who has built a secret compartment inside the ship's hull during construction. This compartment is not on any blueprint and is invisible to standard inspections. Once the ship is at sea, the stowaway can move freely, sabotage the engine, or steal cargo without being detected because the inspection tools only look for things listed in the manifest. A bootkit is even more insidious—it's like a stowaway who has modified the ship's navigation computer itself. When the captain turns the wheel, the computer shows a different course than the ship actually takes. The crew sees normal readings, but the ship is being steered into pirate waters. Detection requires specialized tools that check the integrity of the navigation system's firmware, not just the software running on top. In both cases, the key mechanism is subverting the system's trust in its own low-level components, making the attacker invisible to higher-level monitoring.
What Are Rootkits and Bootkits?
A rootkit is a collection of software tools designed to gain unauthorized access to a computer system while hiding its presence and the presence of other malicious software. The term 'rootkit' originates from Unix/Linux, where 'root' is the superuser account, and 'kit' refers to the tools used to maintain that privileged access. Rootkits operate by modifying core system files, kernel modules, or device drivers to intercept and alter system calls, effectively hiding files, processes, network connections, and registry entries from standard monitoring tools.
A bootkit is a specialized type of rootkit that infects the Master Boot Record (MBR), Volume Boot Record (VBR), or the Unified Extensible Firmware Interface (UEFI) firmware. Bootkits load before the operating system, ensuring that they have complete control over the system from the moment it powers on. They can disable security features like Secure Boot and load their malicious kernel drivers before the OS security mechanisms initialize.
How Rootkits Work Mechanically
Rootkits operate by hooking or replacing system calls—the interface between user applications and the kernel. For example, on Windows, a rootkit might hook the NtQuerySystemInformation API call, which is used by Task Manager to list processes. The rootkit intercepts this call, removes any entries for its own processes, and returns a sanitized list. Similarly, it can hook file enumeration APIs to hide its files and registry APIs to hide its registry keys.
There are several levels of rootkits:
- User-mode rootkits: Operate at the application layer by intercepting Windows API calls via DLL injection or API hooking. They are easier to detect because security software can enumerate loaded DLLs.
- Kernel-mode rootkits: Operate at the kernel level by loading a malicious device driver (.sys file) that hooks system service dispatch tables (SSDT) or the interrupt descriptor table (IDT). These are more powerful and harder to detect.
- Bootkits: Infect the boot process. For example, the TDL-4 rootkit (also known as Alureon) overwrites the MBR with its own code. When the system boots, the bootkit loads a malicious driver before Windows starts, then passes control to the legitimate OS but maintains persistence.
Bootkit Infection Mechanism (MBR Example)
Infection: The bootkit writes its malicious code to the MBR (first sector of the hard disk, 512 bytes). The original MBR is stored elsewhere (e.g., on a hidden partition).
Boot: The BIOS reads the MBR and executes the bootkit code. The bootkit loads its driver into memory.
Persistence: The bootkit driver hooks disk I/O operations. Any attempt to read the original MBR returns the clean version, while the actual infected MBR remains hidden.
OS Load: The bootkit then loads the original MBR (from the hidden location) to boot the OS normally. The OS is unaware of the bootkit's presence.
Stealth: The bootkit intercepts all attempts to read the MBR, including from antivirus software, returning a clean copy.
UEFI Bootkits
With the shift to UEFI (Unified Extensible Firmware Interface) and Secure Boot, bootkits have evolved. UEFI bootkits, like LoJax (discovered in 2018), infect the UEFI firmware itself. LoJax was the first known UEFI rootkit used in the wild. It writes its code to the SPI flash memory where the UEFI firmware is stored. Even if the hard drive is wiped, the bootkit persists in the firmware. Secure Boot is designed to prevent unauthorized code from running during boot, but if the bootkit can hijack the bootloader or sign its code with a stolen certificate, it can bypass Secure Boot.
Key Components and Variants
Hooking: Modifying the flow of system calls. Common hooking points include SSDT, IDT, and the System Service Dispatch Table (SSDT) on Windows.
Direct Kernel Object Manipulation (DKOM): Manipulating kernel data structures directly, such as the process list (EPROCESS blocks) to hide processes.
Driver Loading: Kernel-mode rootkits often load as malicious device drivers. On Windows, this requires administrative privileges.
Bootkit Techniques: Writing to MBR, VBR, or UEFI firmware. Some bootkits use a technique called 'bootkit injection' where they modify the boot configuration data (BCD).
Real-World Examples and CVEs
Sony BMG Rootkit (2005): A user-mode rootkit installed by Sony's music CDs to hide copy protection software. It caused major security vulnerabilities and was a landmark case.
TDL-4 (Alureon): A kernel-mode bootkit that infected the MBR. It was used to create a peer-to-peer botnet and was extremely difficult to remove.
LoJax: The first UEFI bootkit discovered in the wild, used by the Sednit group (APT28). It persists in UEFI firmware and can survive OS reinstallation.
CVE-2018-19320: A vulnerability in the Ring 0 (kernel) that allowed privilege escalation via a rootkit.
CVE-2021-42287 and CVE-2021-42278: Active Directory domain escalation vulnerabilities that could be exploited by kernel-mode rootkits.
Detection and Removal
Detection of rootkits and bootkits requires specialized tools that operate from a trusted environment:
- Offline scanning: Boot from a trusted CD/USB (e.g., Windows Defender Offline, Kaspersky Rescue Disk) to scan the hard drive without the OS running.
- Integrity checking: Tools like Tripwire or RootkitRevealer compare current system files and registry keys against known good baselines.
- Memory analysis: Tools like Volatility can analyze RAM dumps to find hidden processes and kernel objects.
- Secure Boot verification: Check if Secure Boot is enabled and if any unauthorized certificates are present in the UEFI database.
- Firmware scanning: Use vendor-specific tools (e.g., Dell's BIOS verification) or CHIPSEC to scan UEFI firmware for anomalies.
Prevention
Secure Boot: Ensure Secure Boot is enabled in UEFI settings. This verifies that only signed bootloaders and drivers are loaded.
TPM (Trusted Platform Module): Use TPM for measured boot, which records boot components in PCR registers. Remote attestation can verify the boot chain.
UEFI firmware passwords: Protect BIOS/UEFI settings from unauthorized changes.
Regular updates: Apply firmware updates from hardware vendors to patch known vulnerabilities.
Least privilege: Limit administrative access to prevent kernel-level malware installation.
Application whitelisting: Use tools like AppLocker or Windows Defender Application Control to block unauthorized executables.
Command Examples
To check Secure Boot status on Windows:
Confirm-SecureBootUEFITo check if Secure Boot is enabled via command line:
bcdedit /enum {current} | find "resume"To list all loaded drivers on Windows:
driverquery /vTo check MBR integrity (Linux):
sudo dd if=/dev/sda bs=512 count=1 | xxdTo analyze memory with Volatility for hidden processes:
volatility -f memory.dump --profile=Win7SP1x64 pslist
volatility -f memory.dump --profile=Win7SP1x64 psscanThe psscan command scans for processes by looking at EPROCESS blocks in memory, which can reveal hidden processes that pslist (which uses the kernel's linked list) might miss.
Initial Access via Exploit
The attacker gains initial access to the target system, typically through a phishing email, drive-by download, or exploiting a vulnerability (e.g., CVE-2021-34527 for PrintNightmare). This step requires administrative privileges to install kernel-level components. The attacker may use a dropper that downloads the rootkit or bootkit payload. Logs might show unusual process creation (e.g., `rundll32.exe` spawning `cmd.exe`) or network connections to known malicious IPs.
Privilege Escalation to Kernel
If not already running as administrator, the attacker escalates privileges using techniques like token theft or exploiting kernel vulnerabilities. For example, exploiting CVE-2020-0796 (SMBGhost) can give SYSTEM privileges. The attacker then loads a malicious driver (`.sys` file) using `sc create` or `rundll32`. Event logs may show service installation events (Event ID 7045) or driver load failures.
Install Rootkit/Bootkit
The attacker deploys the rootkit or bootkit. For a bootkit, they write to the MBR using raw disk write operations (e.g., `\.\PhysicalDrive0`). For a kernel rootkit, they load the driver and hook system calls. Tools like `Process Monitor` would show write operations to `\.\PHYSICALDRIVE0` at sector 0. The bootkit may also create a hidden partition to store its components. Antivirus may detect this if signatures are present, but many bootkits use custom encryption.
Establish Persistence
The rootkit ensures it survives reboots. Bootkits modify the boot process; kernel rootkits may add entries to the Windows Registry (e.g., `HKLM\SYSTEM\CurrentControlSet\Services`) to load the driver at startup. Some rootkits use DKOM to hide their registry keys. The attacker may also disable security tools like Windows Defender by modifying service configurations. Logs might show registry modifications, but rootkits often hook the registry API to hide changes.
Conduct Malicious Activities
With stealthy persistence, the rootkit performs its intended actions: keylogging, data exfiltration, C2 communication, or downloading additional payloads. It uses encrypted channels (e.g., HTTPS, DNS tunneling) to avoid network detection. The attacker may deploy ransomware or use the system as a bot. The rootkit hides all traces: processes, files, network connections. For example, a rootkit might hook `NtEnumerateValueKey` to hide its registry keys from `regedit`.
Detection and Removal
Detection requires offline scanning or memory analysis. The analyst boots from a trusted USB and runs an anti-rootkit tool (e.g., Malwarebytes Anti-Rootkit, GMER). They may capture a memory dump using `LiveKD` or `WinPmem` and analyze it with Volatility to find hidden processes. Removal often involves rebuilding the MBR (`bootrec /fixmbr`) or reinstalling the OS. For UEFI bootkits, the firmware must be reflashed. A common mistake is trying to remove the rootkit while the OS is running, which fails because the rootkit hides its files.
Scenario 1: Bootkit in a Corporate Environment
A SOC analyst notices anomalous DNS queries from several workstations to a domain known for C2 activity. Traditional antivirus shows no detections. The analyst runs Windows Defender Offline scan on one affected system, which detects a bootkit in the MBR. The bootkit is TDL-4 variant. The analyst uses bootrec /fixmbr to restore the MBR, but after reboot, the bootkit reappears because it also modified the VBR. The correct response is to use a dedicated anti-bootkit tool like Kaspersky Rescue Disk to clean all boot sectors. A common mistake is to rely on online scans that the bootkit can intercept. The analyst should also check for hidden partitions using diskpart and list disk to reveal any suspicious partitions.
Scenario 2: UEFI Bootkit in a Government Agency
During a security audit, a forensics team discovers that a sensitive system's UEFI firmware has been modified. The system exhibits intermittent network issues, but OS-level scans are clean. Using CHIPSEC (a firmware security tool), the team finds unauthorized code in the SPI flash. The bootkit is LoJax. The correct response is to reflash the UEFI firmware using a clean image from the vendor. The team also checks for stolen certificates used to sign the bootkit. A common mistake is to simply reinstall the OS, which does not affect the firmware. The analyst should also enable Secure Boot and ensure that only trusted certificates are in the UEFI database.
Scenario 3: Kernel Rootkit Hiding a Backdoor
A server shows high CPU usage but Task Manager shows no suspicious processes. The security team uses Sysinternals Process Explorer with the 'Verify Signatures' option and notices a driver named msdirectx.sys that is not digitally signed. Running volatility psscan on a memory dump reveals a hidden process svchost.exe with a suspicious PID. The rootkit is a kernel-mode DKOM rootkit. The team uses GMER to scan for SSDT hooks and finds several. The correct response is to boot from a trusted ISO and delete the driver file from C:\Windows\System32\drivers. A common mistake is to kill the hidden process from memory, which the rootkit respawns.
What SY0-701 Tests
For Objective 2.4, the exam focuses on identifying rootkits and bootkits as types of malware that provide persistence and stealth. Key sub-objectives include:
Recognizing that rootkits operate at kernel or user mode.
Understanding that bootkits infect the MBR, VBR, or UEFI firmware.
Knowing that Secure Boot and TPM are countermeasures.
Differentiating rootkits from other malware like Trojans or ransomware.
Common Wrong Answers and Why
'Rootkits are only for Unix/Linux' – Wrong. Rootkits exist for Windows, macOS, and Linux. The term originated in Unix, but they are platform-agnostic.
'Bootkits can be removed by reinstalling the OS' – Wrong. Bootkits that infect UEFI firmware survive OS reinstallation. Only firmware reflash removes them.
'Antivirus can detect all rootkits' – Wrong. Rootkits are designed to hide from antivirus by hooking system calls. Offline scanners are needed.
'Secure Boot completely prevents bootkits' – Wrong. Secure Boot can be bypassed if the bootkit uses a stolen certificate or if Secure Boot is misconfigured.
Specific Terms and Acronyms
MBR: Master Boot Record (first sector of disk)
VBR: Volume Boot Record (first sector of a partition)
UEFI: Unified Extensible Firmware Interface (replaces BIOS)
TPM: Trusted Platform Module (hardware security chip)
DKOM: Direct Kernel Object Manipulation
SSDT: System Service Dispatch Table (hooking point)
LoJax: First known UEFI bootkit
Trick Questions
A question might describe a malware that 'hides processes from Task Manager' – this is a rootkit, not a virus or worm.
A scenario where malware 'persists after OS reinstall' – this points to a bootkit (UEFI) or firmware rootkit.
A question about 'measured boot' – this relates to TPM, which records boot measurements for attestation.
Decision Rule
If a scenario describes malware that is difficult to detect, hides its presence, and survives reboots, look for 'rootkit' or 'bootkit' in the answer choices. If it mentions modification of boot sectors or firmware, choose 'bootkit'. If it focuses on hiding files/processes at the OS level, choose 'rootkit'. Eliminate answers like 'Trojan' or 'spyware' because they lack the stealth mechanism.
Rootkits provide stealthy persistence by hooking system calls; they can hide files, processes, and registry keys.
Bootkits infect the Master Boot Record (MBR), Volume Boot Record (VBR), or UEFI firmware, loading before the OS.
UEFI bootkits (e.g., LoJax) persist in firmware and survive OS reinstallation.
Secure Boot and TPM (Trusted Platform Module) are primary defenses against bootkits.
Detection requires offline scanning or memory analysis (e.g., Volatility) because rootkits hide from live tools.
DKOM (Direct Kernel Object Manipulation) is a technique used by kernel-mode rootkits to hide processes.
Removing a bootkit often requires booting from a trusted medium and rewriting the MBR (bootrec /fixmbr) or reflashing UEFI firmware.
These come up on the exam all the time. Here's how to tell them apart.
Rootkit
Operates at user or kernel mode after OS loads.
Hides files, processes, registry entries via API hooking.
Can be removed by offline scanning or OS reinstall (if not in boot sector).
Examples: Sony BMG rootkit, Rustock.
Detection: Memory analysis, rootkit revealers (e.g., GMER).
Bootkit
Infects MBR, VBR, or UEFI firmware; loads before OS.
Hides its presence by intercepting disk reads of boot sectors.
Survives OS reinstall; requires MBR repair or firmware reflash.
Examples: TDL-4 (Alureon), LoJax.
Detection: Offline boot scans, firmware integrity checks (CHIPSEC).
Mistake
Rootkits are only found on Windows systems.
Correct
Rootkits can infect any operating system, including Linux, macOS, and even mobile platforms. The term originated from Unix, and examples exist for all major OSes.
Mistake
A bootkit is just a type of rootkit, so they are the same thing.
Correct
While all bootkits are rootkits, not all rootkits are bootkits. Bootkits specifically infect the boot process (MBR, VBR, or UEFI), whereas rootkits can operate at user or kernel mode without modifying boot components.
Mistake
Reinstalling the operating system removes all rootkits.
Correct
Reinstalling the OS does not remove bootkits that infect the MBR or UEFI firmware. Only rewriting the boot sectors or reflashing the firmware removes them.
Mistake
Antivirus software can detect and remove all rootkits.
Correct
Rootkits are designed to hide from antivirus by hooking system calls. Many rootkits are only detectable by offline scanners or memory analysis tools that run outside the infected OS.
Mistake
Secure Boot guarantees protection against bootkits.
Correct
Secure Boot can be bypassed if the bootkit uses a stolen certificate, exploits a vulnerability in the bootloader, or if Secure Boot is disabled or misconfigured. It is a strong defense but not foolproof.
A rootkit is a set of tools that hides malware presence by modifying system calls at the user or kernel level. A bootkit is a specific type of rootkit that infects the boot process (MBR, VBR, or UEFI firmware) and loads before the operating system, making it even more stealthy and persistent. The key difference is the infection vector: bootkits target the boot chain, while general rootkits operate after OS boot.
No, if the bootkit infects the MBR or UEFI firmware, reinstalling Windows will not remove it because those components are not overwritten by a standard OS installation. You must either rewrite the MBR (e.g., using bootrec /fixmbr) or reflash the UEFI firmware. For exam purposes, remember that bootkits survive OS reinstall.
Secure Boot verifies that each component loaded during the boot process (bootloader, kernel drivers) is digitally signed by a trusted authority. If a bootkit tries to load unsigned code, Secure Boot will block it. However, bootkits can bypass Secure Boot if they use stolen certificates or exploit vulnerabilities in signed bootloaders.
DKOM stands for Direct Kernel Object Manipulation. It involves modifying kernel data structures directly, such as the linked list of processes (EPROCESS blocks). By removing an entry from the list, the rootkit hides its process from tools that rely on the list (like Task Manager). Memory analysis tools like Volatility can detect hidden processes by scanning memory for EPROCESS structures.
Tools include: GMER (scans for SSDT hooks), RootkitRevealer (compares registry/file listings), Windows Defender Offline (boot-time scan), Kaspersky Rescue Disk, and memory analysis with Volatility. For bootkits, use bootrec /fixmbr or firmware scanners like CHIPSEC.
The attacker writes malicious code to the first sector of the hard disk (MBR) using raw disk write operations (e.g., via \.\PhysicalDrive0 on Windows). The original MBR is moved to another location (e.g., a hidden partition). During boot, the bootkit code executes first, then loads the original MBR to boot the OS, while intercepting all subsequent reads of the MBR to hide its presence.
The first known UEFI bootkit is LoJax, discovered in 2018 by ESET. It was used by the Sednit APT group (also known as APT28 or Fancy Bear) to target government and military organizations. LoJax writes its code to the SPI flash memory where UEFI firmware is stored, making it extremely persistent.
You've just covered Rootkits and Bootkits — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?