Secops-hunt：把威胁狩猎从翻日志升级成查案子

如果说安全运营中心里有一个最消磨人的工种，那就是手工威胁狩猎。拿到一个可疑 IP，先在 SIEM 里搜，再跳去 EDR 交叉比对，再切到威胁情报平台查归属。十几个标签页来回翻，最后可能只确认了一句”当前无命中”。不是能力不行，是工具链太散，每一步都是手工搬运。

google/secops-hunt 这个 Smithery Skill 想解决的，就是这件事。它把 Google SecOps 的 UDM 查询引擎、GTI 威胁情报和 SOAR 案件管理串成了一条自动化管线。你只需要告诉它”查这个攻击组织”或”按这个 TTP 搜一圈”，它会自己构造查询、执行搜索、汇总结果。

从 SKILL.md 的设计文本来看，思路异常清晰：不造新的检测引擎，而是把”分析师的经验判断”翻译成”Agent 可执行的搜索流程”。它把四个原本靠人工决策的环节固化成了一套可重放的步骤序列：

• IOC 收集：从威胁情报中提取攻击指标
• UDM 查询构造：自动生成多字段交叉搜索语句
• 多轮迭代优化：根据结果噪声动态调整查询范围
• 案件关联：将发现与已有 SOAR 案件自动匹配

这篇文章会带你走一遍 secops-hunt 的两条核心狩猎路径，拆开它最值得聊的设计决策，然后诚实地评估它的适用边界，哪些团队应该立刻装上，哪些团队装了也是白装。

环境准备

secops-hunt 是一个 Smithery Skill，依赖 Google SecOps 平台。安装路径很直接：在 Smithery 市场搜索 google/secops-hunt，点一下安装。前提是你已经有了 Google SecOps 环境的访问权限和对应的认证配置，这点没有任何捷径。

安装之后最重要的一步不是急着跑第一条搜索命令，而是搞清楚你的环境支持哪些工具。secops-hunt 的 SKILL.md 里写了一条硬规则，执行任何步骤之前，先判断当前是 Remote 环境还是 Local 环境，然后走对应的工具路径。这个自动路由机制是它整个编排体系的地基。

两套工具的差异不小。Remote 环境走 udm_search 加 get_ioc_match，支持 Natural Language Search 做查询翻译。Local 环境用 search_security_events 加 get_ioc_matches，需要直接用 UDM 语法。如果在 Remote 环境里误调了 Local 的工具接口，轻则报错，重则漏掉关键告警。

# 工具可用性检测（Skill 自动执行）
# Remote 环境: udm_search + get_ioc_match + summarize_entity
# Local 环境:  search_security_events + get_ioc_matches + lookup_entity

环境确认之后，你需要准备狩猎的起点数据。走情报驱动路径需要 GTI Collection ID，走 TTP 路径需要一个 MITRE ATT&CK 技术 ID 列表（比如 T1003.001 对应 LSASS 凭据转储）。这两条路用的工具集相同，但查询构造逻辑完全不同。

操作流程

secops-hunt 提供了两条核心狩猎路径，对应着两种完全不同的安全分析思路。一条叫情报驱动路径，输入是 GTI Collection ID，输出是该威胁组织在你环境中留下的所有痕迹。另一条叫 TTP 驱动路径，输入是 MITRE 技术 ID，输出是”这种攻击行为在当前环境是否正发生”的判断。

情报驱动路径分六个阶段。第一阶段是 IOC 收集，这是最关键的一步，输入质量直接决定后续所有搜索的有效性。Skill 会要求你提供与目标威胁活动关联的四类指标：

• IP 地址
• 域名
• 文件哈希（SHA256/MD5/SHA1）
• URL

第二阶段用 get_ioc_match 快速扫描所有 IOC，筛掉未命中的，避免后续在无意义的搜索上浪费算力。第三阶段对命中 IOC 逐条构造 UDM 查询，IP 类型的会同时查 principal.ip、target.ip 和 network.ip 三个字段。

第四阶段是深度调查。确认命中的 IOC 需要进一步分析上下文：是哪个进程在连接这个 IP？网络流量走了哪个端口？有没有关联的历史 SOAR 案件？这一步决定了你拿到的是一个孤立告警还是一个完整的攻击叙事。第五阶段综合研判，把发现拼成一张完整图。第六阶段输出，可以选择生成 Markdown 报告或直接创建 SOAR 案件。

TTP 驱动路径的思路是反着来的：不关注”谁在攻击”，只关注”某种攻击行为是否正在发生”。给定一个 MITRE 技术 ID（比如 T1003.001），Skill 会先研究该技术的行为特征，然后构造针对性 UDM 查询，在 SIEM 事件中搜索匹配模式。这不是一次性完成的，它是一个”执行、分析、优化”的循环，如果结果噪声太大就加过滤条件，结果太少就放宽查询范围。

找到可疑实体之后，Skill 调用实体富集接口查上下文信息。Remote 环境走 summarize_entity，Local 环境走 lookup_entity。最后同样是两条出路：归档到 SOAR 案件供团队跟进，或者独立生成分析报告。从 SKILL.md 的命令定义来看，整个流程的每一步都至少有两个输出选项，不存在”搜索完了不知道下一步该干什么”的卡壳点。

关键设计

secops-hunt 最值得拆的设计是它的工具适配层。SKILL.md 里明确写了一条：执行任何步骤之前，先检查环境支持 Remote 还是 Local 工具，然后走对应的路径。这个设计解决了一个很实际的工程问题。Google SecOps 的云端部署和本地化部署暴露的工具集不一样。如果硬编码工具路径，Skill 就只能用在一个环境里。

