作为首席威胁狩猎分析师，我的任务是从零开始构建一个威胁狩猎项目。这涉及大量关于威胁狩猎究竟是什么以及如何将其转化为有意义成果的思考。我花了大量时间阅读有关威胁狩猎、检测工程、网络威胁情报（CTI）、取证的各种方法论，甚至还有我在美国空军服役期间的经验。然而，在构建项目的过程中，我意识到我需要一个流程，一个统一的威胁狩猎流程。我开发这个流程是为了提供一种结构化且明确的狩猎方式，并最终为组织带来有意义的成果。
graph LR
Z[Step 0: Environment Context] --> A[Triggering Event]
A --> B[Hypothesis Development]
B --> C[Initial Assessment]
C --> D[Feasibility Assessment]
D --> E[Define Scope & Objectives]
E --> F[Formalize Hunt Plan]
F --> G[Execute Hunt]
G --> H[Document Outcomes]
H --> I[Report & Iterate]
I --> A
威胁狩猎是主动搜寻已绕过你控制措施的威胁。这个定义已经确定；但如何将其作为一个项目来运行则尚无定论。本流程是一种综合，下表是对其的诚实说明：
| 来源 | 在此处的贡献 |
|---|---|
| Sqrrl / 狩猎成熟度模型（Bianco） | 成熟度与指标中使用的核心循环和成熟度阶梯 |
| TaHiTI | 将触发事件作为真正的起点，并在收尾时移交给相邻流程 |
| PEAK | 狩猎类型划分（假设驱动 / 基线驱动 / 模型辅助）以及以结果为导向的“带着知识行动”收尾 |
| AIMOD2 | 假定失陷前提和分类结果类别 |
| OTHF | 将狩猎作为可重复的团队职能来运行的操作框架 |
| 本流程新增 | 步骤 0 环境上下文 · 硬性可行性 GO / NO-GO / CONDITIONAL 门禁 · 带类型化结果的 Jira Epic/Story/Task · 受评分标准约束的假设和明确的检测交接 |
差异化之处在于最后一行。其余一切都建立在他人工作之上，并在参考文献中引用。
关于如何开展狩猎行动，已有多种方法描述：结构化、非结构化、TTP 导向、情报导向、数据驱动等等。虽然这个统一威胁狩猎流程看起来可能是结构化的，但这并不意味着你的假设不能以非结构化方式由数据驱动。本流程旨在纳入各种类型的威胁狩猎，允许模块化方法。我们会使用所有这些技术来确保彻底检验我们的假设。
目标是采用模块化的威胁狩猎方法，不存在一刀切的方案。使用你可支配的所有技术。
在实践中，你选择的狩猎类型取决于你在 DAIKI 链（数据 → 信息 → 知识 → 洞察）中的起点：
| 狩猎类型 | 起点 | 特征 |
|---|---|---|
| 探索性（EDA） | 原始数据 | 建立基线、理解数据形态、无先验假设 |
| 基于假设（HBO） | 态势感知 | 基于团队知识测试可信攻击场景 |
| 威胁情报驱动（TIO） | 可操作 CTI | 情报驱动，聚焦已知行为者或 TTP |
| 紫队行动（DPO） | 红队洞察 | 攻防联合验证 |
遵循数据科学原则，无论狩猎类型如何，你都应致力于探索和理解与狩猎相关的数据源。本仓库中的 /Data_Analysis 文件夹包含用于该探索阶段的支持技术和 notebook。
此外，威胁情报无论是否为起点，都已融入整个流程，以帮助驱动行动。威胁情报
注意： 虽然你通常希望聚焦行为或 TTP，但如果 IoC 确实可操作且及时，它们也有其价值。虽然在整个环境中狩猎 IoC 并不真正算是威胁狩猎，但它们仍可提供有用信息并作为另一个起点。它们可以成为狩猎周期的一部分，但不是整个狩猎本身。
在任何狩猎开始之前，先记录环境，以便每个下游产物（查询、字段名、范围界定决策）都针对你实际工作的环境量身定制，而不是泛泛而写。我将其添加为明确步骤，因为我不断看到狩猎计划引用了没人拥有的数据源，或者完全用错误方言编写的查询。这里花几分钟，之后能节省数小时。
至少应记录：
| 上下文 | 为什么重要 |
|---|---|
| SIEM / 数据平台 | Splunk SPL、KQL、Elastic DSL 和 Chronicle 各自塑造你编写的每个查询 |
| EDR 平台 | CrowdStrike、SentinelOne、Defender for Endpoint 各自使用不同的遥测字段名 |
| 环境类型 | 本地、云原生（AWS/Azure/GCP）或混合环境会改变哪些日志甚至存在 |
| 行业垂直领域 | 决定哪些威胁行为者在现实中相关 |
| 日志保留窗口 | 决定哪些时间范围实际可查询 |
| 狩猎成熟度级别 | 初次狩猎者需要脚手架；经验丰富的团队想要骨架 |
将此记录为 Epic 顶部的 Environment Profile 块。如果你进展很快，绝对最低要求是 SIEM 平台和环境类型，少于这些，你的查询就会是泛泛的。
跨多个组织狩猎？（MSSP/MDR、联邦子公司或共享 SIEM 平台。）在
tenants/<id>/profile.yaml注册表中为每个租户保留一个配置文件，并让每个 Epic 引用tenant: <id>，而不是嵌入配置文件。在可行性评估之前，检查授权：没有 RoE/合同覆盖的租户，或计划行动超出其allowed_actions的租户，属于 NOT AUTHORIZED，并就此停止。单组织团队可以跳过此项。参见多租户操作。
借鉴 TaHiTI 框架，威胁狩猎始于触发事件。这些事件为启动狩猎提供正当理由。根据 TaHiTI，触发事件可以包括：
对于我们的组织，我们使用这些以及一些额外触发因素，例如利益相关者的直接需求和影响环境的漏洞披露。
有些框架以初始假设（此处为步骤 2）开始威胁狩猎，但我要问：你最初是如何得出这个假设的？
很可能有一个触发事件导致了初始假设。正如艾萨克·牛顿看到苹果落下后才思考是什么力把它拉下来，那个苹果就是导致关于重力的假设的触发事件。 同样，在我们形成假设之前，也应该有一个触发事件。
狩猎触发因素（来源：Targeted Hunting Integrating Threat Intelligence (TaHiTI)）
接下来，也许是最重要的一步，是构建狩猎假设。这一步虽然关键，但也可能最模糊。你的假设可能带你找到金矿，也可能带你掉进无休止的兔子洞。
从数据科学原则来看，你的假设是关于创建可检验陈述来指导分析。不仅如此，你还应努力使假设符合 SMART：
一个有用的模板：
我们假设 [威胁行为者 / 技术 / 行为] 可能存在于我们的环境中，证据是 [数据源] 中的 [可观察指标]，我们可以通过在 [时间范围] 内使用 [测试方法] 来验证。
示例 1（CTI 驱动，TIO）：
我们假设，使用 AS-REP Roasting（T1558.004）针对禁用 Kerberos 预认证的账户的对手可能存在于我们的环境中，证据是我们 Splunk Windows Security 日志中来自非域控制器来源、预认证类型为 0 的 Event ID 4768，我们可以通过查询过去 30 天的认证事件，并在冲刺结束前与服务账户清单进行关联来验证。
示例 2（行为驱动，HBO）：
我们假设，特权账户在非工作时间的异常交互式登录可能表明凭据滥用，证据是 CrowdStrike 遥测中 Domain Admins 组成员账户的 Event ID 4624（类型 2 或 10）和 4672，我们可以通过在两周内对 60 天登录历史建立基线，并标记超过 2 个标准差的偏差来验证。
在构建假设时，你实际上可能会形成许多相互竞争的假设。关于这一点，值得一读的书是 Richards J. Heuer 所著、由 CIA 情报研究中心出版的 Psychology of Intelligence Analysis。Heuer 描述了竞争性假设，这对你的狩猎工作有益。
该过程包括定义多个假设并确定其中最有根据的一个，为假设构建阶段提供严谨性，有助于定义狩猎基础。这个 7 步过程描述如下：
接下来的两个阶段依托这一过程，根据假设来定义一次狩猎是否应该执行。
此外，AIMOD2 框架的一个关键概念是假定失陷这一底层假设，我们专注于识别未知，前提是假设对手已经绕过了我们的控制措施。
在初始评估阶段，我们收集和研究数据以支持假设。这包括内部和外部来源。
这里的一个子步骤是识别并在必要时访谈业务或技术负责人。根据你的狩猎，你可能需要让 SME 参与以加深理解。这并不总是需要，你可能已经从经验或过往狩猎中了解系统、日志记录和应用程序。
目标不是成为某个系统的专家，而是对环境形成足够理解。
在规划狩猎活动之前，我们需要评估可行性。这包括：
本质上，我们是在问：“这值得费这个劲吗？”
如果遥测不可用，问：能否使其可用？需要付出什么努力？
每次可行性评估都应产生明确决策：
| 决策 | 含义 |
|---|---|
| ✅ GO | 满足所有标准，进入规划 |
| ❌ NO-GO | 存在关键阻碍，放入待办并附补救计划 |
| ⚠️ CONDITIONAL | 存在轻微缺口，记录假设并带保留条件继续 |
使用上面的 AS-REP Roasting 假设：
| 标准 | 状态 | 备注 |
|---|---|---|
| 数据可用性 | ✅ GO | 来自所有 DC 的 Windows Security 4768 事件已摄取到 Splunk |
| 数据质量 | ⚠️ CONDITIONAL | 5 个 DC 中有 4 个解析了预认证类型字段，一个 DC 的 sourcetype 损坏 |
| 技能组合 | ✅ GO | 团队具备 SPL 和 Active Directory 经验 |
| 时间线 | ✅ GO | 估计 3 天，适合当前冲刺 |
| 工具 | ✅ GO | Splunk Enterprise Security 加内部 AD 清单 |
| 总体 | ⚠️ CONDITIONAL | 带已记录保留条件继续：一个 DC 存在解析缺口。开一个并行工单修复 sourcetype，然后重新运行狩猎以获得完整覆盖。 |
如果某个限制因素阻碍进展，将该想法放入待办，并制定获取所需遥测的计划，同时在此期间处理新的假设或狩猎。
这里我们定义狩猎的目标。这些代表我们狩猎的目标，以及为实现目标需要完成的事项。这些目标将驱动狩猎的方向和结果。
由于我们的狩猎是 SMART 的，我们必须清楚定义如何衡量和管理它们。这包括指定目标环境区段、分析时间窗口、范围内系统和资产，以及任何明确排除项。
现在我们到了有趣的部分，构建狩猎计划。
任何狩猎的关键原则是记录你的行动和发现。这使报告容易得多，让我们保留产物，并确保结果可重复。
我们的团队使用 Jira，但任何文档工具都可以。关键是：记录下来。
我们使用 Epic、Story 和 Task 来组织计划：
代表狩猎的总体假设或主题。我们包括：
这些是与 Epic 假设一致的离散调查或测试。你可以在一个假设下有一个或多个 story，以最终证明或推翻它。每个 story 应反映单一思维过程，并作为一次测试发挥作用。开发多个测试的想法不仅是为了彻底调查你的假设，也是为了挑战初始假设。我们应该挑战我们已经知道的东西。 记住，威胁狩猎是追逐未知，虽然你应该覆盖简单测试的基础（例如，对编码命令进行字符串搜索），但如果我们真的想发现未知，就应该努力思考得更深更远。我相信狩猎过程中应该有一定程度的挣扎；否则你可能没有在学习，并且很可能正在实现已经作为检测存在的东西。如果是这样，问问自己：意义何在？
示例： 如果我的假设是关于管理账户的异常登录事件，我可能有两个 story：
不同方法，同一假设。可能需要各种测试才能完全完成狩猎。
通过使用 Jira 等工具，文档成为轻量级 playbook。我们的团队自然开始开发结构化 playbook，类似 https://threathunterplaybook.com/intro.html，易于参考，并使报告更高效。这些 story 和 playbook 也充当狩猎仓库，我们可以参考过往狩猎。
Task 记录狩猎的结果，并链接到其父 Epic 以便跟踪。它们包含如下结果（主要来自 PEAK 和 AIMOD2 框架）：
指标对狩猎项目至关重要，因为你的管理层很可能以数字思考。可量化指标对于衡量努力效果和展示项目成熟度至关重要。我们还必须考虑哪些指标真正重要，哪些可能被视为坏指标。我们应避免仅仅跟踪活动的指标（花费小时数、执行狩猎数量），而倾向于更有影响力的指标。指标应有助于回答你组织的**“那又怎样？”**问题。