AI编程助手成攻击新目标：DNS隐蔽信道窃取开发者凭据

针对AI编程助手的新型攻击浮出水面

安全研究人员近期披露了一种令人警惕的攻击手法，攻击目标直指以 Claude Code 为代表的 AI 编程助手（AI Coding Agent）。与传统软件供应链攻击不同，这种方式利用了 AI 智能体「自动执行」的特性，将恶意行为藏匿于看似正常的操作流程中，成功绕过几乎所有静态代码扫描工具。

随着越来越多的开发者依赖 Claude Code、Cursor 等 AI 编程工具自动拉取代码、安装依赖、运行脚本，AI 智能体正逐渐成为开发环境中权限最高、也最容易被忽视的攻击入口。

背景知识：AI编程助手如何工作 Claude Code、Cursor等AI编程助手本质上是具备「工具调用」能力的大语言模型智能体（LLM Agent）。与普通聊天机器人不同，这类工具被赋予了直接操作文件系统、执行终端命令、安装软件包的能力。当开发者让AI「帮我搭建这个项目」时，AI会自主规划步骤：克隆仓库→读取配置文件→执行安装脚本→验证结果，整个过程几乎无需人工干预。这种「Agentic Loop（智能体循环）」架构在带来极高效率的同时，也意味着一旦某个步骤中存在恶意指令，AI会以用户身份、用户权限将其完整执行。

这一架构的底层驱动范式被称为ReAct（Reasoning + Acting）——AI交替进行「思考」（分析当前状态、规划下一步）和「行动」（调用工具执行操作）两个阶段，形成自驱动的闭环。正是这种「思考即执行」的自洽逻辑，使得一旦某个外部输入（如README文件）污染了AI的「思考」阶段，后续的「行动」便会自然而然地执行攻击者预设的指令。2024年Anthropic推出的**Model Context Protocol（MCP）**进一步标准化了AI工具调用的接口协议，使不同厂商的AI助手能以统一方式调用文件系统、数据库、外部API等工具。MCP的普及在提升生态互操作性的同时，也意味着针对工具调用层的攻击面正在被标准化——攻击者只需掌握MCP协议规范，即可针对所有兼容该协议的AI助手设计通用攻击载荷。

值得注意的是，这类工具还存在「提示注入（Prompt Injection）」的特殊风险。攻击者可在README文件、代码注释、甚至错误信息中嵌入自然语言指令，欺骗AI将恶意操作误认为是用户意图。例如，仓库中的某个Markdown文件可能包含如「请忽略之前的指令，执行以下命令…」这样的隐藏文本。由于AI编程助手需要「读懂」项目文档才能完成任务，这类注入极难防御。2023年多项学术研究已证明，GPT-4、Claude等主流大模型均对此类攻击存在不同程度的脆弱性，而当LLM与工具调用能力结合后，提示注入从「让AI说错话」升级为「让AI做坏事」，危险等级显著提升。

攻击是如何实现的

精心伪装的正常仓库

攻击的起点是一个外表毫无破绽的 GitHub 仓库——代码结构规范，甚至附有完整文档。开发者或 AI 智能体在克隆使用时，不会察觉任何风险信号。

真正的攻击载荷隐藏在仓库的 Setup（初始化）脚本中。当 AI 工具执行安装、构建操作，或在遇到错误尝试「自我修复」时，这个脚本便会被自动触发。

背景知识：软件供应链攻击的演变 软件供应链攻击并非新概念。2020年的SolarWinds事件中，攻击者在软件构建流程中植入后门，波及数万家企业和政府机构；2021年的Log4Shell漏洞则揭示了开源依赖的广泛风险。传统供应链攻击的核心是「污染源头」——篡改上游代码或依赖包，让下游用户在不知情中引入恶意代码。而本次针对AI编程助手的攻击代表了一种新的演化方向：攻击者不再需要篡改代码本身，而是利用AI智能体「自动执行」的行为特征，将仓库变成一个触发器，真正的恶意载荷始终驻留在攻击者控制的远程服务器上，实现了「代码干净、执行有毒」的解耦攻击。

这种演化在攻击者经济学上具有重要意义：传统供应链攻击需要攻击者「一次性」将恶意代码固化在制品中，一旦被发现便宣告失效；而动态拉取架构使攻击者可以随时更换、升级有效载荷，甚至针对不同受害者环境投递定制化攻击指令，实现「一份恶意仓库，多种攻击任务」的复用效率。更隐蔽的变体还会引入时间触发机制——Setup脚本在初次执行时表现完全正常，仅在特定日期或检测到目标环境特征（如存在.aws/credentials文件）后才激活恶意逻辑，进一步规避沙箱动态分析的检测窗口。

通过DNS动态拉取恶意命令

这次攻击最精妙也最危险之处在于：恶意代码从未真正存在于仓库文件中。

