Analyzes bootkit and advanced rootkit malware infecting the Master Boot Record (MBR), Volume Boot Record (VBR), or UEFI firmware for below-OS persistence, covering boot sector analysis, UEFI module inspection, and anti-rootkit detection. Use when compromise survives OS reinstallation or antivirus/ED

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 Term Definition Bootkit Malware that infects the boot process (MBR, VBR, UEFI) to execute before the operating system loads, gaining persistent low level control MBR (Master Boot Record) First 512 bytes of a disk containing bootstrap code and partition table; MBR bootkits replace this code with malicious loaders UEFI (Unified Extensible Firmware Interface) Modern firmware interface replacing BIOS; UEFI bootkits implant malicious modules in firmware volumes or modify the ESP Secure Boot UEFI security feature verifying digital signatures of boot components; bootkits like BlackLotus exploit vulnerabilities to bypass it SPI Flash Flash memory chip storing UEFI firmware; advanced bootkits like LoJax and MoonBounce modify SPI flash for firmware level persistence DKOM (Direct Kernel Object Manipulation) Rootkit technique modifying kernel structures to hide processes, files, and network connections without hooking functions Driver Signature Enforcement (DSE) Windows security feature requiring kernel drivers to be digitally signed; bootkits disable DSE during boot to load unsigned rootkit drivers 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 : 1. Boot from a Linux live USB to avoid executing any compromised OS components 2. Dump the SPI flash firmware using chipsec or flashrom for offline analysis 3. Dump the MBR and VBR sectors with dd for boot sector analysis 4. Copy the EFI System Partition for bootloader integrity verification 5. Open the SPI dump in UEFITool and compare module GUIDs against vendor provided firmware 6. Look for additional or modified DXE drivers that should not be present 7. Analyze any suspicious modules with Ghidra (x86 64 UEFI module format) 8. 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) Output Format

analyzing-bootkit-and-rootkit-samples