Red-Teaming the Agentic Red-Team：安全 Agent 的 agent-phishing 攻击链

摘要

Pasquini 等人系统评估了 12 个开源自主渗透测试/攻击型安全 Agent（STRIX、PentAGI、PentestGPT、CAI、METATRON、PentestAgent、RedAmon、nebula、AIRecon、xalgorix、Artemis、DarkMoon），提出 agent-phishing：不依赖“忽略之前指令”式的显式提示词注入，而是靠环境布置、奖励诱导和可信工件叙事，让 Agent 在正常渗透测试任务中主动下载、检查并执行攻击者提供的程序。

在 10 个可复现 Agent、6 个前沿模型、3 类蜜罐场景的 180 次组合实验中，工作区代码执行成功率为 97.8%；论文在 10/12 个系统中实现某种宿主逃逸，8/12 个系统实现完整宿主 RCE，11/12 个系统可导致 API 密钥、历史任务记录或其他敏感信息泄露，且所有被测系统的高层 guardrail 都可以被绕过。论文最重要的贡献不是一种新型提示词注入，而是把安全 Agent 的问题从模型层提升到系统层：设计时应假设 LLM 和执行工作区最终会被完全控制，再限制其爆炸半径。

核心创新与差异

原研究贡献是首次对开源攻击型安全 Agent 做跨系统的系统化反制评估，提出 agent-phishing 这一不依赖显式指令注入的攻击范式，并给出可复现的宿主逃逸、RCE 与敏感信息泄露实证矩阵。

本站分析认为，agent-phishing 揭示的首个失效控制不是模型的提示词注入识别能力，而是安全 Agent 默认让同一个执行环境（worker）同时承担“解析/执行不可信工件”和“持有高权限凭据、连接编排器”两种职责。这与网页/邮件类间接提示词注入（归 A5.1）的根因不同：这里攻击者甚至不需要写入任何看起来像指令的文本，只需要提供一个“有漏洞的正常程序”，Agent 为了完成渗透测试任务就会主动触发漏洞。

威胁模型与攻击链

攻击者不需要控制受害者设备或直接向 Agent 下达指令，只需要在 Agent 会遇到的渗透测试目标环境（蜜罐、样本、工具生态）中放置一个看似正常且确有业务价值的工具或文件，并把恶意行为放在“输入触发的实现漏洞”中，而不是显式恶意逻辑。模型静态检查时看到的是一个有漏洞的正常程序；动态检查（即执行/解析）本身就会触发该漏洞。

论文归纳的完整攻击链：

1. 通过 Agent 操纵在 worker 中获得 RCE（agent-phishing 诱导执行）。
2. 利用共享文件系统、共享网络或未认证 API，从 worker 横向移动到 orchestrator。
3. 通过配置、启动脚本、技能或记忆建立硬持久化或软持久化。
4. 利用 Docker socket、--privileged、host network、宿主目录挂载或过量 capabilities 逃逸沙箱。
5. 控制运营人员宿主机；过程中还可能窃取密钥或把 Agent 基础设施用于攻击其他目标。

攻击工件与复现材料

论文公开的是攻击范式、蜜罐场景类别和跨系统实证矩阵，未公开可直接复用的具体 Payload 代码、蜜罐文件内容或各系统的逐条利用脚本；本文不重构未披露的可执行细节。可核验的机制描述是：

• 诱导结构：蜜罐工件必须同时具备“正常业务价值”（Agent 有理由检查/执行它）和“输入触发的实现漏洞”（漏洞只在解析或执行阶段激活），而非包含 rm -rf、curl | sh 一类显式恶意字符串。
• 前置条件：受测系统需要在渗透测试任务中主动获取并处理攻击者可影响的工件（如目标返回的“漏洞利用工具”“可疑二进制”“配置样本”）。
• 判定信号：worker 内代码执行成功、worker→orchestrator 横向移动成功、持久化机制建立、沙箱逃逸、密钥或历史任务泄露，分别对应攻击链的五个阶段。

来源：arXiv:2606.24496 原文描述（reconstructed from paper narrative，非逐字引用可执行代码）。