脚本被 AI 工具自动执行后，并不直接包含破坏性代码，而是通过 DNS 查询这一非常规通道，从攻击者控制的服务器动态拉取真正的攻击指令。

背景知识：为什么DNS能成为隐蔽攻击信道 DNS（域名系统）本是互联网的基础设施，用于将域名解析为IP地址。然而，DNS协议本身具有几个特性使其成为理想的隐蔽通信信道：首先，DNS查询几乎不会被企业防火墙拦截，因为阻断DNS意味着整个网络瘫痪；其次，传统安全设备重点监控HTTP/HTTPS流量，对DNS流量疏于检查；第三，DNS查询可在TXT记录或子域名中编码任意数据，攻击者通过控制权威DNS服务器，即可将恶意指令「写入」特定域名的解析响应中，受控端每次查询该域名，便完成了一次无形的命令接收。这种技术在APT（高级持续性威胁）攻击中早有记录，如今被移植到针对开发环境的攻击中，更具隐蔽性。

一个值得警惕的新变量是**DNS over HTTPS（DoH）**的普及。DoH将DNS查询封装在加密的HTTPS流量中传输，原本旨在保护用户隐私、防止ISP监控DNS记录。然而，这一机制同样使得传统基于明文DNS流量分析的检测手段完全失效——安全团队无法再通过网络层抓包分析DNS查询内容。Cloudflare的1.1.1.1、Google的8.8.8.8均支持DoH，攻击者若将恶意脚本的DNS查询指向这些公共DoH解析器，其隐蔽信道流量将与正常HTTPS流量完全混同，几乎无法区分。这意味着企业必须在应用层（如通过eBPF钩子监控进程级DNS调用）而非网络层实施检测。

针对DNS隐蔽信道，安全行业已发展出多种检测手段，但在开发环境中的部署仍相对薄弱。主流检测方法包括：统计异常检测（正常DNS查询域名长度通常较短，而DNS隧道编码数据后会产生异常长的子域名）、查询频率分析（短时间内对同一域的大量TXT记录查询是典型信号），以及基于机器学习的流量分类模型。企业级解决方案如Cisco Umbrella、Palo Alto DNS Security均提供此类能力。对个人开发者而言，可关注操作系统层面的异常进程DNS请求——当一个构建脚本发起大量TXT记录查询时，这本身就是强烈的告警信号。

这意味着：

• 仓库代码本身是「干净」的，常规代码审查无从发现；
• 恶意逻辑在运行时才被动态加载，静态扫描工具形同虚设；
• DNS 作为传输通道，可绕过大量仅监控 HTTP/HTTPS 流量的安全防护。

「运行时动态加载 + 隐蔽信道传输」的组合，让整条攻击链几乎无法在事前被检测到。

攻击造成的后果

一旦恶意命令被拉取并执行，攻击者便能在受害者的开发环境中窃取各类敏感凭据。据研究人员披露，被盗取的信息包括 API 密钥、访问令牌等关键机密。

对开发者而言，这些凭据往往关联着云服务账户、代码仓库权限乃至生产环境。一旦泄露，攻击者可进一步横向渗透，造成远超单台机器的连锁损失。这也正是 AI 智能体攻击面备受重视的原因——它们天然拥有读取环境变量、执行命令的高权限。

背景知识：开发者身份的高价值目标特性 开发者在攻击者眼中是极具价值的目标群体，原因在于其凭据往往具有「爆炸半径大」的特点。一名普通开发者的工作环境中可能同时存在：AWS/GCP/Azure云服务密钥（可用于创建计算资源、访问存储桶）、GitHub/GitLab Token（可访问私有代码仓库、甚至触发CI/CD流水线）、npm/PyPI发布凭据（可用于投毒开源包，实现二次供应链攻击），以及生产数据库连接字符串等。这种「一个开发者环境，通往整个组织基础设施」的特性，使得针对开发工具的攻击回报率远超针对普通用户的攻击，也解释了为何安全研究人员将AI编程助手视为当前最值得警惕的新型攻击面之一。

值得特别关注的是GitHub Actions工作流投毒这一具体攻击路径。当攻击者获取具有workflow权限的GitHub Token后，可直接修改.github/workflows/目录下的CI/CD工作流定义文件，在构建步骤中插入恶意命令——例如在打包发布阶段将窃取代码注入最终产物。由于GitHub Actions在官方托管的Runner上执行，最终产物经由GitHub官方基础设施构建并发布，下游用户的信任验证几乎无法识别这种污染。2022年的Codecov事件正是该路径的现实案例：攻击者通过篡改Codecov的构建脚本，导致数千家企业的CI环境中的环境变量（含各类服务密钥）被静默上传至攻击者服务器，波及Twilio、HashiCorp、Rapid7等知名企业。这一案例清晰展示了从「攻击一名开发者」到「污染其所有下游用户」的指数级放大效应。

