狩猎流程与数据源体系

01 · 狩猎循环操作规范

Sqrrl狩猎循环把威胁狩猎抽象为四阶段闭环，其核心设计思想是：每次狩猎都必须以"自动化"收尾——无论发现威胁与否，狩猎产出的查询逻辑、排除结论都应转化为可复用资产，使下一次狩猎站在更高起点上。

1.0.1 交付物填写示例（教学样板）

以下为一个按假设模板完整填写的示例，展示"一句话假设"如何展开为可执行的四件套（假设、查询、判定、固化）：

假设陈述：攻击者可能通过RDP在工作站之间横向移动（ATT&CK T1021.001），
           因为M-Trends 2026与CrowdStrike 2026 GTR均记录横向扩散时间窗已压缩至分钟级。
依据来源：情报——M-Trends 2026 / CrowdStrike 2026 GTR；知识库——ATT&CK T1021.001
预期观测：AD安全日志中工作站到工作站、登录类型10（RemoteInteractive）的
           4624成功登录，且登录账户为用户账户（非机器账户）、登录源非运维跳板机
检索范围：近90天 × AD安全日志 × 全量工作站（按资产清单排除服务器网段）
证伪条件：查询零命中；或全部命中均可由"开发测试互访清单"解释并登记
处置分支：命中未登记来源 → 证据链归档 → 升级IR（按第5页§03证据包标准）；
           零命中 → 排除逻辑（为何正常流量无此特征）写入假设库

注：本示例为方法论样板，字段取值需按本组织资产清单、命名约定与排除清单替换；事件编号语义以微软官方文档为准。

1.1 每次狩猎的最低交付标准

• 假设文档：一句话假设陈述 + 依据来源 + 预期观测行为 + 证伪条件。
• 查询方案：可复现的查询语句（含时间窗、数据源、过滤条件），入查询库。
• 结论记录：发现（含证据链）或未发现的排除逻辑，均标注置信度。
• 固化动作：发现→转SIGMA规则进入检测工程流程；未发现→排除逻辑写入假设库，避免重复狩猎。

02 · 假设工程方法

假设是狩猎的货币。高质量假设有三个特征：具体（指向明确行为而非"找异常"）、可证伪（存在明确的推翻条件）、有依据（来自情报、知识库或环境洞察而非臆测）。

2.1 假设的三个生成来源

2.1.1 情报TTP提取示例（示意）

假设生成的第一道工艺是"从情报文本中剥离攻击行为并翻译为查询目标"。下表展示转化链条（示例行为为领域常见技战术的通用描述，具体组织应以来源报告的原始表述为准）：

注：本表为转化方法示意（教学用），ATT&CK技术编号可在attack.mitre.org逐项核验；真实情报消化时应逐条引用报告原文并标注页码，避免二手转述引入偏差。

2.2 假设模板（本课题推荐结构）

假设陈述：攻击者可能通过【行为描述】实现【战术目标】，因为【依据来源】。
依据来源：情报报告名称/ATT&CK技术编号/环境事件编号
预期观测：数据源A中的字段X取值Y；数据源B中的行为模式Z
检索范围：时间窗（建议≥30天回溯）× 数据源 × 资产范围
证伪条件：查询零命中，或命中均可由【已登记的正常行为】解释
处置分支：发现→证据链固化→转检测规则；未现→排除逻辑入库

03 · 狩猎执行节奏

狩猎不是一次性项目，而是有节奏的常态运营。本课题推荐"周狩猎"制：每周固定投入狩猎窗口（建议SOC在告警负载之外划出独立时段），按季度轮换战术主题（本季度聚焦横向移动、下季度聚焦凭证访问），使覆盖度沿ATT&CK矩阵均衡推进而非随缘触碰。

• 计划（周初）：从假设库挑选2—4个高优先级假设，确定数据源与时间窗。
• 执行（周内）：执行查询，对命中做逐条甄别（关联资产属主、业务上下文、历史基线）。
• 验证（周末前）：对疑似发现做独立复核（第二人复核或换数据源交叉验证），避免单源误判。
• 固化（周末）：按§01交付标准归档，更新假设库与排除清单。

04 · 遥测数据源全景

狩猎的可见性由数据源决定。下表梳理六类遥测源、典型数据内容与狩猎价值，数据质量要求贯穿其中：

注：Windows事件编号与Sysmon事件编号为微软官方文档定义的事件标识（Sysmon为微软Sysinternals工具，由Mark Russinovich主导开发），具体字段含义以微软官方文档为准。

4.1 数据质量六维检查表

同样的数据源，质量差异可以差出一个数量级的狩猎效率。每次狩猎假设设计前，先按六维核查数据可用性（任何一维不达标都应先走数据整改流程，而非硬写查询）：

4.2 采集配置参考

