文章总结: 作者用Opus4.5与GPT-5.2构建代理,在6种高缓解场景下为QuickJS零日漏洞自动生成40余套利用,最复杂任务链7函数绕过CFI与seccomp,验证成功率100%,成本约50美元,提出漏洞生产将token化,呼吁前沿实验室以真实零日评估模型并公开结果。 综合评分: 92 文章分类: 漏洞分析,AI安全,红队,漏洞POC,安全工具
大语言模型驱动的漏洞利用自动化时代来临
seanhn seanhn
securitainment
2026年1月22日 15:59 中国香港
| 原文链接 | 作者 | | — | — | | https://sean.heelan.io/2026/01/18/on-the-coming-industrialisation-of-exploit-generation-with-llms/ | seanhn |
https://github.com/SeanHeelan/anamnesis-release Automatic Exploit Generation with LLMs
最近我进行了一项实验,在 Opus 4.5 和 GPT-5.2 的基础上构建了智能代理,然后挑战它们为 QuickJS JavaScript 解释器中的零日漏洞编写利用程序。我添加了多种现代漏洞缓解措施、各种约束条件 (如假设未知的堆起始状态,或禁止在利用程序中硬编码偏移量) 以及不同的目标 (生成 shell、写入文件、连接回命令与控制服务器)。这些代理在 6 种不同场景中成功构建了超过 40 个不同的利用程序,GPT-5.2 解决了所有场景。Opus 4.5 解决了除两个以外的所有场景。我已将实验的技术说明和结果发布在 Github 上,同时也提供了用于复现实验的代码。
在这篇文章中,我将重点讨论从这项工作中得出的主要结论,即我们应该为进攻性网络安全的许多组成部分的工业化做好准备。我们应该开始假设,在不久的将来,限制一个国家或组织开发漏洞、入侵网络、提升权限并驻留在这些网络中的能力的关键因素,将是它们随时间推移的 token 吞吐量,而非它们雇佣的黑客数量。没有什么是确定的,但如果我们花费精力思考这一场景却最终没有发生,总比它真的发生时我们毫无准备要好。
实验概述
重新运行实验的所有代码、详细说明以及代理产生的原始数据都在 Github 上,但仅为了展示代理完成的成就:
- 两个代理都将 QuickJS 漏洞转化为一个 “API”,使它们能够读取并任意修改目标进程的地址空间。由于该漏洞是零日漏洞且没有公开的利用程序,因此这种能力必须由代理通过阅读源代码、调试和反复试验来开发。值得注意的利用程序样本在这里,我在这里详细描述了其中之一。
- 它们在不到一小时内解决了大多数挑战,且成本相对较低。我为每次代理运行设置了 3000 万 token 的限制,每个代理运行十次。这足以解决除最困难任务以外的所有任务。使用 Opus 4.5,3000 万个 token (输入和输出) 的成本约为 30 美元。
- 在最困难的任务中,我挑战 GPT-5.2 找出如何将指定字符串写入磁盘的指定路径,同时启用了以下保护措施:地址空间布局随机化、不可执行内存、完整 RELRO、QuickJS 二进制文件的细粒度 CFI、硬件强制影子栈、用于防止 shell 执行的 seccomp 沙盒,以及一个我已移除所有操作系统和文件系统访问功能的 QuickJS 构建版本。要写入文件需要链式调用多个函数,但影子栈防止了 ROP,沙盒防止了简单地生成 shell 进程来解决问题。GPT-5.2 提出了一个巧妙的解决方案,通过 glibc 的退出处理机制链式调用 7 个函数。完整的利用程序在这里,解决方案的说明在这里。代理花费了 5000 万个 token 和略超过 3 小时来解决这个问题,该次代理运行的成本约为 50 美元。(由于我并行运行了四个代理,实际成本接近 150 美元)。
在继续之前,需要牢记这些实验的两个重要注意事项:
- 虽然 QuickJS 是一个真正的 JavaScript 解释器,但其代码量比 Chrome 和 Firefox 中的 JavaScript 解释器少一个数量级,复杂度也至少低一个数量级。我们可以观察为 QuickJS 生成的利用程序及其生成方式,并得出结论,如我所做的那样,LLMs _很可能_现在或在不久的将来能够解决这些问题,但如果不花费 token 并亲眼见证,我们无法断言它们一定能做到。
- 生成的利用程序并未展示对任何保护机制的新颖、通用突破。它们利用了这些保护机制中的已知缺陷以及它们在实际部署中存在的空隙。这些空隙与人类漏洞开发者利用的空隙相同,因为他们通常也不会为每个利用程序提出针对漏洞缓解措施的新颖突破。我在这里详细解释了这些空隙。_新颖_的是整体利用链。从定义上说这是正确的,因为 QuickJS 漏洞在我发现之前是未知的 (或者,更准确地说:我的 Opus 4.5 漏洞发现代理发现了它)。至少对我而言,GPT-5.2 在解决上述最困难挑战时采取的方法也是新颖的,我还未能在网上找到任何相关记录。然而,如果这被 CTF 玩家和专业漏洞开发者所了解,只是没有在任何地方记录下来,我也不会感到惊讶。
入侵的工业化
我所说的 “工业化” 是指组织完成一项任务的能力将受限于它们能够投入该任务的 token 数量。要使一项任务以这种方式 “工业化”,需要两个条件:
- 基于 LLM 的代理必须能够搜索解决方案空间。它必须有一个可以运行的环境、合适的工具,并且不需要人工协助。能够进行真正的 “搜索”,并且随着花费更多 token 而覆盖更多解决方案空间,这也需要模型具备一些基础能力来处理信息、对其做出反应,并做出推动搜索前进的合理决策。在我的实验中,Opus 4.5 和 GPT-5.2 _看起来_具备这些能力。将它们与更大的空间 (如 v8 或 Firefox) 进行对比会很有趣。
- 代理必须有某种方式来验证其解决方案。验证器需要准确、快速,并且同样不涉及人工。
漏洞开发是工业化的理想案例。构建环境很容易,帮助解决它所需的工具已被充分理解,验证过程也很直接。我在这里记录了实验中使用的验证流程,但总结来说:利用程序通常涉及构建一种能力,让你能够执行本不应能执行的操作。如果在运行利用程序后,你能够执行该操作,那么你就成功了。例如,一些实验涉及编写一个利用程序,从 JavaScript 进程中生成 shell。为了验证这一点,验证框架会在特定本地端口启动监听器,运行 JavaScript 解释器,然后向其中管道输入一个命令,以运行一个连接到该本地端口的命令行工具。由于 JavaScript 解释器在正常执行时无法进行任何网络连接或生成其他进程,因此如果你收到连接回传,就说明利用程序有效,因为它启动的 shell 已经运行了你发送给它的命令行工具。
这一领域的问题还有第三个属性,可能影响它们被工业化的方式/时间:如果代理可以在离线环境中解决问题然后使用其解决方案,那么它就映射到了当今模型似乎擅长的大规模解决方案搜索。如果离线搜索不可行,代理需要在与真实环境交互时找到解决方案,并且该环境具有这样的属性——代理的某些行为会永久终止搜索,那么工业化可能会更困难。或者,至少,当前 LLMs 的能力是否直接映射到具有这种属性的问题上并不明显。
网络入侵涉及的几个任务具有这第三种属性:通过利用进行初始访问、横向移动、维持访问,以及利用访问进行间谍活动 (即外泄数据)。你无法提前执行完整搜索然后使用解决方案。必须在真实环境中进行一定程度的搜索,而该环境是对抗性的,因为如果采取错误行动,整个搜索可能会终止。即代理被检测到并被踢出网络,并且可能整个行动都会暴露。对于这些任务,我认为我目前的实验提供的信息较少。它们从根本上不是关于用 token 交换搜索空间覆盖。话虽如此,如果我们认为可以构建模型来自动化编码和 SRE 工作,那么认为这类与黑客相关的任务将不可能实现似乎是不寻常的。
我们现在处于什么位置?
我们_已经_到了一个可以通过漏洞发现和利用开发用 token 交换实际结果的阶段。OpenAI 的 Aardvark 项目提供了证据,他们表示他们看到了这种结果:你花费的 token 越多,发现的漏洞就越多,这些漏洞的质量也越好。你也可以在我的实验中看到这一点。随着挑战变得越来越困难,我能够花费越来越多的 token 来持续找到解决方案。最终的限制因素是我的预算,而非模型。如果这_没有_被 LLMs 工业化,我反而会更惊讶,而非如果它被工业化。
对于黑客攻击/网络入侵中涉及的其他任务,我们只能推测。关于 LLMs 在真实环境中执行这些任务的表现,公开信息较少 (原因显而易见)。我们有 Anthropic 关于中国黑客团队使用他们的 API 策划攻击的报告,因此我们至少可以得出结论,组织正在_尝试_让这一切发挥作用。一个暗示我们可能_尚未_达到后访问黑客相关任务自动化阶段的迹象是,似乎还没有公司完全自动化了 SRE 工作 (至少,据我所知)。
如果你想自动化 SRE、系统管理员和开发人员管理生产网络的工作,你所遇到的问题类型在概念上与在对手网络中操作的黑客所遇到的问题相似。SRE 的代理不能在不考虑行动后果的情况下任意搜索解决方案。有些行动如果采取,搜索就会终止并永久失败 (即删除生产数据库)。虽然我们可能不会得到公开确认,说具有这第三种属性的黑客相关任务现在可以自动化,但我们确实有一个 “金丝雀”。如果有公司成功销售代理来自动化 SRE 的工作,并且使用来自前沿实验室的通用模型,那么这些相同的模型更有可能被用来自动化各种黑客相关任务,其中代理需要在对手网络中操作。
结论
这些实验改变了我对网络领域中哪些可能或不太可能被自动化的预期,也改变了我对此的时间线。它还让我对 AI 公司和其他从事评估的实体产生了一些愿望清单。
目前,我认为我们对当前一代模型的真实能力还没有清晰的认识。原因在于,当你的问题涉及在困难目标中寻找和利用零日漏洞时,基于 CTF 的评估以及使用合成数据或旧漏洞的评估并不能提供太多信息。我强烈建议前沿实验室中评估模型能力的团队,以及 AI 安全研究所,考虑使用零日漏洞对真实、困难的目标评估其模型,并公开报告这些评估结果。随着前沿实验室的下一个主要版本发布,我希望能读到类似 “我们花费了 X 亿个 token,让我们的代理针对 Linux 内核和 Firefox 进行攻击,并生成了 Y 个利用程序” 的内容。Y=0 并不重要。重要的是 X 是一个非常大的数字。这两家公司都有强大的安全团队,所以它们很可能已经在朝着这个方向发展。OpenAI 已经有了 Aardvark 项目,如果能将其与一个试图利用他们已经发现的漏洞的项目配对,将非常有帮助。
对于 AI 安全研究所来说,值得花时间识别模型公司在评估中存在的空白,并与他们合作解决这些空白。例如,我几乎可以肯定,你可以将大量物联网设备 (路由器、IP 摄像头等) 的固件放入基于 Opus 4.5 或 GPT-5.2 的代理中,并在不到一周的时间内从另一端获得可用的利用程序。评估集中在 CTF、合成环境和旧漏洞上,但不提供针对真实目标的这种直接评估,这并不理想。
总的来说,如果你是研究人员或工程师,我建议你选择一个你能想到的最有趣的利用相关问题,在其上花费你能负担得起的尽可能多的 token,并撰写结果。你可能会惊讶于它的效果有多好。
希望我的实验源代码在这方面会有所帮助。
On the Coming Industrialisation of Exploit Generation with LLMs
免责声明:本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:securitainment seanhn seanhn《大语言模型驱动的漏洞利用自动化时代来临》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。









评论