Analyzing Bootkit And Rootkit Samples

---
name: analyzing-bootkit-and-rootkit-samples
description: Analyzes bootkit and advanced rootkit malware that infects the Master Boot Record (MBR), Volume Boot Record (VBR), or UEFI firmware to gain persistence below the operating system. Covers boot
  sector analysis, UEFI module Denetle:ion, and anti-rootkit Tespit techniques. Activates for requests involving bootkit analysis, MBR malware investigation, UEFI persistence analysis, or pre-OS malware
  Tespit.
tags:
- cybersecurity
- bootkit
- rootkit
- siber-güvenlik
- MBR-analysis
- malware-analysis
- fetih
- malware
- UEFI
triggers:
- analyzing
- bootkit
- exploit
- forensic
- hash
- log
- malware
- network
- ransomware
- rootkit
- samples
- threat
category: malware-analysis
source_subdomain: malware-analysis
nist_csf:
- DE.AE-02
- RS.AN-03
- ID.RA-01
- DE.CM-01
adapted_for: fetih
---

# Analyzing Bootkit and Rootkit Samples


## Ne Zaman Kullanılır

- A system shows signs of compromise that persist through OS reinstallation
- Antivirus and EDR are unable to tespit etme
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 Dağıt: bootkits (APT28, APT41, Equation Group)

**Kullanma:** for standard user-mode malware; bootkits and rootkits operate at a fundamentally different level requiring specialized analysis techniques.

## Ön Gereksinimler

- 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 Tespit
- Bootable Linux live USB for offline system analysis

## İş Akışı

### Adım 1: Acquire Boot Sectors and Firmware

Extract MBR, VBR, and UEFI firmware for offline analysis:

```bash
dd if=/dev/sda of=mbr.bin bs=512 count=1

dd if=/dev/sda of=first_track.bin bs=512 count=63

dd if=/dev/sda1 of=vbr.bin bs=512 count=1

mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/

python chipsec_util.py spi dump firmware.rom

flashrom -p internal -r firmware.rom

sha256sum firmware.rom
```

### Adım 2: Analyze MBR/VBR for Bootkit Code

İncele: boot sector code for malicious modifications:

```bash
ndisasm -b16 mbr.bin > mbr_disasm.txt


python3 << 'PYEOF'
with open("mbr.bin", "rb") as f:
    mbr = f.read()

if mbr[510:512] == b'\x55\xAA':
    print("[*] Valid MBR signature (0x55AA)")
else:
    print("[!] Invalid MBR signature")

bootkit_sigs = {
    b'\xE8\x00\x00\x5E\x81\xEE': "TDL4/Alureon bootkit",
    b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "Standard Windows MBR (clean)",
    b'\xEB\x5A\x90\x4E\x54\x46\x53': "Standard NTFS VBR (clean)",
}

for sig, name in bootkit_sigs.items():
    if sig in mbr:
        print(f"[{'!' if 'clean' not in name else '*'}] Signature match: {name}")

print("\nPartition Table:")
for i in range(4):
    offset = 446 + (i * 16)
    entry = mbr[offset:offset+16]
    if entry != b'\x00' * 16:
        boot_flag = "Active" if entry[0] == 0x80 else "Inactive"
        part_type = entry[4]
        start_lba = int.from_bytes(entry[8:12], 'little')
        size_lba = int.from_bytes(entry[12:16], 'little')
        print(f"  Partition {i+1}: Type=0x{part_type:02X} {boot_flag} Start=LBA {start_lba} Size={size_lba} sectors")
PYEOF
```

### Adım 3: Analyze UEFI Firmware for Implants

Denetle: UEFI firmware volumes for unauthorized modules:

```bash
UEFIExtract firmware.rom all

Bul: firmware.rom.dump -name "*.efi" -exec file {} \;


python chipsec_main.py -m common.secureboot.variables

python chipsec_main.py -m common.bios_wp

yara -r uefi_malware.yar firmware.rom
```

```
Known UEFI Bootkit Tespit Points:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28):
  - Modified SPI flash
  - Added DXE driver that drops agent to Windows
  - Persists through OS reinstall and disk replacement

BlackLotus:
  - Exploits CVE-2022-21894 to bypass Secure Boot
  - Modifies EFI System Partition bootloader
  - Installs kernel driver during boot

CosmicStrand:
  - Modifies CORE_DXE firmware module
  - Hooks kernel initialization during boot
  - Drops shellcode into Windows kernel memory

MoonBounce:
  - SPI flash implant in CORE_DXE module
  - Modified GetVariable() function
  - Dağıt:s user-mode implant through boot chain

ESPecter:
  - Modifies Windows Boot Manager on ESP
  - Patches winload.efi to disable DSE
  - Loads unsigned kernel driver
```

