Analyzing Bootkit and Rootkit Samples
When to Use
- A system shows signs of compromise that persist through OS reinstallation
- Antivirus and EDR are unable to detect malware despite clear evidence of compromise
- UEFI Secure Boot has been disabled or shows integrity violations
- Memory forensics reveals rootkit behavior (hidden processes, hooked system calls)
- Investigating nation-state level threats known to deploy bootkits (APT28, APT41, Equation Group)
Do not use for standard user-mode malware; bootkits and rootkits operate at a fundamentally different level requiring specialized analysis techniques.
Prerequisites
- Disk imaging tools (dd, FTK Imager) for acquiring MBR/VBR sectors
- UEFITool for UEFI firmware volume analysis and module extraction
- chipsec for hardware-level firmware security assessment
- Ghidra with x86 real-mode and 16-bit support for MBR code analysis
- Volatility 3 for kernel-level rootkit artifact detection
- Bootable Linux live USB for offline system analysis
Workflow
Step 1: Acquire Boot Sectors and Firmware
Extract MBR, VBR, and UEFI firmware for offline analysis:
Step 2: Analyze MBR/VBR for Bootkit Code
Examine boot sector code for malicious modifications:
Step 3: Analyze UEFI Firmware for Implants
Inspect UEFI firmware volumes for unauthorized modules:
Step 4: Detect Kernel-Level Rootkit Behavior
Analyze the running system for rootkit artifacts:
Step 5: Boot Process Integrity Verification
Verify the integrity of the entire boot chain:
Step 6: Document Bootkit/Rootkit Analysis
Compile comprehensive analysis findings:
Key Concepts
Tools & Systems
- UEFITool: Open-source UEFI firmware image editor and parser for inspecting firmware volumes, drivers, and modules
- chipsec: Intel hardware security assessment framework for verifying SPI flash protection, Secure Boot, and UEFI configuration
- Volatility: Memory forensics framework with SSDT, IDT, callback, and driver analysis plugins for kernel rootkit detection
- GMER: Windows rootkit detection tool scanning for SSDT hooks, IDT hooks, hidden processes, and modified kernel modules
- Bootkits Analyzer: Specialized tool for analyzing MBR/VBR code including disassembly and comparison against known-good baselines
Common Scenarios
Scenario: Investigating Persistent Compromise Surviving OS Reinstallation
Context: An organization reimaged a compromised workstation, but the same C2 beaconing resumed within hours. Standard disk forensics finds no malware. UEFI bootkit is suspected.
Approach:
- Boot from a Linux live USB to avoid executing any compromised OS components
- Dump the SPI flash firmware using chipsec or flashrom for offline analysis
- Dump the MBR and VBR sectors with dd for boot sector analysis
- Copy the EFI System Partition for bootloader integrity verification
- Open the SPI dump in UEFITool and compare module GUIDs against vendor-provided firmware
- Look for additional or modified DXE drivers that should not be present
- Analyze any suspicious modules with Ghidra (x86_64 UEFI module format)
- Verify Secure Boot configuration and check for exploit-based bypasses
Pitfalls:
- Analyzing the system while the compromised OS is running (rootkit may hide from live analysis)
- Not checking SPI flash (only analyzing disk-based boot components misses firmware-level implants)
- Assuming Secure Boot prevents all bootkits (known bypasses exist, e.g., CVE-2022-21894)
- Not preserving the original firmware dump before reflashing (critical evidence for attribution)