但这个设计也有代价。维护两套平行的工具映射表意味着每次新增功能都要同步两份文档。从 TOOL_MAPPING.md 的存在本身就能推断，这个映射目前还不是自动化的，任何一边的更新滞后都会制造不兼容。对于只有 31 个安装量的早期项目来说，维护负担暂时还不明显。如果安装量上去了，这个点迟早要自动化。

另一个有意思的决策是查询翻译层。Remote 模式下，需要先把自然语言查询 translate 成 UDM 语法再执行，Local 模式则直接用 search_security_events。这层翻译让分析师不用背 UDM 语法就能上手，但翻译准确率完全取决于底层模型对 UDM 格式的理解程度。从 SKILL.md 只给了 translate_udm_query 一个命令名、没有展开描述来看，这层翻译的成熟度可能还比较初级。

两条路径的互补设计也值得聊。情报驱动追”已知的坏人”，TTP 驱动追”坏的行为”。前者依赖高质量外部威胁情报，后者考验行为特征查询的构造能力。实际分析中两者并不互斥，往往会交叉使用：先用情报驱动发现一个 IOC 命中，再用 TTP 驱动沿进程链深挖。从 SKILL.md 的流程编排来看，设计者已经预埋了这种交叉使用的空间，只是没有显式写成一条”联合路径”。

使用场景

场景一：威胁情报响应。假设 Google Threat Intelligence 发了一份关于 APT29 最新活动的报告，附了 15 个 IOC。传统做法是分析师手工把每个 IOC 往 SIEM 里扔，逐条判断命中和误报。用 secops-hunt，拿到 GTI Collection ID，以下步骤全部自动完成：

• IOC 获取：从 GTI 平台拉取全部攻击指标
• 批量扫描：对所有 IOC 做初筛匹配
• 分类搜索：按类型构造 UDM 查询逐条深入
• 结果汇总：将匹配结果按时间线和资产分组

人要做的事从”逐条构造查询”变成了”审阅 Skill 整理好的汇总结果”。

场景二：防御能力验证。安全团队刚部署了一套新的 EDR 规则，想确认它对 LSASS 凭据转储（T1003.001）的检测覆盖率。手工验证需要覆盖所有子技术的变体行为，构造几十条查询。用 secops-hunt 的 TTP 驱动路径，输入技术 ID、设定时间窗口，它会自动遍历该技术下的行为特征模式，输出匹配记录和覆盖率统计。

但这两个场景都有明确的边界条件。如果环境中没有配置 GTI 接入，情报驱动路径等于残废，它不会自己去找替代的情报源。如果 SIEM 中的事件格式与 UDM 标准有显著差异，TTP 查询的覆盖率会打折扣。secops-hunt 强在自动化流程编排，弱在没有数据源的时候什么额外价值都提供不了。

简单说：这是一个效率放大器，不是一个独立的安全分析平台。如果你的 SOC 已经有了 Google SecOps 的完整栈，装上它能省掉大量重复手工操作。如果还在评估阶段或者用的是其他 SIEM，它的价值趋近于零。

洞察与反思

从 SKILL.md 的文本来看，secops-hunt 的设计者很清楚一件事：威胁狩猎的瓶颈从来不是缺工具，而是工具太多、切换太累、流程太碎。它不发明新的分析能力，只把已有工具链的”连接成本”降到最低。这个定位决定了它的价值上限和边界同样清晰。

但这个思路的软肋也很明显。把运营经验转化为可执行查询模板，这件事本身就是安全运营中最”手工艺”的部分。secops-hunt 固化了 IOC 搜索和 TTP 查询的模板，降低了入门门槛。如果遇到不在预置模板里的 TTP 技术，分析师还是得退回到手工构造 UDM 查询的老路上。这个边界目前在 SKILL.md 里没有任何覆盖策略。

31 个安装量是很诚实的早期信号。GTI Collection ID 的获取方式、TTP 查询的优化反馈循环、工具映射表的自动同步，这些在 SKILL.md 里都写得很简洁，但实际落地的复杂度很可能远高于文本描述的乐观程度。尤其是查询翻译层，如果 UDM 生成质量不稳定，用它”省掉”的查询学习成本会以”排查生成错误”的形式加倍返还。

如果你的团队已经在跑 Google SecOps 且有 GTI 订阅，secops-hunt 是值得装的，它能实实在在省掉大量重复性的手工搜索劳动。如果你还在评估阶段、没有 GTI 接入、或者用的是其他 SIEM 产品，现阶段装它没有意义。TTP 路径可以独立使用，但失去了情报驱动路径的加持，整体效率优势就不那么明显了。

资源地址

总结

secops-hunt 做了一件事，而且做得很专一：把威胁狩猎从”人在工具间来回搬数据”变成”Agent 按可编程的狩猎流程自动执行”。两条核心路径覆盖了情报驱动和 TTP 驱动两种最常见的分析场景，工具适配层让它在不同部署形态下都能跑。

它的价值上限取决于两个前提：SIEM 里有数据，分析师知道要搜什么。这两个前提它帮不了你。但前提满足之后，它能帮你的部分相当扎实：

• IOC 批量搜索：一次输入，自动遍历全部攻击指标
• 多字段交叉查询：IP、域名、哈希同时覆盖多个数据字段
• 多轮迭代优化：根据噪声水平动态调整搜索精度
• SOAR 案件关联：自动匹配已有案件，拼接完整攻击链

每一步都是安全分析师的日常高频操作。

下一步建议：如果你的环境满足条件，直接装上跑一遍 T1003.001 的 TTP 狩猎流程，看看你的 SIEM 能不能接住它生成的 UDM 查询。如果环境不满足，先搞清楚欠缺的是 GTI 接入、UDM 格式对齐还是认证配置，比装 Skill 更优先的事是修地基。