利用攻击发现、工作流和代理生成器加快 APT 攻击确认速度

9:15 上午：非事件--头条新闻："蛹后门：莲花深处。"您的 CISO 发送了一条 Slack 消息："我们受到影响了吗？"

在传统的 SOC 中，你整个上午的时间都将浪费在手动操作上--筛选数十个警报、编写查询、手动检查 VirusTotal，并通过索引模式来建立一个时间轴，希望不要错过什么。

但在代理式 SOC 中，工作已经完成。按小时计划运行的 "攻击发现 "系统已将 30 多个关键警报中的 5 相关联，形成了单一的攻击叙述："具有 DLL 侧加载持久性的恶意软件。"这一发现自动触发了一个工作流程，该流程将调查结果交给了一名代理。该代理使用其工具在 VirusTotal 上验证了恶意软件的哈希值，使用 ES|QL 搜索了您的日志，检查了值班计划，创建了一个案例，并启动了一个 Slack 事件频道，其中已添加了值班分析师，还生成了一份 CISO 就绪摘要--所有这一切都发生在您坐下来喝咖啡之前。

您回复您的 CISO："已经确认并分流。此案尚未结案。链接在此。"

本篇文章将介绍我们如何构建该管道：将攻击发现、工作流和代理生成器整合在一起。

威胁莲花盛开的蛹后门

威胁行为者简介

活动概述

Lotus Blossom 对 Notepad++ 更新基础设施实施了供应链入侵：

• 攻击窗口： 2025 年 6 月至 2025 年 12 月（~6 个月）
• 向量：被劫持的 Notepad++ 更新机制 (WinGUp)
• 方法选择性地将目标用户重定向至恶意更新服务器
• 有效载荷：以前未记录的"Chrysalis" 后门
• 发现：Rapid7 MDR 团队，2026-02-02 发布

蛹的后门功能

Chrysalis 后门是一个复杂、功能丰富的植入程序：

• 自定义加密（LCG、FNV-1a 散列、MurmurHash）
• 反射式 DLL 加载
• API 哈希算法用于规避
• 通过合法的 Bitdefender 二进制文件进行 DLL 副加载 (BluetoothService.exe)
• 全面的远程访问功能
• 持久安装 Windows 服务

攻击链

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

MITRE ATT&CK 映射

挑战：速度与精度

当民族国家 APT 活动的威胁情报出现时，SOC 团队面临着残酷的权衡：

速度：高管们现在就想要答案。"我们妥协了吗？"

准确性：分析师需要时间进行搜索、关联和确认，然后才能拨打电话。

传统的工作流程要求分析人员：

1. 确定分析范围和相关搜索标准
2. 在多个数据源中手动搜索增支经营成本
3. 关联可能跨越数天或数周的警报
4. 根据威胁情报验证调查结果
5. 建立攻击时间表
6. 自信地升级

这一过程需要数小时至数天，在此期间，活跃的攻击者可能会外泄数据或横向移动。

解决方案攻击发现+工作流+代理生成器

Elastic Security 的人工智能自动化堆栈将这一工作流程从人工捕猎转变为自动确认。不过，在深入了解具体设置之前，我们有必要先了解这些构件是如何组合在一起的。

代理& 工作流：两个切入点，一个可组合架构

Agent Builder 为您提供了两个可以协同工作的原语：

• 代理是智能层。他们对任务进行推理，决定调用哪些工具，并根据发现的情况进行调整。代理可以将搜索工具、MCP 工具以及关键的工作流程称为工具。
• 工作流程是结构层。它们是确定性流水线：各步骤按顺序运行，可靠且可重复。工作流程中的任何步骤都可以选择成为代理步骤，使其能够在流水线中间进行推理。

二者完全可以兼容。工作流程可以调用代理。代理可以调用工作流程。工作流程中的代理步骤可以调用另一个工作流程。每个连接都是可选的，您可以根据问题的需要进行搭配。

这就是该架构的强大之处：代理进行推理和决策；工作流进行执行和协调。在 "蛹虫袭击 "场景中，我们同时使用了这两种方法。

我们的流程

流动：

1. 许多警报→ 攻击发现将不同的警报关联到单一的攻击叙述中
2. 发现攻击→ 生成触发工作流程的警报
3. 工作流程→ 调用代理生成器分析攻击发现结果
4. 代理生成器→ 调用丰富工作流（VirusTotal、Threat Intel、ES|QL 查询）
5. 代理生成器调用工作流→ 代理生成器继续进行事件响应操作，调用工作流作为工具（案例操作、隔离主机、通知团队）

第 1 步：发现攻击威胁

