
一条记录里有什么
从上往下读,就是研判形成的顺序。
一条研判下挂多个步骤(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)。
这条记录先看哪里
先看研判这一行,置信度为什么停在 0.91。在这个示例里,记录写明了两点:还没有观察到文件被加密,下载的可执行文件哈希在威胁情报中没有匹配。反过来,如果一条记录置信度很高,扣减原因却是空的,那条记录反而更值得怀疑。
接着看审批这一行。按策略,主机隔离不会自动执行。从这条记录还能读出,研判结果出来后,分析师读完依据并批准,用了两分钟多一点。
逐步阅读
- 收到邮件(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 没有下结论。 - 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。 - 删除卷影副本(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 条目中也列有多个勒索软件在加密之前先删除卷影副本的案例。 - 研判。真实威胁,勒索软件执行准备阶段,风险等级 CRITICAL,置信度 0.91。扣减置信度的原因写了两条:“未观察到大量文件变更”和“upd.exe 哈希在情报中无匹配”。
- 建议处置与审批。对主机做网络隔离(需审批),召回带有相同附件哈希的邮件,封禁发件域名和 203.0.113.45。隔离由 analyst-07 在 09:17 批准,备注为“请确认文件服务器的 SMB 会话”。两项封禁在与客户约定的自动响应策略范围之内,无需审批即已执行。
- 重跑。第二天用相同的 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 和复现步骤
- 每条记录都注明模型和策略版本,版本变化后补充重跑结果
- 隔离环境中的主机名和账号,确保不与真实客户环境重名
推荐一起阅读
我们如何衡量 AI 研判质量
基于研判记录测量准确率、误报与漏报、依据缺失和重跑一致性的方法。
查看测量方法Threat Correlator
把告警归并为事件,并记录证据、依据、研判、建议处置和置信度的引擎。
Threat Correlator平台
看 Vulnerability Scanner、Behavioral Analyzer、Threat Correlator 和 Research Lab 如何衔接。
查看平台参考资料
- Phishing: Spearphishing Attachment (T1566.001),MITRE ATT&CK
- Command and Scripting Interpreter: PowerShell (T1059.001),MITRE ATT&CK
- Inhibit System Recovery (T1490),MITRE ATT&CK
- Sysmon,Microsoft Sysinternals(事件 ID 1 为进程创建,11 为文件创建)
- vssadmin delete shadows,Microsoft Learn
- RFC 5737 IPv4 Address Blocks Reserved for Documentation,IETF
- RFC 2606 Reserved Top Level DNS Names,IETF