engineering-detections

检测工程

检测规则是对攻击者行为的假设，并以查询的形式表达，触发后会通知人工。两个属性决定了它是否值得部署：它能否在出现目标行为时触发，以及在其他情况下能否保持安静。大多数规则都过不了第二关，代价则由值班人员承担。

适用场景

• 根据 TTP、样本或事件编写新的检测规则
• 审查或调优现有的高噪声或不触发的规则
• 将威胁情报转化为可部署的检测内容
• 根据 ATT&CK 评估检测覆盖情况
• 搭建检测即代码体系：仓库布局、测试、CI、部署

不适用场景

• 此刻搜索未知的入侵事件——使用 hunting-threats
• 处置正在发生的事件——使用 responding-to-incidents
• 分析检测规则针对的样本——使用 analyzing-malware
• 编写文件／内存特征——使用 writing-yara-rules；编写日志／SIEM 规则——使用 writing-sigma-rules
• 预防性控制和加固——加固不属于检测；规则不能代替关闭攻击路径

转到深入技能

重点	技能
专门编写可移植的 Sigma 规则——字段分类、修饰符、后端转换、SigmaHQ 标准	writing-sigma-rules

此技能涵盖 Sigma、YARA 和 Suricata 的整个检测生命周期；如果任务是编写 Sigma 规则本身并将其转换为目标 SIEM，请使用 writing-sigma-rules。

检测行为，而非特征

根据对手改变行为的成本，为编写的内容排序：

Hash              trivial to change      → block, don't alert
IP / domain       days                   → block + low-severity alert
Filename / path   trivial                → weak signal, combine only
Tooling artifact  weeks (recompile)      → good, decays
Behaviour / TTP   expensive              → this is the target

痛苦金字塔的思路是整个学科的核心：针对 mimikatz.exe 的规则毫无价值；针对进程打开句柄并以 PROCESS_VM_READ 访问 LSASS 的规则，则能捕获所有做同样事情的工具。

规则开发循环

1. Hypothesis   → what behaviour, by whom, visible where?
2. Data check   → is the required telemetry actually collected and retained?
3. Draft        → write the logic against real data
4. FP analysis  → run over 30+ days of production data, characterize every hit
5. Tune         → narrow with attacker-independent conditions only
6. Test         → prove it fires on an emulated true positive
7. Document     → triage steps, response, and known limits
8. Deploy       → with a severity that matches the actual response
9. Review       → re-test after telemetry, environment, or tooling changes

第 2 步淘汰的规则比其他任何步骤都多。在编写逻辑之前，先确认字段确实存在、在你关注的平台上已填充，并且保留时间足以产生价值。针对 Agent 未上报字段编写的规则会造成覆盖假象——这比没有规则更糟，因为它看起来像是已纳入覆盖范围。

编写 Sigma

Sigma 是可移植格式；编写一次，按不同后端分别转换。

title: LSASS Memory Access from Unusual Process
id: 9f2b1c4e-0000-4000-8000-000000000001
status: experimental
description: >
  Detects a process obtaining a handle to lsass.exe with read/clone access,
  the common precondition for credential dumping regardless of tooling.
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: secskills
date: 2026-07-26
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      # QUERY_LIMITED_INFORMATION 0x1000 | QUERY_INFORMATION 0x0400
      # VM_READ 0x0010 | VM_WRITE 0x0020 | VM_OPERATION 0x0008
      - '0x1010'   # QUERY_LIMITED | VM_READ        — minimum to read lsass
      - '0x1410'   # QUERY_LIMITED | QUERY_INFO | VM_READ
      - '0x1438'   # the classic mimikatz mask: adds VM_WRITE | VM_OPERATION
  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Program Files\<your EDR>\'
      - 'C:\Windows\System32\wbem\WmiPrvSE.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - EDR and backup agents; enumerate yours and filter by full path
  - Windows Error Reporting on crash
level: high
tags:
  - attack.credential-access
  - attack.t1003.001

转换：

sigma convert -t splunk -p sysmon rules/lsass_access.yml
sigma convert -t esql -p ecs_windows rules/lsass_access.yml     # Elastic
sigma convert -t kusto -p microsoft_xdr rules/lsass_access.yml  # Defender/Sentinel

**让调优后的规则保持可靠：**基于攻击者无法选择的内容进行过滤。已签名供应商二进制文件的完整路径、特定服务 SID，以及父子进程组合都是可接受的。基于文件名、用户名字符串或攻击者可控的命令行片段进行过滤不算调优——这等于把绕过方式写进规则里。

编写网络检测规则

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"Beacon: HTTP POST, no User-Agent, fixed small body";
    flow:established,to_server;
    http.method; content:"POST";
    http.header_names; content:!"User-Agent";
    threshold:type both, track by_src, count 10, seconds 600;
    classtype:trojan-activity;
    metadata:attack_target Client_Endpoint, mitre_technique_id T1071;
    sid:1000101; rev:1;
)

对于加密流量，应基于元数据而非内容进行检测：JA3／JA4 指纹、证书异常、SNI／DNS 模式，以及最持久的信标通信时序。要让操作人员放弃带抖动的固定间隔通信并不容易，因为这会降低可靠性。

-- Beacon candidate: low variance in connection interval, sustained
SELECT src_ip, dst_ip, count(*) AS n,
       stddev(delta_seconds) AS jitter, avg(delta_seconds) AS interval
