writing-sigma-rules

编写 Sigma 规则

Sigma 是检测逻辑的通用语言——编写一次，即可转换为任意 SIEM。它的价值在于可移植性和可审查性，但前提是规则足够精确：一条什么都能匹配的 Sigma 规则还不如没有，因为它会耗费分析人员的时间，还会让团队习惯于忽略警报。关键在于提高精确性，同时避免规则过于脆弱。

适用场景

• 将 TTP、威胁情报报告或事件调查发现转化为可移植的检测规则
• 编写可转换为多个 SIEM 后端的厂商无关检测逻辑
• 构建或维护以 Sigma 为核心的检测即代码流水线
• 审查或调整现有 Sigma 规则，以提高精确性并减少误报
• 在不同后端之间转换 Sigma 规则（Splunk、Elastic、Sentinel、CrowdStrike、Chronicle）
• 向 SigmaHQ 上游贡献规则，或维护私有规则仓库

不适用场景

• 涵盖 YARA、Suricata 和完整检测生命周期的广泛检测工程——使用 engineering-detections
• 签名针对的是文件或内存，而非日志遥测数据——使用 writing-yara-rules
• 基于假设的威胁狩猎，而非编写规则——使用 hunting-threats
• 正在进行的事件响应，而非规则开发——使用 responding-to-incidents

Sigma 规则结构

每条规则都是包含以下字段的 YAML 文档，字段顺序如下：

规范只要求三个字段：title、logsource 和 detection（其中必须包含 condition）。其他内容对规范而言都是可选的。不要将这一点与 SigmaHQ 规则仓库的要求混为一谈：要向该仓库提交规则，还必须提供更多字段——id、status、description、author、date、level 和 ATT&CK tags。默认按照更严格的 SigmaHQ 约定编写，因为在实际流水线中，没有 id 或 level 的规则无法管理；但也要清楚自己满足的是哪项要求，因为转换器可能接受规则，而审查者却不认可。

title: Short Descriptive Name              # REQUIRED by spec, max ~100 chars
id: a1b2c3d4-0000-4000-8000-000000000001  # optional to spec; UUIDv4, never reuse
related:                                    # optional, link to predecessor rules
  - id: <uuid>
    type: derived | obsoletes | merged | renamed | similar
status: experimental                        # optional; see lifecycle below
description: >                              # optional to spec, expected by SigmaHQ
  Detects X behaviour consistent with Y technique.
references:                                 # optional, strongly recommended
  - https://attack.mitre.org/techniques/T1059/001/
author: Your Name                           # optional to spec
date: 2026-07-26                            # optional; ISO 8601 YYYY-MM-DD
modified: 2026-07-26                        # optional; same format, on update
tags:                                       # optional to spec, expected by SigmaHQ
  - attack.execution                        #   tactic (lowercase, dotted)
  - attack.t1059.001                        #   technique (lowercase)
logsource:                                  # REQUIRED by spec
  category: process_creation
  product: windows
detection:                                  # REQUIRED by spec
  selection:
    CommandLine|contains: 'some-indicator'
  condition: selection                      # REQUIRED inside detection
falsepositives:                             # optional to spec
  - Legitimate admin scripts using the same flag
level: medium                               # optional; informational|low|medium|high|critical

日期格式。 规范规定使用带连字符的 ISO 8601 格式——YYYY-MM-DD。旧规则和许多在线资料使用过时的格式 YYYY/MM/DD；这种格式已经过时，某些工具现在会拒绝它。

状态生命周期。 允许的值为 experimental、test、stable、deprecated 和 unsupported。实际含义如下：experimental = 仅观察，不发出警报。test = 已通过仿真验证，可有限部署。stable = 已在生产环境中调优，并记录误报。deprecated = 已被替代，不再准确。unsupported = 按当前写法无法使用（例如依赖自定义字段）。未完成相应工作时，绝不要提升状态。

日志源分类

logsource 块用于抽象数据源。只指定必要内容。

类别：process_creation、file_event、file_access、network_connection、registry_event、dns_query、image_load、pipe_created、process_access、driver_load、create_remote_thread。

产品：windows、linux、macos。

服务：sysmon、security、system、powershell、powershell-classic、application、taskscheduler、windefend、firewall-as。

如果你关注事件类型，而不在意数据收集方式，请使用 category。如果要定位特定日志通道，请使用 product + service。除非后端有要求，否则不要同时组合 category 和 service。

检测逻辑

选择与过滤模式

定义要匹配的内容（selection）和要排除的内容（filter_*），并在 condition 中组合：

detection:
  selection:
    ParentImage|endswith: '\explorer.exe'
    CommandLine|contains|all:
      - 'powershell'
      - '-enc'
  filter_legitimate:
    CommandLine|contains: 'company-deploy-script'
    User|startswith: 'SVC_'
  condition: selection and not filter_legitimate

条件语法

