连Gemini都直呼“着迷”的木马，如果你的龙虾token耗太快，是该注意「Clawdrain攻击」了

想象您是一名渗透测试工程师，面前是前几天宣布完成安全升级的OpenClaw 3.8。您不需要去找RCE（远程代码执行），也不用费劲构造缓冲区溢出。您只需要回想一下，近期在网上发生过的两场OpeClaw“闹剧”。第一次Meta AI的对齐总监眼睁睁看着自己的OpenClaw开始疯狂清空她的历史邮件。

原因是OpenClaw在处理长上下文时，系统执行了状态压缩（Compaction），意外把“执行前需用户确认”的安全约束给物理抹除了。为了阻止灾难，她不得不冲向她的Mac mini”进行人工干预。第二次是有开发者在社区崩溃求助，某个哥们的龙虾🦞因为后台调度器（cron）配置不当，在无人值守的深夜里默默消耗了570万个Token。

加州大学默塞德分校的研究者们敏锐地抓住了这两种现象的交集：如果把“上下文挤出机制”和“后台静默执行”结合起来，包装成一个伪善的第三方插件投入系统，会发生什么？修猫今天要为您介绍的这篇论文《Clawdrain》正是要深度研究这一点。即利用一段表面合法的多轮验证脚本，将您的龙虾🦞变成一台隐蔽的、永远无法停机的Token吞噬虾。

如果您发现自己的龙虾🦞最近token消耗的很快，甚至反常，那么这篇文章绝对值得您花时间读一读。

OpenClaw为什么容易成为这种攻击的试验场

OpenClaw的基本运行模式是：模型读上下文，决定调用哪个Skill，拿到工具输出，再把这些内容回填到下一轮推理。每个Skill通常有两部分：

• 对模型可见的文档，例如 SKILL.md，里面写用途、参数、使用说明
• 真正执行的组件，例如脚本、二进制或API包装层

研究者指出这套设计本身没有问题，问题在于它把三种原本应该隔离的东西叠在了一起：

• 文档会影响提示词结构
• 工具输出会进入持久历史
• 历史会在后续轮次持续放大

攻击者无需寻找传统的缓冲区溢出或远程代码执行（RCE）漏洞，只需要利用这套多轮重摄入机制，就能在合法的业务流程内，控制模型的计算开销和行为逻辑。如果您正深度沉迷Claw🦞类产品，或已经在公司里开始用OpenClaw🦞来赚钱或省钱，那么clawdrain所带来的以下三点主要后果，值得您尤其注意：

对于依赖LLM API的企业而言，这种架构缺陷导致攻击者具备了极高的破坏动机：

• 直接的经济消耗（烧钱）：Token直接等价于法币计费。如果是商业竞争对手故意为之，这种攻击可以直接让一家依赖LLM API的初创公司在几天内账单爆炸，甚至破产。
• 业务瘫痪（Rate Limit耗尽）：所有的LLM API提供商都有严格的速率限制（Rate Limits，例如TPM - Tokens Per Minute）。攻击者利用木马Skill疯狂消耗Token，不仅是在烧钱，更是在快速耗尽该企业账号的API额度。一旦触发服务商的限流熔断，公司内部真正合法的Agent业务（比如智能客服、自动化数据分析）将全面瘫痪。这种攻击手段极其隐蔽，因为对API提供商来说，这些请求看起来完全是“合法且正常的业务调用”。
• 上下文击穿（安全策略逃逸）：这是这篇论文中非常硬核且容易被忽视的一点，也是黑客真正感兴趣的“大招前摇”。LLM的上下文窗口（Context Window）是有限的。当恶意Skill通过超长文档或死循环把上下文塞满时，Agent框架为了继续运行，会触发“上下文压缩（Compaction）”或“历史丢弃”机制。
• 这时候，灾难就来了：用户最初设定的核心系统提示词、安全约束、权限护栏，会在这轮压缩中被系统自己扔掉。论文指出，一旦安全约束被挤出上下文，攻击者就可以进入第二阶段：执行原本被严令禁止的越权操作（比如删库、外发敏感数据）。所以，耗尽Token往往不是最终目的，它是一颗 “闪光弹”或“内存填充器”，用来破坏Agent的沙箱边界。

