RST AI Copilot for Elastic 实战测评

版本 v1.0 · 2026-10 · 测评环境：Elasticsearch + Kibana 8.15.3（trial 许可，Security 检测引擎）

---

摘要

一名攻击者用一封钓鱼发票打进内网，没有再碰一个漏洞，全程只用合法凭据：从一台终端拿到域账号，Kerberoasting 爆出一个服务账号口令，再用它在域控上发起 DCSync 把整个域的哈希（包括 krbtgt）搬走，建了个后门域管，最后清掉域控的安全日志。这类活在身份里的攻击，是今天 SOC 最难看清的一种。

Elastic Security 忠实地检出了它够得着的部分：用和 Elastic 官方 detection-rules 一致的规则逻辑，一晚上产生了 9 条告警，5 条 RC4 Kerberos 票据（high）、2 条 DCSync（critical）、1 条编码 PowerShell（high）、1 条清日志（high）。但这 9 条摆在分析师面前时，是四种不同规则、不同主体、不同 MITRE 战术的告警，看上去像几起孤立的事件。谁先看、是不是误报、它们到底是不是同一场攻击，全要人去挖。

我们在一台真实的 Elastic 8.15 上重演了这场入侵（Windows 安全事件为合成遥测，字段逐字对齐 Elastic 官方 detection-rules，规则真触发），然后让 RST AI Copilot for Elastic 接手 Elastic 检出之后的活：

• 研判：9 条告警聚类、评级、排序、给处置建议，端到端 7.8 秒，4 个簇，优先级 2 个 critical、1 个 high、1 个 medium，无一误判为误报。数量最多的 5 条、最吵的 Kerberoasting 被压到队尾，2 条 DCSync 排到第一，按攻击意图排，不是按告警数。
• 调查：对一条看似只是编码 PowerShell 的 high 告警发起自主调查，模型自己写 ES 查询取证，3 轮检索、不到一分钟、取证 21 条，从入口机 WS-FIN-07 一路按身份跨主机 pivot 到域控、再追到后门账号，坐实 钓鱼宏 → 编码 PowerShell → Kerberoasting → DCSync → 后门域管 → robocopy 外带财务文件 的完整链条，把这条 high 告警升级为 critical 域陷落，带时间线、MITRE ATT&CK、受影响资产与分级处置建议。
• 护栏：误报判定必须有反证才成立；结论里出现、证据行里查无此值的实体会被标为未核实；对 Elastic 全程只读加索引白名单，出网内容按模式脱敏。

Elastic 负责检出，Copilot 负责把这几条看似无关的告警背后到底是不是同一场攻击、发生了什么在一分钟内讲清楚，包括规则本身不会替你串起来的那一大半上下文。

---

产品一览

RST AI Copilot for Elastic 是一层挂在 Elasticsearch + Kibana 之上的 AI 安全运营助手，通过一个 Docker 网关只读接入现有 Elastic：轮询 .alerts-security 摄取检测告警，按索引白名单只读检索 logs-*，把分析师在检出之后要做的研判、调查、规则维护收进一个界面。不装 agent、不改规则、不自动处置。

登录后一屏能看清当前告警总量、严重度分布、告警时间线，以及告警最多的规则与最新告警。

智能查询是分析师最常用的入口，一句话说清要看什么，Copilot 把 ES 查询和结果一起返回。

下面用一场真实入侵，看这套界面背后的研判与调查能做到什么程度。

---

一、序章

下午，财务的 j.chen 收到一封逾期发票邮件，在终端 WS-FIN-07 上打开了带宏的 .docm，Word 拉起了一个编码过的 PowerShell，这是攻击者的落脚点。

接下来的两小时，攻击者没有再碰一个漏洞，全程活在身份里：用这台机器上的域账号 j.chen 对域控批量请求服务账号的 Kerberos 票据（Kerberoasting，专挑弱加密的 RC4），把票据拿去离线爆破，撞出了服务账号 svc_sql 的口令；用它登进文件服务器 FILE01、应用服务器 APP01；回到域控 DC01 发起 DCSync，冒充域控把整个域的目录复制权限用上、连 krbtgt 的哈希一起搬走；顺手建了个叫 svc_health 的账号塞进 Domain Admins，从境外 C2 远程登回来读取 Finance 共享；临走清空了 DC01 的安全事件日志。

