企业官网建设流程全解析

UEFI Bootkit 持久化分析实战指南：基于 Anthropic-Cybersecurity-Skills 的固件取证与 Secure Boot 绕过检测

【免费下载链接】Anthropic-Cybersecurity-Skills817 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项目地址: 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 Key（MOK）注册；
• 固件完整性校验无法通过厂商提供的基线；
• 内存取证揭示引导早期阶段加载了 rootkit 组件；
• 调查已知会部署 UEFI 植入的 APT 活动；
• 企业端点加固前的固件安全态势审计。

同时技能明确指出不适用范围：传统 BIOS 上的 MBR 引导型 bootkit 不在此分析范畴，应改用 MBR/VBR bootkit 分析方法。

从威胁模型看，UEFI 植入按持久化载体可分为两大类（依据 agent.py 内置的KNOWN_BOOTKITS知识库）：

1.1 框架映射：一次分析，多方合规

该技能在仓库的六框架映射体系中覆盖了 MITRE ATT&CK 与 NIST CSF 2.0，在 SKILL.md 的 YAML frontmatter 中可查证：

• MITRE ATT&CK：T1542.001（System Firmware）、T1542.003（Bootkit）、T1553.006（Code Signing Policy Modification）、T1542（Pre-OS Boot）、T1014（Rootkit）；
• NIST CSF 2.0：ID.RA-01（资产漏洞识别）、PR.PS-01/PR.PS-02（平台保护）；
• MITRE D3FEND：Platform Hardening、Restore Object、Platform Monitoring、Firmware Verification、Firmware Embedded Monitoring Code。

仓库的 ATTACK_COVERAGE.md 与 mappings/mitre-attack/coverage-summary.md 记录了全库 TTP 覆盖情况，其中 Rootkit（T1014）与 Pre-OS Boot（T1542）正是本技能对应的工作面，可在 mappings/attack-navigator-layer.json 中查看可视化的覆盖图层。

二、准备工作：工具链与前提条件

依据 SKILL.md 的 Prerequisites 小节，完整分析需要以下工具链：

• chipsec：Intel 平台安全评估框架，用于 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.md）：

• spi dump输出完整固件镜像；若只需特定区域，可用python chipsec_util.py spi read 0x700000 0x100000 bios.bin按偏移读取；
• flashrom 支持flashrom -p internal --flash-size查看芯片容量、flashrom -L列出支持的芯片型号；
• 对应安全模块的底层含义见下表（参考 api-reference.md 的 Key Modules Reference）：

在 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.variables

Secure Boot 变量的标准 GUID 由 api-reference.md 提供，分析时需精确比对：

关键审计点：MOK（Machine 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 Partition（ESP）

ESP 通常是第一块 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()把上述人工操作自动化了，其检查逻辑可作为判定的源码依据：

1. system32 目录检测：ESP 根下存在system32/目录 → 判定为CRITICAL级 BlackLotus 指标；
2. grubx64.efi 检测：在纯 Windows 系统上发现grubx64.efi→ 判定为HIGH级异常（BlackLotus/Bootkitty 指标）；
3. 非标准目录检测：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_GUIDS（FFS 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()按块计算香农熵，将固件区域分类为 empty（<1.0）、code/data（<5.0）、compressed（<7.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-21894（baton drop）等漏洞以及 MOK 注册均可绕过它，因此必须检查绕过迹象：

# 检查 Secure Boot 是否启用 python chipsec_main.py -m common.secureboot.variables # 验证 SMM（System 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" # 验证 HVCI（Hypervisor-enforced Code Integrity）未被禁用 # BlackLotus 会设置 HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0 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 ATT&CK 映射（T1542.001 - System Firmware、T1542.003 - Bootkit）。

四、关键概念速查

SKILL.md 的核心概念表是理解整个分析流程的基础：

五、工具与系统速览

• chipsec：Intel 框架，用于转储 SPI Flash、读取 UEFI 变量、验证固件写保护与审计 Secure Boot 配置（详见 api-reference.md 的 SPI/UEFI/模块三大命令族）；
• UEFITool：开源 UEFI 固件镜像解析器，用于检查固件卷、提取 DXE 驱动、比对模块 GUID；
• sigcheck：Sysinternals 工具，验证 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 级植入。

处置路径：

1. 从可信的 Linux 应急启动盘启动，避免执行任何被感染的 OS 组件；
2. 使用chipsec_util.py spi dump转储 SPI Flash 固件以离线分析；
3. 挂载 ESP，对全部.efi文件做哈希，与同型号硬件的已知良好值比对；
4. 检查ESP:/system32/目录（BlackLotus 指标）与未授权的grubx64.efi；
5. 用 UEFIExtract 提取固件模块，将 GUID 清单与厂商基线比对；
6. 验证 Secure Boot 变量——查找未授权的 MOK 注册或被修改的 db/dbx；
7. 用 chipsec 模块检查 SPI Flash 写保护与锁定位；
8. 用 UEFI 专用 YARA 规则扫描固件转储与提取的模块；
9. 若怀疑 BlackLotus，检查注册表中 HVCI 是否被禁用，并审阅 MeasuredBoot 日志中的异常条目。

常见陷阱（务必规避）：

• 在被感染的 OS 内运行分析（rootkit 组件会向活动分析隐藏自身）；
• 只查 ESP 而不查 SPI Flash 固件（会漏掉 LoJax、MoonBounce 这类固件植入）；
• 假设 Secure Boot 能阻止所有 bootkit（CVE-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 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 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

其关键设计对分析实践的直接价值：

1. 内置 7 大已知家族知识库：BlackLotus、LoJax、MoonBounce、CosmicStrand、ESPecter、MosaicRegressor、Bootkitty，每条记录都包含持久化载体、ESP/固件/注册表指标与 MITRE ATT&CK 映射，可直接作为归因对照表；
2. ESP 自动化取证：scan_esp_partition()同时输出全量 EFI 文件清单（路径/大小/SHA-256）与分级告警（CRITICAL/HIGH/MEDIUM）；
3. 固件无依赖体检：scan_firmware_dump()无需 UEFITool 即可完成固件卷定位、PE 枚举与可疑字符串扫描；
4. 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 ATT&CK 覆盖矩阵中的位置，结合 ATTACK_COVERAGE.md 了解全库战术层面的整体覆盖情况。注意本仓库为只读资料库，所有分析应在你拥有授权的独立环境（应急启动盘、隔离取证机）中执行。

【免费下载链接】Anthropic-Cybersecurity-Skills817 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项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills