初次了解? 3 分钟看懂 Genox Cybersecurity AI → 7×24 小时应急受理
研判记录

如何阅读
研判记录(Trace)

Threat Correlator 每做出一条研判,都会记下它看了什么、调用了哪些工具、依据什么得出结论。
我们目前还没有可以公开的真实运行记录,所以本页先说明记录的结构,再把一条示例记录从头到尾读一遍。

结构

一条记录里有什么

从上往下读,就是研判形成的顺序。
一条研判下挂多个步骤(step),每个步骤包含观察、工具调用、证据和推理四部分。

字段内容阅读时要确认的点
input_hash参与研判的全部输入打包后的 SHA-256重跑时用这个值核对是否用了相同的输入
sources输入来源(EDR、邮件网关、代理等)及时间范围缺了哪个数据源,研判覆盖的范围就相应变窄
steps[].observation该步骤中注意到的事实这是对原始日志的概括,要看它和下面的证据是否对得上
steps[].tool_call调用的工具、参数、结果摘要看时间范围、主机名等参数是否正确
steps[].evidence证据 ID、原始位置、哈希还附有自动核对结果,说明引用的日志在原始数据中是否真实存在
steps[].reasoning从证据推到结论的理由,ATT&CK 技术 ID每条依据语句都必须指向证据 ID
verdict · confidence研判标签、风险等级、置信度,以及置信度被扣减的原因看置信度偏低的原因有没有写明
recommended_actions建议的处置及是否需要审批主机隔离、账号锁定始终需要审批
approval审批人角色 ID,批准、修改或拒绝,时间,备注审批耗时也从这里算出
versions模型版本、提示词模板版本、策略版本哪怕只改了提示词措辞,研判标准也算变了
replay事后在相同条件下重跑的结果,及其与原研判的差异文字可以不同,要看标签和风险等级是否一致
示例记录

从头读一遍示例记录

示例记录 · 不是真实客户数据,也不是真实运行记录。这是我们把 MITRE ATT&CK 中收录的勒索软件早期阶段技术(钓鱼附件、PowerShell 执行、删除卷影副本)串起来编写的记录。主机名、账号、时间和置信度都只用于说明,域名和 IP 使用了为文档用途保留的值(.example、203.0.113.0/24)。

示例记录 · 不是真实客户数据,也不是真实运行记录fin-ws-0412
1 观察收到带宏附件的邮件 · T1566.00109:12
2 观察WINWORD.EXE 启动 powershell.exe · T1059.00109:14
3 观察通过 vssadmin 删除卷影副本 · T149009:14
研判真实威胁 · 勒索软件执行准备 · CRITICAL · 置信度 0.9109:15
审批批准主机隔离(analyst-07)09:17
重跑标签 · 风险等级一致,部分文字不同10/22

这条记录先看哪里

先看研判这一行,置信度为什么停在 0.91。在这个示例里,记录写明了两点:还没有观察到文件被加密,下载的可执行文件哈希在威胁情报中没有匹配。反过来,如果一条记录置信度很高,扣减原因却是空的,那条记录反而更值得怀疑。

接着看审批这一行。按策略,主机隔离不会自动执行。从这条记录还能读出,研判结果出来后,分析师读完依据并批准,用了两分钟多一点。

逐步阅读

  1. 收到邮件(step 1)。邮件网关日志中有一封来自 billing@invoice-notice.example 的邮件,附件是 견적서_1021.docm(韩文“报价单”)。AI 用 mail.search(message_id=…) 查询邮件原始元数据,用 intel.domain_whois("invoice-notice.example") 查询域名信息,结果显示域名注册才 3 天。依据语句是“带宏的 Office 附件加新注册域名,可能为 T1566.001”,指向证据 E1、E2。仅凭这一步,AI 没有下结论。
  2. PowerShell 执行(step 2)。Sysmon 事件 ID 1(进程创建)中有一行,父进程为 WINWORD.EXE,子进程为 powershell.exe -NoP -W Hidden -enc JABjAD0A…。AI 用 edr.process_tree(host="fin-ws-0412", from="09:12", to="09:20") 取得进程树,并解码编码后的命令,确认这段代码会下载 https://203.0.113.45/u.ps1。baseline.parent_child(host, 30d) 的查询结果显示,过去 30 天里这台主机上从未出现过 Office 应用启动 PowerShell 的情况。依据为 T1059.001,证据为 E3、E4。
  3. 删除卷影副本(step 3)。Sysmon 事件 ID 11(文件创建)记录了 C:\Users\user01\AppData\Local\Temp\upd.exe 的生成,大约 20 秒后,事件 ID 1 中出现了 vssadmin.exe delete shadows /all /quiet,父进程是 upd.exe。intel.hash_lookup 返回无匹配。依据为 T1490(Inhibit System Recovery,阻止系统恢复),ATT&CK 的 T1490 条目中也列有多个勒索软件在加密之前先删除卷影副本的案例。
  4. 研判。真实威胁,勒索软件执行准备阶段,风险等级 CRITICAL,置信度 0.91。扣减置信度的原因写了两条:“未观察到大量文件变更”和“upd.exe 哈希在情报中无匹配”。
  5. 建议处置与审批。对主机做网络隔离(需审批),召回带有相同附件哈希的邮件,封禁发件域名和 203.0.113.45。隔离由 analyst-07 在 09:17 批准,备注为“请确认文件服务器的 SMB 会话”。两项封禁在与客户约定的自动响应策略范围之内,无需审批即已执行。
  6. 重跑。第二天用相同的 input_hash、模型版本和策略版本重跑,标签和风险等级相同,置信度为 0.89,依据语句的措辞有部分不同。文字不在比较范围内,所以记为“一致”。
