LLM驱动后渗透攻击实战分析：从Marimo CVE到数据库窃取的全链路拆解

2026年5月31日 | 技术安全分析 | 原创内容

开篇

2026年5月10日，云安全公司Sysdig记录了一起不同寻常的攻击事件。一个未知的威胁行为者利用公开暴露的Marimo笔记本应用中的严重RCE漏洞（CVE-2026-39987）获取初始访问权限后，没有使用传统的人工渗透或预设脚本，而是部署了一个LLM（大语言模型）代理来执行后续的所有后渗透操作。

最终结果？攻击者在不到两分钟的时间内完成了内部PostgreSQL数据库的完整窃取。整个攻击链从头到尾只用了大约一小时。

这不是科幻小说。这是2026年网络安全攻防的新现实——当攻击者开始用AI代理替代人工操作时，攻击的边际成本从”工程时间”变成了”推理预算”，攻击规模和速度都将发生质变。

本文将基于Sysdig的详细报告，逐层拆解这次攻击的每一个步骤，分析LLM代理在后渗透中展现出的独特能力，并讨论防御方应该如何应对这一新范式。

一、初始突破：Marimo CVE-2026-39987

1.1 Marimo是什么

Marimo是一个开源的Python响应式笔记本工具，类似于Jupyter Notebook，但具有更强的交互性和响应式特性。它支持在浏览器中创建和运行Python代码，被数据科学家和研究人员广泛使用。

关键问题是：Marimo实例经常被直接暴露在互联网上，方便远程协作——这在数据科学社区中是常见做法，但从安全角度来看，相当于把一个可以执行任意代码的解释器直接开放给全世界。

1.2 漏洞详情

CVE-2026-39987是一个严重的预认证远程代码执行漏洞：

这个漏洞允许未经认证的攻击者在Marimo服务器上执行任意系统命令。漏洞的根本原因是Marimo的某些API端点没有正确验证用户输入，导致命令注入。

1.3 为什么Marimo实例会被暴露

在Shodan和Censys上搜索Marimo，你会发现数千个公开实例。原因包括：

• 开发者为了方便远程访问而直接暴露端口
• Docker/K8s部署时默认网络配置不当
• 云安全组规则过于宽松
• 用户根本没意识到Marimo有安全风险

“我只是想在家也能跑Notebook”——这句话背后，可能就是一个9.8分的RCE漏洞。

二、攻击链拆解：四步完成从突破到数据窃取

Sysdig的威胁研究团队完整记录了这次攻击的全过程。让我们逐步分析：

2.1 第一步：初始突破（突破边界）

攻击者 → 互联网暴露的Marimo实例 → CVE-2026-39987 RCE → 服务器Shell

攻击者首先利用CVE-2026-39987在Marimo服务器上获得了命令执行能力。这一步本身并不特别——Marimo的这个漏洞已经被多个威胁行为者利用，Sysdig自己的蜜罐系统此前就记录过手动侦察和数据收集尝试。

真正让这次事件与众不同的，是接下来发生的事情。

2.2 第二步：凭据提取（横向移动准备）

服务器Shell → 环境变量/配置文件搜索 → 提取AWS Access Key × 2

获得初始访问后，攻击者（准确地说，是LLM代理）开始在受感染的环境中搜索凭据。这里出现了第一个LLM代理的标志性特征：即兴搜索能力。

传统攻击者会使用预定义的凭据搜索脚本，按固定路径查找（如~/.aws/credentials、环境变量等）。而LLM代理的表现更像一个经验丰富的人类渗透测试者——它根据环境反馈动态调整搜索策略，在文件系统、环境变量、配置文件中灵活穿梭，最终成功提取了两套AWS访问密钥。

2.3 第三步：云凭据利用和SSH密钥获取（权限提升）

AWS Access Key → AWS Secrets Manager API → 获取SSH私钥

这是攻击链中最精妙的一步。LLM代理使用提取到的AWS凭据，通过API调用访问AWS Secrets Manager，从中获取了一个SSH私钥。

值得注意的是，攻击者使用了”扇出式出口池”（fanned-out egress pool）来发起AWS API请求——这意味着它通过多个不同的IP地址来分散请求，避免触发单一IP的速率限制或异常检测。