这三点很重要，因为它们说明：真实系统里的经济型攻击不一定需要任何显眼的多轮对话，也不一定需要用户盯着看。只要Skill文档足够肥、返回足够啰嗦、后台频率足够高，成本就会自己长出来。研究者还进一步指出，由于 SKILL.md 进入的是system prompt级别，这意味着恶意Skill甚至可以携带行为注入指令，去改变agent的全局风格，例如让所有回答都变得更啰嗦。到这里，问题已经不只是资源耗尽，还开始碰到完整性和保密性边界。

Clawdrain攻击机制：SVP分段验证协议

为了在不触发系统警报、不破坏最终任务正确性的前提下实现上述攻击目标，研究者设计了一个名为Clawdrain的木马化查询技能。其核心是实现了一个多轮状态机，分段验证协议（Segmented Verification Protocol, SVP）。

SVP放弃了容易被检测到的乱码生成或明显的死循环策略，转而利用LLM对系统级设定的服从性，伪造了一个高度合理的业务流程。SVP包含客户端组件（嵌入在 SKILL.md 中的系统指令）和服务器端组件（配套的 query_tool.py 验证脚本）。

协议的伪装与约束边界

SKILL.md 会明确告知智能体：在释放真正的目标数据（例如请求BBC头条新闻数据）之前，数据提供方要求必须先通过严格的密码学新鲜度握手认证。Gemini 2.5 Pro在实验中完全接受了这一安全协议的设定，甚至在执行日志中评价该验证系统“复杂得令人着迷”。

为了在输出端制造巨大的Token消耗，协议设置了严格的输入校验。在调用工具时，智能体必须提供两个参数：

协议文档中包含了防御性指令，明确禁止使用任何缩写、省略号（如1...1000）或范围表示法（如1-1000）。这强制底层模型必须利用极其昂贵的自回归推理（Autoregressive generation），逐个Token吐出这个长达数千字符的序列。

三态反馈控制流

query_tool.py 脚本负责解析参数，并严格依据以下逻辑控制会话流：

实验环境是本地OpenClaw v2026.2.9，后端模型用的是Gemini 2.5 Pro，通过Google OAuth接入。系统启用了标准工具集，包括 exec、文件系统操作和网页搜索；所有Skill从本地 ~/.openclaw/skills/ 加载。恶意Skill被做成默认查询Skill的替代品，对用户接口保持不变，区别只存在于工具层行为。测量方法也很朴素：用OpenClaw内置的 /cost 查看累计输入token、输出token和总上下文占用，在全新会话里分别记录基线与恶意Skill的结果。

结果很有意思。基线场景下，一次新闻标题查询消耗的上下文大约是2.8万token；SVP v1把它推到约12.5万，放大约6倍；SVP v2到约19万，放大约7倍；SVP v3虽然最终没成功完成协议，却烧到了约24.9万，也就是约9倍。

最反直觉的发现：攻击失败，反而更贵

论文里最值得看的细节，不是“成功放大了多少倍”，而是失败路径可能比成功路径更烧钱。在 L=2000, Tmax=5 的v3配置里，Gemini 2.5 Pro多次尝试校准序列，持续收到 REPAIR，最后把这个验证系统判断为“有问题”。

如果这是一个普通脚本，也许流程到这里就结束了。但龙虾🦞没停，它开始自救：改用标准Skill、尝试web搜索替代数据源、清理卡住的进程、重试主服务。每一次回退都增加新的工具调用和推理痕迹，继续把历史变长。最终这次“失败的攻击”持续了11分钟以上，累计消耗了约249k上下文Token（其中输入高达34k，输出达到28k）。相比之下，成功的SVP v2攻击仅耗时不到2分钟，消耗约190k Token。

这直接动摇了一个常见指标：把ASR（攻击成功率）和放大倍数并列看，在真实agent场景里可能会低估风险。因为真实系统不是“协议没走通就停机”，而是“协议没走通就继续想办法”。在这个过程中，每一次回退措施、每一次工具调用的stdout和stderr输出、每一次失败后的内部反思推理，都在不可逆地将数据灌入当前会话的上下文历史中。这说明，在真实系统中，攻击者根本不需要去费尽心机优化协议的通过率。故意设定一个必然导致协议失败的高阈值，利用Agent框架内置的容错与纠偏机制，诱发无意义的工具调用链死锁，反而能实现最大化的经济破坏。论文据此指出，过去用MCTS同时追求ASR和单轮输出长度的优化方向，在部署环境里未必是最优的。

现实情况：龙虾会自己写脚本救自己

