javierDAW/detection-diary

GitHub: javierDAW/detection-diary

基于公开威胁情报的每日检测规则生成项目,将真实攻击案例转化为Sigma、KQL、SPL、YARA等多格式可部署检测内容。

Stars: 0 | Forks: 0

# detection-diary [![Sigma](https://img.shields.io/badge/Sigma-rules-blue)](https://github.com/SigmaHQ/sigma) [![KQL](https://img.shields.io/badge/KQL-Sentinel%20%7C%20Defender%20XDR-0078D4)](https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/) [![SPL](https://img.shields.io/badge/SPL-Splunk-black)](https://docs.splunk.com/Documentation/SCS/current/Search/Aboutsearchlanguage) [![YARA](https://img.shields.io/badge/YARA-rules-yellow)](https://yara.readthedocs.io/) [![MITRE ATT&CK](https://img.shields.io/badge/MITRE-ATT%26CK%20mapped-red)](https://attack.mitre.org/) [![许可证](https://img.shields.io/badge/license-MIT-green)](LICENSE) ## 这是什么 这个仓库是我的个人**检测日志**:每天我从威胁情报源中选取一个高影响力且技术含量高的案例(来自 Mandiant、Microsoft、Volexity、Unit 42、ESET、Talos、Securelist、SentinelOne、CrowdStrike、Dragos 等供应商的文章,以及 DFIR Report 和 CISA 公告),并将其转化为**可部署的检测内容**: - **Sigma** 规则(与供应商无关,可通过 `pySigma`/`uncoder`/`sigmac` 转换) - **KQL** 查询(适用于 Microsoft Sentinel 和 Defender XDR) - **SPL** 查询(适用于 Splunk Enterprise / ES) - **YARA** 规则(文件/进程内存) - **Suricata / Snort** 签名——在相关时提供 - **PEAK / TaHiTI** 狩猎假设及基线 每个条目都基于已发布且有来源的案例,因此具有可辩护性和可重现性。 ## 这**不是**什么 - 这不是用于生产环境拦截列表的订阅源。在将每个 IOC 接入预防性控制措施之前,请务必进行验证——虽然记录了置信度,但情况会发生变化。 - 这不是 SigmaHQ 的替代品。达到上游质量要求的规则会通过 PR 提交到 [SigmaHQ](https://github.com/SigmaHQ/sigma);这里是该步骤之前的**实验记录本**。 - 这不是武器化的 PoC。这里所有的攻击性代码片段均已公开,其存在是为了**检测设计**,而非用于利用。 ## 仓库布局 ``` detection-diary/ ├── README.md ├── INDEX.md ← AUTO-GENERATED — chronological + by-actor + by-technique + by-platform ├── CHANGELOG.md ├── LICENSE ├── .gitignore │ ├── days/ ← source of truth — one folder per case │ └── YYYY-MM-DD_/ │ ├── README.md ← YAML frontmatter at the top is the canonical metadata │ ├── sigma/*.yml │ ├── kql/*.kql │ ├── spl/*.spl │ ├── yara/*.yar │ ├── suricata/*.rules │ ├── hunts/*.md │ └── iocs.csv │ ├── byActor/ ← AUTO-GENERATED view: one folder per cluster/alias │ ├── README.md │ └── /README.md │ ├── byTechnique/ ← AUTO-GENERATED view: one folder per MITRE ATT&CK ID │ ├── README.md │ └── txxxx/README.md │ ├── byPlatform/ ← AUTO-GENERATED view: one folder per platform tag │ ├── README.md │ └── /README.md │ └── tools/ ├── validate_all.py ← offline multi-format validator (Sigma, YARA, Suricata, KQL, SPL, CSV, YAML, MD, Bash) ├── sigma_check.py ← Sigma-only offline validator (PyYAML-only dep) ├── lint_sigma.sh ← Sigma wrapper: sigma-cli if installed, else falls back to sigma_check.py ├── lint_all.sh ← full chain wrapper └── generate_index.py ← rebuilds INDEX.md + byActor/ + byTechnique/ + byPlatform/ from frontmatter ``` ## 命名规范 ``` days/YYYY-MM-DD_/ ``` - `YYYY-MM-DD` 是**课程交付**的日期,而不是案例披露的日期。 - `` 是活动 ID、恶意软件家族或攻击者名称(短横线命名法)。示例: - `2026-05-04_C0063-Poland-Wiper` - `2026-05-03_BAUXITE-CyberAvengers-AA26-097A` - `2026-05-02_Nexcorium-TBK-DVR-CVE-2024-3721` 其中的规则文件遵循以下格式: ``` . ``` ## 规则元数据标准 每个 Sigma 规则必须包含: ``` title: # imperative, < 80 chars id: # UUID v4 status: # experimental | test | stable | deprecated description: # 2–4 lines, plain English, what + why references: - https://... # primary vendor write-up - https://... # secondary corroboration - https://attack.mitre.org/... author: # your handle date: # YYYY/MM/DD modified: # YYYY/MM/DD tags: - attack. - attack. - cve.YYYY-NNNN # if applicable logsource: # exact provider/service/category detection: ... falsepositives: - ... # always at least one — be honest level: # informational | low | medium | high | critical ``` 每个 KQL/SPL 文件都以一个头部注释块开头: ``` // Title: Lateral Movement via Rubeus S4U2self with TGS Burst // Id: uuid-v4 // MITRE: T1558.003, T1550.003 // Reference: https://... // Author: // Date: 2026-05-04 // Tested on: Sentinel (DeviceProcessEvents, SecurityEvent) // FP notes: Legitimate constrained delegation cases; baseline before deploy. ``` 每个 YARA 规则的 `meta:` 块中必须填充 `author`、`description`、`date`、`reference`、`confidence` 以及(在相关时)`eset_family` / `vendor_family`。 ## 如何使用 ### Microsoft Sentinel / Defender XDR ``` // Drop the .kql contents into: // Sentinel → Analytics → Create → Scheduled query rule // or Defender XDR → Hunting → Custom detection rule ``` ### Splunk Enterprise / ES ``` # 将 .spl 保存为 Saved Search,计划运行。 # 对于 Splunk ES,接入 Correlation Search 并分配 Risk-Based Alerting。 ``` ### Sigma → 供应商目标平台 ``` pip install pysigma pysigma-backend-splunk pysigma-backend-microsoft365defender sigma convert -t splunk days/2026-05-04_C0063-Poland-Wiper/sigma/*.yml sigma convert -t microsoft365defender days/2026-05-04_C0063-Poland-Wiper/sigma/*.yml ``` ### YARA — 扫描取证镜像 ``` yara -r days/2026-05-04_C0063-Poland-Wiper/yara/*.yar /mnt/triage/ ``` ## 验证 在每次提交之前会在**本地运行验证**——不涉及 CI。根据您想要检查的内容,有三个入口点: ``` # 1) 快速离线检查 — 无需外部工具,仅需 PyYAML python3 tools/validate_all.py # 2) 完整链 — 运行离线检查 + 你已安装的每个外部工具 ./tools/lint_all.sh # 3) Sigma-only 快速路径 (快速) ./tools/lint_sigma.sh ``` 验证内容: | 格式 | 离线验证 (`validate_all.py`) | 外部工具 (`lint_all.sh`) | |---|---|---| | Sigma `.yml` | UUID、status、level、modifiers、condition 引用 | `sigma check` + `sigma convert -t splunk -p sysmon` | | YARA `.yar` | 规则块、大括号平衡、`condition:` 节、重复名称 | `yara -w rule.yar /dev/null` | | Suricata `.rules` | action、sid 唯一性、`(...;)` body、msg/rev | `suricata -T -S rule.rules` | | KQL `.kql` | 括号平衡、头部注释、关键字存在、末尾管道符 (trailing-pipe) | — | | SPL `.spl` | 括号平衡、管道符后的命令、头部注释 | — | | CSV `iocs.csv` | 头部 schema、行宽 | — | | YAML | 严格加载 (workflows + Sigma + 所有 `.yml`) | — | | Markdown | 失效的相对链接 | `markdownlint` | | Bash `.sh` | 如果可用,运行 `bash -n` | `shellcheck` | | GitHub Actions | YAML 加载 | `actionlint` | 建议安装完整的本地工具链: ``` pip install --user pysigma sigma-cli pysigma-backend-splunk \ pysigma-pipeline-sysmon yamllint sudo apt-get install -y yara suricata shellcheck bash <(curl -sSfL https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash) sudo install -m 0755 actionlint /usr/local/bin/actionlint npm install -g markdownlint-cli ``` ## 发布前测试 每个规则都应至少在脑海中对相同技术 ID 的 [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) 测试进行演练。 如有疑问,请遵循 [PEAK Threat Hunting Framework](https://www.splunk.com/en_us/blog/security/peak-threat-hunting-framework.html): 1. **准备** — 我要测试什么假设? 2. **执行** — 运行狩猎活动,建立基线,进行优化。 3. **基于知识采取行动** — 提升为检测项,记录误报面,进行加固。 ## 索引 请参阅 [`INDEX.md`](INDEX.md) 获取所有案例的时间顺序和主题索引。 ## 来源策略 - **多方交叉验证。** 每个案例必须引用至少两个独立的来源(供应商报告 + 机构公告,或存在交集的两个供应商)。 - **引用首要来源。** 始终链接到原始文章,而非聚合网站的标题。 - **标注置信度。** 当归因存在争议时(例如,C0063 归因为 Static Tundra 还是 Sandworm),应记录两种观点及其所依据的证据。 - **绝不捏造 IOC、哈希或 CVE。** 如果某个哈希值未公开,则相应的规则为启发式规则,并会明确标记。 ## 贡献 这主要是一个个人笔记本,但接受 PR。
标签:CISA项目, Cloudflare, Defender XDR, EDR, IOCs, IP 地址批量处理, KQL, Metaprompt, Microsoft Sentinel, MITRE ATT&CK, PEAK方法论, PE 加载器, Sigma规则, SPL, Suricata, TaHiTI, YARA, 云资产可视化, 威胁情报, 子域名变形, 安全运营, 库, 应急响应, 应用安全, 开发者工具, 归因分析, 扫描框架, 数据展示, 现代安全运营, 目标导入, 紫队, 红队, 网络信息收集, 网络安全, 脆弱性评估, 误报处理, 逆向工具, 隐私保护