攻击发现使用 LLM 分析安全警报并识别攻击模式。与传统的警报分组不同，它能理解警报之间的语义关系。

警报队列大海捞针

这就是 SOC 分析师所面临的现实。打开警报页面，你会看到几十个警报，涉及多个主机、用户和规则的组合，严重程度不一，类型各异，其中很多都是噪音。

数十个警报。多重规则启动。严重程度由低到高不等。有些是蛹的攻击。有些是与 Windows Defender 无关的事件。有些是来自完全不同工作流程的 SIEM 变更检测。在这堵噪音墙中，很难找到协调的攻击。

攻击发现》的发现

Attack Discovery 对所有这些警报进行了分析，并确定了属于单一协调攻击的 5 个警报--将它们从噪声中提取出来，并将它们关联到一个叙述中：

Attack Discovery 不再提供 5 单个警报，而是将它们关联到一个单一的发现中：

具有 DLL 侧加载持久性的恶意软件

srv-win-defend-01 上的恶意可执行文件通过BluetoothService.exe 与 DLL 侧加载升级到持久性

• 主机：srv-win-defend-01
• 用户：james_spiteri
• 严重性：严重
• 攻击链：初始访问 → 执行 → 持续 → 防御规避 → C2

同时攻击发现者：

• 映射警报至 MITRE ATT&CK 战术
• 识别出 DLL 侧载技术
• 标记可疑的持久性机制
• 突出显示 C2 网络指标

第 2 步：计划发现触发工作流程

攻击发现不需要分析人员点击按钮。我们将其配置为每小时运行一次，持续分析协调攻击的最新警报。

当我们开始每小时运行时，它会摄取上一小时的所有警报，包括埋藏在常规检测中的 Chrysalis 相关警报，并将 DLL 侧加载攻击作为一个发现浮出水面。

将工作流程作为攻击发现的一个行动步骤进行链接，意味着每次攻击发现发现协同攻击时，都会自动启动工作流程。

但是，这种方法与传统 SOAR 流程手册的不同之处在于：工作流程并没有将每一步都编成脚本。它把整个攻击发现交给 Agent Builder，然后说"弄明白。"

工作流程定义

这是我们使用的真实工作流程，包括两个步骤，仅此而已：

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id: <your-agent-id>        # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https://<your-kibana-url>/app/agent_builder/conversations/<conversation-id>)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: <your-agent-id>
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

本工作流程为何如此简短

整个自动化过程分为两个步骤：

1. initial_analysis:将攻击发现发送给代理生成器，并用自然语言说明您想要做什么
2. followup_analysis:故障保险：恢复相同的对话，并要求代理验证所有任务是否已完成。由于代理会依次调用多个工具，而任何单个工具的调用都可能超时或遇到瞬时错误，因此这一步骤可确保不会出现任何差错。

这就是根本性的转变：工作流程是触发器和安全网；代理人是大脑。

引擎盖下：我们如何扩展威胁猎捕代理

在继续介绍结果之前，我们不妨先来看看是什么让这一切成为可能。Agent Builder 最强大的功能之一就是可以使用其他工具扩展现有代理。我们没有从零开始，而是采用了默认的威胁猎捕代理，并添加了自定义的工作流支持工具，使其具备这种情况所需的特定功能。

我们增加的内容

Agent Builder 预装了platform.core.generate_esql 和platform.core.product_documentation 等平台工具。但真正的力量来自于添加自己的内容。我们通过多个类别的工具扩展了威胁猎捕代理：

五种定制工具。就这样，默认的狩猎代理就能自动验证恶意软件、搜索日志、找到值班人员、创建案例并启动事件通道--所有这一切都加快了检测潜在威胁的时间。

代理人的推理链

难能可贵的是：在 "攻击发现 "的背景下，代理会自动决定调用哪些工具以及调用的顺序。这些步骤都不是人为编排的。

步骤 1：VirusTotal 查询：vt.hash.lookup

• 特工的第一招：验证恶意软件的哈希值。

步骤 2：生成 ES|QL 查询：platform.core.generate_esql

• 在确认了恶意软件后，特工搜索了所有相关活动。

步骤 3：产品文档：platform.core.product_documentation

• 代理引用 Elastic Security 文档为响应控制台生成修复命令！

推理步骤显示为提高透明度依次调用了哪些工具

显示了额外的推理链：参考产品文档，然后检查值班计划信息，然后创建包含所有相关信息的案例，并通过 Slack 通知值班分析师。

步骤 4：查看当前时间： get.time

步骤 5：查看待命时间表：check.on.call.schedule

• 代理针对on-call-schedule 索引运行 ES|QL 查询，以查找当前应答器：