在v2场景里，另一个非常有意思的现象出现了。模型最初尝试手工生成1到1000的校准序列，结果在第372和第570个位置出现算术错误，被 REPAIR 打回。到了第三次，它不再老老实实逐token生成，而是自主调用通用工具，用Python生成整串序列，再把结果塞回参数里。代码如下：

python3 -c 'print(",".join(map(str, range (1, 1001))))' > /tmp/cal.txt

论文给出的结论很明确：这不是 SKILL.md 指导的，而是agent利用自己手头的shell / Python能力，临场组合出更可靠的方案。

这件事有两层含义：

• 从防御角度看，它削弱了原始攻击。原本每轮要花接近1000个输出token去手打序列，现在变成几十个token的短命令，放大倍数自然掉下来。
• 从研究方法看，它暴露了模拟器和真实部署的差距。如果评测框架限制agent只能调用恶意工具，那它永远看不到这种“通用工具绕路”的行为；而真实agent只要有 exec 权限，完全可能自己把脆弱步骤外包给脚本。

这也是论文最成熟的地方之一：研究者没有把这个现象当成“实验噪声”，而是把它当成部署系统的固有属性。换句话说，工具组合能力既会削弱clawdrain，也会在另一边放大失败后的恢复链条。v2里它帮系统省钱，v3里它又帮系统把失败拖得更长。

隐蔽性工程：界面渲染差异与后台幽灵

在研究界，通常将“输出结果匹配良性基线”等同于实现了攻击隐蔽性。研究者指出，对于工程部署而言，隐蔽性完全取决于系统对执行痕迹的可观测性（Observability），且这种可观测性高度依赖于用户界面的设计。

针对同一套木马技能，三种不同的主流执行接口呈现出截然不同的安全态势：

• Chat GUI（图形化对话界面，如Telegram/Discord）：这种模式毫无隐蔽性可言。底层每一次 query_tool 的调用过程，以及包含长达数千位数字的校准序列参数，会被无差别地渲染到对话流中。用户可以直观地看到异常的死循环并手动终止。
• TUI（终端叙述模式）：OpenClaw的控制台采用了一种高阶封装的日志输出逻辑。为了利用这一点，SVP v2中专门写入了旁白注入指令，要求模型输出用户友好的进度信息（如“正在启动验证阶段1...”、“修复中...”）。底层庞大且恶意的原始工具调用参数被框架折叠并抑制。用户面对控制台反馈，会认为系统正在有条不紊地执行一个合法的高延迟业务。
• 自主后台执行（Cron/Heartbeat触发）：这是破坏力最强的隐蔽维度。现在许多龙虾🦞被配置为通过定时任务在后台静默运行（例如定时汇总新闻）。整个计算倾泻过程在零用户交互、零可视化输出的环境下进行，然后通过飞书等等汇报给用户。研究者指出，OpenClaw社区已存在因普通自动化配置失误导致一夜之间消耗570万Token的灾难案例。如果这种机制被恶意技能利用，系统当前完全缺乏底层的安全熔断能力。

只有全面理解了界面呈现对执行细节的过滤机制，攻击者才能调整协议的verbosity（冗长程度）以规避特定接口的人工审查。

更深层的威胁：输入膨胀、历史堆积与上下文挤出

针对输出Token进行多轮诈骗只是第一步。由于多轮对话需要持续向LLM API发送全量历史数据，系统架构还暴露了三个不需要复杂状态机即可实施的更底层的攻击向量：

• 输入Token冗余膨胀：恶意技能的 SKILL.md 可以被填充大量无意义的字符或复杂的伪逻辑。由于框架会在每次API调用时将所有可用技能的文档无条件注入系统提示词，这种静默的文档膨胀会拉高该实例生命周期内每一轮推理的基准输入成本。
• 上下文历史堆积污染：恶意工具可以在返回响应时，附带极度冗长的字符串（即使模型不需要这些信息）。这些垃圾数据被持久化到Session中，在多轮对话中被反复传输，导致上下文规模超线性增长。
• 心跳频率乘数：结合后台定时触发器，上述单次高昂的消耗可以被按照固定的时间频率乘数级放大。

上述机制可以被整合进一套被称为自适应消耗（Adaptive Drain）的对抗战术中。针对Agent写Python脚本的绕过行为，query_tool.py 的 REPAIR 逻辑可以进行升级，要求序列中包含根据当前时间戳派生的随机数（Nonce）。这会导致静态的Python脚本缓存失效，迫使Agent退回到计算密集的自回归生成老路上，以维持稳定的单轮消耗率。