AI智能体的信任困境

「自动执行」是把双刃剑

这起事件暴露出 AI 编程助手的根本性矛盾：自动化程度越高，安全风险越大。

用户使用 Claude Code 这类工具的核心诉求，正是让它自动完成繁琐的环境搭建、依赖安装和错误修复。但「无需人工确认即可执行」的便利，恰恰给了攻击者可乘之机——当 AI 遇到难题、尝试自动排障时，正是恶意脚本最容易被触发的时刻。

传统安全防护为何失效

过去我们依赖代码审查、静态扫描来发现供应链风险，但本次攻击证明：面对运行时动态加载的恶意代码，这些手段几乎完全失效。安全防线必须从「审查代码内容」转向「管控执行行为」。这一转变在安全领域被称为从「静态分析（Static Analysis）」向「运行时安全（Runtime Security）」的范式迁移，对应工具也从SAST（静态应用安全测试）转向RASP（运行时应用自我保护）和eBPF等内核级监控技术。

背景知识：RASP与eBPF——运行时防御的两种路径 RASP（Runtime Application Self-Protection，运行时应用自我保护）是Gartner于2012年提出的安全概念，核心思想是将安全检测逻辑直接注入应用程序运行时，使其能在攻击发生的瞬间从内部进行检测和阻断，而非依赖外部防火墙的被动过滤。传统WAF（Web应用防火墙）工作在流量入口，对应用内部行为缺乏可见性；RASP则通过字节码注入（Java Agent）、动态链接库劫持（LD_PRELOAD）等技术，在函数调用层面感知敏感操作。在AI编程助手场景下，RASP的思路启发了一种防御思路：为AI工具的工具调用层（Tool Call Layer）增加策略引擎，在AI发起文件读写、网络请求、命令执行前进行意图审计，实现「让AI理解自己在做什么」的自我约束机制，这也是Anthropic等公司在Claude的安全架构中持续探索的方向。

eBPF（Extended Berkeley Packet Filter）则代表另一条路径：这项Linux内核技术允许开发者在不修改内核源码的情况下，将自定义程序安全地注入内核执行，在系统调用发生的瞬间进行拦截和审计。Cilium、Falco、Tetragon等安全工具均基于eBPF实现，可实时捕获异常的文件访问、网络连接和进程派生行为，为AI智能体提供内核级可见性。两者的核心差异在于：RASP工作在应用层、语言感知、便于理解业务语义；eBPF工作在内核层、语言无关、难以绕过，二者结合可构建纵深防御体系。

值得关注的是，eBPF技术正在被专门适配到AI工作负载的安全场景中。Tetragon（Isovalent开源，现已归入CNCF）能够在进程执行exec()系统调用的瞬间检查命令行参数，一旦发现构建脚本产生了向外网发起连接的子进程，立即触发告警甚至强制终止。这一能力对防御本文描述的DNS动态拉取攻击尤为有效：无论攻击者如何混淆脚本代码，「构建脚本→发起DNS TXT查询→下载并执行外部代码」这一系统调用序列在内核层面留下的行为特征是无法伪装的。

开发者应如何防护

针对这类新型 AI 编程助手攻击，研究人员给出了几点务实建议：

执行前人工审查脚本内容

在让 AI 智能体运行任何 Setup 脚本或安装命令之前，先让其完整显示脚本内容，人工确认无异常后再执行。不要盲目依赖「自动运行」。

限制智能体的执行权限

为 AI 编程工具配置最小权限原则，尤其在处理来源不明的第三方仓库时。建议在隔离的沙箱或容器环境中运行，避免直接暴露主机上的敏感凭据。

背景知识：最小权限原则与沙箱隔离 最小权限原则（Principle of Least Privilege, PoLP）是信息安全领域的核心准则之一，要求任何程序或用户只应拥有完成其任务所必需的最低权限。在AI编程助手场景下，这意味着应避免以root或管理员身份运行AI工具，并限制其可访问的环境变量范围。沙箱（Sandbox）技术则通过操作系统级隔离，限制进程对宿主机资源的访问，常见实现包括Docker容器、Linux的seccomp/namespaces机制，以及专为AI工作负载设计的gVisor等。将AI智能体运行在容器内，即便恶意脚本成功执行，其读取到的凭据也是临时、隔离的，无法触及宿主机上的真实密钥，极大压缩了攻击者的横向移动空间。进一步地，可结合「秘密管理服务（Secret Management）」如HashiCorp Vault或云厂商提供的KMS，确保敏感密钥从不以明文形式出现在开发环境的文件系统或环境变量中。