第 6 步：创建案例：create.case

第 7 步：创建 Slack 频道：create.channel

为什么这很重要

特工并没有照本宣科。它对情况进行了推理，并做出了决定：

1. 首先，验证恶意软件是否真实（VirusTotal）
2. 然后，了解影响（ES|QL 日志搜索）
3. 然后，找出补救方法（产品文档）
4. 然后，找到合适的人员做出回应（待命时间表）
5. 然后，创建跟踪工件（案例）
6. 最后，协调团队（Slack 频道）

这就是工作流程（遵循固定顺序）和代理（推断下一步该做什么）之间的区别。工作流程触发了代理，代理则负责其他工作。

步骤 3：自动事件响应

通过高置信度确认，工作流程会自动进行：

1.创建事件案例

创建结构化案件，并附上所有相关证据：

• 攻击发现结果
• VirusTotal 分析结果
• 威胁情报匹配
• 代理生成器分析
• 建议采取的应对行动

2.通知 SOC

向正确的频道发送 Slack 消息，告知分析人员该关键事件。

3.启用响应行动

工作流程可选择触发自动响应操作：

• 主机隔离：通过弹性防御隔离srv-win-defend-01
• 用户暂停：在 Active Directory 中禁用james_spiteri
• 网络阻断：将 C2 域推送到防火墙阻止列表
• IOC 清扫：在整个舰队范围内扫描蛹虫症指标

---

确认时间：之前和之后

---

另一条路只需询问代理

以上描述的都是自动化流水线--攻击发现发现威胁、工作流启动、代理分流、通知正确的分析师。

但还有一种同样有效的方法：直接进入代理生成器，用简单的英语提问。

情景：您首先阅读了有关威胁的信息

想象一下，您正在浏览威胁情报源，看到 Rapid7 关于 Chrysalis 后门的博文。你只想知道：我们妥协了吗？

就是这样。剩下的工作就由同一位特工使用同样的工具来完成：

1. 使用web.search 工具阅读威胁报告，从 Rapid7 博客中提取 IOC 和 TTP
2. 生成 ES|QL 查询，在文件、网络和进程事件日志中查找 Chrysalis 指标
3. 检查 VirusTotal，查找在您的环境中发现的任何匹配文件哈希值
4. 编写 CISO 就绪摘要，包括调查结果、可信度和建议采取的行动

代理会调用与自动管道相同的工具。不同之处在于切入点：不是由预定的 "攻击发现 "触发工作流程，而是由一个问题触发代理。

为什么这改变了分析师的游戏规则

这部分很容易被忽视，但却非常重要：分析师不需要知道任何一种查询语言、索引模式或工具名称。

他们没有写 ES|QL。他们不需要记住不同数据的位置。他们不需要记住 VirusTotal API 的语法，也不需要弄清楚要查询哪个威胁情报索引。

他们用自然语言提出了一个问题。其余的工作则由代理来完成，包括搜索哪些索引、编写哪些查询、调用哪些工具以及如何合成结果。

对于上个月才加入团队的初级分析师来说，这是一次变革。对于一个干了十年的资深分析师来说，这是他们人生中的几个小时。对于想要了解最新情况的 CISO 来说，只需提出一个问题即可。

从"知道 ES|QL 和 47 索引模式" 到"可以描述他们正在寻找的东西，有效猎杀威胁的障碍就这样降低了。"

关键要点

1. 按计划发现攻击意味着你不会错过攻击--它会持续分析你的警报，因此即使没有人在看队列，协调的威胁也会浮出水面。
2. 工作流负责协调响应、触发发现、调用代理和执行操作。
3. 通过代理生成器，您可以根据自己的需要构建或扩展代理--无论是从零开始，还是向现有代理添加自定义工具，您都可以根据自己的环境塑造代理功能。
4. 代理进行推理，执行工作流--代理自主决定调用 VirusTotal、搜索日志、检查值班计划并创建 Slack 频道。这一连串的脚本都不是人为编排的。
5. 两个入口，相同的功能- 自动管道和聊天界面使用相同的代理和工具。无论是计划中的发现触发，还是分析师提出问题，结果都是一样的。
6. 自然语言是新的查询语言--分析人员无需了解 ES|QL、索引模式或 API 语法。他们描述自己在寻找什么，剩下的就交给中介。

蛹虫草后门活动证明了这一点的重要性。当民族国家行为体可以在 4 秒内入侵您的供应链并建立持久性时，您需要的防御系统必须能与这种速度相匹配--无论是在您睡觉时运行的自动管道，还是在您最先发现威胁时与代理进行的直接对话。