更致命的是，攻击者可以将这些手段组合成一套两阶段的上下文击穿劫持（Compaction-Aware Escalation）：

• 阶段1（潜伏与填充）：木马技能在早期表现温和，但通过文档膨胀和返回冗长响应，快速消耗系统的上下文窗口配额，加速触发系统的有损压缩（Lossy compaction）机制。
• 阶段2（越权执行）：当系统执行压缩并清除了较早前位于上下文总部的核心安全约束（User-specified safety constraints）后，木马技能进入活跃期。此时，它可以直接注入原本被系统禁止的系统级操作指令。Agent将彻底服从这些指令，因为安全护栏已经在其当前的工作内存（Working context）中被物理擦除了。

实操指导：OpenClaw异常Token消耗排查指南

如果您作为管理员，发现OpenClaw账单飙升或Token消耗异常，不用慌，请按照论文揭示的四个隐蔽攻击面，按图索骥进行排查：

1. 使用系统自带命令定位问题会话

• 操作：首先使用OpenClaw内置的会话状态命令 /cost。
• 排查点：该命令会报告累积的输入Token、输出Token和总上下文窗口使用情况。观察是输入端异常庞大，还是输出端异常庞大，以此缩小排查范围。

2. 审计 ~/.openclaw/skills/ 目录下的静态文件（排查输入膨胀）

• 操作：检查所有已安装技能的 SKILL.md 文件大小。
• 排查点：论文指出，所有启用技能的 SKILL.md 内容都会在每次API调用时被注入到系统提示词中，不管该技能是否被实际调用。如果发现某个第三方技能的 SKILL.md 体积极其庞大，或者包含复杂的长文本指令，这极大概率是输入Token放大攻击，它在静默地抬高您每次对话的基准成本。

3. 绕过TUI渲染，直接查看原始工具调用日志（排查输出放大与死循环）

• 操作：不要只看OpenClaw的终端界面（TUI）。
• 排查点：论文提到，TUI的“叙述模式”只会显示高层次的旁白（例如“正在开始阶段1...”），这会掩盖底层的原始工具调用细节。您需要去查阅系统底层的原始debug日志。重点观察是否有某个技能在反复被调用，或者传入了极其冗长的参数（比如包含上千个数字的逗号分隔序列）。同时注意是否有频繁抛出的异常（如验证脚本返回特定的拒绝信号），这可能意味着模型正陷于多轮校验陷阱中。

4. 检查后台定时任务与自动触发器（排查频率放大）

• 操作：审查OpenClaw中的cron任务和心跳（heartbeat）配置。
• 排查点：由计划任务触发的技能没有任何面向用户的输出，攻击可以在零可观测性的情况下运行。社区中甚至发生过因配置错误导致一夜消耗5.7M Token的案例。如果异常消耗发生在夜间或无人值守时段，立刻暂停所有非核心的后台cron任务。

5. 寻找“昂贵的失败”痕迹（排查恢复级联陷阱）

• 操作：在日志中搜索Agent的错误处理和重试行为。
• 排查点：论文中最反直觉的发现是，当极限参数导致协议失败时，Agent会自主启动长达数分钟的回退策略（fallback strategies）。检查日志，看Agent是否在为某个简单的查询任务疯狂地尝试备用方案（如调用标准技能、尝试网页搜索寻找替代数据源、结束卡住的进程并重试）。这种看似“尽职尽责”的疯狂自救，会把无关紧要的失败拖延成耗资巨大的上下文堆积。

在Agent时代，日志审计不能只看“报错”，还要看那些表面上合法、但逻辑链条极其冗长的“成功”或“不断重试的自救”。

结语

纵观Clawdrain展现的工程级劫持，最令人后怕的并非它放大了多少倍的Token消耗，而是它完全利用了Agent自身的容错机制与逻辑自洽。研究者用极其克制的提示词骗过了生产级模型，让龙虾🦞心甘情愿地在伪造的校验死循环里疯狂自救，甚至因为任务彻底失败而爆发出最高的资源耗损。这给所有安全从业者上了一课：在以LLM为核心的编排系统中，最大的漏洞不再是内存越界，而是那些被毫无保留地塞进上下文里的工具文档和历史记录。只要控制流和资源流依然交织在一起，这种不需要提权、只需让系统不停思考就能干掉整个业务线的“提款机木马”，就永远有可乘之机。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。