jeffersoncesarantunes/K-Verify

# K-Verify SYNTROPY 取证生态系统的紫队对抗验证套件。 [](https://kernel.org) [](https://gcc.gnu.org/) [](LICENSE) [](#-roadmap) [](https://github.com/jeffersoncesarantunes/K-Verify/actions/workflows/ci.yml) [](https://github.com/jeffersoncesarantunes/K-Verify/actions/workflows/codeql.yml) [](Dockerfile) [](https://security.archlinux.org/) [](#-overview) ## 词源与起源 **K-Verify** 这个名字来源于 Linux **Kernel**（内核）—— 它是支撑这里每一项验证逻辑的基础接口。“K”是对 Kernel 的致敬，就像 SYNTROPY 生态系统中的姊妹项目 **K-Scanner** 一样。它们的不同之处在于各自的功能。扫描器用于枚举状态。而 K-Verify 则用于*验证*：它在运行中的系统上主动执行对抗行为，并检查检测机制是否真的能捕捉到这些行为。 ## 概述 K-Verify 是一款紫队对抗验证工具，专为压力测试 SYNTROPY 取证生态系统中的检测层而构建 —— 特别是 **K-Scanner** 和 **LinSpec**。 它在运行的 Linux 机器上执行受控的对抗行动，然后将每一项行动与蓝队工具所依赖的内核接口进行交叉比对。每个场景都映射到一项 **MITRE ATT&CK** 技术，最终报告包含一份**检测差距分析**，用于指出目前无人覆盖的盲区。 该工具涵盖了几个核心领域。它会分配可写加可执行内存，并检查 K-Scanner 是否能发现它。它会 fork 并重命名进程，以查看 /proc 枚举的执行情况。它会尝试绕过 W^X 和 ASLR，并验证 LinSpec 的审计功能。它会检查内核 BTF 和 BPF JIT 状态以确保 eBPF 的就绪情况，并针对 shellcode 特征码验证 YARA 模式匹配。当存在可运行的二进制文件时，它甚至可以调用真实的 K-Scanner 和 LinSpec 实例，进行真正的端到端测试。每个场景都标记了其对应的 MITRE ATT&CK 技术 ID，并且检测差距分析会统计出有哪些场景是这两个工具均未覆盖的。 ## 功能 K-Verify 自带八个对抗场景，每个都映射到一个 MITRE ATT&CK 技术 ID。你可以通过 `--bpf` 进行 eBPF 遥测验证，以检查内核 BTF 和 BPF JIT 的就绪情况；通过 `--yara` 进行 YARA 规则检测测试，将已知的 shellcode 模式放入引擎中运行；还可以通过 `--live` 进行实时的工具集成，当 K-Scanner 和 LinSpec 二进制文件位于 $PATH 时，直接调用它们。自动化验证会将所有内容与这两个工具内部使用的相同内核接口进行交叉比对。输出结果会在终端中显示为带有颜色标记的紫队验证矩阵，你还可以导出结构化的 JSON 或 CSV 文件，用于你的报告流水线。**检测差距分析**会指出没有任何工具覆盖的盲区。**MITRE ATT&CK** ID 会显示在终端输出、JSON 和 CSV 中。此外还有 **Silent JSON 模式**（`--json`），该模式会完全隐藏横幅信息，专为 CI/CD 流水线设计。它的引擎采用模块化的 C99 架构 —— 每个场景都位于其独立的源文件中。它通过 `make test` 提供自动化单元测试套件，通过 GitHub Actions 实现 CI/CD 流水线，拥有只读验证阶段（可在不发动任何攻击的情况下评估系统状态），以及具备清理模式的完整子进程生命周期管理。 ## MITRE ATT&CK 映射 每个场景都映射到了真实的 MITRE ATT&CK 技术： | 场景 | 技术 ID | 描述 | |---|---|---| | RWX_ALLOC | [T1055.001](https://attack.mitre.org/techniques/T1055/001/) | 进程注入：便携式可执行文件注入 | | RWX_EXEC | [T1055](https://attack.mitre.org/techniques/T1055/) | 进程注入 | | HIDE_PROC | [T1564](https://attack.mitre.org/techniques/T1564/) | 隐藏痕迹 | | HIDE_COMM | [T1564](https://attack.mitre.org/techniques/T1564/) | 隐藏痕迹 | | BYPASS_WX | [T1562.001](https://attack.mitre.org/techniques/T1562/001/) | 损害防御：禁用或修改工具 | | BYPASS_ASLR | [T1562.001](https://attack.mitre.org/techniques/T1562/001/) | 损害防御：禁用或修改工具 | | BPF_VALIDATE | [T1059](https://attack.mitre.org/techniques/T1059/) | 命令和脚本解释器 | | YARA_SCAN | [T1560](https://attack.mitre.org/techniques/T1560/) | 归档收集的数据 | 技术 ID 被嵌入到了终端输出、JSON 导出和 CSV 报告中。 ## 输出示例 ``` ╔═══════════════════════════════════╗ ║ K-Verify ║ ║ Purple Team — Adversarial ║ ║ Validation ║ ╚═══════════════════════════════════╝ ══════════════════════════════════════════════════════════════════════════ RUN SEQUENCE INITIATED ══════════════════════════════════════════════════════════════════════════ [01/08] RWX_ALLOC ...... PASS [KS:✔ LS:✘] T1055.001 [02/08] RWX_EXEC ....... PASS [KS:✔ LS:✘] T1055 [03/08] HIDE_PROC ...... PASS [KS:✔ LS:✘] T1564 [04/08] HIDE_COMM ...... WARN [KS:✘ LS:✘] T1564 [05/08] BYPASS_WX ...... PASS [KS:✘ LS:✔] T1562.001 [06/08] BYPASS_ASLR .... FAIL [KS:✘ LS:✔] T1562.001 [07/08] BPF_VALIDATE ... PASS [KS:✔ LS:✘] T1059 [08/08] YARA_SCAN ...... SKIP [KS:✘ LS:✘] T1560 ══════════════════════════════════════════════════════════════════════════ FINAL ASSESSMENT ══════════════════════════════════════════════════════════════════════════ [██████░░░░] 4/8 (50%) adversarial actions succeeded [██░░░░░░░░] 2/8 (25%) detected by K-Scanner [█░░░░░░░░░] 1/8 (12%) detected by LinSpec [██████░░░░] 4/8 (50%) unmonitored gaps (no KS or LS coverage) STATUS: Purple Team Validation Complete ══════════════════════════════════════════════════════════════════════════ ``` ## 工作原理 K-Verify 的运行分为三个阶段。 ### 第一阶段：对抗执行 每个场景都会执行一种受控的攻击技术。RWX_ALLOC 调用带有 `PROT_READ|PROT_WRITE|PROT_EXEC` 参数的 `mmap`。RWX_EXEC 会将 shellcode (exit(0)) 写入 RWX 区域并执行它。HIDE_PROC 会 fork 出一个子进程，然后对它使用 `prctl(PR_SET_NAME, "[kworker/0:0]")`。HIDE_COMM 会直接写入 `/proc/self/cmdline`。BYPASS_WX 会尝试进行 RWX mmap 并检查是否触发了强制限制。BYPASS_ASLR 会读取 `randomize_va_space`。BPF_VALIDATE 会检查内核 BTF 和 BPF JIT 加固状态。YARA_SCAN 会编译一条 YARA 规则，并针对测试 shellcode 运行该规则。 ### 第二阶段：检测 对于每个场景，K-Verify 都会查询目标蓝队工具将会读取的相同内核接口。在 K-Scanner 路径上，它会解析 `/proc/[PID]/maps` 以寻找 `rwx` 权限条目。在 LinSpec 路径上，它会读取 `/proc/sys/kernel/*` 加固参数。这两个工具 —— K-Scanner 和 LinSpec —— 都是 SYNTROPY 生态系统中的参考项目。你无需安装它们即可运行 K-Verify。这两者的检测逻辑已经被直接内置在 K-Verify 的源代码中：它会读取它们本应读取的相同内核接口，并*预测*它们是否会触发警报。如果你传递了 `--live` 参数，它可以选择调用真实的二进制文件以进行真正的验证。 ### 第三阶段：关联 结果将以验证矩阵的形式呈现。你可以看到对抗行动是否成功、每个蓝队工具是否能检测到它，以及对应的 MITRE ATT&CK 技术 ID。最后会提供一份包含进度条的总结，展示对抗成功率、检测覆盖率和未受监控的漏洞情况。 ### 检测差距分析 最终评估包含一个名为**未受监控的漏洞**的指标 —— 指的是 K-Scanner 和 LinSpec 均未提供覆盖的场景。这些就是你最高风险的盲区。 ## 构建与运行 ``` # Clone 仓库 git clone https://github.com/jeffersoncesarantunes/K-Verify.git cd K-Verify # Build 项目 make clean && make # 运行 test suite make test # 使用默认终端输出运行所有场景 sudo ./kverify # 使用静默 JSON export 运行所有场景（无 banner，适配 CI/CD） sudo ./kverify --json # 将结果 export 到 CSV sudo ./kverify --csv # 运行特定 module sudo ./kverify --rwx sudo ./kverify --hide sudo ./kverify --bypass sudo ./kverify --bpf sudo ./kverify --yara # 结合实时 K-Scanner/LinSpec integration 运行 sudo ./kverify --live # 只读验证（无对抗性行为） sudo ./kverify --verify-only # 清理任何剩余的子进程 sudo ./kverify --cleanup ``` ### YARA 规则检测 [YARA](https://virustotal.github.io/yara/) 是一个用于恶意软件识别的模式匹配引擎。K-Verify 使用它来检查 YARA 规则是否能正确检测内存中的 shellcode 模式。在运行 `--yara` 场景和 `YARA_SCAN` 测试时需要用到它。 ``` # 安装 YARA（可选，--yara 需要） sudo pacman -S yara ``` 当单独使用 `--json` 时，工具会完全跳过横幅和终端输出，仅写入 JSON 报告文件。这专为自动化流水线、cron 任务和 CI/CD 集成而设计。 ## 后分析与报告查看 生成报告后，你可以直接从终端中查看它们： ``` # 查看对齐且格式化的 CSV 结果（前 15 个结果） column -t -s ',' kverify-report.csv | head -n 16 # 快速检查结构化的 JSON output header cat kverify-report.json | head -n 15 ``` ## 项目实际运行情况 截图预留给未来的可视化演示。images 目录包含了相关的资源文件，一旦演示文档定稿，就会在这里引用。 ## 操作完整性 K-Verify 专为受控的对抗测试而设计。所有 shellcode 都是无害的 —— 仅为 exit(0)。子进程会受到跟踪并被妥善回收。`--cleanup` 模式会杀死任何残留的子进程。`--verify-only` 用于执行只读评估。不会对系统进行持久化修改，没有任何网络活动，也没有横向移动。每一项操作都会被透明地记录下来。 ## 部署 ### 环境要求 你需要 Linux Kernel 5.x 或更高版本、gcc、make，以及用于 /proc 访问和 mmap 测试的 root 权限。建议使用兼容 UTF-8 的终端。可选配置：用于 `--yara` 的 yara 和 yarac，以及用于 `--live` 的 kscanner 和 linspec。 ## 仓库结构 ``` ├── .github/workflows/ │ └── ci.yml ├── build/ │ └── obj/ ├── docs/ │ ├── ADVERSARIAL_SCENARIOS.md │ ├── PURPLE_MODEL.md │ └── VALIDATION_PROTOCOL.md ├── Images/ │ ├── kverify1.png │ ├── kverify2.png │ └── kverify3.png ├── include/ │ ├── colors.h │ ├── kverify.h │ └── modules.h ├── reports/ ├── scenarios/ ├── src/ │ ├── bpf_validate.c │ ├── bypass.c │ ├── hide.c │ ├── main.c │ ├── rwx.c │ ├── utils.c │ ├── verify.c │ └── yara_scan.c ├── tests/ │ ├── .gitkeep │ └── test_utils.c ├── .gitignore ├── LICENSE ├── Makefile └── README.md ``` ## 技术栈 编程语言为 C99。数据源为 `/proc`、`mmap` 和 `prctl`。构建工具为 GNU Make。测试框架为定制的 C 测试框架。目标平台为 Linux Kernel 5.x 和 6.x。 ## 路线图 - [x] 包含 RWX、隐藏和绕过模块的模块化 C99 引擎 - [x] 交叉比对 K-Scanner 和 LinSpec 的验证引擎 - [x] 带有颜色标记的终端验证矩阵 - [x] 包含 MITRE ATT&CK ID 的结构化 JSON/CSV 导出 - [x] 检测差距分析（未受监控的盲区） - [x] 适用于 CI/CD 流水线的 Silent JSON 模式 - [x] `--verify-only` 只读评估模式 - [x] 基于 eBPF 的检测验证（`--bpf`） - [x] 基于 YARA 规则的检测模式匹配（`--yara`） - [x] 实时工具集成（`--live`） - [x] 自动化测试套件（`make test`） - [x] CI/CD 流水线（GitHub Actions） - [ ] 多进程协同攻击场景 ## 文档 [](./docs/PURPLE_MODEL.md) [](./docs/ADVERSARIAL_SCENARIOS.md) [](./docs/VALIDATION_PROTOCOL.md)

标签：取证, 安全渗透, 客户端加密, 对抗验证, 检测规则测试, 紫队工具, 请求拦截