Hunting Bootkits in the EFI System Partition

Overview

The EFI System Partition (ESP) is a small FAT32-formatted partition that the platform firmware reads at power-on to locate and execute the operating system's boot loader. Because it executes before the operating system, kernel, and any EDR agent, the ESP is one of the most coveted persistence locations for advanced adversaries. UEFI bootkits that live on the ESP survive OS reinstallation, disk reformatting of the OS partition, and most endpoint defenses.

This skill follows the detection research published by Eclypsium ("Enhanced Threat Detection: Bootloaders, Bootkits, and Secure Boot", and the Bootkitty and Glupteba analyses) and aligns with the ESP-hunting methodology Rapid7 documented for Velociraptor (Windows.Forensics.UEFI, Windows.Detection.Yara.UEFI). The threat context is concrete and current:

• ESPecter (ESET, 2021) — a UEFI bootkit that persists on the ESP as a patched Windows Boot Manager (bootmgfw.efi) plus malicious kernel-mode drivers. It marked the move of UEFI threats from SPI flash to the ESP, where they are far easier to deploy.
• BlackLotus (2023) — the first in-the-wild UEFI bootkit able to bypass Secure Boot on fully patched Windows 11 by exploiting CVE-2022-21894 ("baton drop") and staging a vulnerable signed bootmgfw.efi on the ESP.
• Bootkitty (2024) — the first UEFI bootkit targeting Linux, dropped onto the ESP.
• Glupteba — commodity malware whose UEFI variant replaces software on the EFI partition.

The core detection insight from Eclypsium and Rapid7 is that the bootloader normally changes only during a vendor or OS update; an out-of-band change to ESP binaries, an unsigned or untrusted-signed boot loader, or any file in the ESP root that is not under the EFI/ directory is a high-fidelity indicator of compromise. This skill builds that baseline and hunts deviations from it.

When to Use

• During proactive threat hunts for firmware/bootkit persistence (MITRE ATT&CK T1542.003 — Pre-OS Boot: Bootkit)
• After an incident where an adversary achieved SYSTEM/root and may have established below-OS persistence
• When validating Secure Boot posture across a fleet and confirming boot-chain integrity
• As a periodic integrity check, comparing the current ESP contents against a trusted golden baseline
• When triaging hosts that show measured-boot (TPM PCR) mismatches

Prerequisites

• Administrative/root access to the target host (mounting and reading the ESP requires elevation)
• Linux analysis tooling — install on Debian/Ubuntu:

  sudo apt-get update
  sudo apt-get install -y sbsigntool pesign efitools efibootmgr binwalk yara
  pip install pefile
  

• UEFITool for inspecting firmware/binaries (download from https://github.com/LongSoft/UEFITool/releases)
• A trusted golden baseline of EFI binary hashes for the OS/vendor versions in scope (build it once on a known-clean, freshly imaged host)
• For Windows targets: WinPE or a forensic boot environment, or Velociraptor with the Windows.Forensics.UEFI artifact

Objectives

• Mount and enumerate the ESP read-only without altering evidence
• Inventory every EFI binary and compute cryptographic hashes
• Verify Secure Boot signatures on each boot loader against trusted keys
• Compare contents against a golden baseline to surface out-of-band changes
• YARA-scan ESP binaries for known bootkit signatures
• Flag anomalies: files outside EFI/, unsigned loaders, modified bootmgfw.efi/grubx64.efi, and tampered boot entries
• Confirm measured-boot (TPM PCR 0/2/4) integrity where TPM is present

MITRE ATT&CK Mapping

Workflow

Step 1: Identify and mount the ESP read-only

The ESP is a FAT32 partition, usually flagged EF00 (GPT) or esp,boot. Locate it and mount read-only to preserve evidence.

# Identify the ESP (type code EF00 / "EFI System")
sudo lsblk -o NAME,FSTYPE,PARTTYPENAME,MOUNTPOINT
sudo fdisk -l | grep -i "EFI System"

# Mount the ESP read-only (replace /dev/sda1 with the identified partition)
sudo mkdir -p /mnt/esp
sudo mount -o ro,umask=077 /dev/sda1 /mnt/esp

# Confirm the canonical layout: EFI/ should be the only top-level dir

…