analyzing-uefi-bootkit-persistence skill (Anthropic-Cybersecurity-Skills)
- Install
- SKILL.md (verbatim)
- When to Use
- Prerequisites
- Workflow
- Step 1: Dump SPI Flash Firmware
- Step 2: Inspect UEFI Variables
- Step 3: Analyze EFI System Partition (ESP)
- Step 4: Scan Firmware for Known Bootkit Signatures
- Step 5: Detect Secure Boot Bypass Mechanisms
- Step 6: Perform Boot Chain Integrity Verification
- Step 7: Document UEFI Bootkit Analysis Findings
- Key Concepts
- Tools & Systems
- Common Scenarios
- Scenario: Investigating Persistent Compromise Surviving OS Reinstallation
- Output Format
- Other files in this skill
- references/api-reference.md (verbatim)
- chipsec - Platform Security Assessment Framework
- SPI Flash Operations
- UEFI Variable Operations
- Security Assessment Modules
- Firmware Whitelist Module
- Key Modules Reference
- UEFITool / UEFIExtract
- UEFIExtract CLI
- Output Structure
- Secure Boot Variable GUIDs
- flashrom - SPI Flash Programmer
- Syntax
- sigcheck - Signature Verification (Windows)
- Syntax
- bcdedit - Boot Configuration (Windows)
- Syntax
- YARA - Firmware Pattern Scanning
- UEFI Bootkit Rules
- Example UEFI Detection Rule
What it does. 'Analyzes UEFI bootkit persistence (SPI flash implants, ESP modifications, Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).
| Upstream | mukul975/Anthropic-Cybersecurity-Skills |
| Skill file | skills/analyzing-uefi-bootkit-persistence/SKILL.md |
| License | Apache-2.0 (skill folder LICENSE) |
| Author | mukul975 |
| Fetched | 2026-09-10 |
Install
npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill analyzing-uefi-bootkit-persistence, or copy the skill folder into~/.claude/skills/analyzing-uefi-bootkit-persistence/.- Raw file:
curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/analyzing-uefi-bootkit-persistence/SKILL.md
SKILL.md (verbatim)
name: analyzing-uefi-bootkit-persistence
description: 'Analyzes UEFI bootkit persistence (SPI flash implants, ESP modifications,
Secure Boot bypass, UEFI variable manipulation) using chipsec for firmware integrity
verification, detecting known families like BlackLotus, LoJax, and MoonBounce.
Use for UEFI malware analysis, firmware persistence investigation, or Secure Boot
bypass detection.
'
domain: cybersecurity
subdomain: firmware-security
tags:
- UEFI
- bootkit
- firmware
- Secure-Boot
- chipsec
- ESP
- persistence
version: 1.0.0
author: mukul975
license: Apache-2.0
d3fend_techniques:
- Platform Hardening
- Restore Object
- Platform Monitoring
- Firmware Verification
- Firmware Embedded Monitoring Code
nist_csf:
- ID.RA-01
- PR.PS-01
- PR.PS-02
mitre_attack:
- T1542.001
- T1542.003
- T1553.006
- T1542
- T1014
Analyzing UEFI Bootkit Persistence
When to Use
- A compromised system re-establishes C2 communication after OS reinstallation or disk replacement
- Secure Boot has been tampered with, disabled, or shows unexpected Machine Owner Key (MOK) enrollment
- Firmware integrity verification fails against vendor-provided baselines
- Memory forensics reveals rootkit components loading during early boot phase
- Investigating advanced persistent threat (APT) campaigns known to deploy UEFI implants
- Auditing firmware security posture for enterprise endpoint hardening
Do not use for standard MBR-based bootkits on legacy BIOS systems without UEFI; use MBR/VBR bootkit analysis instead.
Prerequisites
- chipsec framework for SPI flash dumping, UEFI variable inspection, and firmware security modules
- UEFITool / UEFIExtract for firmware volume parsing and DXE driver extraction
- Python 3.8+ with struct, hashlib, subprocess, and os modules
- Bootable Linux live USB for offline analysis (avoid running compromised OS)
- Volatility 3 for memory forensics of boot-phase artifacts
- YARA with UEFI malware rule sets for pattern-based detection
- Access to vendor firmware baselines for integrity comparison
Workflow
Step 1: Dump SPI Flash Firmware
Acquire the UEFI firmware from the SPI flash chip for offline analysis:
# Using chipsec to dump SPI flash contents
python chipsec_util.py spi dump firmware_dump.rom
# Using flashrom as an alternative
flashrom -p internal -r firmware_dump.rom
# Verify dump integrity
sha256sum firmware_dump.rom
# Read SPI flash descriptor information
python chipsec_util.py spi info
# Check SPI flash region access permissions
python chipsec_main.py -m common.spi_access
# Verify BIOS write protection is enabled
python chipsec_main.py -m common.bios_wp
# Check SPI flash controller lock
python chipsec_main.py -m common.spi_lock
Step 2: Inspect UEFI Variables
Enumerate and analyze UEFI variables for unauthorized modifications:
# List all UEFI variables on a live system
python chipsec_util.py uefi var-list
# List UEFI variables from a SPI flash dump
python chipsec_util.py uefi var-list-spi firmware_dump.rom
# Read specific Secure Boot variables
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F
# Dump UEFI key databases for analysis
python chipsec_util.py uefi keys
# Check Secure Boot configuration module
python chipsec_main.py -m common.secureboot.variables
Step 3: Analyze EFI System Partition (ESP)
Inspect the ESP for unauthorized or modified boot components:
# Mount ESP (typically the first FAT32 partition, ~100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp
# List all files on ESP with timestamps
find /mnt/esp -type f -exec ls -la {} \;
# Check for BlackLotus indicators - custom directory under ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null
# Verify Windows Boot Manager signature
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi
# Hash all EFI binaries for comparison against known-good values
find /mnt/esp -name "*.efi" -exec sha256sum {} \;
# Check for unauthorized .efi files outside standard directories
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"
# Look for grubx64.efi planted by BlackLotus
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;
# Examine MeasuredBoot logs for anomalies (Windows)
# Logs located at C:\Windows\Logs\MeasuredBoot\
Step 4: Scan Firmware for Known Bootkit Signatures
Analyze the firmware dump for known UEFI malware patterns:
# Extract all firmware modules with UEFIExtract
UEFIExtract firmware_dump.rom all
# Generate firmware module whitelist from vendor baseline
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom
# Compare current firmware against whitelist
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom
# Scan firmware with UEFI-specific YARA rules
yara -r uefi_bootkits.yar firmware_dump.rom
# Scan extracted modules individually
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;
# Check for modified CORE_DXE module (targeted by MoonBounce, CosmicStrand)
# Compare GUID and hash against vendor baseline
Step 5: Detect Secure Boot Bypass Mechanisms
Check for known Secure Boot bypass techniques:
# Check if Secure Boot is enabled
python chipsec_main.py -m common.secureboot.variables
# Verify SMM (System Management Mode) protections
python chipsec_main.py -m common.smm
# Check SMM BIOS write protection
python chipsec_main.py -m common.bios_smi
# On Windows - check boot configuration for bypass indicators
bcdedit /enum firmware
bcdedit /v
# Check for testsigning/nointegritychecks/debug flags
bcdedit | findstr /i "testsigning nointegritychecks debug"
# Verify HVCI (Hypervisor-enforced Code Integrity) is not disabled
# BlackLotus sets HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# Check Secure Boot state via PowerShell
# Confirm-SecureBootUEFI returns True if properly enabled
Step 6: Perform Boot Chain Integrity Verification
Verify every component in the boot chain from firmware through kernel:
# Verify firmware integrity against vendor hash
sha256sum firmware_dump.rom
# Compare with vendor-published hash
# Verify bootloader signatures
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Check for unsigned or invalid boot drivers
sigcheck -u -e C:\Windows\System32\drivers\
# Analyze Measured Boot logs for unexpected EFI_Boot_Services_Application entries
# BlackLotus components appear as EV_EFI_Boot_Services_Application
# Memory forensics for boot-phase artifacts
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan
Step 7: Document UEFI Bootkit Analysis Findings
Compile a comprehensive analysis report:
Report should include:
- Firmware version, vendor, and platform identification
- SPI flash protection status (write protect, lock bits, access control)
- Secure Boot configuration and any bypass indicators detected
- UEFI variable anomalies (unauthorized keys, modified db/dbx, MOK enrollment)
- ESP contents inventory with hash verification against known-good baselines
- Firmware module comparison against vendor whitelist (added, modified, removed)
- Known bootkit family attribution with confidence level
- Boot chain integrity verification results for each component
- Remediation steps (reflash, key rotation, hardware replacement)
- MITRE ATT&CK mapping (T1542.001 - System Firmware, T1542.003 - Bootkit)
Key Concepts
| Term | Definition |
|---|---|
| UEFI Bootkit | Malware that persists in UEFI firmware or the boot process, executing before the operating system loads and surviving OS reinstallation |
| SPI Flash | Serial Peripheral Interface flash memory chip on the motherboard storing UEFI firmware; firmware-level bootkits like LoJax and MoonBounce modify SPI flash contents |
| EFI System Partition (ESP) | FAT32 partition containing EFI bootloaders and drivers; bootkits like BlackLotus and ESPecter modify files on the ESP for persistence |
| Secure Boot | UEFI security feature that verifies digital signatures of boot components; can be bypassed via vulnerabilities (CVE-2022-21894) or MOK enrollment |
| DXE Driver | Driver Execution Environment driver loaded during UEFI boot; firmware implants inject malicious DXE drivers that execute before the OS |
| Machine Owner Key (MOK) | User-installable Secure Boot key; BlackLotus enrolls attacker-controlled MOKs to sign malicious bootloaders |
| chipsec | Intel platform security assessment framework for analyzing SPI flash, UEFI variables, Secure Boot, and hardware security configurations |
| HVCI | Hypervisor-enforced Code Integrity, a Windows security feature that bootkits disable to load unsigned kernel drivers |
Tools & Systems
- chipsec: Intel framework for dumping SPI flash, reading UEFI variables, verifying firmware write protection, and Secure Boot configuration auditing
- UEFITool: Open-source UEFI firmware image parser for inspecting firmware volumes, extracting DXE drivers, and comparing module GUIDs
- sigcheck: Sysinternals utility for verifying digital signatures of EFI binaries and boot chain components
- flashrom: Open-source SPI flash programmer for reading and writing firmware chips on supported platforms
- YARA: Pattern matching engine used with UEFI-specific rule sets to detect known bootkit signatures in firmware dumps
Common Scenarios
Scenario: Investigating Persistent Compromise Surviving OS Reinstallation
Context: An enterprise endpoint was reimaged after a confirmed breach, but identical C2 beaconing resumed within hours. The endpoint has UEFI firmware with Secure Boot enabled, and a TPM 2.0 chip. The security team suspects a UEFI-level implant similar to BlackLotus or LoJax.
Approach:
- Boot the system from a trusted Linux live USB to avoid executing any compromised OS components
- Dump SPI flash firmware using
chipsec_util.py spi dumpfor offline analysis - Mount the ESP and hash all
.efifiles for comparison against known-good values from identical hardware - Check for the
ESP:/system32/directory (BlackLotus indicator) and unauthorizedgrubx64.efi - Extract firmware modules with UEFIExtract and compare GUID inventory against vendor baseline
- Verify Secure Boot variables -- look for unauthorized MOK enrollment or modified db/dbx
- Check SPI flash write protection and lock bits using chipsec modules
- Scan firmware dump and extracted modules with UEFI-specific YARA rules
- If BlackLotus is suspected, check registry for HVCI disabled and MeasuredBoot logs for anomalous entries
Pitfalls:
- Running analysis from the compromised OS (rootkit components hide from live analysis)
- Only checking the ESP without examining SPI flash firmware (misses firmware-level implants like LoJax, MoonBounce)
- Assuming Secure Boot prevents all bootkits (CVE-2022-21894 and other bypasses exist)
- Not preserving the original firmware dump before remediation (critical forensic evidence)
- Reflashing firmware without verifying the vendor image is authentic and unmodified
Output Format
UEFI BOOTKIT PERSISTENCE ANALYSIS REPORT
============================================
System: Lenovo ThinkPad X1 Carbon Gen 11
Firmware: N3HET82W (1.54) - Lenovo UEFI BIOS
Platform: Intel 13th Gen (Raptor Lake)
TPM: 2.0 (Infineon SLB 9672)
Secure Boot: ENABLED (BYPASSED via CVE-2022-21894)
Analysis Method: Linux live USB + chipsec + UEFITool
SPI FLASH PROTECTION STATUS
BIOS Write Protection: DISABLED [!]
SPI Flash Lock (FLOCKDN): SET [OK]
SMM BIOS Write Protect: DISABLED [!]
SPI Protected Ranges: Region 0 only (descriptor)
UEFI VARIABLE ANALYSIS
SecureBoot: Enabled (value=1)
SetupMode: Disabled (value=0)
PK: Lenovo Ltd. (legitimate)
KEK: Microsoft + Lenovo (legitimate)
db: MODIFIED - contains unauthorized entry [!]
[!] Unknown certificate: CN=Secure Boot Signing, O=Unknown
[!] Not present in vendor baseline db
MOK: 1 unauthorized key enrolled [!]
[!] MOK enrolled: CN=shim, self-signed, not from distro vendor
ESP PARTITION ANALYSIS
Total EFI binaries: 12
Verified (signed): 9
Modified (hash mismatch): 2 [!]
Unauthorized: 1 [!]
[!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFIED
Expected SHA-256: a3f2c8...
Current SHA-256: 7b1e4d...
Signature: Valid (signed with unauthorized MOK)
[!] EFI/Microsoft/Boot/grubx64.efi - UNAUTHORIZED
SHA-256: e9c1a7...
Not present in vendor baseline
Matches BlackLotus stage-2 loader signature
[!] system32/ directory present on ESP (BlackLotus artifact)
Directory empty (files deleted post-installation)
FIRMWARE MODULE ANALYSIS
Total firmware modules: 312
Vendor baseline modules: 312
Added modules: 0
Modified modules: 0
SPI flash integrity: CLEAN (no firmware-level implant detected)
BOOTKIT ATTRIBUTION
Family: BlackLotus
Confidence: HIGH
Persistence: ESP-based (not SPI flash)
Bypass Method: CVE-2022-21894 (baton drop)
MITRE ATT&CK: T1542.003 (Bootkit), T1553.006 (Code Signing Policy Modification)
INDICATORS OF COMPROMISE
- ESP:/system32/ directory (empty, post-cleanup artifact)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (unauthorized, BlackLotus loader)
- Modified bootmgfw.efi (re-signed with attacker MOK)
- HVCI disabled via registry: DeviceGuard\...\Enabled = 0
- Unauthorized MOK enrollment in UEFI variable store
- MeasuredBoot log shows EV_EFI_Boot_Services_Application for grubx64.efi
REMEDIATION
1. Replace bootmgfw.efi with authentic copy from Windows installation media
2. Delete unauthorized grubx64.efi and system32/ directory from ESP
3. Reset Secure Boot keys to factory defaults (clear MOK, restore PK/KEK/db)
4. Enable BIOS write protection and verify SPI flash lock bits
5. Apply firmware update to latest version (patches CVE-2022-21894)
6. Enable HVCI and verify via Group Policy
7. Reimport only trusted certificates into Secure Boot db
8. Monitor MeasuredBoot logs for anomalous boot component loading
Other files in this skill
references/api-reference.md (verbatim)
API Reference: UEFI Bootkit Analysis Tools
chipsec - Platform Security Assessment Framework
SPI Flash Operations
python chipsec_util.py spi info # SPI flash info
python chipsec_util.py spi dump firmware.rom # Dump entire SPI flash
python chipsec_util.py spi read 0x700000 0x100000 bios.bin # Read specific region
python chipsec_util.py spi write 0x0 0x1000 data.bin # Write to SPI flash
UEFI Variable Operations
python chipsec_util.py uefi var-list # List all UEFI variables
python chipsec_util.py uefi var-list-spi firmware.rom # List vars from dump
python chipsec_util.py uefi var-read <name> <GUID> # Read specific variable
python chipsec_util.py uefi var-find <name> # Find variable by name
python chipsec_util.py uefi keys # Dump Secure Boot keys
python chipsec_util.py uefi tables # List UEFI tables
python chipsec_util.py uefi decode firmware.rom # Decode firmware image
Security Assessment Modules
python chipsec_main.py -m <module> # Run security module
python chipsec_main.py -m common.secureboot.variables # Secure Boot check
python chipsec_main.py -m common.bios_wp # BIOS write protection
python chipsec_main.py -m common.spi_lock # SPI flash lock bits
python chipsec_main.py -m common.spi_access # SPI region permissions
python chipsec_main.py -m common.spi_desc # SPI descriptor check
python chipsec_main.py -m common.smm # SMM protection
python chipsec_main.py -m common.bios_smi # SMI suppression
Firmware Whitelist Module
# Generate whitelist from known-good firmware
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,vendor.rom
# Check firmware against whitelist
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,suspect.rom
Key Modules Reference
| Module | Purpose |
|---|---|
common.secureboot.variables |
Verify Secure Boot PK, KEK, db, dbx variables |
common.bios_wp |
Check BIOS region write protection (BIOSWE, BLE, SMM_BWP) |
common.spi_lock |
Verify SPI flash controller lock (FLOCKDN) |
common.spi_access |
Check SPI flash region read/write permissions |
common.spi_desc |
Verify SPI flash descriptor is write-protected |
common.smm |
Verify SMRAM range register protection (SMRR) |
common.bios_smi |
Check SMI event configuration and suppression |
tools.uefi.whitelist |
Generate and verify firmware module whitelists |
tools.uefi.scan_image |
Scan firmware image for known vulnerabilities |
tools.uefi.uefivar_fuzz |
Fuzz UEFI variable interface for vulnerabilities |
UEFITool / UEFIExtract
UEFIExtract CLI
UEFIExtract firmware.rom all # Extract all modules
UEFIExtract firmware.rom <GUID> body # Extract specific module
UEFIExtract firmware.rom report # Generate report
Output Structure
Extracted firmware is organized by GUID into a directory tree containing:
- PEI modules (Pre-EFI Initialization)
- DXE drivers (Driver Execution Environment)
- SMM drivers (System Management Mode)
- Option ROMs
- NVRAM variables
Secure Boot Variable GUIDs
| Variable | GUID | Description |
|---|---|---|
SecureBoot |
8BE4DF61-93CA-11D2-AA0D-00E098032B8C |
Secure Boot enable status |
SetupMode |
8BE4DF61-93CA-11D2-AA0D-00E098032B8C |
Setup mode (keys not enrolled) |
PK |
8BE4DF61-93CA-11D2-AA0D-00E098032B8C |
Platform Key (root of trust) |
KEK |
8BE4DF61-93CA-11D2-AA0D-00E098032B8C |
Key Exchange Key |
db |
D719B2CB-3D3A-4596-A3BC-DAD00E67656F |
Signature database (allowed) |
dbx |
D719B2CB-3D3A-4596-A3BC-DAD00E67656F |
Forbidden signature database |
MokList |
605DAB50-E046-4300-ABB6-3DD810DD8B23 |
Machine Owner Key list |
flashrom - SPI Flash Programmer
Syntax
flashrom -p internal -r firmware.rom # Read/dump flash
flashrom -p internal -w clean.rom # Write/reflash
flashrom -p internal --verify clean.rom # Verify contents
flashrom -p internal --flash-size # Show flash size
flashrom -L # List supported chips
sigcheck - Signature Verification (Windows)
Syntax
sigcheck -a file.efi # Full signature info
sigcheck -u -e C:\Windows\System32\drivers\ # Find unsigned drivers
sigcheck -c -h file.efi # CSV output with hashes
bcdedit - Boot Configuration (Windows)
Syntax
bcdedit /enum firmware # List firmware entries
bcdedit /v # Verbose boot config
bcdedit | findstr /i "testsigning nointegritychecks" # Check bypass flags
YARA - Firmware Pattern Scanning
UEFI Bootkit Rules
yara -r uefi_bootkits.yar firmware.rom # Scan firmware dump
yara -s -r rules.yar firmware.rom # Show matching strings
Example UEFI Detection Rule
rule BlackLotus_ESP_Indicator {
meta:
description = "Detects BlackLotus ESP-based bootkit artifacts"
reference = "ESET Research 2023"
strings:
$mok_enroll = { 4D 00 6F 00 6B 00 4C 00 69 00 73 00 74 }
$esp_path = "\\EFI\\Microsoft\\Boot\\grubx64.efi"
$hvci_disable = "HypervisorEnforcedCodeIntegrity"
condition:
any of them
}
Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.