FROM connection_deltas
WHERE ts > now() - interval '7 days'
GROUP BY src_ip, dst_ip
HAVING count(*) > 50 AND stddev(delta_seconds) < 0.15 * avg(delta_seconds)
ORDER BY n DESC;

编写用于大规模检测的 YARA 规则

在每个终端的每个文件上运行的规则，与分析规则有着不同的成本特征。应先使用计算开销低的条件进行锚定。

rule Suspicious_Loader_Pattern
{
    meta:
        author = "secskills"
        date   = "2026-07-26"
        scope  = "endpoint scanning"      // vs. hunting/triage
    condition:
        // Cheap gates before expensive string matching
        uint16(0) == 0x5A4D and filesize < 500KB and
        pe.imports("kernel32.dll", "VirtualAlloc") and
        pe.imports("kernel32.dll", "CreateThread") and
        math.entropy(0, filesize) > 7.0
}

部署前，务必先用良性软件样本库进行测试。一条误报率为 0.1% 的 YARA 规则，在拥有一百万个文件的终端群中会产生一千条警报。

误报分析就是本职工作

绝不能仅凭“看起来没问题”就部署。所需证据如下：

检查项	阈值
使用 ≥30 天的生产数据进行历史回溯	对每个命中进行分类，而不只是计数
警报量预测	符合接收警报团队的分诊能力
良性原因枚举	每项均记录在 falsepositives 中，并附带过滤条件或分诊说明
真阳性测试	在模拟执行目标行为时触发

# Emulate the behaviour to prove the rule fires
atomic-red-team -T T1003.001              # Atomic Red Team
caldera / prelude operator                 # adversary emulation frameworks
# Then confirm: alert fired, fields populated, triage steps sufficient

如果因模拟执行不安全而无法测试某条规则，请在文档中说明，并将该规则标记为未经验证。不要让它未经说明就作为已测试的覆盖内容通过。

覆盖度衡量

将规则映射到 ATT&CK，但要正确解读这份映射。

# Generate a layer for the ATT&CK Navigator from your rule set
python3 scripts/rules_to_navigator.py rules/ > coverage.json

如实统计覆盖度：

• 只有在针对某项技术的仿真中测试过规则，且在整个设备群中都采集到所需遥测数据时，该技术才算已覆盖。
• 每项技术对应一条规则不等于已覆盖——一项技术有许多不同的实施方式。T1055（进程注入）就有十几种实质上不同的实现方式。
• 覆盖度应报告为已测试／未测试／无遥测，绝不要只报一个百分比。基于未经测试的规则构建绿色 Navigator 图层，是安全团队最常见的自欺方式。

检测即代码

detections/
├── rules/            # Sigma source of truth, one file per rule
├── tests/            # unit tests: sample events → expected match/no-match
├── filters/          # environment-specific allowlists, kept OUT of the rules
├── deployed/         # generated backend queries (build artifact, never edited)
└── .github/workflows/ci.yml

CI 应当：对每条规则进行 lint 和架构验证，确保每条规则都有唯一的 id 和非空的 falsepositives，运行单元测试，转换为各目标后端的格式，并在转换出错时失败。对规则进行版本管理，在拉取请求中审查，并将环境过滤条件与检测逻辑分开，这样规则就能在不泄露环境信息的情况下共享或上游提交。

应当摒弃的借口

• “部署后再调优。” 未调优的规则会让分析师养成不看告警就直接关闭的习惯，这比缺少检测更糟。
• “告警虽然很多，但分析师能应付。” 告警疲劳会导致安全控制失效，造成严重后果。先衡量告警量。
• “我们有针对该技术的规则。” 针对哪种实施方式？如何测试的？哪些平台具备相关遥测数据？
• “厂商规则能覆盖。” 看看规则本身。厂商默认配置针对的是普通客户，而不是你的环境。
• “把哈希加进规则里。” 那么下次构建时，这条规则就失效了。
• “把那个告警太多的主机排除掉。” 如果攻击者能触及该排除条件，你就等于公开了一个绕过方法。应根据攻击者无法假定的属性进行过滤。
• “没有告警就说明一切正常。” 没有告警就是没有告警。通过仿真进行验证。

ATT&CK 覆盖度

根据 secskills-core/ttp-index.json 生成——编辑该文件，然后运行 python3 scripts/sync_attack.py --write。在报告中引用 ID 前，请根据当前 ATT&CK 版本重新核验。

凭证访问（TA0006）

• T1003.001 LSASS 内存——另见 attacking-active-directory

命令与控制（TA0011）

• T1071 应用层协议——另见 analyzing-malware、analyzing-network-traffic
• T1071.004 DNS——另见 hunting-threats、analyzing-network-traffic
• T1573 加密通道——另见 analyzing-malware、analyzing-network-traffic

上述任一技术的检测内容：engineering-detections。主动搜寻：hunting-threats。入侵后的处置：responding-to-incidents。

阅读外部来源

将公开公告、规范和厂商报告获取为 Markdown：

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

这会去除网页的样板内容——对于纯文本页面，令牌数大约减少 78%——并返回全文而非摘要，因此你可以搜索全文，并相信未找到相关内容的结果。

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

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

参考资料

• hunting-threats — 深入分析并发展为检测规则的威胁狩猎
• analyzing-malware — 为规则逻辑提供依据的能力分析
• responding-to-incidents — 揭示检测盲区的事件响应
• MITRE ATT&CK、Sigma（SigmaHQ）、Atomic Red Team、MITRE CAR、Elastic 检测规则
• 用于规则文档编写的警报与检测策略（ADS）框架