condition: selection                           # simple match
condition: selection and not filter            # match minus exclusions
condition: selection1 or selection2            # either pattern
condition: (sel1 and sel2) and not (fp1 or fp2)
condition: all of selection*                   # all blocks starting with "selection"
condition: 1 of selection*                     # any one block

关键字

匹配完整日志事件（所有字段）。这是个粗糙的工具——生产规则应优先使用针对特定字段的选择条件：

detection:
  keywords:
    - 'Invoke-Mimikatz'
    - 'sekurlsa::logonpasswords'
  condition: keywords

修饰符

使用 | 链接。示例：CommandLine|contains|all。

修饰符	效果
contains	子字符串匹配
startswith / endswith	前缀 / 后缀匹配
re	正则表达式（PCRE）
base64offset	匹配三个偏移量下的 Base64 编码变体
all	列表中的所有值都必须匹配（默认匹配任意值）
cidr	匹配 IP 字段中的 CIDR 网络范围
windash	将 - 和 / 均匹配为参数前缀
expand	展开 %SystemRoot% 等环境变量
wide / utf16le / utf16be / utf16	匹配值的宽字符（UTF-16）编码；wide 是 utf16le 的别名。没有 utf8 修饰符
exists	字段存在（true）或不存在（false）

常见检测模式

进程创建——可疑命令行

detection:
  selection:
    CommandLine|contains|windash|all: ['bypass', 'hidden', 'noprofile']
  filter_admin:
    ParentImage|endswith: ['\sccm.exe', '\intune_agent.exe']
  condition: selection and not filter_admin

父子进程关系（Office 启动 shell）

detection:
  selection:
    ParentImage|endswith: '\winword.exe'
    Image|endswith: ['\cmd.exe', '\powershell.exe', '\wscript.exe', '\mshta.exe']
  condition: selection

在可疑路径中创建文件

