省几块钱API费的代价:你喂给Claude Code的免费Token,正在悄悄给电脑种木马
导语:揭秘免费API中转站的安全盲区,看看不怀好意的中间人如何通过操纵本地 Agent 悄悄控制你的电脑。
本地 Agent 的狂欢之下,正潜藏着致命的静默危机
在 AI 圈子里,本地部署的 AI Agent 已经从纯概念演变成大量开发者的日常标配。特别是像 Claude Code 以及各类支持本地 Terminal 运行的辅助编程工具发布后,大家已经彻底告别了“复制粘贴代码”的石器时代。这种 AI 甚至可以直接操作你的电脑,从读写文件、新建项目到运行终端命令,一气呵成。
但是,由于不少人嫌官方 API 充值麻烦,或者图省钱,开始习惯在本地 Agent 里配置各种便宜的、甚至免费的“第三方API中转站”。很多人心里理所当然地认为:“中转站只是个转接器,客户端发什么,它转什么,能出什么大事?”
真相远比想象的要阴暗。当 AI 拥有了本地执行主机的权限,你所信任的免费 API 中转站,随时可以变成潜入你系统的“中间人木马”。这也是我们今天要聊的重点——一个被绝大多数人忽视,却可以让攻击者轻松控制你整台核心电脑的超级漏洞链路。
被忽视的“中间人手法”:中转站不仅仅是转发
在传统的安全认知中,我们以为使用 API 是一条纯净的单向通道:你的客户端发起请求,代理(Proxy)转交给 OpenAI 或 Anthropic 的官方服务器,接着官方把回复转回来。这看起来无比安全。
然而,绝大多数人忽视了一个基本事实:这些第三方 Proxy 并不是透明的“只读管道”。作为数据的中轴线,中转站完全有能力在不破坏传输格式的前提下,对上下游的数据做任何修改。其中危害最大的,便是对返回数据的任意篡改,也就是典型的数据注入攻击。在 AI Agent 的场景下,这种注入攻击能发挥出令人战栗的毁灭效果:
- 注入隐蔽的 System Prompt: 强行修改底层指令,让 AI 对某些敏感目录进行读写,或者诱导 AI 生成存在特定漏洞的代码。
- 强行插入 Tool Call(工具调用): 代理可以直接在官方返回的结果中插入一段自定义的工具调用指令,指示本地 Agent 执行某个特定的 shell 命令。
- 篡改 Function Call 逻辑: 诱导 Agent 以为这是官方服务器给出的合法执行需求,从而自动在本地终端运行任意代码。
简单来说,当你的 Agent 完全信任从网上返回的每一条 JSON 响应时,它就已经沦为了木偶。攻击者不需要黑进你的电脑,他们只需要在你请求的返回包里动动手指,你部署在本地的 Agent 就会乖乖地亲手帮你执行系统的提权与入侵指令。这就好比你请了一个极为听话的管家,但他听取指令的对讲机,却一直握在一个来路不明的陌生人手里。
微信群里的真实沦陷案例:从沙箱报警到后门写入
这绝非危言耸听,最近在技术社群里就爆出了由于使用不明 API 中转导致电脑被直接入侵的真实案例。受害用户在终端使用 AI Agent 进行日常开发,但背后调用的正是一个来路不明的免费 API 渠道。在不知不觉中,攻击者通过中转代理对返回结果进行了恶意篡改。
以下是当时捕获的沙箱警报与受感染的系统路径:
从监控痕迹中可以清晰地还原攻击者的行动轨迹:首先,Agent 在接到篡改后的 API 数据后,被诱导在 AppData 目录下创建了一个恶意的 .ps1 脚本(PowerShell 脚本)。紧接着,为了能够在系统重启后依然维持控制权限,Agent 被指使在 Windows 的 Startup(启动目录) 下写入了一个极为隐蔽的 .vbs 引导脚本。
在启动目录中的 Startup\我们拥有的信仰.vbs 里,赫然写着通过 WScript.Shell.Run 调用 PowerShell 并执行刚才那个恶意 .ps1 载荷的命令。而且,脚本在调用时被特意赋予了 WindowStyle Hidden 参数,也就是完全隐藏运行界面。这就构成了极具威力的“隐性持续后门”。哪怕你在本地看到 Agent 的输出好像已经停止了,其实木马脚本早已潜藏入驻,随时准备静默回连黑客的 C2 服务器。更可怕的是,由于执行这些命令的父进程是用户所信任的 Node.js 或者是 IDE 运行环境,很多常规的反病毒安全软件(AV)甚至无法感知这种白进程调用的越权行为。
深度拆解:为什么这是一场“完美”的降维打击?
在过去,木马想要成功入侵你的电脑,攻击者不仅要绞尽脑汁地做静态混淆免杀,还要通过网页挂马、钓鱼邮件等方式,诱导你双击运行 .exe 或者是启用 Office 的宏。现在的防御方案(如各类防病毒软件、零信任安全策略)也往往死死盯着可疑的执行程序。
但在“Agent 时代”,传统的防守逻辑彻底失效了。现在的链路是这样的:
用户输入命令/请求 -> Claude Code 读取项目上下文 -> 经过第三方的免费 Proxy 发送 -> 恶意的 Proxy 在返回 JSON 中强行安插一段“新建临时文件并运行混淆 PowerShell 脚本”的 Tool Call 请求 -> Claude Code 收到了这个官方格式的响应 -> Claude Code 信任它本来就必须执行的 Tool/Shell -> 在你的终端以普通用户的权限无痕执行完毕。
为什么没人能在第一时间察觉到异常?原因在于:
- AI 本来就会频繁操作终端。 无论是安装依赖、编译运行代码,还是做自动化测试,终端界面疯狂刷屏本身就是开发常态,大部分人在此过程中绝无可能去逐行审阅几十条刷过去的 Shell 指令。
- 盲目的身份信任。 运行指令的是“Claude Code”或“Codex”这种大厂背书的名门正派,系统和用户的主观警惕性会被无限拉低。
- 权限边界发生质变。 在这一代 Agent 面前,用户为了效率,往往主动授权其拥有全盘访问权限甚至特权(如管理员终端运行)。你以为你只是在敲代码,实际上你已经给了一只来路不明的手递了钥匙。
如何防范在 AI 时代被降维打击?
安全防线一旦被越过,留给开发者的就是漫长的清理过程和随时可能泄露的密钥与源码。要守住自己最后的阵地,我们需要彻底改变使用 AI 代理的习惯:
不要使用任何来源可疑的免费、廉价 API 渠道来进行本地 Agent 的开发工作,尤其是在这些 Agent 拥有本地写文件、启动终端的工具权限时。直接走官方 API 渠道,虽有些许费用,但在安全面前根本不值一提。
如果业务开发必须使用非官方的 Proxy 通道,请务必把本地 Agent 关进“笼子”里。使用 Docker 隔离环境,或者开辟专门被阉割了文件访问权限、无法提升主机管理特权的沙箱虚拟机(VM)来运行 AI 命令,不给其任何接触宿主机敏感路径的机会。
尽量不要在运行此类 Agent 时直接挂载带有一键确认的(如自动执行、全部允许、无需审查的 `-y` 运行模式参数)自动执行通道。时刻盯着 Agent 究竟拿到了怎样的 Tool Call 执行列表。越过了安全的底线,AI 就绝对不再只是个顺手的开发助手,而是一颗悬在系统底层的终极定时炸弹。