Anthropic-Cybersecurity-Skills 实战UEFI Secure Boot 绕过与 BootkitBlackLotus/Bootkitty检测全流程指南【免费下载链接】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导读UEFI Secure Boot 是固件层强制执行的信任链Bootkit 一旦绕过它就能获得早于操作系统、可跨系统重装与磁盘擦除存活的持久化控制权。本指南基于 Anthropic-Cybersecurity-Skills 仓库中的 detecting-secure-boot-bypass 技能系统讲解如何用mokutil、efi-readvar/dbxtool、CHIPSEC、sbverify/pesign以及 Windows 的Confirm-SecureBootUEFI/Get-SecureBootUEFI完成跨平台Linux WindowsSecure Boot 绕过检测。读完本文你将掌握一套可落地的五要素检测方法论确认 Secure Boot 开启、核验 dbx 吊销列表新鲜度、用 CHIPSEC 校验固件变量保护、对 ESP 上 EFI 引导二进制做哈希与签名校验、并排查 bootkit 持久化痕迹同时学会使用仓库附带的 agent.py 一键生成审计报告。法律声明固件与 Secure Boot 评估只能在自有或获得明确授权的系统上进行。CHIPSEC 的写入/修改模式与 EFI 变量操作可能导致硬件变砖破坏性检查务必在实验室环境执行。本技能仅用于防御性验证与授权评估。为什么打补丁不等于已修复Secure Boot 绕过威胁模型UEFI Secure Boot 的信任链依赖三组关键数据库允许签名列表db、吊销撤销列表dbx、密钥交换密钥KEK以及平台密钥PK。固件只允许加载签名存在于 db 且不在 dbx 中的引导组件。攻击者一旦拿到一个已被签名但存在漏洞的引导管理器就可以借它之手合法地关闭 Secure Boot。本技能聚焦的威胁案例充分说明了这一点BlackLotus2023首个被公开观测到能在完全修补的 Windows 11 上绕过 Secure Boot 的 UEFI bootkit通过滥用CVE-2022-21894baton drop易受攻击且已签名的 Windows 引导管理器中和 Secure Boot并进一步禁用 BitLocker、HVCI 与 Defender获得内核实权与持久化。Bootkitty2024首个针对 Linux 的 UEFI bootkit PoC。CVE-2023-24932微软处理的相关 Secure Boot 绕过漏洞之所以需要分阶段吊销 dbx是因为草率吊销易受攻击的引导管理器可能直接导致系统无法启动。由此得出核心防御洞见只给操作系统打补丁远远不够——在易受攻击的已签名二进制被写入 dbx 吊销之前平台依然可被利用。检测必须组合五个方面确认 Secure Boot 实际处于启用状态核验 dbx 是否为最新且包含相关吊销项用 CHIPSEC 检查 Secure Boot EFI 变量的完整性与保护对磁盘上的 EFI 引导二进制做哈希并与吊销列表、已知恶意集合比对检查固件/ESP 中的 bootkit 痕迹。何时使用本技能在 CVE-2023-24932 / BlackLotus 公告发布后核验企业资产中 Secure Boot 是否启用、锁定user 模式且吊销列表最新在疑似被入侵终端上猎杀 UEFI bootkit 指标验证 dbx 吊销如易受攻击的 Windows 引导管理器、Kaspersky 等易受攻击的引导加载程序是否真的在整片资产上生效在硬件安全评估期间审计固件完整性与 Secure Boot 变量保护建立针对引导链篡改的周期性测量/基线检查。前提条件目标机需要root/管理员权限读取固件变量需要特权Linux 工具链Debian/Ubuntu 与 Fedora/RHEL 包名略有差异# Debian/Ubuntu sudo apt install mokutil efitools sbsigntool dbxtool # Fedora/RHEL sudo dnf install mokutil efitools sbsigntools dbxtoolCHIPSEC会加载内核驱动建议从 Live USB 或受控主机运行pip install chipsecWindows 工具PowerShell 内置的Confirm-SecureBootUEFI、Get-SecureBootUEFI可选微软官方 UEFI dbx 更新包用于比对的当前官方 UEFI 吊销列表文件dbxupdate来自 uefi.org 的 revocation list file 页面。检测目标Objectives确认 Secure Boot 已启用且处于user 模式而非 setup 模式枚举 db、dbx、KEK、PK 内容并评估 dbx 新鲜度确认相关 CVE 吊销项已存在于 dbx用 CHIPSEC 验证 Secure Boot EFI 变量经过认证且受保护对 ESP 引导二进制做哈希并对照 dbx 与已知恶意哈希集识别 bootkit 痕迹报告可利用缺口并给出修复建议。MITRE ATTCK 映射技术 ID技术名称相关性T1542.003启动前引导Bootkit核心技术——bootkit 在 OS 之下颠覆引导链T1542启动前引导Pre-OS Boot父级技术覆盖固件/引导组件篡改T1542.001启动前引导系统固件相邻技术——固件修改被用于持久化或削弱 Secure BootT1014RootkitBootkit 提供 rootkit 级隐蔽与持久化T1562.001削弱防御禁用或修改工具BlackLotus 在绕过 Secure Boot 后禁用 BitLocker/HVCI/Defender同时该技能对应 NIST CSF 2.0 的DE.CM-01持续监测网络与系统以发现潜在恶意事件将引导链/固件完整性监测纳入检测与响应能力。更多框架映射细节见 standards.md。十步检测工作流第 1 步确认 Secure Boot 状态Linux已禁用或处于 setup 模式的平台不提供任何保护。# 预期输出 SecureBoot enabled mokutil --sb-state # systemd-boot 视角 bootctl status | grep -i secure boot # 直接读取 EFI 变量6 启用 user 模式 # 变量 GUID 8be4df61-93ca-11d2-aa0d-00e098032b8c od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c第 2 步确认 Secure Boot 状态Windows# $true 表示已启用 Confirm-SecureBootUEFI # 从 Windows 导出原始 dbx 变量字节便于离线分析 [System.BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) | Out-File dbx.hex第 3 步枚举 Secure Boot 数据库列出 db允许、dbx吊销、KEK 与 PK。# 导出 PK、KEK、db、dbx efi-readvar # 将 dbx 导出为 EFI 签名列表文件供离线分析 efi-readvar -v dbx -o dbx.esl # MOKshim 机器所有者密钥已注册密钥 mokutil --list-enrolled # 通过 shim 查看平台 db 条目 mokutil --db # 补充通过 shim 查看 dbx 吊销条目 mokutil --dbx第 4 步评估 dbx 新鲜度与已应用的吊销项将系统内 dbx 与当前官方 UEFI 吊销列表比对。# 当前 dbx 条目与数量 dbxtool --list # 下载最新 DBXUpdate.bin 后用 --dry-run 预览将被添加的吊销项不写入 dbxtool --dbx ./DBXUpdate.bin --apply --dry-run解读要点dbx 条目数量过低或缺少近期吊销项说明平台落后于最新缓解状态很可能仍受已知绕过影响。agent.py同样会基于此给出信号详见后文。第 5 步用 CHIPSEC 检查 Secure Boot 变量保护验证 Secure Boot 密钥变量经过认证且不可随意写入。# 验证 Secure Boot 已启用且 SB 变量受到正确保护 sudo chipsec_main -m common.secureboot.variables # 检查 S3 恢复引导脚本保护SMM/固件绕过向量 sudo chipsec_main -m common.uefi.s3bootscript # 导出 SPI 闪存用于离线固件比对 sudo chipsec_util spi dump rom.bin注意chipsec_main -m common.secureboot.variables -a modify会尝试写入/破坏 SB 变量属于破坏性测试仅在实验室且确认可承受后果时执行。第 6 步对 ESP 引导二进制做哈希与签名校验验证引导加载程序已签名且不在 dbx 中。# 定位并哈希所有 EFI 引导二进制 find /boot/efi -iname *.efi -exec sha256sum {} \; # 校验二进制签名列出签名 sbverify --list /boot/efi/EFI/BOOT/bootx64.efi # 用平台 db 证书校验签名 sbverify --cert /etc/secureboot/db.crt /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi # RHEL 系的 pesign 等价命令 pesign -S -i /boot/efi/EFI/BOOT/bootx64.efi第 7 步对照已知恶意 bootkit 哈希集将采集到的哈希与吊销/已知恶意集如 LoFP、厂商公告比对。# 示例确认某个二进制的 SHA-256 不属于被吊销的 CVE-2022-21894 引导管理器集合 sha256sum /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi # 与从最新 dbxupdate / 公告中提取的哈希列表比对第 8 步排查 bootkit 痕迹寻找未经授权的 ESP 修改与自我部署标记。# ESP 上的意外文件 / 近期修改的二进制 ls -laR /boot/efi/EFI/ find /boot/efi -newermt -30 days -iname *.efi # Windows 侧检查 EFI 分区是否存在伪造的 \EFI\Microsoft\Boot 条目第 9 步验证测量启动证据可选延伸若存在 TPM当前PCR[7]反映 Secure Boot 策略偏离即佐证篡改。tpm2_pcrread sha256:7 # Secure Boot 策略 PCR第 10 步运行仓库自带的评估辅助脚本scripts/agent.py 将 SB 状态、dbx 数量、ESP 二进制哈希与 CHIPSEC 结果汇总为一份报告sudo python scripts/agent.py --check-chipsec --output secureboot_report.json源码级原理agent.py 如何实现自动检测仓库为本技能提供了开箱即用的检测器其实现逻辑完整对应上述工作流值得逐段解读。多平台 Secure Boot 状态采集secure_boot_state()函数按平台分支处理agent.pyLinux优先调用mokutil --sb-state通过输出中是否包含enabled判断状态若mokutil不存在则回退为直接读取/sys/firmware/efi/efivars/SecureBoot-*变量文件——这正是第 1 步中od命令的编程化等价实现通过判定变量数据最后一个字节是否为1来确认启用Windows调用powershell -NoProfile -Command Confirm-SecureBootUEFI将输出解析为True/False。注意源码中的回退逻辑非常实用无mokutil且无 efivars 时会在报告里给出明确的error字段如no mokutil and no SecureBoot efivar避免静默失败。dbx 新鲜度信号dbx_status()优先使用dbxtool --list将输出中非空行数作为吊销条目数的近似值agent.py。关键启发式条目数小于 50 时自动给出 warning——low dbx entry count; platform may be behind on revocations这正是第 4 步人工判断的自动化版本。若dbxtool不可用则回退到efi-readvar -v dbx摘录前 800 字符。ESP 二进制哈希hash_esp_binaries()在三个常见挂载路径中探测 ESP/boot/efi/EFI、/boot/EFI、/efi/EFIagent.py随后递归遍历所有*.efi文件计算 SHA-256 与文件大小单个文件读取失败时记录error而不中断整体任务agent.py。CHIPSEC 集成与报告输出--check-chipsec参数控制是否运行chipsec_main -m common.secureboot.variables超时 600 秒通过解析输出中的PASSED/FAILED得出判定agent.py。非 root 运行会输出警告报告以 JSON 结构化落盘控制台给出人类可读的摘要包括Secure Boot 未启用和dbx 落后两条高危告警agent.py。整个脚本默认只读--apply --dry-run之外的写操作都不在脚本内从源码结构看其设计意图是让安全人员能在 Live 环境或受控主机上安全采集证据再进行离线分析。命令参考速查本技能配套的 api-reference.md 提供了完整的命令清单以下为核心速查表mokutilLinux Secure Boot 状态命令说明mokutil --sb-state报告 Secure Boot 是否启用mokutil --list-enrolled列出已注册的 MOK机器所有者密钥mokutil --db通过 shim 显示平台 db 条目mokutil --dbx通过 shim 显示 dbx 吊销条目efitools命令说明efi-readvar导出 PK、KEK、db、dbxefi-readvar -v dbx -o dbx.esl将 dbx 导出为 EFI 签名列表文件dbxtool命令说明dbxtool --list列出当前 dbx 条目与数量dbxtool --dbx DBXUpdate.bin --apply --dry-run预览某更新将添加的吊销项不写入dbxtool --dbx DBXUpdate.bin --apply应用 dbx 更新写入需谨慎CHIPSEC命令说明chipsec_main -m common.secureboot.variables验证 SB 密钥变量已认证/受保护chipsec_main -m common.secureboot.variables -a modify尝试写入/破坏 SB 变量破坏性测试chipsec_main -m common.uefi.s3bootscript检查 S3 恢复引导脚本保护chipsec_util spi dump rom.bin导出 SPI 闪存用于离线分析签名校验命令说明sbverify --list file.efi列出 EFI 二进制的签名sbverify --cert db.crt file.efi用 db 证书校验二进制pesign -S -i file.efi显示签名RHEL 系Windows PowerShellCmdlet说明Confirm-SecureBootUEFI返回$true表示 Secure Boot 已启用Get-SecureBootUEFI dbx获取原始 dbx 变量字节Get-SecureBootUEFI db获取允许签名数据库TPM 佐证命令说明tpm2_pcrread sha256:7读取 PCR[7]Secure Boot 策略测量值工具与资源清单工具用途mokutilLinux 下查询 Secure Boot 状态与已注册密钥efitoolsefi-readvar导出 PK/KEK/db/dbxdbxtool检查并应用 dbx 更新CHIPSEC固件与 Secure Boot 变量评估sbsigntool / pesignEFI 二进制签名校验UEFI Revocation List官方 dbx 更新文件Microsoft KBCVE-2023-24932Secure Boot 绕过缓解指引ESET BlackLotus 分析Bootkit 技术分析报告相关标准与框架除上文 MITRE ATTCK 映射外本技能还与以下标准相互印证详见 standards.mdCVE-2022-21894Baton DropBlackLotus 借以绕过 Secure Boot 的易受攻击且已签名的 Windows 引导管理器CVE-2023-24932Secure Boot 安全功能绕过通过分阶段 dbx 吊销缓解微软 KB5025885NSA UEFI Secure Boot 定制化指引UEFI Secure Boot 信任链的加固与验证NIST SP 800-147 / 800-193 平台固件弹性固件完整性的保护、检测与恢复要求UEFI 规范 —— Secure Bootdb/dbx/KEK/PK本技能所检查变量模型的权威来源。验证标准Validation Criteria完成一次检测后对照以下清单确认覆盖度目标上确认 Secure Boot 已启用且处于 user 模式PK/KEK/db/dbx 已枚举并导出用于分析dbx 已与当前官方 UEFI 吊销列表比对确认 CVE-2022-21894 / CVE-2023-24932 吊销项已存在或标记缺口CHIPSECsecureboot.variables与s3bootscript模块已运行ESP 引导二进制已完成哈希与签名校验哈希已与已知恶意/吊销集合交叉比对ESP 已检查是否存在未授权或近期修改的二进制发现的问题已按主机记录并给出修复建议dbx 更新 / 固件更新。结语检测 Secure Boot 绕过本质上是对信任链末端的审计Secure Boot 是否真的开着、dbx 是否真的吊销了易受攻击的引导管理器、EFI 变量是否真的受保护、磁盘上的引导二进制是否真的与预期一致。将上述十步流程固化为脚本如本技能配套的 agent.py并纳入周期性基线检查就能在 bootkit 真正落地前发现可被利用的缺口。需要更多上下文时可继续阅读技能定义 SKILL.md 及其命令参考 api-reference.md并参阅仓库 ATTACK_COVERAGE.md 了解本技能在 MITRE ATTCK 覆盖中的位置。【免费下载链接】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），仅供参考