# 攻击链伪代码（概念展示）
# Step 3: AWS Secrets Manager访问
import boto3

# 使用窃取的凭据
session = boto3.Session(
    aws_access_key_id=stolen_key_1,
    aws_secret_access_key=stolen_secret_1
)

# 通过扇出IP池发起请求
secrets_client = session.client('secrets_manager')
ssh_key = secrets_client.get_secret_value(
    SecretId='prod/ssh/bastion-key'
)

# 获得SSH私钥 → 准备下一步

2.4 第四步：数据库窃取（目标达成）

SSH私钥 → SSH堡垒机 → 8个并行SSH会话 → PostgreSQL数据库完整导出

攻击的最后阶段堪称教科书级别。LLM代理使用获取的SSH私钥，首先登录到一个SSH堡垒机（Bastion Server），然后从堡垒机发起了8个并行的SSH会话，连接到下游的内部PostgreSQL数据库服务器。

关键细节：数据库的主机名是”不透明的”——没有应用标识符，也没有预先准备的Schema转储。换句话说，LLM代理面对的是一个完全未知的目标，它需要：

1. 自行发现数据库类型和结构
2. 即兴编写数据库导出命令
3. 在不知道Schema的情况下完成完整数据窃取

这一切，在不到两分钟内完成。

三、LLM代理攻击的四个识别特征

Sysdig的研究人员总结出了四个表明LLM代理参与攻击的指标：

3.1 即兴能力（Improvisation）

传统自动化工具（如Metasploit、Cobalt Strike）依赖预定义的攻击路径和已知漏洞利用模块。遇到未预期的环境配置时，它们会失败或卡住。

LLM代理不同。面对”没有应用标识符、没有预知Schema”的数据库主机，它能够即兴分析环境、猜测命令、调整策略——就像一个经验丰富的人类渗透测试者会做的那样。

3.2 中文规划注释泄露

这是一个极其有趣的细节。在执行凭据搜索命令时，命令流中出现了一条中文注释：“看还能做什么”。

$ grep -r "password\|secret\|key" /opt/app/  # 看还能做什么
$ find /home -name "*.env" -exec cat {} \;

这条注释强烈暗示： – 攻击者使用的是支持中文的LLM（很可能是中国的开源或闭源模型） – LLM在”思考”过程中输出的规划文本被直接嵌入到了命令中 – 攻击者没有或忘记清理LLM输出的注释

3.3 非结构化的探索模式

传统攻击脚本通常遵循线性的攻击路径（A→B→C→D）。而LLM代理的探索模式更像是树状的——它会同时尝试多个方向，根据反馈选择最优路径，回溯无效路径，整体表现出一种”弹性探索”的特征。

在Sysdig的记录中，可以看到命令序列中存在明显的”试探→评估→深入”的模式，而非预设脚本的”执行→检查返回码→继续”模式。

3.4 速度与规模的悖论

一方面，某些步骤（如数据库窃取）在两分钟内完成，展现了超越人工操作的速度。另一方面，整个攻击链持续约一小时——这对于人工渗透测试来说可能偏快，但对于传统自动化攻击来说则偏慢。

这种”慢快结合”的模式是LLM代理的典型特征：在需要”思考”和”决策”的步骤上花费时间，在执行步骤上极快。

四、防御视角：如何检测和阻止LLM驱动的攻击

4.1 检测策略

面对LLM驱动的攻击，传统的基于签名的检测方法效果有限。以下是更有效的检测策略：

行为分析（UBA/UEBA）

异常指标：
- 命令执行中包含LLM风格的注释或规划文本
- 短时间内跨多个系统/账户的快速横向移动
- 非标准工具链的使用（如curl/wget进行AWS API调用）
- 命令执行模式呈现"树状探索"而非"线性脚本"特征
- 数据库操作没有预先的Schema发现步骤

蜜罐和欺骗技术

在内部网络中部署蜜罐服务（如假的AWS Secrets Manager端点、假的数据库服务器），可以： – 早期发现攻击者的横向移动 – 通过分析攻击者的交互模式判断是否为LLM驱动 – 收集攻击者使用的凭据和工具信息

云审计日志

AWS CloudTrail等云审计日志在这次攻击的检测中发挥了关键作用：