Elastic 全程在看。它用和官方 detection-rules 一致的规则逻辑把海量事件降噪，到第二天早上，Kibana 的 Alerts 页上躺着 9 条告警：

这就是分析师早上打开 Kibana 看到的一屏。降噪已经做完了，可真正耗时的后半段才刚开始：

1. 哪个先看？ 9 条里 5 条都是同一个 RC4 Kerberos 票据（high），数量最多，但它其实是攻击链里最早、最不致命的一步，真正要命的 2 条 DCSync（critical）淹在里面。
2. 是不是同一场攻击？ 这 9 条分属四种规则、三个主体（DC01、WS-FIN-07、源 IP 10.10.20.57），横跨凭据访问、执行、反取证三种战术。它们是一条链，还是几起不相干的事？规则不会告诉你。
3. 到底发生了什么？ 一条编码 PowerShell 的 high 告警，背后可能只是某个运维脚本，也可能是一场域陷落的起点。要判断，得手写一堆 ES 查询，按主机、按账号、按时间窗一路翻下去。

这后半段，正是 RST AI Copilot for Elastic 的战场：不替代 Elastic 的检测，而是接手检出之后的研判与调查。

---

二、双线复盘

把这场入侵拆成两条并行的线看得最清楚：左边是攻击者一步步做的事，右边是这一步在 Elastic 里留下（或没留下）什么，以及 Copilot 最终把它补成了什么。

阶段	攻击者动作（MITRE）	Elastic 原生检出	Copilot 补齐的上下文
1 初始访问	j.chen 开宏文档，WINWORD 拉起 powershell -enc（T1566/T1059）	告警：编码 PowerShell（high）	调查 r1 从 WS-FIN-07 挖出完整进程链与下载串
2 凭据窃取	对 DC01 批量请求 RC4 服务票据（Kerberoasting，T1558.003）	告警：RC4 Kerberos 票据 ×5（high）	研判识别为 Kerberoasting 前兆，调查关联到入口机工具化操作
3 离线破解	svc_sql 口令哈希离线爆破	无遥测	调查据链路推断为凭据破解环节
4 横向移动	用 svc_sql 登入 FILE01/APP01（T1021）	无告警（看似合法登录）	跨主机证据，调查按服务账号可回溯
5 凭据访问	在 DC01 上 DCSync 拉域 + krbtgt（T1003.006）	告警：DCSync ×2（critical）	研判抬为 critical·排第一；调查 r3 跨主机 pivot 坐实
6 持久化	建 svc_health 加入 Domain Admins（T1136.002/T1098）	无告警	调查把它纳入攻击链（后门域管）
7 数据外泄	后门账号从 C2 远程登入读 Finance（T1048）	无告警	跨主机证据，调查标为外泄路径
8 反取证	清除 DC01 安全日志（T1070.001）	告警：清日志（high）	研判单列为反取证簇，与 DCSync 关联

这张表里最关键的有两类行。一类是没有原生告警的那几行，离线破解、横向移动、持久化、数据外泄，这些活在合法身份里的步骤根本不会单独产生告警（对应攻击链图里的虚线阶段），只以原始事件的形态躺在索引里，要有人主动拉出来才看得见。另一类更微妙，那些有告警的行彼此不相连，Elastic 给了你四种告警，却没告诉你它们是同一个 j.chen、同一条链。这正是检出与看懂之间的鸿沟。

这些告警背后的检测规则，就是用 Elastic 官方 detection-rules 的逻辑建的（DCSync 认 event.code:4662 加复制权限 GUID 加 AccessMask:0x100，RC4 票据认 4769 加 TicketEncryptionType:0x17，清日志认 1102）：

攻击的原始证据就躺在 logs-system.security-* 里。下图是 Discover 里一条 4662 事件，j.chen 对域对象请求了 Replicating Directory Changes（复制权限 GUID 1131f6aa-…）、AccessMask 0x100，这正是 DCSync 的铁证，也是规则名「Potential Credential Access via DCSync」背后、要展开原始事件才读得到的东西：

点开那条 DCSync 告警，Kibana 给出的是规则名加 MITRE 映射，准确，但背后的故事要人去挖：这次 DCSync 的凭据从哪来？谁、从哪台机器发起的？之后又做了什么？

