产品实测··Sevion Xia
RST QRadar AI Copilot 实战测评
一封钓鱼发票，一夜横向移动，一屏没人看懂的 Offense：看 IBM QRadar 与 RST QRadar AI Copilot 如何合力把它还原成一个完整故事。
版本 v1.1 · 2026-09 · 测评环境：QRadar 7.6 CE（Community Edition）
摘要
一个下午到深夜，一名外部攻击者用一封钓鱼发票打进内网，一路走到把 2.3 GB 财务数据搬出境、再抹掉痕迹。IBM QRadar 忠实地把这条攻击链上"够得着"的部分关联成了 7 个 OPEN Offense——但这 7 个 Offense 摆在分析师面前时，只是 7 句规则名，谁先看、是不是误报、背后到底发生了什么，全要人去挖。
我们在一台真实的 QRadar 7.6 CE 上重演了这场入侵（攻击流量由公开的 rst-attack-sim 生成），然后让 RST QRadar AI Copilot 接手 QRadar 检出之后的活：
- 研判：7 个 Offense 聚类、评级、排序、给处置建议，端到端 约 20 秒，优先级 1 个 critical / 2 个 high / 3 个 medium / 1 个 low，无一误判为误报。
- 调查：对排第一的横向移动 Offense 发起自主调查，模型自己写 AQL 在 Ariel 上取证，4 轮检索、约 56 秒，还原出「钓鱼文档 → 编码 PowerShell → LSASS 转储 → 口令喷洒 → PsExec 横向 → robocopy 外泄」的完整链条，带时间线、MITRE ATT&CK、受影响资产与分级处置建议。
- 护栏：误报判定必须有反证才成立；结论里出现、证据行里查无此值的实体会被标为「未核实」；模型想拿脱敏占位值当查询条件会被拦下、由服务端还原真实值再查。
一句话：QRadar 负责检出，Copilot 负责把每个 Offense 背后"到底发生了什么"在约一分钟内讲清楚——包括 QRadar 规则本身不会替你串起来的那一大半上下文。
产品一览：RST QRadar AI Copilot 是什么
RST QRadar AI Copilot 是一层挂在 IBM QRadar 之上的 AI 安全运营助手，通过 REST API 只读接入 QRadar，把分析师在"检出之后"要做的活收进一个界面：安全态势总览、智能查询（自然语言转 AQL）、批量分诊、规则副驾、告警调查，以及分析记录 / 平台健康 / 系统设置等管理能力。
登录后的默认落地页是「安全态势」——一屏看清当前告警总量、严重度分布、告警时间线，以及告警最多的规则与最新告警：
而「智能查询」则是分析师最常用的入口：一句话说清要看什么，Copilot 把 AQL 和结果一起给你，旁边还挂着一排"有人在攻击我们吗 / 账号有没有被盗用 / 有没有人半夜偷偷操作"这样的开箱问题：
下面几节，就用一场真实入侵，看这套界面背后的研判与调查到底能做到什么程度。
一、序章：一封发票，和一屏读不懂的 Offense
下午三点，财务的 j.chen 收到一封"逾期发票"邮件，附件是一个 .docm。他点开、启用了宏。就在这一下，一台叫 WS-FIN-07 的终端上，Word 拉起了一个编码过的 PowerShell，向境外一个地址打出了第一个心跳。
接下来的几个小时里，攻击者没有停：转储了这台机器的 LSASS 抓凭据，拿着凭据对域控 DC01 做口令喷洒，用 svc_backup 通过 PsExec 横向到了文件服务器 FILE01 和 DC01，又爆破加密钥登进了 srv-app01，在上面建了个 sysadm 账号和一条 cron 后门，最后经 Finance 共享用 robocopy 把 2.3 GB 数据搬了出去，临走清空了 DC01 的审计日志、抹掉了 srv-app01 的 /var/log。与此同时，另一个不相关的攻击者正从 91.240.118.66 扫 DMZ、爆破 srv-app01 的 oracle 账号。
QRadar 全程在看。它把这些海量事件关联、降噪，到第二天早上，Console 上安静地躺着 7 个 OPEN Offense：
这就是分析师早上打开 Console 看到的一屏——7 句规则名。降噪已经做完了，可真正耗时的后半段才刚开始：
- 哪个先看？ magnitude 排序不理解业务上下文。
- 是不是误报？ 扫描器、运维脚本、批量任务天天制造相似告警。
- 到底发生了什么？ 一个「Multiple Login Failures」的 Offense，背后可能只是密码过期，也可能是一次成功横向移动的前奏——要判断，得手写十几条 AQL 去 Ariel 里翻进程创建、出站连接、登录后的账号动作……
这后半段，正是 RST QRadar AI Copilot 的战场：不替代 QRadar 的检测，而是接手检出之后的研判与调查。
二、双线复盘：攻击者做了什么，QRadar 与 Copilot 看见了什么
把这场入侵拆成两条并行的线看得最清楚——左边是攻击者一步步做的事，右边是这一步在 QRadar 里留下（或没留下）什么，以及 Copilot 最终把它补成了什么。
| 时间线 | 攻击者动作 | QRadar 原生检出 | Copilot 补齐的上下文 |
|---|---|---|---|
| T0 | 外网端口扫描（45.142.212.100） | ✅ Offense：Excessive Firewall Denies | 研判为端口扫描、medium，压到队尾 |
| T+1 | j.chen 打开钓鱼 .docm，宏拉起 powershell -enc，信标外联 C2 185.220.101.4:443 | ⛔ 无 Offense（CE 规则不覆盖） | 调查第 5 轮从入口机 WS-FIN-07 挖出 winword → powershell -enc |
| T+2 | 转储 LSASS 抓凭据 | ⛔ 无 Offense | 调查第 5 轮同批取证，标为凭据窃取 |
| T+3 | 用凭据对 DC01 口令喷洒 | ✅ Offense：Multiple Login Failures（DC01/srv-app01） | 研判抬为 critical·横向移动，排第一 |
| T+4 | svc_backup 经 PsExec 横向到 FILE01/DC01 | ✅ Offense：Login Failures Followed By Success | 调查第 6 轮：svc_backup PsExec 执行 + robocopy 读 Finance 目录 |
| T+5 | 爆破 + 密钥登入 srv-app01（deploy） | ✅ Offense：Multiple Login Failures（多条） | 调查第 2 轮：deploy publickey 登入、sudo 提权 |
| T+6 | 新建 sysadm 账号 + cron 后门 | ⛔ 无 Offense | 调查第 7 轮：持久化，新建账号 + crontab 后门 |
| T+7 | 经 Finance 共享 robocopy 外泄 2.3 GB | ⛔ 无 Offense | 调查第 6 轮同批取证，标为数据外泄 |
| T+8 | 清空 DC01 审计日志、抹 srv-app01 /var/log | ⛔ 无 Offense | 调查证据链中标为反取证 / 清痕 |
| （并行）事件 B | 91.240.118.66 扫 DMZ、爆破 srv-app01 的 oracle | ✅ Offense：Firewall Denies + Login Failures | 研判判为独立的低危扫描/爆破，与主链分开 |
这张表里最关键的是那些 ⛔ 行：钓鱼、C2 信标、LSASS 转储、持久化、外泄、清痕——攻击链里最致命的几步，在 CE 默认规则下根本不会单独产生 Offense（对应攻击链图里的虚线阶段）。它们只以原始事件的形态躺在 Ariel 里，要有人主动拉出来才看得见。这正是"检出"与"看懂"之间的鸿沟。
点开排第一的那个 Offense，QRadar 给出的是这样一张摘要：
「Login Failures Followed By Success … preceded by Multiple Login Failures …」——规则名准确，但背后的故事要人去挖。还有个典型的坑：这个 Offense 的 Source 显示为采集器 IP、用户名 root，这是 Linux DSM 采集场景常见的主体错位（主体落到了 syslog 采集器上）。Copilot 会把主体回退到真正的日志源主机，避免研判抓错对象。
但攻击的原始事件其实都躺在 Log Activity 里。比如独立事件 B——外部 IP 91.240.118.66 对 srv-app01 的 oracle 账号连续 SSH 爆破、最后一次登入成功——在 Log Activity 里就是一串清清楚楚的设备事件：11 条「User failed to login to SSH」（SSH Login Failed）后跟一条「Accepted Password for User」（Host Login Succeeded），源端口从 52000 一路递增，日志源是 Linux OS @ srv-app01：
再双击一条事件、展开原始 payload，攻击的真凭实据就摆在眼前。下图是 DC01 上一条 Windows 7045 事件的原始 payload：Service Name: PSEXESVC、Service File Name: %SystemRoot%\PSEXESVC.exe——这正是攻击者用 PsExec 横向移动、在域控上装服务落脚的铁证。这类原始 payload，就是研判表里「横向移动」结论背后、QRadar 规则名不会替你读出来的东西：
QRadar 这一层的能力来自它的规则与日志源配置——把七台设备的日志采进来、用关联规则降噪成 Offense：
检出到此为止是干净利落的。接下来的两节，就是 Copilot 如何把这 7 个 Offense 从"一屏规则名"变成"一份可以直接行动的作战计划"。
三、研判：约 20 秒把一屏 Offense 排成作战顺序
分析师在产品里点「开始分诊」。Copilot 按给定时间窗拉取 QRadar 里所有 OPEN Offense，按（规则，主体）聚类，交大模型评级、排序、判误报、给处置建议。真机实测：
点击到结果表渲染完成约 20 秒，7 个 Offense → 7 个簇，全部评分成功，无降级。严重度分布：严重 1 · 高 2 · 中 3 · 低 1，无一被判为误报。
输出（分诊队列，按优先级排序，与上图一致）：
| 优先级 | 严重度 | 攻击意图 | 主体 |
|---|---|---|---|
| #1 | 严重 (critical) | 暴力破解 | WindowsAuthServer @ DC01 / Linux OS @ srv-app01 |
| #2 | 高 (high) | 暴力破解 | Source IP 10.10.20.57 |
| #3 | 高 (high) | 暴力破解 | Username oracle |
| #4 | 中 (medium) | 暴力破解 | Username root |
| #5 | 中 (medium) | 端口扫描 | Source IP 45.142.212.100 |
| #6 | 中 (medium) | 暴力破解 | Username probe9 |
| #7 | 低 (low) | 端口扫描 | Source IP 91.240.118.66 |
Copilot 把打在 DC01 / srv-app01 上的那一簇判成唯一的 critical、排到第一（也正是下一节深入调查坐实的横向移动那条），把两起端口扫描压到末尾——与实际威胁程度一致，而不是照抄 magnitude。每个簇都带严重度、攻击意图标签、告警数与时间跨度，点开还有一句中文处置建议和原始告警 ID，分析师一眼知道先看哪个、为什么。序章那一屏读不懂的 Offense，约 20 秒后变成一张有先后、有理由的作战顺序。
四、调查：约一分钟把最急的那条讲成完整故事
分析师选中排第一的横向移动 Offense，点「深入调查」。
这不是把日志丢给模型让它总结，而是一个自主检索循环：模型看完 Offense，自己写一条只读 AQL 去 Ariel 取证，看回来的（脱敏）结果，再决定下一条查什么——像一个不知疲倦、每次都按同一份查证清单走完的分析师。
这次调查真机跑出的检索轨迹（4 轮、约 56 秒、结论 critical，无降级；每条 AQL 都由模型现场生成，不是模板；命中 0 的阴性结果也被当证据保留）：
| 轮 | 模型这一步去查什么 | 命中 | 揭示的环节 |
|---|---|---|---|
| 1 | INOFFENSE(5) — Offense 自身事件 | 20 | 建立基线：DC01/FILE01/srv-app01 上多账号的登录失败与成功 |
| 2 | deploy 账号在 srv-app01 的动作 + payload | 6 | deploy 8 次 SSH 口令失败后以 publickey 登入、sudo 提权 |
| 3 | 目标主机 / 端口的出站会话聚合 | 0 | 阴性排除：无异常直连出站 |
| 4 | 源 sourceip='10.10.x.x' 的横向足迹 + payload（脱敏 IP 由服务端还原真实值再查） | 11 | 新建 sysadm 后门 → 该账号 48 秒后从外网 185.220.x.x 登录 → 打包 /etc/shadow、/root/.ssh → 清日志、停 rsyslog |
这几步不是随机翻日志——它遵循一份最少查证清单（Offense 自身事件、登录成功后的账号动作、主体的出站、外泄与清痕）。Offense 表面只是「DC01/srv-app01 上多次登录失败」，模型却顺着 deploy → sysadm → 外网回连 → 外泄 → 清痕 把一条已得手的入侵完整串了出来——正是双线表里那些 QRadar 没能单独告警的 ⛔ 阶段。
这一次调查里，产品做到了几件靠「把日志喂给大模型」做不到的事：
- 自己写对 AQL：
QIDNAME/CATEGORYNAME/LOGSOURCENAME/INOFFENSE/UTF8(payload) ILIKE全部用法正确，无需人给查询模板； - 脱敏下仍能顺藤摸瓜：模型只看得到
10.10.x.x，服务端把它在证据里见过的真实值悄悄还原后再查（第 4 轮），既不泄露真实 IP 给大模型、又不打断调查； - 会做阴性验证：第 3 轮命中 0 也写进证据用于排除，而不是当作「没查到」忽略；
- 全程只读 + 白名单：每条 AQL 都过日志源白名单，越界即拒，不会因为模型「想查」就碰到不该碰的数据。
模型每一步的 AQL、命中数、耗时都对分析师透明可查（下图为智能查询里的「查看生成的 AQL」，整页可见 logo 与模块侧栏；调查循环用的是同一套只读检索）：
查完，收尾结论一次给全——摘要、按时间戳排的完整时间线、攻击链、MITRE ATT&CK 技术、受影响资产、分级处置建议。下图是产品对整条主攻击链的一次深入调查报告，从 WS-FIN-07 的钓鱼入口（Invoice_Q3_2026.docm → WINWORD → powershell -enc）一路查到 svc_backup 经 PSEXESVC 横向、robocopy 读取 Finance 目录外泄：
每一次调查都自动归档在「分析记录」里，可回溯、可复核——同一起入侵，产品既能从横向移动 Offense 入手，也能从整条主攻击链入手，结论互相印证：
回到序章：QRadar 给分析师的是「DC01/srv-app01 上多次登录失败」这句规则名；Copilot 给他的是从 j.chen 打开钓鱼文档到财务数据出境的整条故事，附每一步的证据来源。这段过去要资深分析师手写十几条 AQL、花半小时才能拼出的全貌，现在约一分钟、可回溯、可审计。
五、护栏：为什么这套结论敢给分析师看
在一条真实入侵链上，一个"聪明但不可靠"的 AI 会带来新风险——臆造一个不存在的账号、把一次真实横向当误报放过，都可能误导处置。本产品把三条护栏固化进研判与调查：
- 误报要有反证才成立——模型若想判某 Offense 为误报，会先核对时间窗内有无特权登录、账户变更、外网直连、审计清除、可疑进程；只要有其一，误报判定被否决并升级。宁可升级一个真误报让人复核，也不放过一个真威胁。
- 实体必须逐字来自证据——结论里出现、但证据行里查无此值的用户名 / IP，会被移出受影响资产并标为「未核实」，杜绝模型幻觉出账号。
- 脱敏值不当查询条件——模型只看脱敏行（如
10.10.x.x）。它想拿占位值回查时，服务端用取证时见过的真实值还原（唯一 → 替换，多候选 →IN列表），既不让脱敏值污染查询、又不打断调查。正是这条让上面的调查能从 Offense 一路查到入口主机。
三条护栏的共同目的只有一个：让结论能被复核，而不是"AI 说是就是"。
六、价值
SOC 最贵的从来不是买 SIEM，是 SIEM 报出 Offense 之后、分析师读懂它的那段人力。这段人力有三个老问题：慢、不稳、依赖资深。产品正是压这三点。
慢 → 快。 一屏 Offense 的排序 + 处置建议从「逐个点开、凭经验」压到 约 20 秒；单个 Offense 的彻底调查从资深分析师手写十几条 AQL 的 半小时 压到 约 1 分钟。
不稳 → 可复现、可审计。 每次调查都走同一份最少查证清单，不会今天想起查入口机、明天忘了查外泄；误报判定必须有反证支撑（见 §五），且每条结论都附 AQL 证据来源。
依赖资深 → 拉平。 「知道该查哪十几条 AQL」是资深分析师最难复制的经验，产品把它固化进检索循环——一线分析师点一下「深入调查」，就能得到接近资深水平的取证链路。
| 环节 | 传统人工 | RST QRadar AI Copilot |
|---|---|---|
| 排优先级 | 按 magnitude 或经验逐个点开，易被高噪声淹没 | 约 20 秒给出懂业务意图的优先级 + 中文处置建议 |
| 判误报 | 靠经验，漏判即放过真实威胁 | 反证机制否决草率误报，判定可审计 |
| 查全貌 | 手写十几条 AQL，30–60 分钟，因人而异 | 自主检索 4 轮、约 1 分钟，带时间线 + MITRE + 证据 |
| 覆盖度 | 容易停在 Offense 表面，漏掉入口机 / 外泄 | 按最少查证清单主动回溯到入口机与外泄路径 |
| 数据安全 | — | 只读 + 日志源白名单 + 出网脱敏，可接生产 QRadar |
产品不取代分析师、也不自动处置——处置决策仍在人手里。它做的是把「这个 Offense 到底发生了什么」在约一分钟内、带着证据讲清楚，让分析师的时间花在决策上，而不是取证上。同样的 SOC 团队，能盯住更多的 Offense、也更少漏掉真的那一个。
七、边界与说明
- 测评在 QRadar 7.6 CE 上完成；商业版规则更多，检出层只会更强，研判 / 调查层不变。
- 对 QRadar 只做只读检索 + 三类有限写（备注 / 关闭 / 分配跟进），不自动封禁、不改规则——处置决策仍在人手里。
- 所有 Ariel 检索受日志源白名单强制约束，引用白名单外的日志源直接拒绝。
- 测评数据由公开的 rst-attack-sim 生成，任何人可在自己的授权实验环境复现。
八、结论
一封钓鱼发票，一夜横向移动，一屏读不懂的 Offense——这是每个 SOC 都会遇到的一天。在这一天里，IBM QRadar 完成了它最擅长的事：把海量事件降噪成 7 个 Offense。而 RST QRadar AI Copilot 补上了 QRadar 检出之后最缺的两件事：秒级的、理解业务意图的研判排序，和自主、可回溯、带护栏的深入调查。
它把一个「多次登录失败」的 Offense，在约一分钟内还原成一条从钓鱼到外泄的完整故事——并且不会替你臆造账号、不会把真实威胁当误报放过。检出交给 QRadar，看懂交给 Copilot，决策留给人。
复现本测评：用 rst-attack-sim 打入攻击链，接入 RST QRadar AI Copilot，即可得到本文的研判与调查结果。