Firmware Integrity Monitoring: Catching Bootkits Before They Load
Why firmware attacks matter
You reinstall the OS. You rotate every credential. You wipe the disk. And the attacker is still there. That is what a bootkit does. It lives below the operating system, in the firmware layer that loads before your kernel even starts. Your antivirus cannot see it. Your EDR cannot reach it. Your fresh install boots right into compromised code.
This is not theoretical. BlackLotus was the first UEFI bootkit to bypass Secure Boot in the wild, sold for $5,000 on criminal forums. LoJax, attributed to APT28 (Fancy Bear), was the first in-the-wild UEFI rootkit discovered by ESET in 2018. It survived OS reinstalls by writing directly to SPI flash. MosaicRegressor targeted diplomats across Asia and Africa. CosmicStrand hid in motherboard firmware images distributed through supply chain compromise.
The common thread: if your firmware is compromised, nothing above it can be trusted. The kernel loads from firmware. The kernel loads your security tools. If the firmware is hostile, the entire chain is hostile. Most security tools never look at this layer. Inner Warden does.
Six runtime checks, no hardware dependency
The firmware integrity collector in v0.4.2 runs six checks every five minutes. All of them read from /sys/, /proc/, and /boot/efi/. No special hardware required. No kernel modules to load.
Reads /sys/firmware/efi/efivars/SecureBoot-* and alerts if Secure Boot is disabled or in setup mode. A disabled Secure Boot means any unsigned bootloader can run, which is exactly what BlackLotus exploits.
Reads /proc/sys/kernel/tainted and decodes the bitmask. Flags include unsigned module loaded, module forced load, out-of-tree module, unsigned module, and kernel live patching. A tainted kernel means something modified the kernel at runtime. That might be legitimate (a vendor driver) or it might be a rootkit loading its own module.
Checks for /sys/class/tpm/tpm0 to determine whether a TPM is available. With a TPM, the system can verify measured boot chains. Without one, firmware integrity relies entirely on software checks.
Verifies that /boot/grub/ and /boot/efi/ are not world-writable. If any user can modify boot files, an attacker with any foothold can plant a bootkit without needing root.
Checks whether Intel VT-d or AMD-Vi is enabled. Without IOMMU, a malicious PCI/Thunderbolt device can read and write arbitrary system memory via DMA. This is how hardware-based attacks bypass all software security.
Reads /sys/kernel/security/lockdown. When enabled, lockdown prevents even root from modifying the running kernel. It blocks /dev/mem access, unsigned module loading, and direct hardware I/O. A system without lockdown gives root unrestricted kernel access.
ESP integrity monitoring
The EFI System Partition (ESP) is the FAT32 partition that holds your boot loader. It is the first code that runs after the firmware hands off control. BlackLotus works by planting a malicious .efi binary into the ESP. ESPecter does the same thing with a modified Windows Boot Manager. If an attacker can write to the ESP, they own your boot chain.
Inner Warden builds a SHA-256 hash baseline of every file in the ESP at startup. Every five minutes, it rescans. If a new .efi file appears, or an existing one changes, the sensor fires a critical-severity incident. Legitimate boot loader updates are rare and predictable (a kernel update, a GRUB update). Anything else is suspicious.
/boot/efi/EFI/BOOT/
/boot/efi/EFI/ubuntu/
/boot/efi/EFI/debian/
/boot/efi/EFI/centos/
/boot/efi/EFI/fedora/
/boot/efi/EFI/Microsoft/Boot/The collector hashes every file in these directories, not just .efi files. A bootkit could also drop a malicious configuration file, a DXE driver, or a shell script that runs during boot. Everything gets hashed. Everything gets compared.
UEFI variable tracking
UEFI variables stored in NVRAM control the boot process. They determine which boot loader runs, whether Secure Boot is enforced, and which signatures are trusted or revoked. LoJax wrote directly to SPI flash to persist its payload in NVRAM. Other bootkits modify boot variables to redirect the boot chain to their own loader.
Inner Warden monitors these UEFI variables through /sys/firmware/efi/efivars/:
Any change from enabled to disabled at runtime is a critical alert. This should never happen during normal operation.
New boot entries can redirect the system to a malicious loader on next reboot. If a boot variable is added or modified outside of a known update, something is wrong.
The DBX contains hashes and certificates of known-bad boot loaders. If the DBX size decreases, someone is removing revocations. A bootkit might do this to un-revoke its own signature so it can pass Secure Boot validation again.
The Platform Key (PK) and Key Exchange Key (KEK) control who can modify Secure Boot policy. Changing these is equivalent to taking ownership of the Secure Boot chain. This should only happen during initial system setup.
ACPI table scanning
ACPI (Advanced Configuration and Power Interface) tables are provided by the firmware to the kernel at boot. They describe hardware configuration, power management, and device enumeration. They also contain AML bytecode that the kernel executes. This is the part that gets interesting for attackers.
The DSDT (Differentiated System Description Table) can contain AML instructions that access physical memory addresses. A legitimate DSDT handles things like telling the OS what happens when you close the laptop lid. A malicious DSDT can read and write kernel memory, install hooks, and persist code that survives across boots. This technique was demonstrated at Black Hat Europe 2006 in "Implementing and Detecting an ACPI BIOS Rootkit."
Inner Warden extracts ACPI tables from /sys/firmware/acpi/tables/ and hashes them at baseline. If a table changes between boots or during runtime (which should never happen on a healthy system), the sensor fires a critical alert. The collector also scans the DSDT for AML opcodes that reference suspicious memory regions. Legitimate power management does not need to touch kernel memory.
Firmware version tracking
DMI (Desktop Management Interface) data exposed through /sys/firmware/dmi/ contains the BIOS vendor, version string, and release date. Inner Warden reads this at startup and baselines it. On every subsequent check, it compares the current values against the baseline.
A firmware version change during normal operation is unusual. It either means someone performed a legitimate BIOS update (and you should know about it) or something modified the firmware without authorization. A version downgrade is even more suspicious, as attackers sometimes flash older firmware versions that contain known vulnerabilities they can exploit.
/sys/firmware/dmi/tables/DMI # Raw SMBIOS tables
/sys/class/dmi/id/bios_vendor # e.g., "Dell Inc."
/sys/class/dmi/id/bios_version # e.g., "2.17.0"
/sys/class/dmi/id/bios_date # e.g., "01/15/2024"Boot timing anomaly detection
SMM (System Management Mode) rootkits run in a special CPU mode that is invisible to the operating system. They intercept hardware interrupts and can keylog, modify disk I/O, or tamper with network traffic. The OS cannot detect them directly because SMM executes at a higher privilege level than the kernel.
But SMM rootkits have a side effect: they add latency. Every System Management Interrupt (SMI) pauses the CPU, executes the SMM handler, and resumes. A rootkit that intercepts keyboard interrupts or disk operations adds measurable delay to the boot process. Not much. Maybe a few hundred milliseconds. But it is consistent.
Inner Warden tracks boot time across reboots. It calculates the mean and standard deviation of boot duration. If the boot time deviates by more than two standard deviations for three or more consecutive boots, it flags the anomaly. One slow boot is nothing. Three in a row is a pattern worth investigating.
What each check catches
Different firmware threats target different layers. Here is what each Inner Warden check detects, mapped against known bootkit families:
| Check | Catches | How |
|---|---|---|
| ESP integrity | BlackLotus, ESPecter | Detects new or modified .efi binaries in the boot partition |
| UEFI variable tracking | LoJax, boot variable hijack | Detects NVRAM changes to SecureBoot, DBX, PK, KEK, Boot#### |
| ACPI scanning | ACPI rootkits, DSDT injection | Hashes ACPI tables, scans for AML memory access opcodes |
| Firmware version | Firmware downgrade, unauthorized flash | Baselines DMI/SMBIOS data, alerts on version changes |
| Secure Boot status | BlackLotus, any unsigned bootloader | Alerts if Secure Boot is disabled or in setup mode |
| Kernel taint flags | Rootkit kernel modules, unsigned drivers | Decodes taint bitmask, flags unsigned or forced modules |
| Boot timing | SMM rootkits, SMI handler keyloggers | Statistical anomaly detection across consecutive boots |
Coverage estimates
No software-only solution catches everything. Hardware implants at the Equation Group level (nation-state, physical access to the motherboard) will evade any OS-level detection. But here is what you get with each layer:
The 5% gap is hardware implants and supply-chain attacks that modify firmware before it reaches you. Closing that gap requires hardware attestation, which is a different problem entirely.
How innerwarden harden integrates firmware checks
The innerwarden harden command includes firmware checks as part of the security score. When you run it, the hardening advisor reads the same paths that the sensor monitors in production. The difference is that harden runs once and gives you a snapshot, while the sensor monitors continuously.
$ innerwarden harden --verbose
Firmware & Boot Integrity
✓ Secure Boot is enabled
x TPM not detected (-5)
✓ Kernel lockdown mode is active
✓ IOMMU (VT-d/AMD-Vi) is enabled
✓ Boot loader permissions are correct
✓ No kernel taint flags set
! BIOS version has not been checked against (-3)
known-good baseline (run innerwarden baseline)
Recommendation: Install a TPM 2.0 module or enable
fTPM in BIOS settings. Without TPM, measured boot
is not available, reducing firmware attack coverage
from 90% to 60-70%.If Secure Boot is disabled, the score drops. If the TPM is missing, you get a warning with actionable advice. If the kernel is tainted by unsigned modules, the advisor tells you which taint flags are set and what they mean. The goal is not just to flag problems. It is to tell you exactly what to do about them.
# Quick firmware check as part of full hardening scan
innerwarden harden
# Continuous monitoring (runs every 5 minutes automatically)
# Enabled by default in the sensor, no configuration needed
innerwarden configure capability firmwareWhat to do next
- eBPF for security : see how kernel-level monitoring complements firmware integrity checks for defense in depth.
- Linux hardening checklist : the full system hardening guide, including SSH, firewall, kernel parameters, and file permissions.
- AI isolation model : understand how firmware alerts flow through the AI triage pipeline for automated response.