Analyzing Uefi Bootkit PersistenceSAFE
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 ·
Overview
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 ·
6c59587be632OBSERVED · 2026-10-07What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
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:
```bash
# 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:
```bash
# 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:
```bash
# 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:
```bash
# 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:
```bash
# 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 "testsigninTrust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | PASS |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
6c59587be632full audit observations/trust-audit/skill/mukul975__analyzing-uefi-bootkit-persistence.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-07 | 6c59587be632 | SAFE | B | 89 | first audit |
Questions
What does the Analyzing Uefi Bootkit Persistence skill do?
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 ·
Is Analyzing Uefi Bootkit Persistence safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Analyzing Uefi Bootkit Persistence access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (6c59587be632), read on 2026-10-07. The repository is watched, and a new audit runs when it changes — this is the first audit.