UEFI Bootkit 持久化分析实战指南基于 Anthropic-Cybersecurity-Skills 的固件取证与 Secure Boot 绕过检测【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills导读本指南源自 Anthropic-Cybersecurity-Skills 仓库中analyzing-uefi-bootkit-persistence技能属于 29 个安全域中的 Hardware Firmware Security 域系统讲解 UEFI bootkit 持久化分析的完整方法论——从 SPI Flash 固件转储、UEFI 变量审计、ESP 分区取证到 Secure Boot 绕过机制检测与启动链完整性校验。读完本篇你将掌握使用 chipsec、UEFITool、YARA 等工具链识别 BlackLotus、LoJax、MoonBounce 等已知固件植入家族的实战能力并能输出一份可供溯源与整改的标准化分析报告。一、为什么需要关注 UEFI Bootkit 持久化UEFI bootkit 是持久化在 UEFI 固件或引导流程中的恶意程序它在操作系统加载之前执行因此具备两项致命特性重装系统无法清除、磁盘更换后仍能复活。当企业终端出现系统重灌后数小时内 C2 回连恢复的现象时最先怀疑的就应是固件层植入。该技能在 SKILL.md 中将其适用范围界定为以下场景系统重装或更换磁盘后仍重新建立 C2 通信Secure Boot 被篡改、禁用或出现异常的 Machine Owner KeyMOK注册固件完整性校验无法通过厂商提供的基线内存取证揭示引导早期阶段加载了 rootkit 组件调查已知会部署 UEFI 植入的 APT 活动企业端点加固前的固件安全态势审计。同时技能明确指出不适用范围传统 BIOS 上的 MBR 引导型 bootkit 不在此分析范畴应改用 MBR/VBR bootkit 分析方法。从威胁模型看UEFI 植入按持久化载体可分为两大类依据 agent.py 内置的KNOWN_BOOTKITS知识库持久化类型载体代表家族SPI Flash 固件植入主板 SPI 闪存芯片中的固件卷LoJax首个野外发现的 SPI Flash 植入APT28、MoonBounce钩挂GetVariable()、CosmicStrand修补 CORE_DXE 钩挂内核初始化、MosaicRegressor通过 READY_TO_BOOT 回调投递 NTFS 文件ESP 分区文件植入EFI System Partition 中的引导文件BlackLotus首个绕过完全修补 Windows 11 Secure Boot 的野外 UEFI bootkit、ESPecter修补 winload.efi 禁用 DSE、Bootkitty首个针对 Linux 的 UEFI bootkit1.1 框架映射一次分析多方合规该技能在仓库的六框架映射体系中覆盖了 MITRE ATTCK 与 NIST CSF 2.0在 SKILL.md 的 YAML frontmatter 中可查证MITRE ATTCKT1542.001System Firmware、T1542.003Bootkit、T1553.006Code Signing Policy Modification、T1542Pre-OS Boot、T1014RootkitNIST CSF 2.0ID.RA-01资产漏洞识别、PR.PS-01/PR.PS-02平台保护MITRE D3FENDPlatform Hardening、Restore Object、Platform Monitoring、Firmware Verification、Firmware Embedded Monitoring Code。仓库的 ATTACK_COVERAGE.md 与 mappings/mitre-attack/coverage-summary.md 记录了全库 TTP 覆盖情况其中 RootkitT1014与 Pre-OS BootT1542正是本技能对应的工作面可在 mappings/attack-navigator-layer.json 中查看可视化的覆盖图层。二、准备工作工具链与前提条件依据 SKILL.md 的 Prerequisites 小节完整分析需要以下工具链chipsecIntel 平台安全评估框架用于 SPI Flash 转储、UEFI 变量检查与固件安全模块审计UEFITool / UEFIExtract固件卷解析与 DXE 驱动提取Python 3.8内置struct、hashlib、subprocess、os模块本仓库 agent.py 的运行环境可引导的 Linux 应急启动盘离线分析避免在已被感染的系统上运行分析工具Volatility 3引导阶段内存取证YARA配合 UEFI 恶意软件规则集做模式匹配检测厂商固件基线用于完整性比对。⚠️重要前提固件分析涉及底层硬件访问与关键安全配置修改必须在获得授权的系统上执行。仓库在 SECURITY.md 中明确要求所有攻防技能仅用于获得授权的测试、研究与防御。下方agent.py启动时也会打印 AUTHORIZED USE ONLY 声明。三、七步分析工作流SKILL.md 将整个分析过程组织为 7 个步骤下面逐一步骤展开并补充源码级细节。Step 1转储 SPI Flash 固件从 SPI 闪存芯片获取 UEFI 固件以进行离线分析这是所有固件层分析的地基——只检查 ESP 而不检查 SPI Flash会漏掉 LoJax、MoonBounce 这类固件植入。# 使用 chipsec 转储 SPI Flash 内容 python chipsec_util.py spi dump firmware_dump.rom # 备选方案使用 flashrom flashrom -p internal -r firmware_dump.rom # 校验转储完整性记录哈希作为证据 sha256sum firmware_dump.rom # 读取 SPI Flash 描述符信息 python chipsec_util.py spi info # 检查 SPI Flash 区域访问权限 python chipsec_main.py -m common.spi_access # 验证 BIOS 写保护是否启用 python chipsec_main.py -m common.bios_wp # 检查 SPI Flash 控制器锁定状态 python chipsec_main.py -m common.spi_lock补充说明依据 api-reference.mdspi dump输出完整固件镜像若只需特定区域可用python chipsec_util.py spi read 0x700000 0x100000 bios.bin按偏移读取flashrom 支持flashrom -p internal --flash-size查看芯片容量、flashrom -L列出支持的芯片型号对应安全模块的底层含义见下表参考 api-reference.md 的 Key Modules Referencechipsec 模块检测目的common.bios_wpBIOS 区域写保护BIOSWE、BLE、SMM_BWPcommon.spi_lockSPI 控制器锁定FLOCKDNcommon.spi_accessSPI 区域读写权限common.spi_descSPI 描述符写保护common.smmSMRAM 范围寄存器保护SMRRcommon.bios_smiSMI 事件配置与抑制common.secureboot.variablesSecure Boot 的 PK、KEK、db、dbx 变量校验tools.uefi.whitelist固件模块白名单生成与比对tools.uefi.scan_image固件镜像已知漏洞扫描tools.uefi.uefivar_fuzzUEFI 变量接口模糊测试在 agent.py 中run_chipsec_spi_dump()与run_chipsec_module()通过 subprocess 封装了上述调用其中run_firmware_security_audit()会顺序执行 7 个核心安全模块bios_wp → spi_lock → spi_access → spi_desc → secureboot.variables → smm → bios_smi并对输出中的PASSED/FAILED/WARNING关键字做自动判定可作为自动化审计入口。Step 2审计 UEFI 变量枚举并分析 UEFI 变量寻找未授权修改——尤其是 Secure Boot 密钥库PK/KEK/db/dbx与 MOK 列表的异常# 在活动系统上列出所有 UEFI 变量 python chipsec_util.py uefi var-list # 从 SPI Flash 转储中列出 UEFI 变量离线分析 python chipsec_util.py uefi var-list-spi firmware_dump.rom # 读取特定 Secure Boot 变量 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 # 转储 UEFI 密钥库供分析 python chipsec_util.py uefi keys # 检查 Secure Boot 配置模块 python chipsec_main.py -m common.secureboot.variablesSecure Boot 变量的标准 GUID 由 api-reference.md 提供分析时需精确比对变量GUID说明SecureBoot8BE4DF61-93CA-11D2-AA0D-00E098032B8CSecure Boot 启用状态SetupMode8BE4DF61-93CA-11D2-AA0D-00E098032B8C设置模式密钥未注册PK8BE4DF61-93CA-11D2-AA0D-00E098032B8CPlatform Key信任根KEK8BE4DF61-93CA-11D2-AA0D-00E098032B8CKey Exchange KeydbD719B2CB-3D3A-4596-A3BC-DAD00E67656F允许签名数据库dbxD719B2CB-3D3A-4596-A3BC-DAD00E67656F禁止签名数据库MokList605DAB50-E046-4300-ABB6-3DD810DD8B23Machine Owner Key 列表关键审计点MOKMachine Owner Key是用户可自行安装的 Secure Boot 密钥BlackLotus 正是通过注册攻击者控制的 MOK 来为恶意引导加载程序签名而修改后的 db 中混入未授权证书、未知 CN 条目同样是强烈异常信号。从实现层面看agent.py 的check_secure_boot_status()展示了 Linux 侧读取这些变量的等价做法直接解析/sys/firmware/efi/efivars/下的变量文件——注意 efivarfs 文件的前 4 字节是属性位第 5 字节才是变量值SecureBoot值为 1 表示启用、SetupMode值为 1 表示处于设置模式。Step 3分析 EFI System PartitionESPESP 通常是第一块 FAT32 分区约 100–500 MB存放 EFI 引导加载程序与驱动。BlackLotus 与 ESPecter 正是通过修改 ESP 上的文件实现持久化# 挂载 ESP通常为第一个 FAT32 分区约 100-500MB mkdir /mnt/esp mount /dev/sda1 /mnt/esp # 列出 ESP 上所有文件及时间戳 find /mnt/esp -type f -exec ls -la {} \; # 检查 BlackLotus 指标ESP:/system32/ 自定义目录 ls -la /mnt/esp/system32/ 2/dev/null # 验证 Windows Boot Manager 签名 sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi # 哈希所有 EFI 二进制与已知良好值比对 find /mnt/esp -name *.efi -exec sha256sum {} \; # 检查标准目录之外的未授权 .efi 文件 find /mnt/esp -name *.efi | grep -v Microsoft\|Boot\|ubuntu\|grub # 查找 BlackLotus 植入的 grubx64.efi find /mnt/esp -name grubx64.efi -exec sha256sum {} \; # 检查 MeasuredBoot 日志异常Windows # 日志位于 C:\Windows\Logs\MeasuredBoot\agent.py 的scan_esp_partition()把上述人工操作自动化了其检查逻辑可作为判定的源码依据system32 目录检测ESP 根下存在system32/目录 → 判定为CRITICAL级 BlackLotus 指标grubx64.efi 检测在纯 Windows 系统上发现grubx64.efi→ 判定为HIGH级异常BlackLotus/Bootkitty 指标非标准目录检测EFI 二进制不在efi/boot/microsoft/ubuntu/debian/fedora/grub等标准目录内 → 判定为MEDIUM级异常。每个发现都会附带文件路径与 SHA-256 哈希便于生成 IOC。Step 4扫描固件的已知 Bootkit 签名对固件转储执行模式匹配识别已知 UEFI 恶意软件家族# 用 UEFIExtract 提取所有固件模块 UEFIExtract firmware_dump.rom all # 从厂商基线生成固件模块白名单 python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom # 将当前固件与白名单比对 python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom # 用 UEFI 专用 YARA 规则扫描固件 yara -r uefi_bootkits.yar firmware_dump.rom # 逐个扫描提取出的模块 find firmware_dump.rom.dump -name *.efi -exec yara -r uefi_bootkits.yar {} \; # 检查被 MoonBounce、CosmicStrand 盯上的 CORE_DXE 模块是否被修改 # 将 GUID 与哈希同厂商基线比对UEFIExtract 的输出按 GUID 组织目录树包含 PEI 模块、DXE 驱动、SMM 驱动、Option ROM 与 NVRAM 变量见 api-reference.md。辅助命令UEFIExtract firmware.rom GUID body提取指定模块、UEFIExtract firmware.rom report生成解析报告。从源码层面看agent.py 的scan_firmware_dump()提供了不依赖外部工具的固件体检能力固件卷定位扫描_FVH魔数位于 FV 头偏移 0x28 处解析卷长度与 16 字节 GUID并与KNOWN_FV_GUIDSFFS v2/v3、DXE Core 卷等比对PE/COFF 定位扫描MZ魔数并校验PE\0\0签名找出固件中嵌入的所有 EFI 可执行体可疑字符串扫描以正则匹配 LoJax 组件rpcnetp、autoche、DXE 修改目标CORE_DXE、SmmAccessDxe、UEFI 运行时服务GetVariable、SetVariable即 hook 目标、MosaicRegressor 指标READY_TO_BOOT以及固件中不应出现的cmd.exe、powershell引用熵值分析firmware_entropy_map()按块计算香农熵将固件区域分类为 empty1.0、code/data5.0、compressed7.5、encrypted/random≥7.5帮助定位异常的高熵加密区域。tools.uefi.whitelist模块的 generate/check 双动作设计见 api-reference.md正好对应该步骤中生成基线 → 比对当前的流程-a generate,baseline.json,vendor.rom与-a check,baseline.json,suspect.rom。Step 5检测 Secure Boot 绕过机制Secure Boot 并非绝对防线——CVE-2022-21894baton drop等漏洞以及 MOK 注册均可绕过它因此必须检查绕过迹象# 检查 Secure Boot 是否启用 python chipsec_main.py -m common.secureboot.variables # 验证 SMMSystem Management Mode保护 python chipsec_main.py -m common.smm # 检查 SMM BIOS 写保护 python chipsec_main.py -m common.bios_smi # Windows 上检查引导配置中的绕过迹象 bcdedit /enum firmware bcdedit /v # 检查 testsigning/nointegritychecks/debug 标志 bcdedit | findstr /i testsigning nointegritychecks debug # 验证 HVCIHypervisor-enforced Code Integrity未被禁用 # BlackLotus 会设置 HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled0 reg query HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity /v Enabled # 通过 PowerShell 检查 Secure Boot 状态 # Confirm-SecureBootUEFI 返回 True 表示已正确启用HVCI 是 Windows 通过虚拟化保护代码完整性的关键机制bootkit 常先将其禁用再加载未签名内核驱动。这与 agent.py 中 BlackLotus 的registry_indicators定义完全对应SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity下的Enabled值被改为 0。Step 6执行启动链完整性校验从固件到内核逐组件验证启动链的每个环节# 用厂商发布的哈希比对固件完整性 sha256sum firmware_dump.rom # 验证引导加载程序签名 sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi sigcheck -a C:\Windows\System32\winload.efi sigcheck -a C:\Windows\System32\ntoskrnl.exe # 检查未签名或无效的引导驱动 sigcheck -u -e C:\Windows\System32\drivers\ # 分析 Measured Boot 日志中的异常 EFI_Boot_Services_Application 条目 # BlackLotus 组件以 EV_EFI_Boot_Services_Application 形式出现 # 引导阶段产物的内存取证 vol3 -f memory.dmp windows.modules vol3 -f memory.dmp windows.driverscan其中sigcheck的常用参数依据 api-reference.md-a输出完整签名信息-u -e枚举目录查找未签名驱动-c -h输出带哈希的 CSV 格式。Measured Boot 日志是 TPM 度量结果的审计记录——任何意外出现在启动链中的EFI_Boot_Services_Application条目都意味着有未授权组件被执行过。Step 7撰写 UEFI Bootkit 分析报告SKILL.md 给出了报告应包含的要素清单固件版本、厂商与平台识别SPI Flash 保护状态写保护、锁定位、访问控制Secure Boot 配置及检测到的任何绕过指标UEFI 变量异常未授权密钥、被修改的 db/dbx、MOK 注册ESP 内容清单及与已知良好基线的哈希比对固件模块与厂商白名单的比对新增、修改、删除已知 bootkit 家族归因及置信度启动链各组件完整性校验结果整改措施重新刷写、密钥轮换、硬件更换MITRE ATTCK 映射T1542.001 - System Firmware、T1542.003 - Bootkit。四、关键概念速查SKILL.md 的核心概念表是理解整个分析流程的基础术语定义UEFI Bootkit持久化在 UEFI 固件或引导进程中的恶意软件在操作系统加载前执行可挺过操作系统重装SPI Flash主板上的串行外设接口闪存芯片存储 UEFI 固件LoJax、MoonBounce 等固件级 bootkit 会修改 SPI Flash 内容EFI System Partition (ESP)存放 EFI 引导加载程序与驱动的 FAT32 分区BlackLotus、ESPecter 通过修改 ESP 文件实现持久化Secure Boot校验引导组件数字签名的 UEFI 安全特性可被漏洞如 CVE-2022-21894或 MOK 注册绕过DXE DriverUEFI 引导期间加载的 Driver Execution Environment 驱动固件植入会注入在 OS 之前执行的恶意 DXE 驱动Machine Owner Key (MOK)用户可自行安装的 Secure Boot 密钥BlackLotus 注册攻击者控制的 MOK 以签名恶意引导加载程序chipsecIntel 平台安全评估框架用于分析 SPI Flash、UEFI 变量、Secure Boot 及硬件安全配置HVCIHypervisor-enforced Code IntegrityWindows 安全特性bootkit 会禁用它以加载未签名内核驱动五、工具与系统速览chipsecIntel 框架用于转储 SPI Flash、读取 UEFI 变量、验证固件写保护与审计 Secure Boot 配置详见 api-reference.md 的 SPI/UEFI/模块三大命令族UEFITool开源 UEFI 固件镜像解析器用于检查固件卷、提取 DXE 驱动、比对模块 GUIDsigcheckSysinternals 工具验证 EFI 二进制与启动链组件的数字签名flashrom开源 SPI Flash 编程器在受支持平台上读写固件芯片YARA模式匹配引擎配合 UEFI 专用规则集检测固件转储中的已知 bootkit 签名。YARA 规则示例源自 api-reference.md可用于自动化检测 BlackLotus 的 ESP 指标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 }六、实战场景重装系统后仍复发的持久化感染场景设定摘自 SKILL.md 的 Common Scenarios某企业端点在确认失陷后被重灌系统但数小时内又出现完全相同的 C2 心跳。该端点采用 UEFI 固件、已启用 Secure Boot、带 TPM 2.0。安全团队怀疑存在类似 BlackLotus 或 LoJax 的 UEFI 级植入。处置路径从可信的 Linux 应急启动盘启动避免执行任何被感染的 OS 组件使用chipsec_util.py spi dump转储 SPI Flash 固件以离线分析挂载 ESP对全部.efi文件做哈希与同型号硬件的已知良好值比对检查ESP:/system32/目录BlackLotus 指标与未授权的grubx64.efi用 UEFIExtract 提取固件模块将 GUID 清单与厂商基线比对验证 Secure Boot 变量——查找未授权的 MOK 注册或被修改的 db/dbx用 chipsec 模块检查 SPI Flash 写保护与锁定位用 UEFI 专用 YARA 规则扫描固件转储与提取的模块若怀疑 BlackLotus检查注册表中 HVCI 是否被禁用并审阅 MeasuredBoot 日志中的异常条目。常见陷阱务必规避在被感染的 OS 内运行分析rootkit 组件会向活动分析隐藏自身只查 ESP 而不查 SPI Flash 固件会漏掉 LoJax、MoonBounce 这类固件植入假设 Secure Boot 能阻止所有 bootkitCVE-2022-21894 等绕过真实存在在整改前未保留原始固件转储这是关键取证证据未验证厂商镜像真实性与完整性就重新刷写固件。七、分析报告输出格式参考SKILL.md 提供了一个可直接套用的报告模板节选关键段落将上述所有发现结构化汇总UEFI BOOTKIT PERSISTENCE ANALYSIS REPORT System: Lenovo ThinkPad X1 Carbon Gen 11 Firmware: N3HET82W (1.54) - Lenovo UEFI BIOS Secure Boot: ENABLED (BYPASSED via CVE-2022-21894) SPI FLASH PROTECTION STATUS BIOS Write Protection: DISABLED [!] SPI Flash Lock (FLOCKDN): SET [OK] UEFI VARIABLE ANALYSIS db: MODIFIED - contains unauthorized entry [!] MOK: 1 unauthorized key enrolled [!] ESP PARTITION ANALYSIS [!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFIED Expected SHA-256: a3f2c8... Current SHA-256: 7b1e4d... [!] EFI/Microsoft/Boot/grubx64.efi - UNAUTHORIZED Matches BlackLotus stage-2 loader signature [!] system32/ directory present on ESP (BlackLotus artifact) FIRMWARE MODULE ANALYSIS 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 ATTCK: 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 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八、自动化辅助仓库提供的分析脚本本技能目录附带一个可直接运行的自动化分析脚本 agent.py它把上述流程中的多项人工操作封装为 CLI适合交给 AI Agent 执行或嵌入取证工作流# 分析固件转储自动识别类型 python skills/analyzing-uefi-bootkit-persistence/scripts/agent.py firmware_dump.rom # 分析已挂载的 ESP 分区 python skills/analyzing-uefi-bootkit-persistence/scripts/agent.py /mnt/esp --type esp # 检查本地 Secure Boot 状态Linux efivarfs python skills/analyzing-uefi-bootkit-persistence/scripts/agent.py -s # 运行全套 chipsec 固件安全审计7 个模块 python skills/analyzing-uefi-bootkit-persistence/scripts/agent.py -c # 列出内置的已知 bootkit 家族知识库 python skills/analyzing-uefi-bootkit-persistence/scripts/agent.py --list-bootkits # JSON 结构化输出便于下游平台消费 python skills/analyzing-uefi-bootkit-persistence/scripts/agent.py firmware_dump.rom -j其关键设计对分析实践的直接价值内置 7 大已知家族知识库BlackLotus、LoJax、MoonBounce、CosmicStrand、ESPecter、MosaicRegressor、Bootkitty每条记录都包含持久化载体、ESP/固件/注册表指标与 MITRE ATTCK 映射可直接作为归因对照表ESP 自动化取证scan_esp_partition()同时输出全量 EFI 文件清单路径/大小/SHA-256与分级告警CRITICAL/HIGH/MEDIUM固件无依赖体检scan_firmware_dump()无需 UEFITool 即可完成固件卷定位、PE 枚举与可疑字符串扫描chipsec 封装run_chipsec_module()对超时120s与工具缺失chipsec not found均有容错处理适合长时审计任务。九、结语与延伸UEFI bootkit 分析的价值在于它覆盖了传统端点检测的盲区——当 EDR、杀软与系统重装都失效时固件层才是最后的安全边界。掌握本文的七步工作流后你可以从固件层SPI Flash 转储、模块白名单比对与文件层ESP 取证、YARA 匹配两个维度完整覆盖已知 UEFI 植入家族的检测通过Secure Boot 变量审计与启动链签名校验识别绕过与劫持痕迹输出结构化分析报告直接支撑企业固件安全态势审计与 APT 溯源归因。若需进一步查阅底层资料可深入 SKILL.md技能完整定义与 frontmatter、api-reference.md全量命令与 GUID 参考、agent.py自动化分析实现或通过 mappings/attack-navigator-layer.json 查看本技能在 MITRE ATTCK 覆盖矩阵中的位置结合 ATTACK_COVERAGE.md 了解全库战术层面的整体覆盖情况。注意本仓库为只读资料库所有分析应在你拥有授权的独立环境应急启动盘、隔离取证机中执行。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考