原始记录

同一条记录的原文形式

把上面的示例按记录格式精简后搬到这里。
字段名仅用于说明,实际导出格式会在发布时以文档形式公开。

// 示例记录 · 不是真实客户数据,也不是真实运行记录
{
  "trace_id": "VT-EXAMPLE-0001",
  "input_hash": "sha256:9f3a…c21e",
  "sources": [
    {"type": "mail_gateway", "range": "09:00~09:20"},
    {"type": "edr_sysmon",   "host": "fin-ws-0412", "range": "09:00~09:20"}
  ],
  "steps": [
    {"n": 1,
     "observation": "带宏附件(견적서_1021.docm),发件域名注册第 3 天",
     "tool_calls": ["mail.search(message_id=…)", "intel.domain_whois(\"invoice-notice.example\")"],
     "evidence": [{"id": "E1", "ref": "mailgw/2026/10/21/09.log#L2207", "sha256": "1c0d…7be2", "verified": true},
                  {"id": "E2", "ref": "intel/whois/invoice-notice.example", "verified": true}],
     "reasoning": "E1+E2:可能为鱼叉式钓鱼附件", "attack": ["T1566.001"]},
    {"n": 2,
     "observation": "WINWORD.EXE → powershell.exe -NoP -W Hidden -enc …",
     "tool_calls": ["edr.process_tree(host=\"fin-ws-0412\", from=\"09:12\", to=\"09:20\")",
                    "baseline.parent_child(host=\"fin-ws-0412\", window=\"30d\")"],
     "evidence": [{"id": "E3", "ref": "sysmon:EventID=1 RecordID=884213", "verified": true},
                  {"id": "E4", "ref": "baseline/fin-ws-0412/parent_child", "verified": true}],
     "reasoning": "E3:Office 应用执行了编码的 PowerShell,E4:30 天内无先例",
     "attack": ["T1059.001"]},
    {"n": 3,
     "observation": "生成 upd.exe 后执行 vssadmin.exe delete shadows /all /quiet",
     "tool_calls": ["edr.process_tree(…)", "intel.hash_lookup(\"sha256:3b7e…a19f\")"],
     "evidence": [{"id": "E5", "ref": "sysmon:EventID=11 RecordID=884240", "verified": true},
                  {"id": "E6", "ref": "sysmon:EventID=1 RecordID=884251", "verified": true}],
     "reasoning": "E6:删除恢复手段,判断为加密前阶段", "attack": ["T1490"]}
  ],
  "verdict": {"label": "true_positive", "severity": "critical",
              "summary": "勒索软件执行准备阶段",
              "confidence": 0.91,
              "confidence_notes": ["未观察到大量文件变更", "upd.exe 哈希在情报中无匹配"]},
  "recommended_actions": [
    {"action": "isolate_host", "target": "fin-ws-0412", "requires_approval": true},
    {"action": "recall_mail", "match": "attachment_sha256", "requires_approval": false},
    {"action": "block", "targets": ["invoice-notice.example", "203.0.113.45"], "requires_approval": false}
  ],
  "approval": {"action": "isolate_host", "by": "analyst-07", "decision": "approved",
               "at": "2026-10-21T09:17:40+09:00", "comment": "请确认文件服务器的 SMB 会话"},
  "versions": {"model": "correlator-model-x.y", "prompt_template": "triage-vNN", "policy": "auto-response-YYYY.MM"},
  "replay": {"at": "2026-10-22T10:05:12+09:00", "same_input_hash": true,
             "label_match": true, "severity_match": true, "confidence": 0.89,
             "text_diff": "依据语句措辞部分不同"}
}

verified 是自动核对的结果,表示引用的日志是否真实存在于原始存储中。只要有一处为 false,研判就会暂缓并转交分析师。这项核对怎么统计,写在 AI 研判质量页面 的输出捏造检测一项中。

用途

拿到记录的一方可以做什么

研判记录在设计时就假定客户安全团队和审计人员会直接打开查看,Genox 内部日志只是它的用途之一。

审计应对

审计或事件调查中被问到“为什么隔离这台主机”,用一条记录就能回答。看了什么在 evidence 里,谁批准的在 approval 里,当时运行的是哪个模型和策略在 versions 里。证据以位置和哈希的形式保存,所以原始日志的保留期限要与研判记录的保留期限保持一致。

误报分析

对确认为误报的研判,查找是在哪一步出了偏差。工具调用参数错了,基线查询是空的,还是推理超出了证据,顺着 step 逐个看下去,通常就能发现。我们在月度报告中列出误报案例时,也会原样附上这份记录。

规则改进

如果同一个原因反复导致置信度被扣减,就能看出采集范围或检测规则哪里需要调整。以上面的示例来说,sources 里没有文件服务器审计日志,所以无法确认是否发生了横向移动。修改策略后,用新的策略版本重跑历史研判,确认差异。

下一步

真实记录
准备好就公开

我们正在 Research Lab 隔离环境中复现公开的攻击技术,并整理 Threat Correlator 对这些攻击做出的研判记录。不含客户数据的运行记录积累到一定数量后,会原样发布在本页。在那之前,本页的记录都是示例。

公开时遵守的原则

  • 判错的记录和判对的记录一起发布
  • 同时写明复现所用的技术 ID 和复现步骤
  • 每条记录都注明模型和策略版本,版本变化后补充重跑结果
  • 隔离环境中的主机名和账号,确保不与真实客户环境重名

与 Genox 安全专家
聊一聊。

联系我们