### Adım 4: tespit etme
Kernel-Level Rootkit Behavior

Şunu analiz et: running system for rootkit artifacts:

```bash
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"

vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt

vol3 -f memory.dmp windows.callbacks

vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules

vol3 -f memory.dmp windows.driverscan | while read line; do
    driver_path=$(echo "$line" | awk '{print $NF}')
    if [ -f "$driver_path" ]; then
        sigcheck -nobanner "$driver_path" 2>/dev/null | grep "Unsigned"
    fi
done

vol3 -f memory.dmp windows.idt
```

### Adım 5: Boot Process Integrity Verification

Verify the integrity of the entire boot chain:

```bash
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi

sigcheck -a C:\Windows\System32\winload.efi

sigcheck -a C:\Windows\System32\ntoskrnl.exe

bcdedit /enum firmware

Confirm-SecureBootUEFI  # PowerShell cmdlet

bcdedit /v

bcdedit | Bul:str /i "testsigning nointegritychecks debug"
```

### Adım 6: Document Bootkit/Rootkit Analysis

Compile comprehensive analysis Bul:ings:

```
Analysis should document:
- Boot sector (MBR/VBR) integrity status with hex comparison
- UEFI firmware module inventory and integrity verification
- Secure Boot status and any bypass mechanisms Detected
- Kernel-level hooks (SSDT, IDT, IRP, inline) identified
- Hidden processes, drivers, and files discovered
- Persistence mechanism (SPI flash, ESP, MBR, kernel driver)
- Boot chain integrity verification results
- Attribution to known bootkit families if possible
- Remediation steps (reflash firmware, rebuild MBR, replace hardware)
```

## 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 Denetle:ing 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 Tespit
- **GMER**: Windows rootkit Tespit 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 Bul:s 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. Şunu aç: SPI dump in UEFITool and compare module GUIDs against vendor-provided firmware
6. Ara: 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

```
BOOTKIT / ROOTKIT ANALYSIS REPORT
====================================
System:           Dell OptiPlex 7090 (UEFI, TPM 2.0)
Firmware Version: 1.15.0 (Dell)
Secure Boot:      ENABLED (but bypassed)
Capture Method:   Linux Live USB + chipsec SPI dump

MBR/VBR ANALYSIS
MBR Signature:    Valid (0x55AA)
MBR Code:         MATCHES standard Windows 10 MBR (clean)
VBR Code:         MATCHES standard NTFS VBR (clean)

UEFI FIRMWARE ANALYSIS
Total Modules:    287
Vendor Expected:  285
Extra Modules:    2 UNAUTHORIZED
  [!] DXE Driver GUID: {ABCD1234-...} "SmmAccessDxe_mod" (MODIFIED)
      Original Size: 12,288 bytes
      Current Size:  45,056 bytes (32KB ADDED)
      Entropy: 7.82 (HIGH - encrypted payload)

  [!] DXE Driver GUID: {EFGH5678-...} "UefiPayloadDxe" (NEW - not in vendor firmware)
      Size: 28,672 bytes
      Function: Drops persistence agent during boot

BOOT CHAIN INTEGRITY
bootmgfw.efi:     MODIFIED (hash mismatch, Secure Boot bypass via CVE-2022-21894)
winload.efi:      MODIFIED (DSE disabled at load time)
ntoskrnl.exe:     CLEAN (but unsigned driver loaded after boot)

KERNEL ROOTKIT COMPONENTS
Driver:           C:\Windows\System32\drivers\null_mod.sys (unsigned, hidden)
SSDT Hooks:       3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Hidden Processes: 2 (PID 6784: beacon.exe, PID 6812: keylog.exe)
Hidden Files:     C:\Windows\System32\drivers\null_mod.sys

ATTRIBUTION
Family:           BlackLotus variant
Confidence:       HIGH (CVE-2022-21894 exploit, ESP modification pattern matches)

REMEDIATION
1. Reflash SPI firmware with clean vendor image via hardware programmer
2. Rebuild EFI System Partition from clean Windows installation media
3. Reinstall OS from verified media
4. Enable all firmware write protections
5. Update firmware to latest version (patches CVE-2022-21894)
```

<!--
  ⚔ Bu skill FETIH AI Agent icin gelistirilmistir — https://github.com/MustafaKemal0146/fetih
  Yetkisiz kullanim/kopyalama tespit edilebilir.
  hash: 362665b31fb2e2d4
-->