detection:
  selection:
    TargetFilename|contains: ['\AppData\Local\Temp\', '\ProgramData\', '\Users\Public\']
    TargetFilename|endswith: ['.exe', '.dll', '.scr', '.hta']
  condition: selection

注册表持久化（run 键）

detection:
  selection:
    TargetObject|contains: ['\CurrentVersion\Run\', '\CurrentVersion\RunOnce\']
    EventType: SetValue
  filter_installers:
    Image|startswith: 'C:\Windows\Installer\'
  condition: selection and not filter_installers

命名管道创建（C2 指标）

detection:
  selection:
    PipeName: ['\MSSE-*', '\postex_*', '\msagent_*', '\status_*']
  condition: selection

WMI 事件订阅和计划任务创建

WMI：logsource 为 product: windows、service: sysmon，匹配 EventID: 21、 Operation: Created。计划任务：logsource 为 category: process_creation， 匹配 Image|endswith: '\schtasks.exe'，并使用 CommandLine|contains|all: ['/create', '/sc']，同时筛选 SYSTEM 和已知管理工具。

误报处理

筛选模式

排除项应放在命名的 filter_* 块中，不要内联到 selection 中。 使用 condition: selection and not 1 of filter_* 应用所有筛选条件。

已知可信的排除项

根据攻击者无法控制的属性进行筛选：已签名供应商二进制文件的完整路径（而非仅文件名）、服务帐户 SID（而非用户名）、特定软件工作流中的父子进程对，以及已验证的证书主题。切勿仅根据文件名、攻击者可控的命令行片段或没有正当理由的主机名进行筛选。

严重性校准

级别	预期响应
informational	自动标记，仅作为关联分析输入
low	批量审核，每日分类
medium	分析师队列，在数小时内调查
high	及时调查，很可能是恶意活动
critical	立即响应，存在活跃入侵

根据预期 TP 率和业务影响设置级别，而不是根据技术听起来有多危险来设置。嘈杂的 critical 规则造成的损害可能大于精准的 medium 规则。

关联规则

当单个事件过于常见、不适合触发警报时，可使用 Sigma 关联规则引用其他规则的 ID，按某个字段（例如 ComputerName）分组，并要求在某个时间窗口内达到阈值：

title: Correlation - Multiple Suspicious Events from Same Host
type: correlation
rules:
  - id: <uuid-of-rule-1>
  - id: <uuid-of-rule-2>
group-by: [ComputerName]
timespan: 15m
condition:
  gte: 2
level: high

后端转换

使用 pySigma 的 sigma-cli

pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch \
  pySigma-backend-kusto pySigma-backend-qradar

sigma convert -t splunk -p sysmon rules/rule.yml
sigma convert -t elasticsearch -p ecs_windows rules/rule.yml
sigma convert -t kusto -p microsoft_xdr rules/rule.yml
sigma convert -t qradar rules/rule.yml
sigma convert -t splunk -p sysmon rules/                     # entire directory
sigma convert -t splunk -p sysmon -f savedsearches rules/    # output format

流水线选择

后端	常见流水线
Splunk	sysmon、splunk_windows、splunk_cim
Elastic	ecs_windows、ecs_zeek、filebeat
Sentinel/XDR	microsoft_xdr、azure_monitor
CrowdStrike	crowdstrike
Chronicle	chronicle_default

务必根据实际字段名验证转换后的输出。流水线默认设置可能与自定义解析配置不符。

测试和验证

架构验证

sigma check rules/rule.yml       # single rule
sigma check rules/               # entire directory

常见错误：id 缺失或重复、level 无效、YAML 格式错误、修饰符未定义、检测块为空。

使用 EVTX 离线验证

hayabusa csv-timeline -d ./sample_evtx/ -r rules/rule.yml
chainsaw hunt ./sample_evtx/ -s rules/rule.yml --mapping mappings/sigma-mapping.yml

测试工作流

1. 收集示例日志。 在实验环境中运行该技术（Atomic Red Team、 Caldera），并捕获 EVTX 或 JSON。
2. 验证检测。 运行 Hayabusa/Chainsaw——规则必须在 TP 日志上触发。
3. 验证排除项。 在干净的基线环境中运行。分析每个命中。
4. 转换并测试。 在 7+ 天的生产数据上运行后端查询。分析每个匹配结果。
5. 记录文档。 记录 TP/FP 数量、FP 原因及添加的筛选条件。更新规则的 falsepositives 字段和 PR 描述。

质量标准

**SigmaHQ 要求：**有效的 UUIDv4 id；适当设置 status （新规则设为 experimental）；date/modified 格式为 YYYY/MM/DD；至少添加一个 ATT&CK 标签；falsepositives 不得为空（即使填写 Unknown 也可以）；根据 TP 率设置 level；撰写描述性 description；添加指向源情报的 references。

**YAML 格式：**缩进两个空格，不使用制表符；用竖线分隔修饰符， 且不加空格（field|contains|all）；列表项使用短横线加空格；含特殊字符的字符串使用单引号； 长描述使用折叠标量（>）；每个文件只放一条规则，文件名采用与标题匹配的 snake_case 格式。

**字段命名：**使用 Sigma 标准名称（Image、ParentImage、 CommandLine、User、TargetFilename、TargetObject、DestinationIp、 DestinationPort、SourceIp、PipeName、Hashes）。后端转换会处理映射。 使用特定于后端的字段名会破坏可移植性。

**标签合规性：**使用 attack.<tactic>（小写，连字符分隔）和 attack.t<number>（小写，子技术以点分隔）。适用时添加 cve.YYYY.NNNNN。 请根据当前 ATT&CK 版本验证 ID——已退役技术的过期 ID 会导致下游映射错误。

应避免的自我辩解

• “规则很简单，不需要测试。” 简单规则的匹配范围最广。 逻辑越简单，误报（FP）分析就越重要。
• “上线后再添加过滤条件。” 噪声规则在生产环境中每运行一小时， 就会削弱分析师的信任。部署前先测试并添加过滤条件。
• “直接用关键词，按字段匹配范围太窄。” 关键词会跨所有字段匹配。 命中包含该字符串的主机名只会产生噪声。
• “转换后的结果看起来没问题，不用测试。” 转换过程默认 你的字段映射与流水线默认值一致。请使用实际数据进行验证。
• “每种技术一条规则就够了。” 每种技术都包含许多行为方式。T1059 涵盖 PowerShell、cmd、bash、Python、VBScript——每种都需要自己的逻辑。
• “规则在 Splunk 中有效，就说明它到处都有效。” 可移植性需要 正确抽象日志源。特定于后端的字段名会破坏可移植性。
• “设为 critical——凭据转储永远都是 critical。” 严重级别 反映的是信号质量，而非技术类别。高噪声的 critical 规则 造成的损害大于精准的 medium 规则。

阅读外部来源

将公开公告、规范和供应商报告抓取为 Markdown：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

这会去除网页上的模板内容——对于以正文为主的页面，令牌数大约减少 78%——并且 返回全文而非摘要，因此你可以用 grep 搜索，也可以相信未找到结果的结论。

以下三类内容不适用。抓取 JSON 和 API 响应时应使用原始内容，因为 可读性提取会破坏结构化数据。抓取需要身份验证或由 JavaScript 渲染的页面时应直接访问， 因为该工具会以匿名方式抓取。切勿通过它传递对手基础设施（钓鱼链接、C2、恶意软件托管服务）、 客户所属主机或交战行动 URL——请求会离开你的机器并发送给第三方；对于仍在运行的对手基础设施， 这还会向操作者发出警示。

某些网站会拦截提取器，并返回错误内容而非页面——例如 freedesktop.org 返回的 {"error":"Failed to fetch: 418 I'm a teapot"}。这表示抓取请求被拒绝， 并不代表来源称该内容不存在。在据此得出任何结论前，请直接重新抓取该 URL。

参考资料

• engineering-detections -- 完整的检测生命周期，包括 YARA、Suricata 和覆盖率测量
• hunting-threats -- 以假设为驱动的威胁狩猎，产出规则所依据的发现
• mapping-attack-techniques -- ATT&CK 技术解析与紫队协作闭环
• reporting-security-findings -- 撰写检测结果报告