• Sysmon配置基线：Sysmon的价值高度依赖XML配置质量。社区有成熟配置可直接研究改造——SwiftOnSecurity维护的sysmon-config仓库与Olaf Hartong维护的sysmon-modular模块化配置（均为GitHub公开项目），覆盖进程、网络、注册表等关键事件的常用裁剪方案；组织应在测试环境验证开销后再推广。
• Windows审核策略：除Sysmon外，原生审核策略需显式开启"审核进程创建"并勾选"在事件日志中包括命令行"（对应4688事件的CommandLine字段），否则进程狩猎将缺失最关键字段。
• 时间同步：所有日志源统一接入组织NTP层级；狩猎工具包中应常备"时间漂移检查脚本"，在跨源关联异常时第一时间核查时钟。
• 日志量估算：留存基线落地前应做量级估算（每台Windows终端开启上述采集后，典型量级为每日数百MB至数GB事件日志，视配置裁剪而异；域控制器与DNS服务器通常高出一个量级），据此规划SIEM许可/存储与冷热分层，避免留存策略写在纸上、落地时被成本击穿。

注：Sysmon与Windows审核策略字段语义以微软官方文档为准；上述社区配置仓库以GitHub当期内容为准；日志量数值为工程经验量级，实际以本组织实测为准。

05 · 数据采集与留存基线（工程建议）

M-Trends 2026揭示的122天长驻留间谍案件意味着：回溯能力是狩猎的生死线。若遥测只留存7天，任何慢于一周的入侵对狩猎者都不可见。以下为工程实践建议（属本课题经验基线，非强制标准）：

06 · 查询语言组合

狩猎查询需要跨平台可移植。本课题要求每个狩猎假设的查询方案以SIGMA规则（平台无关）为规范载体，同时给出主流平台的落地写法对照：

6.1 对照示例：异常RDP登录狩猎查询

假设：攻击者可能通过RDP在工作站之间横向移动（ATT&CK T1021.001）——检索"工作站到工作站的RDP登录"（服务器运维场景除外）。

// KQL（Microsoft Sentinel / Microsoft Defender XDR Advanced Hunting 同义骨架）
SecurityEvent
| where EventID == 4624 and LogonType == 10        // 4624=登录成功, Type 10=RemoteInteractive(RDP)
| where AccountType =~ "User"                      // 聚焦用户账户（自动排除以$结尾的机器账户）
| where Computer !endswith "-SV"                   // 排除服务器命名约定（按资产清单调整）
| summarize dc(TargetLogonId), min(TimeGenerated), max(TimeGenerated) by Account, Computer, IpAddress
| where IpAddress !in~ (已登记运维跳板机)           // 排除清单：登记的合法来源

# SPL（Splunk，Windows TA 数据模型字段）—— 同义对照
index=wineventlog EventCode=4624 Logon_Type=10
| search NOT Computer="*-SV"
| where NOT match(Account_Name, "\$$")            // 排除机器账户（名称以$结尾）
| stats earliest(_time) as first, latest(_time) as last, count by Account_Name, Computer, Source_Network_Address
| search NOT Source_Network_Address IN (已登记运维跳板机)

注：上述查询为方法示意（教学用骨架），实际部署需按本组织资产清单、命名约定与排除清单调整；SecurityEvent表的AccountType字段取值（User/Machine）与Splunk Windows TA字段名以各平台数据字典为准；事件编号与字段语义以微软官方文档为准。

6.2 对照示例：办公进程派生脚本解释器（EQL）

假设：攻击者通过钓鱼文档投递宏或利用漏洞，使Office进程派生脚本解释器执行载荷（对应第3页剧本B、第6页案例D所涉攻击链的通用前置行为）。

// EQL（Elastic Stack）—— 事件序列示例：Office启动后60秒内派生脚本引擎
sequence by process.entity_id with maxspan=60s
  [process where event.type == "start" and
     (process.name : "winword.exe" or process.name : "excel.exe" or process.name : "outlook.exe")]
  [process where event.type == "start" and
     process.name in ("powershell.exe", "cmd.exe", "wscript.exe", "mshta.exe", "rundll32.exe")]

6.3 对照示例：疑似DNS隧道（KQL骨架）

// KQL 教学骨架：按客户端统计"长域名、高离散"的可疑DNS查询
DnsEvents
| where TimeGenerated > ago(30d)
| extend NameLength = strlen(Name)
| where NameLength > 52                                  // 隧道型域名通常显著长于常规域名
| summarize QueryCount=count(), DistinctNames=dcount(Name) by ClientIP, bin(TimeGenerated, 1h)
| where DistinctNames > 30                               // 单位时间内大量离散子域
| order by QueryCount desc                               // 命中后需人工排除CDN、杀毒云查杀等正常高频源

注：EQL的sequence语法为Elastic官方文档定义的能力；上述查询均为教学骨架，阈值需按本组织DNS基线校准，命中后必须经§07交叉验证流程后方可定性。

07 · 误报与成本控制

• 排除清单先行：任何假设执行前，先加载已登记的正常行为（运维跳板机、备份窗口、扫描器网段），从源头压噪。
• 分层收敛：查询设计遵循"宽检索→聚合→聚焦"三级收敛，先粗筛再下钻，避免逐条检查原始事件。
• 双人复核与交叉验证：疑似发现须经第二数据源独立验证（如身份日志×终端日志×网络日志三方印证），单源命中不得直接进入事件流程。
• 时间盒纪律：单次狩猎设定时间盒（如4—8小时），超时未获决定性证据即归档为"待补充数据"而非无限下钻——控制机会成本是狩猎可持续运营的前提。

本节参考来源（第2页）

以下均为真实可查的权威来源，用于支撑本页事实性表述与技术事实；全部链接经2026年9月终审核验可访问。