Auditing UEFI Firmware with CHIPSEC

Authorized Use Only: CHIPSEC loads a kernel driver and reads/writes low-level hardware registers, SPI flash, and SMM. Run it only on systems you own or are explicitly authorized to assess, ideally on dedicated test hardware. Misuse (especially write/modify modules) can brick a machine. Never run write-capable modules on production systems.

Overview

CHIPSEC is the open-source Platform Security Assessment Framework created by Intel's Advanced Threat Research team. It inspects the low-level security configuration of x86 platform firmware and hardware — the layer below the operating system where bootkits and firmware implants live. CHIPSEC loads a signed kernel driver (Linux, Windows, or it can run from the UEFI shell) to read and write hardware registers, Model-Specific Registers (MSRs), PCI config space, SPI flash, and UEFI variables, then runs an automated test suite that checks whether the platform's defensive locks are actually engaged.

The threat CHIPSEC addresses is MITRE ATT&CK T1542.001 — Pre-OS Boot: System Firmware: adversaries who modify system firmware (the BIOS/UEFI image on SPI flash) to gain stealthy, persistent, OS-survivable control. Firmware implants persist across OS reinstall and disk replacement and are invisible to most EDR. CHIPSEC's value is verifying the prerequisites that prevent such implants: that the SPI flash BIOS region is write-protected (BIOS_CNTL BLE/SMM_BWP, SPI Protected Ranges), that the flash descriptor locks region access, that SMRAM/SMRR are configured, and that Secure Boot variables are protected. It also dumps the SPI flash for offline forensic comparison.

Sources: Intel/CHIPSEC project (https://github.com/chipsec/chipsec), CHIPSEC documentation (https://chipsec.github.io/).

When to Use

• Baseline firmware-security assessment of a new laptop/server platform or fleet image
• Verifying that BIOS write protection and SPI flash locks are correctly enabled by the OEM
• Firmware forensics: dumping SPI flash to compare against a known-good image
• Validating Secure Boot variable protection and S3 boot-script protection
• Hunting for evidence of a firmware implant or misconfiguration enabling one

Prerequisites

• Physical or admin/root access to the target x86 platform (Intel or AMD)
• Linux (root) or Windows (Administrator), or a UEFI shell environment
• Ability to load a kernel driver (Secure Boot may need to allow the CHIPSEC driver, or use --no_driver for limited checks)
• Python 3.8+ and a C compiler/build tools for the kernel module on Linux
• Dedicated test hardware strongly recommended

Install CHIPSEC:

# From PyPI
pip install chipsec

# Or from source (builds the kernel helper/driver)
git clone https://github.com/chipsec/chipsec
cd chipsec
python setup.py install        # builds and installs, including the Linux driver

# Verify
sudo chipsec_main --help
sudo chipsec_util --help

Objectives

• Run the full automated platform-security test suite and interpret PASS/FAIL/WARNING
• Verify BIOS write protection (BIOS_CNTL) and SPI Protected Ranges
• Verify the SPI flash descriptor locks region read/write access
• Verify SMRAM/SMRR and SMI handler protections
• Verify Secure Boot variable protection and S3 boot-script protection
• Dump SPI flash and decode it for offline analysis
• Enumerate UEFI variables and detect anomalous/unexpected entries

MITRE ATT&CK Mapping

CHIPSEC defends against T1542.001 by verifying that the controls preventing unauthorized firmware modification are enabled. A FAIL on common.bios_wp (BIOS not write-protected) or chipsec.modules.common.spi_lock (flash descriptor unlocked) means an attacker with OS privileges could rewrite the SPI flash and implant persistent firmware — exactly the precondition for this technique.

Workflow

Step 1: Run the full automated test suite

chipsec_main with no module argument runs every applicable security check for the detected platform and prints a summary of PASS/FAIL/WARNING/INFORMATION results.

sudo chipsec_main

# Save machine-readable output for reporting / diffing
sudo chipsec_main -j results.json -x results.xml -l chipsec.log

Step 2: Run the core firmware-protection modules individually

…