Dissecting boot and kernel rootkits

Dissecting Boot and Kernel Rootkits

When to Use

• You have a sample (MBR/VBR image, UEFI module, or kernel driver) suspected of boot-process or kernel-level tampering and stealth.
• You need to identify the persistence vector and stealth technique class statically.

Do not use this on production firmware/boot media without acquisition — analyze a captured image. The skill reads bytes statically and executes nothing.

Prerequisites

• The boot image / UEFI module / driver (read inertly).

Safety & Handling

• Read bytes statically; never write the sample to boot media or load the driver.

Workflow

Step 1: Classify the artifact

python scripts/analyst.py classify sample.bin

Detects MBR/VBR (boot signature 0x55AA at 0x1FE), UEFI modules (PE with EFI subsystem / PI GUIDs / EFI_ strings), and kernel drivers (PE importing ntoskrnl/hal, .sys indicators).

Step 2: Identify tampering / hooking indicators

Flag disk-write primitives (Int 13h for MBR bootkits), SSDT/IRP hooking and Zw*/Ke* kernel APIs, DKOM strings, and driver-callback registration.

Step 3: Map the persistence vector

Determine whether persistence is via MBR/VBR overwrite, UEFI variable/module, or driver service.

Step 4: Document

Record the artifact type, persistence vector, and stealth technique class, mapping to ATT&CK.

Validation

• The artifact type is identified by concrete signatures (boot signature, PE subsystem, imports).
• Tampering/hooking indicators reference real primitives, not generic strings.
• The persistence vector is stated with its evidence.

Pitfalls

• A legitimate bootloader/driver resembling a bootkit/rootkit — corroborate with behavior.
• UEFI modules requiring firmware-volume parsing beyond simple PE checks.
• Kernel samples needing signed-driver and callback context to confirm stealth.

References

• See references/api-reference.md for the classifier.
• ATT&CK T1542.003 and T1014 (linked in frontmatter).