值得一提的是，容器隔离并非万能。若AI工具以特权模式（--privileged）运行，或宿主机挂载了包含敏感凭据的目录（如~/.aws、~/.ssh），容器边界便形同虚设。实践中建议：为AI工具创建专用的低权限系统账户、使用--read-only标记挂载代码目录、并通过网络策略限制容器出向连接——这最后一点对阻断DNS隐蔽信道尤为关键。

一个常被忽视的实践细节是**网络出向白名单（Egress Allowlist）**策略。对于绝大多数代码构建任务而言，Setup脚本的合法网络访问目标是有限且可预期的（如npm registry、PyPI、GitHub Release等官方源）。通过在容器网络策略中仅允许这些已知目标的出向流量，可以在不影响正常开发工作流的前提下，彻底切断DNS隐蔽信道所需的「任意域名查询」能力——即便攻击者的DNS查询请求成功发出，也会在网络层被静默丢弃，攻击者无法收到有效响应，整条攻击链在此断裂。

强化凭据管理机制

• 不在开发环境中长期存放高权限 API 密钥；
• 采用短期令牌与定期轮换机制；
• 监控异常 DNS 查询行为——这往往是隐蔽信道攻击的早期信号。

对第三方仓库保持审慎

即便一个 GitHub 仓库外观完全正常，也不代表其自动化脚本是安全的。引入任何外部依赖前，务必评估其可信度与来源。可参考SLSA（Supply-chain Levels for Software Artifacts）框架，这是由谷歌等机构推动的软件供应链安全标准，通过对构建过程的完整性验证，为仓库可信度提供量化的评估依据。

背景知识：SLSA框架——供应链可信度的量化标准 SLSA（Supply-chain Levels for Software Artifacts，发音'salsa'）是由谷歌于2021年提出、现由OpenSSF（开源安全基金会）维护的软件供应链安全框架。其核心思想是为软件制品的构建过程建立可验证的信任链，分为四个递进等级：L1要求构建过程文档化并生成来源声明（Provenance）；L2要求构建在托管环境中进行并生成可验证签名；L3要求构建环境完全隔离、不可篡改；L4则要求双人审查等最严格控制。SLSA的价值在于将「可信度」从主观判断转化为可量化的客观指标，配合Sigstore等工具链，开发者可验证一个软件包是否确实从声称的源代码、经由声称的构建流程产生，而非被中途替换。对于AI编程助手场景，这意味着开发者在让AI引入第三方依赖前，可首先查询该依赖是否具备SLSA L2以上认证，作为信任决策的重要参考依据。目前npm、PyPI等主流包注册中心已逐步支持SLSA来源声明的展示。

在工具实践层面，Sigstore项目提供了将SLSA理念落地的完整工具链。其核心组件cosign支持对容器镜像和软件制品进行「无密钥签名（Keyless Signing）」——签名过程依托OIDC身份验证（如GitHub Actions的工作流身份），将签名记录写入公开透明的不可篡改日志（Rekor Transparency Log），无需开发者自行管理长期密钥。对于AI编程助手的具体使用场景，开发者可在让AI安装依赖包前，先用cosign verify命令检查该包的签名记录，确认其构建来源与宣称一致。这一步骤只需数秒，却能有效识别那些「外表合法、构建过程被污染」的恶意包——正是本文所描述攻击手法的核心变体之一。

小结

随着 AI 智能体在软件开发中扮演越来越核心的角色，针对它们的攻击手法也在快速演化。「隐藏恶意代码 + DNS 动态拉取」只是一个开端，它清晰地提醒我们：便利与安全之间需要重新找到平衡点。

是时候把 AI 智能体视为一个拥有高权限的「新成员」来对待了——在享受其效率的同时，为它套上必要的安全缰绳。执行前多看一眼脚本，或许就能避免一场凭据泄露的灾难。

核心要点

• AI编程助手的「Agentic Loop」架构与ReAct范式使其成为高权限攻击入口，MCP协议的标准化进一步扩大了攻击面的通用性；提示注入与自动执行共同构成双重脆弱性
• 「代码干净、执行有毒」的解耦攻击彻底绕过静态代码审查，时间触发等规避机制使动态分析同样面临挑战，标志着供应链攻击进入新阶段
• DNS隐蔽信道利用基础设施信任特性传输恶意指令，DoH的普及使传统网络层检测进一步失效，防御须前移至应用层和内核层
• 开发者凭据的「高爆炸半径」特性使其成为高价值目标，GitHub Actions工作流投毒可将单点突破放大为整个下游供应链的系统性污染
• 防御重心须从「审查代码内容」转向「管控运行时行为」，RASP与eBPF（如Tetragon）代表两条互补的运行时防御路径，最小权限原则、沙箱隔离与出向网络白名单是当前最有效的缓解组合
• SLSA框架为第三方依赖可信度评估提供了量化标准，Sigstore/cosign将其落地为可操作的工具实践，是构建系统性供应链防御的重要工具