/auditing-uefi-firmware-with-chipsec
Use Intel CHIPSEC to assess platform firmware configuration, SPI flash write protection, BIOS lock, SMM/SMRR, and Secure Boot variable state, dump SPI flash, and triage UEFI variables for firmware-level threats.
$ npx -y skills add mukul975/Anthropic-Cybersecurity-Skills --skill auditing-uefi-firmware-with-chipsec --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/auditing-uefi-firmware-with-chipsec
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use Intel CHIPSEC to assess platform firmware configuration, SPI flash write protection, BIOS lock, SMM/SMRR, and Secure Boot variable state, dump SPI flash, and triage UEFI variables for firmware-level threats.
SKILL.md
auditing-uefi-firmware-with-chipsec.SKILL.mdname: auditing-uefi-firmware-with-chipsec
description: Use Intel CHIPSEC to assess platform firmware configuration, SPI flash write protection, BIOS lock, SMM/SMRR, and Secure Boot variable state, dump SPI flash, and triage UEFI variables for firmware-level threats.
domain: cybersecurity
subdomain: hardware-firmware-security
tags:
- hardware-firmware-security
- uefi
- chipsec
- spi-flash
- bios-write-protection
- secure-boot
- firmware-assessment
- platform-security
version: '1.0'
author: mahipal
license: Apache-2.0
nist_csf:
- ID.AM-02
mitre_attack:
- T1542.001
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
| Technique ID | Name | Tactic | |--------------|------|--------| | T1542.001 | Pre-OS Boot: System Firmware | Persistence / Defense Evasion |
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
The `common` module group contains the OEM-independent security checks. Run the group or specific modules:
# Run the whole common group
sudo chipsec_main -m common
# BIOS write protection: checks BIOS_CNTL BLE/SMM_BWP and SPI protected ranges
sudo chipsec_main -m common.bios_wp
# SPI flash descriptor lock (FLOCKDN) — are flash region accesses locked?
sudo chipsec_main -m common.spi_lock
# SMRR programming — protects SMRAM from cache-based attacks
sudo chipsec_main -m common.smrr
# SMM BIOS write protection
sudo chipsec_main -m common.smm
# S3 resume boot-script protection (against bootscript table attacks)
sudo chipsec_main -m common.uefi.s3bootscript
Step 3: Verify Secure Boot variable protection
# Checks that Secure Boot UEFI variables are properly protected
sudo chipsec_main -m common.secureboot.variables
# To actively test write protection of the variables (test hardware ONLY):
sudo chipsec_main -m common.secureboot.variables -a modify
Read more
name: auditing-uefi-firmware-with-chipsec description: Use Intel CHIPSEC to assess platform firmware configuration, SPI flash write protection, BIOS lock, SMM/SMRR, and Secure Boot variable state, dump SPI flash, and triage UEFI variables for firmware-level threats. domain: cybersecurity subdomain: hardware-firmware-security tags: - hardware-firmware-security - uefi - chipsec - spi-flash - bios-write-protection - secure-boot - firmware-assessment - platform-security version: '1.0' author: mahipal license: Apache-2.0 nist_csf: - ID.AM-02 mitre_attack: - T1542.001
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
| Technique ID | Name | Tactic | |--------------|------|--------| | T1542.001 | Pre-OS Boot: System Firmware | Persistence / Defense Evasion |
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
The `common` module group contains the OEM-independent security checks. Run the group or specific modules:
# Run the whole common group sudo chipsec_main -m common # BIOS write protection: checks BIOS_CNTL BLE/SMM_BWP and SPI protected ranges sudo chipsec_main -m common.bios_wp # SPI flash descriptor lock (FLOCKDN) — are flash region accesses locked? sudo chipsec_main -m common.spi_lock # SMRR programming — protects SMRAM from cache-based attacks sudo chipsec_main -m common.smrr # SMM BIOS write protection sudo chipsec_main -m common.smm # S3 resume boot-script protection (against bootscript table attacks) sudo chipsec_main -m common.uefi.s3bootscript
Step 3: Verify Secure Boot variable protection
# Checks that Secure Boot UEFI variables are properly protected sudo chipsec_main -m common.secureboot.variables # To actively test write protection of the variables (test hardware ONLY): sudo chipsec_main -m common.secureboot.variables -a modify
817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0
Repo: mukul975/Anthropic-Cybersecurity-Skills
Other skills on cybersecurity-skills.
- /abusing-dpapi-for-credential-access
Extract and decrypt Windows DPAPI-protected secrets (Credential Manager, browser logins/cookies, Wi-Fi credentials, KeePass keys) online or offline using SharpDPAPI, SharpChrome, Mimikatz, or Impacket's dpapi.py, including domain-wide decryption via the DPAPI backup key. Use
Open skill - /abusing-shadow-credentials-for-privesc
Take over Active Directory accounts by writing attacker-controlled public keys to msDS-KeyCredentialLink (Shadow Credentials) with pyWhisker, Whisker, or Certipy, then authenticate via PKINIT to recover the target's NT hash without a password reset. Use when BloodHound shows
Open skill - /achieving-cmmc-level-2-compliance
Prepare a defense-contractor environment for CMMC Level 2 certification: scope CUI and FCI, implement the 110 NIST SP 800-171 Rev 2 security requirements across 14 families, compute the SPRS score with the DoD Assessment Methodology, manage a compliant POA&M, and ready the
Open skill - /acquiring-disk-image-with-dd-and-dcfldd
Create forensically sound bit-for-bit disk images with dd or dcfldd on a Linux forensic workstation, preserving evidence integrity through hash verification (MD5/SHA) during acquisition. Use when imaging a suspect drive, USB device, or memory card for investigation, preserving
Open skill - /analyzing-active-directory-acl-abuse
Detect dangerous ACL misconfigurations in Active Directory using ldap3
Open skill - /analyzing-android-malware-with-apktool
Perform static analysis of Android APK malware using apktool for resource decompilation, jadx for Java source recovery, and androguard for manifest inspection, dangerous permission-combination detection, and identification of obfuscated code, dynamic code loading, and
Open skill