检出到此为止是干净利落的。接下来两节，是 Copilot 如何把这 9 条告警从四种互不相干的信号变成一份可以直接行动的作战计划。

---

三、研判

把这 9 条告警交给批量分诊，Copilot 按（规则，主体）聚类，交大模型评级、排序、判误报、给处置建议。真机实测：

从发起到结果表渲染完成 7.8 秒，9 告警聚成 4 个簇，全部评分成功，无降级。严重度分布：严重 2、高 1、中 1，无一被判为误报。

分诊队列按优先级排序：

优先级	严重度	攻击意图	主体	告警数
#1	严重 (critical)	凭据窃取 · DCSync	j.chen	2
#2	严重 (critical)	反取证 · 清日志	DC01	1
#3	高 (high)	宏钓鱼初始执行	j.chen	1
#4	中 (medium)	Kerberoasting 侦察	10.10.20.57	5

这里有两个细节值得停一下。其一，数量最多的那个簇排在最后，5 条 RC4 Kerberos 票据告警被判为 medium、压到队尾，因为 Kerberoasting 是攻击链里最早、最不致命的一步，而不是因为它告警多就重要。其二，Copilot 把两条 DCSync 判成 critical、排到第一，并在处置建议里直接把它和 DC01 的清日志簇关联起来，它已经隐约看出这几条是同一场攻击。序章那一屏读不懂的告警，7.8 秒后变成一张有先后、有理由的作战顺序。

---

四、调查

这次分析师没有从 critical 入手，而是选中了那条看起来最普通的 high 编码 PowerShell 告警做深入调查，想知道这台终端到底怎么了。

这不是把日志丢给模型让它总结，而是一个自主检索循环：模型看完告警，自己写一条只读 ES 查询去取证，看回来的脱敏结果，再决定下一条查什么，像一个不知疲倦、每次都按同一份查证清单走完的分析师。

这次调查真机跑出的检索轨迹（3 轮、取证 21 条、结论 critical，无降级；命中 0 的阴性结果也被当证据保留）：

轮	模型这一步去查什么	命中	揭示的环节
1	近 1 小时窗口内 host.name=WS-FIN-07 或 user.name=j.chen	0	阴性：攻击发生在更早，模型据此主动放宽时间窗
2	放宽到 8 小时窗口，按主机 + 身份 j.chen	13	宏文档 Invoice_Q3.docm → powershell -enc → Kerberoasting（setspn 枚举 SPN、RC4 TGS）→ 域控 DC01 上 4662 DCSync（复制域 + krbtgt）
3	追加第 2 轮新发现的后门账号 svc_health 一起查	8	持久化：建 svc_health 入 Domain Admins；该账号从境外 185.220.101.4 远程登入 FILE01，用 robocopy 窃取 Finance 文件（含 bank_tokens.csv）

这几步不是随机翻日志，它遵循一份最少查证清单（入口机、身份、横向、外泄、清痕）。告警表面只是一台终端跑了编码 PowerShell，模型却顺着 入口机 → 身份 j.chen → 域控 DCSync → 后门账号 svc_health → 外带 把一条已得手的入侵完整串了出来，并把这条 high 告警的结论升级为 critical，正是双线表里那些 Elastic 没能单独告警、或没能彼此关联的环节。

这一次调查里，产品做到了几件靠把日志喂给大模型做不到的事：

• 会自己放宽条件。第 1 轮用近 1 小时的窄窗命中 0，模型没有就此收手，而是把时间窗放宽到 8 小时重查，像真人一样没查到就换个查法。
• 会顺着新线索 pivot。第 2 轮发现了后门账号 svc_health，第 3 轮就把它加进查询，才挖出外带那一步。这步跨账号的身份枢轴，正是把工作站告警一路连到数据外泄的关键。
• 会做阴性验证。第 1 轮命中 0 也写进证据，而不是当作没查到忽略。
• 全程只读加白名单。每条查询都过索引白名单，越界即拒，不会因为模型想查就碰到不该碰的数据。

查完，收尾结论一次给全：摘要、按时间戳排的完整时间线、攻击链、MITRE ATT&CK 技术（T1566.001、T1059.001、T1558.003、T1003.006、T1136.002、T1005）、受影响资产、分级处置建议。处置建议里不只是禁用账号，还点出了把被 Kerberoasting 的服务账号全部轮换、视 krbtgt 已泄漏做两次密码重置、阻断 C2 185.220.101.4 并评估 bank_tokens.csv 泄漏范围这类资深 AD 应急动作：

