Lion Cipher Lab
Characterize a bootkit: persistence that loads before Windows does
- Digital Forensics & IR (DFIR)
- Advanced
- ~50 min
- Free · no account required
Why it matters
A bootkit is the nastiest kind of persistence: it plants itself in the code that runs BEFORE the operating system — the firmware boot path, the EFI System Partition, the boot record — so it is already in control by the time Windows, and therefore any antivirus, starts. That is why a bootkit survives a full OS reinstall and is invisible to the tools running inside the OS: whatever loads first gets to decide what everything after it is allowed to see. If you can only ask the live machine 'are you infected?', a good bootkit will confidently answer 'no'. The professional skill this drill builds…
What you'll learn
- reading an EFI System Partition (ESP) listing for unauthorized .efi binaries
- comparing pre-OS boot components against a known-good baseline (hash + signature)
- interpreting UEFI boot entries and BootOrder (efibootmgr / bcdedit output)
- spotting a modified Volume Boot Record / MBR at the disk-sector level
- finding a rogue boot-start driver in an offline registry hive
- judgment: why a running OS cannot be trusted to detect what loads before it
- mapping findings to MITRE ATT&CK T1542 / T1542.003 and to the Secure Boot defense
Steps in this lab
- The scenario, and what a bootkit actually is
- The one rule of bootkit hunting: do not trust the running OS
- Artifact 1 — the EFI System Partition listing (read the ESP)
- Artifact 2 — hash and signature: prove the boot file was tampered
- Artifact 3 — boot entries and BootOrder (what the firmware runs first)
- Artifact 4 — the disk-sector view (a modified VBR, the BIOS branch)
- Artifact 5 — the rogue boot-start driver (offline registry hive)
- WHEN this evidence answers the question — and when it can still fool you
- What you actually learned