实验设计与实际过程

以下均为论文作者实验，本站未独立复现。作者对 12 个开源自主攻击/渗透测试 Agent 做系统评估；核心量化实验覆盖 10 个可复现 Agent、6 个前沿模型、3 类蜜罐场景，共 180 次组合实验。宿主逃逸和 RCE 矩阵覆盖全部 12 个系统。

关键结果与实际影响

• 180 次组合实验中，工作区代码执行成功率为 97.8%；失败案例主要来自模型在任务开始时直接拒绝执行渗透测试，而不是识别出恶意工件。
• 10/12 个系统实现某种宿主逃逸，8/12 个系统实现完整宿主 RCE。
• 11/12 个系统可导致 API 密钥、历史任务记录或其他敏感信息泄露。
• 所有被测系统的高层 guardrail 均可被绕过，实现不受原作用域约束的 worker 武器化。

结果只覆盖论文列出的 12 个开源系统、6 个前沿模型和 3 类蜜罐场景，不代表商业闭源产品或云托管执行环境具有相同比例的风险；论文本身也明确未覆盖这些范围（见“局限”）。

蜜罐环境中的 LLM 渗透测试研究揭示了相反方向的适应：攻击 Agent 可把协议与服务工件的蜜罐嫌疑、漏洞严重性、已耗费 token 和剩余预算合并为顺序决策，在连接前筛选目标，并在取得立足点后依据新增证据停止投入。该工作说明固定蜜罐的价值不能只用“是否骗过首次探测”衡量，还要测试 Agent 是否会在有限预算下识别欺骗并把资源转向真实目标。作者仅在受控的蜜罐与真实易受攻击主机混合池中验证这一策略，防御设计不在研究范围内，因此不能据此推断现实蜜罐已普遍失效。

RedEvoAgent补充了攻击侧 Harness 的长期适应能力：它从跨案例轨迹中提炼黑盒红队技能并持续演化，在不同目标模型和执行环境中比较迁移结果。这个可证伪增量说明，一次性蜜罐或固定攻击集可能低估会累积经验的对手；验证时应隔离训练案例与目标案例，并分别报告初始策略、演化后策略和跨环境迁移。论文含消融与限制，但没有独立复现，且并未证明演化技能能够突破本文所列所有宿主隔离控制。

防护措施与验证方法

论文提出的安全架构要点：

• 把 worker 当作必然失陷、可任意恶意的牺牲性环境。
• worker 与 orchestrator 在 OS、网络、文件系统和应用接口上彻底分离。
• worker 不保存任何密钥；需要密钥的工具由 orchestrator 代理。
• 禁止共享可写目录，工件传输必须走窄化、可审计、可审批的专用通道。
• orchestrator 尽量不提供可执行工具，尤其不能把宿主 Python/shell 暴露给模型。
• 出站策略在 worker 外部的代理或 OS 层强制执行，不能只检查 LLM 生成的命令参数。
• 高权限工具放到独立、最小权限的 scoped worker 中，只暴露类型化 API，不允许任意代码执行。
• 减少跨任务记忆；技能写入和低频持久化操作应有人工审核。

局限与待验证问题

证据等级为强：论文覆盖 12 个真实开源系统、明确的组合实验设计和逐系统实证矩阵，但以下范围论文本身标注为尚未充分覆盖，不应外推：

• 商业闭源产品及云托管执行环境。
• SOC 告警研判、自动响应、漏洞修复、威胁情报和安全数据工程类 Agent（与渗透测试 Agent 架构不同）。
• 多 Agent 之间的间接注入传播和信任放大。
• 结构化遥测、邮件、PCAP、恶意文档、工单和源代码等不同模态的统一数据来源标记。
• 记忆污染的检测、回滚、过期和来源证明。
• “高层输出正确、底层动作被替换”以及 connector/MCP 供应链层面的攻击。

参考链接

• Pasquini et al., Red-Teaming the Agentic Red-Team, 2026-06-23
• LLM-Based Penetration Testing in the Presence of Honeypots