每一次调查都自动归档在分析记录里，可回溯、可复核：

回到序章，Elastic 给分析师的是四条分属不同规则、不同主体的告警，Copilot 给他的是从 j.chen 打开钓鱼文档到整个域被 DCSync 搬空的一条完整故事，附每一步的证据来源。这段过去要资深分析师手写十几条查询、花半小时才能拼出的全貌，现在不到一分钟，可回溯、可审计。

---

五、护栏

在一条真实入侵链上，一个聪明但不可靠的 AI 会带来新风险，臆造一个不存在的账号，或把一次真实 DCSync 当误报放过，都可能误导处置。产品把三条约束固化进研判与调查，让每条结论都能被复核，而不是 AI 说是就是。

1. 误报要有反证才成立。 模型若想判某告警为误报，会先核对时间窗内有无特权操作、账户变更、外联、审计清除、可疑进程，只要有其一，误报判定被否决并升级。这次调查对编码 PowerShell 给出的是 is_likely_false_positive = false，并以 Kerberoasting、DCSync 等后续动作为据。宁可升级一个真误报让人复核，也不放过一个真威胁。
2. 实体必须逐字来自证据。 结论里出现、但证据行里查无此值的用户名、IP、主机，会被移出受影响资产并标为未核实，杜绝模型幻觉出账号。
3. 只读加白名单加分级脱敏。 对 Elastic 全程只读检索加轮询摄取告警，不改规则、不自动处置；每条 ES 查询过索引白名单，越界即拒；出网内容按部署模式脱敏（cloud、private、airgapped），气隙模式下全链本地闭环，模型看真实值而数据不出域。

---

六、价值与结论

SOC 最贵的从来不是买 SIEM，是 SIEM 报出告警之后、分析师读懂它的那段人力。这段人力有三个老问题，慢、不稳、依赖资深，产品正是压这三点。

慢变快。一屏告警的排序加处置建议从逐个点开、凭经验压到 7.8 秒，单个告警的彻底调查从资深分析师手写十几条查询的半小时压到不到一分钟。

不稳变可复现、可审计。每次调查都走同一份最少查证清单，不会今天想起查入口机、明天忘了做身份 pivot，误报判定必须有反证支撑，且每条结论都附查询证据来源。

依赖资深变拉平。知道该按主机查、再按账号 pivot、哪些是阴性排除，是资深分析师最难复制的经验，产品把它固化进检索循环，一线分析师一次深入调查就能得到接近资深水平的取证链路。

环节	传统人工	RST AI Copilot for Elastic
排优先级	按严重度或数量逐个点开，易被最吵的告警淹没	7.8 秒给出懂攻击意图的优先级加中文处置建议
关联	靠经验判断几条告警是不是同一场攻击	聚类加跨主体 pivot，自动把分散告警连成一条链
判误报	靠经验，漏判即放过真实威胁	反证机制否决草率误报，判定可审计
查全貌	手写十几条查询，30 到 60 分钟，因人而异	自主检索 3 轮，不到 1 分钟，带时间线加 MITRE 加证据
覆盖度	容易停在告警表面，漏掉入口机或外泄	按最少查证清单主动回溯到入口机与域控
数据安全	无专门约束	只读加索引白名单加出网脱敏，可接生产 Elastic

一封钓鱼发票，一次 Kerberoasting，一场靠合法凭据完成的域陷落，这是每个 SOC 都怕遇到的一天。在这一天里，Elastic Security 完成了它最擅长的事，把海量事件降噪成几条检测告警，而 RST AI Copilot for Elastic 补上了 Elastic 检出之后最缺的两件事，秒级的、理解攻击意图的研判排序，和自主、可回溯、带护栏的跨主机深入调查。

它把一条看似普通的编码 PowerShell 告警，在一分钟内还原成一条从钓鱼到 DCSync 域陷落的完整故事，并且不会替你臆造账号、不会把真实威胁当误报放过。产品不取代分析师、也不自动处置，处置决策仍在人手里。检出交给 Elastic，看懂交给 Copilot，决策留给人。同样的 SOC 团队，能盯住更多的告警，也更少漏掉真的那一个。