A bootkit is malware that modifies the boot sectors of a drive so its code runs before the operating system loads. MITRE tracks this as T1542.003 in the Stealth and Persistence tactics for Linux and Windows.
Because a bootkit sits below the operating system, it is hard to find from inside it, and MITRE warns that full remediation can be difficult unless an organization suspects a bootkit and acts accordingly.
How attackers use it
How it works depends on the firmware type.
BIOS systems. After hardware initialization, the BIOS loads the Master Boot Record (MBR), the part of the disk that holds the boot loader. An adversary with raw access to the boot drive can overwrite it and send execution at startup to their own code instead of the normal boot loader. The MBR then passes control to the Volume Boot Record (VBR), and an adversary with the same access can overwrite that too.
UEFI systems. A bootkit may create or change files in the EFI system partition (ESP), the partition that lets the device start the operating system and other utilities. Files created or patched there can be used to run malicious kernel code.
In both cases the adversary needs privileged, low level access to the boot drive first. That is why the mitigations focus on privileged accounts and boot integrity.
How to detect it
MITRE's detection strategy covers raw disk access and boot file changes:
- Windows: raw access to physical drives, modification of boot records (MBR or VBR), and file creation or changes in the EFI system partition. Correlate privileged process execution with low level disk changes and unexpected driver or firmware interaction.
- Linux: suspicious writes to block devices, changes to bootloader files such as GRUB, initrd and vmlinuz, and unexpected changes in the EFI system partition. Watch privileged runs of utilities such as dd, grub-install or efibootmgr that change boot sectors or loader entries.
Practical monitoring ideas:
- Alert on processes that open a physical disk for writing, other than your known tools.
- Hash the files in the ESP and the boot folder on a schedule, and compare.
- Treat any bootloader change outside a package update or OS upgrade as an incident until explained.
- Track unsigned driver loads shortly after boot configuration changes.
How to reduce the risk
MITRE lists two mitigations:
- Boot Integrity. Use TPM technology and a secure or trusted boot process so system integrity cannot be silently undermined.
- Privileged Account Management. Make sure the right permissions are in place to stop adversaries reaching the privileged accounts needed to install a bootkit.
Additional hygiene: keep secure boot on, keep firmware current, restrict who can run disk tools as administrator, and plan how you would rebuild a machine from trusted media if you suspect boot level compromise, since cleaning from within the OS may not be enough.
Check your own environment
Read only checks:
# Windows, elevated PowerShell
Confirm-SecureBootUEFI
bcdedit /enum
# Linux
mokutil --sb-state
efibootmgr -v
Then ask:
- Is secure boot on for all endpoints and servers that support it?
- Do you record raw disk writes by processes on critical systems?
- Is there a baseline of boot loader and ESP file hashes?
- Do you have a rebuild procedure from trusted media for suspected boot level compromise?
Quick check
Where does a bootkit hide on a UEFI system?
In the EFI system partition, where it can create or modify files used at boot to run malicious kernel code. On BIOS systems it targets the MBR and VBR.
Why is a bootkit hard to clean?
It sits below the operating system and runs before it, so cleaning from inside the OS may not reach it. MITRE notes full remediation is difficult unless the organization suspects it and acts accordingly.