# CloudTrail可疑活动检测
# 监控异常的Secrets Manager访问模式
source = aws.cloudtrail
| where eventSource = "secretsmanager.amazonaws.com"
| where userIdentity.arn contains compromised_role
| where eventName in ("GetSecretValue", "DescribeSecret")
| where userAgent not in (known_automation_agents)
| project eventTime, sourceIP, eventName, secretName

4.2 阻断策略

减少攻击面

# Marimo安全加固清单
1. 永远不要将Marimo直接暴露在互联网上
2. 使用反向代理（如Nginx）+ 认证网关
3. 网络隔离：Marimo实例不应能访问敏感凭据
4. 升级到Marimo ≥ 0.23.0
5. 使用防火墙限制Marimo的出站连接

凭据保护

# AWS凭据安全最佳实践
1. 使用IAM角色而非长期Access Key
2. 为Secrets Manager访问配置IP白名单
3. 启用CloudTrail日志监控
4. 配置凭据轮换策略
5. 使用临时凭据（STS）替代长期凭据

网络分段

# 纵深防御架构
互联网 → [WAF/反向代理] → Marimo实例（隔离VLAN）
                              ↓（无直接访问）
                          [堡垒机] → [数据库VLAN]
                                       ↓
                                   [PostgreSQL]
                                   （无公网访问）
                                   （仅堡垒机IP可连）

4.3 LLM攻击的特异性防御

由于LLM驱动攻击具有独特特征，可以设计针对性的防御措施：

五、未来展望：AI对抗AI的时代

5.1 攻击成本的根本性变化

这次事件标志着一个重要转折点：攻击的边际成本发生了根本性变化。

当攻击成本从”人力”变成”API调用费”，攻击的经济模型彻底改变了。攻击者不再需要雇佣熟练的渗透测试者，只需要一个初始漏洞利用模块和一个LLM API密钥。

5.2 防御侧的AI应用

好消息是，AI同样可以用于防御。安全团队可以部署LLM代理来：

• 实时分析：解析海量的安全日志，识别传统规则无法捕捉的异常模式
• 自动响应：在检测到攻击时自动隔离受影响的系统
• 威胁狩猎：主动搜索网络中的潜在威胁
• 事件复盘：快速分析安全事件的完整时间线

未来的网络安全对抗，很可能是”AI攻击代理 vs AI防御代理”的局面。

5.3 对中国安全社区的启示

这条中文注释”看还能做什么”的出现，值得中国安全社区深思。它暗示攻击者使用的可能是中国开发的LLM。这提醒我们：

1. LLM安全护栏需要加强：模型提供商需要更好地防止模型被用于恶意目的
2. 使用审计和溯源：需要对LLM API的使用建立更好的审计机制
3. 安全研究先行：在AI安全领域需要更多的前瞻性研究

结语

Marimo CVE-2026-39987 + LLM后渗透攻击案例，是网络安全进入AI时代的一个缩影。攻击者不再需要是技术精湛的黑客——他们只需要知道如何利用一个已知漏洞，然后让AI代理来完成剩下的事情。

对于防御者来说，关键启示是：

1. 基础安全卫生仍然最重要：不要把Marimo暴露在互联网上，不要在笔记本环境中存储AWS长期凭据，做好网络分段
2. 检测能力需要升级：从基于签名的检测转向基于行为的检测，关注LLM代理的独特行为模式
3. 纵深防御不可替代：没有任何单一安全控制是完美的，层层设防才能在某一层被突破后限制损失
4. 拥抱AI防御工具：攻击者已经在使用AI，防御方也需要

当攻击者开始用LLM代理”看还能做什么”的时候，防御方需要更快地问自己同样的问题——但在敌人行动之前找到答案。

本文基于Sysdig公开安全研究报告和The Hacker News报道撰写，仅供技术学习和安全防御参考。文中涉及的技术细节旨在帮助安全团队理解威胁并加强防御，请勿用于非法用途。

参考资料： – Sysdig Blog: “AI Agent at the Wheel: How an Attacker Used LLMs to Move from a CVE to an Internal Database in 4 Pivots” – The Hacker News, May 29, 2026: “Attackers Use LLM Agent for Post-Exploitation After Marimo CVE-2026-39987 Exploit” – CVE-2026-39987: Marimo Pre-Auth RCE