产品实测··Sevion Xia
RST AI Copilot for Splunk 实战测评
一份带宏的发票、一条编码 PowerShell 下载、9 条 ES notable：看 RST AI Copilot for Splunk 如何分诊排序，并从 PowerShell 告警自主检索，追到 C2 信标和对域控的口令猜解。
版本 v1.0 · 2026-10 · 测评环境：RST AI Copilot for Splunk 2.0.17 · Splunk Enterprise 10.4.1 · Splunk Enterprise Security 8.7.0 · 模型 MiniMax-M2.7
摘要
财务部工作站 WS-FIN-07 的用户 j.chen 打开一份带宏的发票文档。约 1 小时内，攻击者下载脚本、加载伪装 DLL、每 6 分钟向 185.220.101.4 发信标、转储 lsass、对域控 DC01 喷洒口令拿到 svc_backup、用 PsExec 横向，从 FILE01 外传 2.382 GB 后清空安全日志。Splunk Enterprise Security（ES）的 6 条关联搜索产生 8 条 notable，4 条属于这条攻击链，另 4 条是同时段的外部扫描、SSH 爆破、密码过期和服务器间备份。ES 自带的基于风险的告警（RBA）把 srv-app01 上两条 SSH 爆破累计到 120 分，再出 1 条，共 9 条。
数据为 849 条合成事件，写入装有 ES 8.7.0 的 Splunk Enterprise 10.4.1 容器，由 docs/round-2026-10-12/wp/scripts/gen_events.py 生成、make_correlation_searches.py 部署关联搜索，WP_TARGET=esv py refresh_data.py 可一键重放。数字均取自 2026-10-15 同一次实跑（中文界面）。
- 研判：85.06 秒，9 条告警聚为 9 簇并全部评级，严重 2、高 2、中 3、低 2。两条已登录成功的 SSH 爆破排前两位，PowerShell 下载排第四，服务器间 SMB 传输判为疑似误报。
- 调查：从 PowerShell 告警出发，131.6 秒用满 12 次工具调用（6 次 SPL），追到用户登录、脚本下载、每 6 分钟一次的 C2 信标和对 DC01 的口令猜解。报告含 8 条时间线、6 个 MITRE 技术编号、8 条处置建议，判为严重。
- 护栏：SPL 先过只读守卫；发往模型的数据先脱敏，录制代理另跑一遍抓到的 12 条出站请求体中没有真实用户名或 IP；调查上限 12 次工具调用、180 秒，本次第 13、14 次调用被拒，报告照常产出；报告中 23 个实体全部与检索结果一致。分诊结论可由分析师一键写回 ES 的 notable。
ES 负责检出，RST AI Copilot for Splunk 给出 notable 背后的事件脉络和每一条执行过的检索，处置由人决定。
一、序章
环境为 Splunk Enterprise 10.4.1 Docker 容器，装 Enterprise Security 8.7.0。849 条事件经 REST 写入索引 rst_wp：fw-edge 的 cisco:asa 490 条，DC01、FILE01 和工作站的 wineventlog:security 246 条，代理 proxy:web 81 条，srv-app01 的 linux:secure 32 条。6 条 WP - 关联搜索每 5 分钟运行，检出写成 notable，并按严重度记风险分（高 60、中 40、低 20）。RBA 规则 Risk - 24 Hour Risk Threshold Exceeded 在对象 24 小时风险分超过 100 时另出一条。产品检测到 ES 后直接读 index=notable。模型为云端 MiniMax-M2.7，脱敏模式 private。
时间均为 2026-10-15 UTC。09:01 起，45.142.212.100 扫描 DC01 的 85 个端口，被拒 255 次。09:07:58 j.chen 打开 Invoice_Q3_2026.docm；09:08:34 WINWORD 启动编码 PowerShell，6 秒后代理记下 ld.ps1 的下载；09:09:04 rundll32 加载 theme.dll。主机随后每 6 分钟向 185.220.101.4 的 443 端口发信标，09:10:10 至 10:28:10 共 14 次。09:15:40、09:15:58 转储 lsass。09:18 起喷洒 DC01 的 14 个账号，09:20:37 拿到 svc_backup；09:24、09:26 用 PsExec 登上 FILE01 和 DC01，09:29 SSH 爆破 srv-app01 的 deploy 成功。09:49 到 09:53，FILE01 分 6 次外传 2.382 GB；09:55:40 改审计策略，09:56:04 清空安全日志。
无关事件有四件：91.240.118.66 扫描 WEB01 并 SSH 爆破 srv-app01 的 oracle 账号；未登记主机 10.10.20.99 对 DC01 做 RDP 喷洒；m.zhang 密码过期，失败 3 次后自行改密；备份服务器 10.10.1.30 每 72 分钟向 FILE01 复制约 5 MB。
11:00 之后，值班分析师打开 ES 的 Analyst Queue。
9 条 notable 全是 New / Undetermined，其中 RBA 那条风险分 120。分析师面对三个问题：
- 先处理哪条？4 条 High 平铺，8 条 WP notable 的时间都是「Today, 10:56」。
- 哪些属于同一事件？两条 SSH 爆破来源一内一外，口令喷洒有两个来源 IP，RBA 又把两条爆破合到 srv-app01 上，与 PowerShell 告警是否同源无从判断。
- 根因是什么？PowerShell 告警只说明 WS-FIN-07 启动了一条编码命令，前后经过要手写 SPL 逐条查。
RST AI Copilot for Splunk 以 App 形式装在搜索头上，用分析师自己的 Splunk 会话做只读检索，负责告警之后的研判与调查。它的「安全态势」页此时已把 4 条高危标为「需先看」。
二、双线复盘
数据一次写入，关联搜索各跑一次，所以 8 条 WP notable 检出于 10:56:26 到 10:56:33，RBA 那条在 11:00:24。表中「时间」为事件时间（notable 的 orig_time），括号内为检出时间（_time）。规则名省略 WP - 前缀和括号说明，如 Windows Account Brute Force 即 WP - Windows Account Brute Force (Password Spray)，Excessive Firewall Denies 即 WP - Excessive Firewall Denies From Single Source。
| 时间 | 实际事件 | ES notable | RST AI Copilot for Splunk 补充 |
|---|---|---|---|
| 09:01–09:04 | 45.142.212.100 对 DC01 扫描 85 个端口，被拒绝 255 次 |  Excessive Firewall Denies（10:56:26） | 分诊第九，中危，建议查命中端口，仅扫描则封禁 |
| 09:07:58 | j.chen 打开 Invoice_Q3_2026.docm |  无 | 调查从父进程 WINWORD 推断文档投递，标 T1566.001 |
| 09:08:34–09:08:40 | 编码 PowerShell 经代理下载 ld.ps1（48,210 字节） | Suspicious PowerShell Download（10:56:31） | 分诊第四，高危；调查解码命令行，查到下载记录 |
| 09:09:04 | rundll32 加载 theme.dll | 无 | 未查到，见第四章 |
| 09:10:10–10:28:10 | 每 6 分钟向 185.220.101.4:443 发信标，共 14 次 | 无 | 调查查到信标，起点和间隔正确，判为 C2 |
| 09:15:40–09:15:58 | pd.exe 和 comsvcs MiniDump 转储 lsass | 无 | 未查到，见第四章 |
| 09:18–09:20 | 对 DC01 喷洒 42 次、14 个账号，09:20:37 svc_backup 登录成功 | Windows Account Brute Force（10:56:28） | 分诊第三，高危；调查查到这批 4625 来自 WS-FIN-07，与 PowerShell 告警同一主机 |
| 09:24–09:29 | PsExec 登上 FILE01 和 DC01；SSH 爆破 srv-app01 的 deploy 成功 | Brute Force Followed By Successful Login（10:56:29） | 分诊第二，严重，建议核查 deploy 会话是否授权 |
| 09:32–09:33 | m.zhang 密码过期，3 次失败后改密登录（无关） | User Logon Failures（10:56:33） | 分诊第六，低危 |
| 09:49–09:53 | FILE01 分 6 次向 185.220.101.4 传出 2.382 GB | 无 | 未覆盖，见第四章 |
| 09:55–09:56 | 改审计策略，清空 DC01 安全日志 | 无 | 未覆盖 |
| 08:44、09:56 | 10.10.1.30 向 FILE01 复制约 5 MB，每 72 分钟一次（无关） | Large Internal SMB Transfer（10:56:32） | 分诊第七，低危，疑似误报 |
| 10:04–10:11 | 91.240.118.66 扫描 WEB01，SSH 爆破 srv-app01 的 oracle 成功（无关） | Excessive Firewall Denies（10:56:26）、Brute Force Followed By Successful Login（10:56:29） | 分诊第八和第一，建议查登录后操作，异常即隔离 srv-app01 |
| 09:29、10:11 | srv-app01 两条 SSH 爆破各计 60 分，24 小时累计 120 分 | Risk - 24 Hour Risk Threshold Exceeded（11:00:24） | 分诊第五，中危，建议确认风险事件中有无登录成功 |
攻击链 10 个阶段只有 4 个有原生告警：侦察、PowerShell 下载、口令喷洒、横向移动。钓鱼文档、theme.dll、C2 信标、lsass 转储、外泄和清日志 6 个阶段只留在原始事件里。RBA 把 deploy 爆破和无关的 oracle 爆破合在一起，指向了 srv-app01，但分不开两件事。
PowerShell 告警的关联搜索，和它匹配到的唯一一条原始事件（命令行是 Base64）：
C2 信标和外泄没有告警，防火墙日志按目标地址一筛就能看到：10.10.20.57 每 6 分钟一次 612 到 644 字节的请求，中间夹着 10.10.1.20 六次 391 MB 到 403 MB 的传输。
6 条关联搜索均已启用；RBA 那条以 srv-app01 为对象，紧急度 Low，MITRE 为 T1110。
三、研判
「实时告警」页定时从 index=notable 拉取告警，每条带「ES · 新建」徽标，分诊和调查都从这里发起。
「批量分诊」拉取最近 24 小时的告警，按（规则名，主体）聚类，每簇的签名、主体和样本脱敏后交模型评级、排序、判误报并给建议。
85.06 秒出结果。9 条告警聚为 9 簇：严重 2、高 2、中 3、低 2，1 簇疑似误报。
| 优先级 | 严重度 | 告警 / 主体 | 攻击意图 | 研判要点 |
|---|---|---|---|---|
| #1 | 严重 | Brute Force Followed By Successful Login · 91.240.118.66 | 暴力破解 | 查该 IP 登录后的操作，异常即隔离 srv-app01 |
| #2 | 严重 | Brute Force Followed By Successful Login · 10.10.20.57 | 暴力破解 | 核查 deploy 会话是否授权，否则禁用账号并隔离 srv-app01 |
| #3 | 高 | Windows Account Brute Force · 10.10.20.57、10.10.20.99 | 暴力破解 | 查 DC01 登录失败明细和有无成功登录，必要时重置服务账号密码 |
| #4 | 高 | Suspicious PowerShell Download · j.chen | 可疑外联 | 隔离 WS-FIN-07 取证（进程树、内存），查 j.chen 到 cdn-static-update.com 的其他外联 |
| #5 | 中 | Risk - 24 Hour Risk Threshold Exceeded · rst-splunk-esv | 暴力破解 | 汇总 srv-app01 近 24 小时风险事件，确认 T1110 事件中有无成功登录，必要时加入 watchlist |
| #6 | 低 | User Logon Failures · 10.10.22.41 | 异常登录 | 联系 HR/IT 确认 m.zhang 是否在职，通知其重置密码 |
| #7 | 低 | Large Internal SMB Transfer · 10.10.1.30 | 未知 | 疑似误报：仅 2 次 SMB 大文件传输，无其他恶意特征，大概率是文件共享或备份 |
| #8 | 中 | Excessive Firewall Denies · 91.240.118.66 | 端口扫描 | 查命中端口和有无成功入站，仅扫描则封禁 |
| #9 | 中 | Excessive Firewall Denies · 45.142.212.100 | 端口扫描 | 同上 |
前四位正是 Analyst Queue 里的 4 条 High，已登录成功的两条爆破在最前。备份和密码过期排在低位，只有拒绝记录的扫描垫底。每条建议写明主体，除 #6 外都附检索条件。
复核要点：
- #2、#3、#4 同出一台主机：WS-FIN-07 即 10.10.20.57。分诊分别评级，没有指出三者同属一个事件；处置时应合并，先隔离这台主机。第四章的调查补上了喷洒与这台主机的关联。
- #3 的建议 SPL 用
earliest=-1h@h latest=now。分诊于 11:11 前后完成，照此执行只能从 10:00 查起，漏掉 09:18 到 09:20 的 42 次失败，运行前需放宽窗口。 - #5 的主体 host=rst-splunk-esv 是 ES 搜索头本身。建议正文指向 srv-app01，方向对，但 120 分有一半来自无关的 oracle 爆破。
- #7 判误报只凭「只有 2 次」，没用上相隔 72 分钟、都约 5 MB 这一备份特征，结论对，依据偏薄。#6 判低危而非误报，也没查之后的 4723 改密事件；m.zhang 第三次失败后已自行改密并登录成功。
- 9 条建议都用
index=*加相对时间窗。产品已用 Splunk 解析器逐条核对，本轮无标记。
四、调查
分析师对 PowerShell 告警发起「深入调查」。排前两位的严重告警都是 srv-app01 的 SSH 登录；PowerShell 告警排第四，但它是唯一落在员工工作站上的告警，测评预先选定从它调查。查什么由模型决定。
- 告警脱敏后送入。用户名和 IP 换成请求内可逆的编号占位符；
-enc载荷由产品先解码，模型看到明文命令。private 模式下主机名不脱敏，可附资产台账背景。 - 自主检索。模型自选只读工具：
list_indexes、list_sourcetypes、get_fields探查索引、数据类型和字段，lookup_asset查资产，threat_intel查情报（本次关闭），run_spl执行只读 SPL。返回行数和调用预算见第五章。
PowerShell 下载告警：131.6 秒，用满 12 次工具调用，追到 C2 信标和口令猜解
模型先列出 13 个索引，调 threat_intel（返回 egress_disabled），查看 rst_wp 和 ers 的数据类型及两类日志的字段，再执行 6 条 SPL。第 12 次调用后预算用尽，随后两次被拒，模型用已有结果收尾。
| 步骤 | 工具 | 检索条件 | 命中 |
|---|---|---|---|
| 1 | list_indexes | 列出可见索引 | 13 个 |
| 2 | threat_intel | 查情报 | 出网已关闭 |
| 3 | list_sourcetypes | rst_wp 下的数据类型 | 4 个 |
| 4 | list_sourcetypes | ers 下的数据类型 | 2 个 |
| 5 | get_fields | rst_wp · proxy:web 的字段 | 30 个 |
| 6 | get_fields | rst_wp · wineventlog:security 的字段 | 44 个 |
| 7 | run_spl | index=rst_wp sourcetype=proxy:web (url="*cdn-static-update.com*" OR url="*ld.ps1*")，10-14 00:00 至 10-15 12:00 | 1 条 |
| 8 | run_spl | index=rst_wp sourcetype=wineventlog:security Workstation_Name="WS-FIN-07"，10-15 08:00 至 12:00 | ≥ 20 条（截断） |
| 9 | run_spl | 同上，加 EventCode=4688 | 0 条 |
| 10 | run_spl | index=rst_wp sourcetype=proxy:web user="j.chen"，同一窗口 | 15 条 |
| 11 | run_spl | index=rst_wp sourcetype=proxy:web src_ip="10.10.20.57"，同一窗口 | 15 条 |
| 12 | run_spl | index=ers (host="WS-FIN-07" OR user="j.chen")，同一窗口 | 0 条 |
| 13 | （预算） | 第 13 次调用 | 已拒绝 |
| 14 | （预算） | 第 14 次调用 | 已拒绝 |
6 条 SPL 都用绝对时间窗。第 7 条命中 ld.ps1 的下载；第 8 条拿到 j.chen 的登录和发往 DC01 的失败登录；第 10、11 条拉出这台主机的全部上网记录，包括发往 185.220.101.4 的信标。
结论为严重，置信度高，非误报：
- 摘要：j.chen 打开恶意文档，PowerShell 从 cdn-static-update.com 下载执行 ld.ps1，主机随后约每 6 分钟向 185.220.101.4 发 C2 信标。
- 时间线 8 条：09:07:40 j.chen 登录，09:08:40 代理返回 48,210 字节的 ld.ps1，09:10:10 起向 185.220.101.4 的 /api/v1/ping 发信标（列出 09:10、09:16、09:22、09:28），09:18 起向 DC01 的 administrator、svc_backup、svc_sql、it.admin 等账号发起失败登录。
- 攻击链：初始访问、执行、命令与控制、凭证访问，各注明依据事件。
- MITRE：T1566.001、T1059.001、T1027、T1071.001、T1095、T1110.001。
- 受影响资产：WS-FIN-07、j.chen、10.10.20.57、cdn-static-update.com、185.220.101.4、DC01。
- 处置建议 8 条：隔离 WS-FIN-07；改 j.chen 密码并轮换可能被窃的凭据；检索脚本落地记录；检查新增脚本和 DLL；检索该主机其他外联；扩大窗口查 DC01 的 4625；域名和 C2 地址加入威胁情报；确认后启动事件响应。3 条附可直接运行的 SPL。
「检索过程」记录每一步的工具、参数、命中数和耗时，含被拒的两次调用，结论可逐条回查。
复核要点：
- 12 次调用有 6 次是探查，其中 2 次花在 ES 8 自带的 UEBA 索引 ers 上，与本案无关，第 12 步命中 0。省下这两步可再查一次进程事件。
- 第 9 步查 4688 时沿用了
Workstation_Name="WS-FIN-07"，4688 事件中该字段无值，命中 0，于是 rundll32 加载 theme.dll（09:09:04）和两次 lsass 转储（09:15:40、09:15:58）没进报告。改用host="WS-FIN-07" EventCode=4688即可补上，下文智能查询就是这样查到的。 - 时间线列了 4 次信标，实际 14 次：第 10 步命中 15 行，模型只拿到前 5 行（ld.ps1 下载和前 4 次信标）。起点和间隔正确，完整序列见第二章的防火墙截图。
- 报告列出 4 个被猜解账号，实际 14 个；svc_backup 09:20:37 的成功登录没查到，之后的 PsExec 横向、FILE01 外泄和清日志不在检索范围内。对 #3 口令喷洒告警再调查一次可覆盖。
- 时间线最后一条 10:56:31 是 notable 生成时间，PowerShell 实际启动于 09:08:34（
orig_time）。一条时间写成09:18:10-15+00:00，指 09:18:10 到 09:18:15。 - 报告称 185.220.101.4 是 Tor 出口节点并据此标 T1095。情报查询已关闭，这一判断来自模型自身知识，未经核实。文档名写成 Invoice_Q3_2026.doc，实为 .docm。
智能查询：一句话看主机上的进程链
在「智能查询」输入「列出 2026 年 10 月 15 日 09:00–10:00（UTC）主机 WS-FIN-07 上新建的 PowerShell 进程（EventCode 4688），显示父进程和完整命令行」。检索 519 毫秒，整个回答 61.4 秒，返回 1 条：09:08:34，账户 j.chen，父进程 WINWORD.EXE，命令行以 powershell.exe -nop 开头。生成的 SPL 可展开、在 Splunk Search 中打开或保存。
分诊和调查归档在「分析记录」，本文相关截图均取自这里。
五、护栏
以下均为产品 2.0.17 的现有实现。
- 只读与校验。待执行的 SPL 先过只读守卫：禁止
collect、outputlookup、sendalert、delete等写入命令和宏、map，起始命令须在白名单内；占位符换回真实值后再校验一次。相对「现在」的时间窗、重复的时间修饰符和空窗口会被拒，并提示改用绝对窗口。建议 SPL 不执行，但经 Splunk 解析器核对，语法错误、不存在或无数据的索引会被标出。管理员可用索引白名单限定 Agent 的检索范围。 - 返回上限与脱敏。
run_spl每次最多取 20 行，模型拿到前 5 行和总行数。发往模型的数据按三档脱敏：cloud 把 IP、用户名、邮箱全部换成占位符；private 按字段脱敏，IP 到 /16；airgapped 用于内网模型，不脱敏。前两档的占位符带编号、请求内可逆，执行前换回真实值，报告返回后再还原，还原不了的标「[未还原]」。在模型端点前挂录制代理重跑分诊和调查，12 条出站请求体中没有一个真实用户名或内网 IP。 - 预算。每次调查最多 12 次工具调用、180 秒，分诊 150 秒；超出后工具返回「预算用完」，模型用已有证据作答，被拒调用记入审计。上限临时调成 1 时，第一次检索照常执行，之后两次均被拒。
- 证据留存。报告保存每一步的工具、参数、命中数和耗时；其中的 IP、用户、主机、文件名和时间逐一对照检索结果，对不上的标「未核实」，本次 23 项全部一致。每次 AI 调用在
index=_internal sourcetype=copilot:audit留一行审计（调用人、时间、功能、模型、脱敏档、耗时、工具调用次数），不记提示词和回答原文。Agent 执行的 SPL 原文在 Splunk 的_audit索引里。
ES 写回：处置结果回到 notable
装有 ES 时，分诊抽屉中有「写回 ES」按钮（需企业版许可和 analyst 角色），点击后产品调用 notable 更新接口写入状态、处置和备注。只有分析师点击才会写回。
写回演示是 10 月 17 日另做的一次分诊：时间窗 2880 分钟，重新拉取这 9 条 notable（49.16 秒，9 簇）。m.zhang 密码过期这一簇选「误报」写回后，notable 变为 Closed，处置 False Positive，备注「False positive (Copilot triage)」，页面提示「已把 1 条 notable 的处置写回 ES」。截图里这一簇已带「误报」标记、建议提到 ES 的 disposition，是因为英文界面此前对同一条 notable 写回过一次。
写回前 9 条都是 New / Undetermined；写回后只有 WP - User Logon Failures (Password Expiry) 变为 Closed，处置 False Positive - Incorrect Analytic Logic，紧急度仍为 Low，其余 8 条不变。
finding 详情中可见状态、处置、更新时间和写回备注。
六、价值与结论
告警之后的工作最耗人力：读懂首屏告警，判断同源，逐条写 SPL 还原过程，再回 ES 改状态。这一步慢，结论因人而异，还离不开资深分析师。
更快：9 条告警排序加建议 85 秒；从 PowerShell 告警追到 C2 信标和口令猜解 131.6 秒。
可复现、可审计：工具调用、SPL、命中数和耗时都留在分析记录里，被拒的调用也在。换人复核，看到的是同一份检索记录。
降低经验门槛：解码命令行、再查代理、登录和外联，原本靠经验。一线分析师点「深入调查」就能拿到这些检索和结果，用一句话查原始事件，确认误报后一键写回 ES。
| 环节 | 人工 | RST AI Copilot for Splunk |
|---|---|---|
| 排优先级 | 4 条 High 检出时间相同，凭经验逐条打开 | 85 秒聚为 9 簇并排序，已登录成功的两条爆破在最前 |
| 关联分析 | 人工比对主机、IP 和时间 | 每簇带主体和攻击意图；调查把口令喷洒和 PowerShell 告警归到同一台主机 |
| 还原过程 | 手写 SPL 查代理、登录、进程，再解码命令行 | 自主检索 12 次、6 条 SPL，131.6 秒给出 8 条时间线和攻击链 |
| 看原始事件 | 要记住 sourcetype、EventCode 和字段名 | 一句自然语言生成 SPL 并返回结果 |
| 回写处置 | 在 ES 里逐条改状态、处置和备注 | 分诊抽屉里选好处置，点「写回 ES」 |
| 数据安全 | 取决于个人习惯 | 只读守卫、出网脱敏、预算上限、证据核对、调用审计 |
本次实跑中，6 条关联搜索覆盖了攻击链 10 个阶段中的 4 个和全部 4 件无关事件。RST AI Copilot for Splunk 补出了没有规则触发的 C2 信标阶段，把口令喷洒告警和这台工作站联系起来，预算用尽时拒绝多余调用并照常交出报告。
每条结论都附带执行过的 SPL 和结果，分析师可先复核再动手。隔离主机、重置密码、封禁地址由人决定，写回 ES 也只在分析师点击时发生。检出交给 ES，研判交给产品，决策留给人。