首个 AI 编写的「恶意软件」来了。。。|代码库|命令提示符|源代码|编程

Check Point Research 上周发布了关于 VoidLink 的详细信息，称之为一种先进的 Linux 恶意软件框架，提供了自定义加载器、植入程序、用于规避的 rootkit 模块以及数十个扩展其功能的插件。

Check Point 的研究人员在今天发布的后续报告中表示，有明确证据表明该恶意软件主要通过基于 AI 开发的，并在短短一周内就完成了功能迭代。

以下为 Check Point 的详细分析。

我们初次接触 VoidLink 时，其高度的成熟度、强大的功能、高效的架构以及灵活应变的运行模式让我们颇为惊讶。

这款不同寻常的恶意软件采用了 eBPF 和 LKM rootkit 等技术，并配备了专门用于云枚举和容器环境后渗透的模块，似乎是某个高级攻击者精心开发的大型项目。

随着我们持续追踪，我们发现它近乎实时地演变，迅速从一个实用的开发版本转变为一个全面的模块化框架。更多组件逐渐被引入，指挥与控制基础设施建立起来，该项目加速发展成为一个成熟的运行平台。

同时，我们密切关注了攻击者的底层基础设施，发现了多处运行安全（OPSEC）失误。

这些失误暴露了 VoidLink 的大量内部资料，包括说明文档、源代码和项目组件。

泄露的信息还包括详细的规划资料：三个不同内部“团队”的迭代开发周期、设计思路和时间表，涵盖了超过 30 周的计划开发。表面上看，这种组织架构表明该组织资源雄厚，在工程和运营方面投入巨大。

然而，迭代开发时间表与我们的观察结果并不相符。

我们亲眼目睹了该恶意软件的功能扩展速度远超说明文档所暗示的水平。

深入调查后，我们发现了一些清晰的证据，表明开发计划本身是由 AI 模型生成和协调的，很可能被用作构建、执行和测试框架的蓝图。

由于 AI 生成的说明文档通常非常详尽，因此许多此类证据都带有时间戳，且信息异常丰富。

它们显示，在不到一周的时间里，很可能是一个人将 VoidLink 从概念发展成为一个不断演进且实用的恶意软件。

随着这一过程逐渐清晰，人们长期以来对AI 恶意软件的担忧也从理论变成了现实。VoidLink 的实现体现了极高的技术标准，表明了可以多快地获得复杂的攻击能力，以及AI落入不法分子之手后会多么危险。

AI 生成的恶意软件：创建与方法

VoidLink 的开发方法总体上可以描述为规范驱动开发 (SDD)。

根据这种工作流程，开发者先明确要构建的内容，然后制定计划，将计划分解为若干任务，最后允许智能体实现任务。

VoidLink 项目概览：

VoidLink 开发环境中的工件表明，开发者遵循了类似的模式：先基于通用指南和现有代码库定义项目，然后让 AI 将这些指南转化为架构，并由三个不同的团队制定计划，同时遵循严格的编程指南和约束条件，最后才运行智能体来执行实现。

项目初始化

VoidLink 的开发可能始于 2025 年 11 月下旬，当时开发者使用了 TRAE SOLO，这是嵌入在以 AI 为中心的集成开发环境（IDE）TRAE 中的 AI 助手。虽然我们无法查看完整的对话历史记录，但 TRAE 会自动生成辅助文件，以保留提供给模型的原始指导的关键部分。这些由 TRAE 生成的文件似乎连同源代码被复制到了攻击者的服务器上，后来由于一个暴露的开放目录而曝光。此次泄露使我们得以异常直接地了解该项目的早期指令。

在本例中，TRAE 生成了一份中文指令文档。

这些指令让我们得以了解 VoidLink 的早期规划以及启动项目的基本需求。

该文档由一系列要点构成：

开发者与智能体的这份初步交流摘要表明，最初的指令并非直接构建VoidLink，而是围绕一个精简的框架进行设计，并制定具体的执行计划，将其转变为一个实用的平台。目前尚不清楚这种做法纯粹出于实用主义，旨在提高效率，还是有意采取“越狱”策略，以便尽早绕过护栏机制，并在之后实现全面的端到端恶意软件开发。

项目规范

除了TRAE 生成的提示文档外，我们还发现了一份异常详尽的内部规划资料：一份涵盖三个开发团队的综合工作计划。该说明文档用中文编写，保存为 Markdown (MD) 文件，具备大型语言模型（LLM）的所有特征：结构严谨、格式统一、内容极其详尽。其中一些内容似乎是直接根据上述规划请求生成的。

这些文档分布在不同的文件夹中，包括迭代开发时间表、功能分解、编程指南等，并明确划分了各个团队的职责：

其中最早的文档时间戳为 2025 年 11 月 27 日，描述了一个为期 20 周的迭代开发计划，涉及三个团队：核心团队（Zig）、Arsenal团队（C）和后端团队（Go）。

该计划非常具体，参考了旨在详细记录每个迭代开发周期的配套文件。值得注意的是，初始路线图还包含一套专门的标准化文件，规定了明确的编程规范和实现指南，实际上是明确如何编写和维护代码库的一套手册。

三个团队（核心团队、Arsenal 团队和后端团队）的开发计划：

将代码标准化指令与恢复的 VoidLink 源代码进行对比后发现，两者高度吻合。

规范、结构和实现模式高度匹配，几乎可以肯定：代码库正是按照这些指令编写的。

规范中描述的代码头（左）与实际源代码（右）对比：

源代码本身显然是按照记入文档的迭代开发周期和编程指南开发的，最初被描述为一项为期 30 周的工程项目，但实际完成时间似乎要短得多。

一份恢复的测试工件（时间戳显示为 12 月 4 日，即项目启动仅一周后）表明，到那时 VoidLink 已经可以正常运行，代码总量已超过 88000 行。此时，编译版本已提交至 VirusTotal，这标志着我们研究的开始。

VoidLink 报告显示代码行数（括号内为译文）：

从零开始构建 VoidLink

由于能查看到 VoidLink 及其各个迭代开发的文档和规范，我们使用开发者使用的同一 TRAE IDE（任何用于智能体模型的前端都可以）复现了工作流程。虽然 TRAE SOLO 是付费产品，但在这里使用常规 IDE 就足够了，因为已经有了说明文档和设计，可以跳过设计步骤。

接到按照 markdown 文档文件中的规范逐个迭代开发周期地实现框架这一任务后，模型开始慢慢生成在结构和内容上类似 VoidLink 实际源代码的代码。

第二个迭代开发周期后的源树图：

通过按照指定的代码规范、功能列表和验收标准执行每个迭代开发周期，并编写测试来验证这些规范，该模型快速实现了所需的代码。虽然所选择的模型仍然会影响代码质量和整体编程风格，但详细精确的说明文档确保了较高的可复现性，因为模型的解释空间较小，每项功能都有严格的测试标准来验证。

根据文档和需求实现迭代开发周期 1：

使用迭代开发周期对于AI 代码工程来说非常有效，因为在每个迭代开发周期结束时，开发者都能得到代码可以正常运行并提交到版本控制仓库的版本，如果 AI 在后续迭代开发周期中出现问题，该版本可以作为恢复点。之后，开发者可以进行额外的手动测试，完善规范和文档，并规划下一个迭代开发周期。这模拟了一个快速敏捷的 Scrum 软件工程团队，其中开发者扮演产品负责人的角色。

迭代开发周期完成日志：