Secops-hunt：把威胁狩猎从翻日志升级成查案子，Google开源自动化狩猎工具

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

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

不是新引擎，是把分析师的经验翻译成可执行的流程

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

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

安装后的第一件事，不是跑搜索

secops-hunt 是一个 Smithery Skill，依赖 Google SecOps 平台。安装路径很直接：在 Smithery 市场搜索 google/secops-hunt，点一下安装。

安装之后最重要的一步不是急着跑第一条搜索命令，而是搞清楚你的环境支持哪些工具。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 的工具接口，轻则报错，重则漏掉关键告警。

这个自动路由机制，是整个编排体系的地基。

两条路：情报驱动 vs TTP 驱动

secops-hunt 提供了两条核心狩猎路径，对应着两种完全不同的安全分析思路。

情报驱动路径，输入是 GTI Collection ID，输出是该威胁组织在你环境中留下的所有痕迹。分六个阶段运行：

第一步是 IOC 收集。Skill 会要求你提供与目标威胁活动关联的四类指标：IP 地址、域名、文件哈希（SHA256/MD5/SHA1）、URL。这一步的输入质量，直接决定后续所有搜索的有效性。

第二步用 get_ioc_match 快速扫描所有 IOC，筛掉未命中的，避免后续在无意义的搜索上浪费算力。

第三步对命中 IOC 逐条构造 UDM 查询。IP 类型的会同时查 principal.ip、target.ip 和 network.ip 三个字段。

第四步是深度调查——确认命中的 IOC 需要进一步分析上下文：是哪个进程在连接这个 IP？网络流量走了哪个端口？有没有关联的历史 SOAR 案件。

TTP 驱动路径，输入是 MITRE ATT&CK 技术 ID（比如 T1003.001 对应 LSASS 凭据转储），输出是“这种攻击行为在当前环境是否正发生”的判断。两条路用的工具集相同，但查询构造逻辑完全不同。

适用边界：谁该装，谁装了也白装

secops-hunt 解决的核心问题是“工具链太散，每一步都是手工搬运”。如果你的团队已经在 Google SecOps 生态里，每天花大量时间在多个控制台之间来回切换、手工拼凑上下文，那这个东西装上就能见效。

但如果你的安全运营还处于“告警都处理不完”的阶段，连基本的 SIEM 查询都不熟练，那 secops-hunt 帮不上什么忙。它不替代分析师的判断，它只负责把分析师的经验判断翻译成可执行的搜索流程。没有经验可以翻译，它就只是一个高级搜索框。

另一个硬性门槛：它依赖 Google SecOps 平台的访问权限和对应的认证配置。没有这个前提，装了也是白装。

把翻日志变成查案子

手工威胁狩猎之所以消磨人，是因为它把分析师的精力消耗在了“找东西”上，而不是“判断东西”上。secops-hunt 做的事情很朴素：把“找东西”这步自动化，让分析师把精力留给“判断”。

资源地址

它把威胁狩猎从“翻日志”升级成了“查案子”——你只需要告诉它你在查什么，它负责把证据链串好，剩下的交给你的判断力。