AI 自动化渗透的实践落地记录

原创

天下大木头
天下大木头

木头的信安小屋

2026年6月15日 21:04

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

前言

随着 Agent 能力以及 Claude Code / Codex 的不断迭代，模型的能力其实相较于去年又有了很大程度上的提升，去年我基于意图工程来实现了基于人工编写经验的自动化演练，在日常工作中有用，也能在纵深角度上发现一些问题，但是还不够，主要是有两个问题

1. 经验沉淀的成本：上一个版本的意图工程下，需要人来花费精力来去编写意图文档，需要编写目标、编写门控、编写实现路径（从开始 -> 结束，这一条链路下攻击手法都需要在文档中沉淀）
2. 泛化能力不够：之前算是在既有随机编排的路径下来实现基于 AI 的启发式拓展渗透，并不是完全从头开始

通俗的来讲之前主要专注在后渗透场景下，并不是完全的自动化全链路演练，之前是基于 attck 的沉淀来随机组合成骨架，然后通过多 agent 来基于攻击过程中可深入探索的点来进行深度利用

今年 AI 自动化渗透大家说的也越来越多，同时还有非常多优秀的项目，以及腾讯云的渗透比较都给我们提供了很多思路，许久没写文章，这篇文章主要是介绍一下目前这段时间在自动化渗透逻辑的一些实践化的落地和感悟

感谢的话写在前面，在编写这个文章的时候我借鉴了 ChainReactor 和 淚笑大哥们的思路，我在实践化落地的过程中也借鉴了很多他们的思路，在这里非常感谢他们，让我也学到了很多。

参考链接:

https://mp.weixin.qq.com/s/Rb9HeZRPBu-bkG\_iFV5RZQ

https://mp.weixin.qq.com/s/2rEqFLvkxvYWM3gW170C2w

同时也感谢狼组大哥们的 benchmark 靶场的开源，让我能够用数据来证明我的优化并不是负向的

项目链接：https://github.com/wgpsec/hunxiang

困境

下面是我的判断和假设，并不代表一定是对的，欢迎一起讨论

第一：AI 应用数量持续增长，各个厂家都在不断的推进 ai native / agent 的应用，那么带来了一个实际的问题，agent 本身就是一个动态的，那么现有的白盒代码审计，能应对未来可能各种 agent 应用吗，毕竟 agent 应用是动态的，他的爆炸半斤有可能更大，有可能研发开发出来之后也不会知道这个应用沦陷之后能够导致多大的风险面。

第二：就是以甲方的视角来看，互联网边界上有这么多的资产，在漏洞扫描器这么多年扫描的情况下，更多的风险反而是隐藏的，需要组合拳或者基于当前业务环境的理解来造成组合杀伤，单纯的打poc或者发几个请求的场景只会越来越少。

同时 AI 带来的能力让攻击的门槛进一步降低，攻击poc、利用的整体时间窗口都会极大程度的缩短，甚至门槛也会降低，那么对于防守来说如何挑战更大（如何缩短防护能力的上线时间、如何先一步于攻击者完成问题的发现）

设计思路

在设计之初我也看了网上很多大哥们的项目和思路，每个项目都有出彩的点，不同的项目以不同的目的所以演化成了不同的形态。

那么对于我来说甲方视角，我需要考虑到未来的运营、未来的通用性，同时我也想享受到 ai 基础设施迭代发展过程中所带来的技术红利。我希望框架具有通用性，并不只是来解决某一类的特定问题。我的目标是用极低的成本来让这套框架未来能做更多的事情，例如：自动化渗透、代码审计、防御设备能力度量等等...

然后再结合目前很多模型的 Agentic RL 过程中很多都是基于 Claude Code ，所以我的构建方向就确定了以 Claude + 基模来构建演练引擎，这样无论是工具调用的整体稳定性还是选择的部分都会有比较好的效果，然后外层再通过 Harness 来进行牵引，然后随着 Claude code 和 基模能力的不断迭代来享受到最先进的技术。

由于腾讯的自动化渗透挑战赛，现在外面有非常多优秀的开源项目和思路以及分析文章，我重点主要关注在了 Cairn 这个项目，因为这个项目在底层设计理念上其实并不是单独为渗透测试挑战赛而定制化开发的，底层具有不少的通用性，这里我不会详细展开介绍这个项目，因为外面已经有非常多关于这个项目的分析文章了，简单一句话就是通过 「事实 -> 假设 -> 验证」这样的通用循环来引导让模型在一定的空间下持续的探索利用，从结果来看实际效果也非常的亮眼，所以我这次的工程逻辑过程中就是基于 Cairn 这个项目的理念开发而来的。

测评

在开发初期我首先需要确定一个事情，那就是我如何证明我们对于 Claude 的封装、引导等等是正向的收益，我不希望花费很多时间然后做出来的东西最终还不如直接通过 claude 在触发，所以我需要做一个测试，我利用狼组提供的 benchmark plateform 平台来进行测试。

测试的主要有三组：原生 Claude Code、Cairn 、cyber robot（我自己开发的demo版本），我让 ai 从平台提供的 150 题中挑选出 20道题来作为测试的集合，所有框架的模型都是使用的 Qwen3.7 Max，然后搭配同样的输入，即 「这是一道CTF 题请你找到他的 flag」

Claude Code： 没有任何的知识和工具，工具就是 Bash、python、Grep 这类的基础工具

Cairn：采用的是 Claude Code 的模型引擎（Cairn 中可以选择采用 pi agent、codex 还是 Claude Code），Cairn 是运行在 kali 容器中的，然后拥有工具，以及一些辅助的知识例如 Payload ALL The Things 这些...

Cyber Robot：采用和 Cairn 同样的设计理念，因为是demo 测试，所以我没有给任何的 skill、工具和知识，就是让他尽可能的自己发挥

Benchmark 平台自带了近 150+ 的题目，然后还支持不同队伍，以及 agent 自动启动自动提交的接口，所以这也让我的测评变得更加的便捷

我只需要给 claude code 设置一个 /goal 然后让他在睡觉的时候持续的去跑这三个框架去分批解同样的题目即可，然后睡醒之后看一下结果即可。

然后下面这个就是我这次的测评结果，颜色最深代表时间用的最长，也同样意味着我们完成一道题目的过程中所花费的成本更高（更多的 token）

从结果不难看出 Harness 的重要性，以及模型自身的能力，在 hard 难度题的情况下，在通过 Harness 牵引之后，我们可以将时间最多缩短近 30 倍，所以至少从实验结果来看，我们的 Harness 是起了正向的收益的。

我也观察了一下测试过程中的一些信息，在没有任何牵引的场景下，原生 Claude Code + Qwen 在初次探索的过程中的深度都比较浅，他在探测到了正确的方向之后由于测试深度不够，会觉得这里不存在问题，然后就会切换其他的漏洞类型，至此会进行很多无效的测试，然后最终测了一圈之后再慢慢测回到正确的方向，想要大模型在过程中发挥出更好的效果，需要让他去进行推导，而不是让他进行各种猜测，一旦陷入过多的猜测那么效果就会变差。

同时也有不少师傅针对腾讯这次比赛的项目做了一些消融实验，结论就是很多过多的知识、skill 有可能对于最终的效果反而是负向的。

文章链接

https://mp.weixin.qq.com/s/nzgX4OoqjJ75vkH4mlQJAw

所以经过测试对于我来说得出了2个结论

1. 有效的 Harness 很重要，能够很大程度提高我们整体的效率，因为模型就像是一个没有附带说明书的黑盒求解器，所以我需要 “马鞍” 来牵引他，让他在正确的路上进行持续的求解，而不是在各个方向进行无谓的碰壁
2. 外部拓展需要谨慎，给的很多知识、手法甚至skill 有可能并不能提升我们最终的效果，反而会限制模型在当前环境下的创造力。然而在自动化渗透的场景下我们最需要的是拓展，让模型从原来的 5 条路在我们的拓展下变成 8 条路，所以如何更好的进行拓展也非常重要（如何编写、加载形式......）

工程化落地

在经过前面的一些测试，基本上把技术选型和路线都确认下来了，然后在这里我需要在明确一下目标，从甲方视角来说我们要对海量暴露在互联网上的资产进行自动化演练，那么就需要考虑到2个最大的问题：

1. 稳定性：如何能在跑的时候针对一些可能造成故障风险的面来进行识别或者拦截
2. 成本：如何在固定时间窗口下尽可能多的完成探索利用，以及如何及时停止而不是无限的深度探索

项目架构

我这里的理念其实很简单：

1. 所有的工具和知识，都尽可能的走 skill ，通过渐进式披露节省上下文的特性来更好的挂载
2. 入口就是 浏览器 与 请求测试，一个尽可能的发现业务问题，另一个从 api 角度进行探测，同时并行验证（信息搜集 -> 风险验证 -> 风险利用）

核心理念还是不变：事实 -> 假设 -> 消费，通过期间让 Agent 自动生成意图，然后来进行消费拆解，从而达到持续求解的逻辑。

但是 ctf 场景下解题的路径往往不会很多只有 1-2 条，然后最终的目标也只有一个 flag，所以我们不需要去思考覆盖度的一些问题，但是实际业务环境往往是多条路线，并且我们是不知道完整答案的，所以是需要尽可能广、且尽可能高效的找全所有的风险面。

实际在实际环境下测试存在一些工程化的优化点：

1. 持续的深度求解从而导致时间、token 成本激增（如何控制深度？然后又不影响效果）
2. 长周期演练下图信息持续膨胀，从而挤占上下文
3. 意图生成速度大于下游 Worker 消费能力（ 如何剪枝）
4. 稳定性：（自动审查、hook 机制）

下面我会尽可能简单的来介绍这些问题我是怎么发现的以及我是如何缓解的，并不一定是对的，希望对你们有帮助

在这个项目中我使用了 ioa 作为唯一真相的图引擎

项目链接

https://github.com/chainreactors/ioa

这块后面就让作者来重点介绍吧哈哈

5.1 问题1: 如何控制深度，避免在错误方向上空耗

Worker 消费过程中会存在钻牛角尖的情况，这种情况人很多时候会一眼看出来，但是模型不会他会各种的持续尝试，生成字典持续枚举爆破，持续的尝试探测，或者持续的和 waf 杠上，这时候让模型无限制不加约束的跑下去很显然是不现实的，我们没有必要在错误的方向上持续花费时间，毕竟如果我们的目标针对的是有可能 几十万+ 资产的时候，每一个方向上错误的持续花费乘上数量所带来的成本都是我们不可接受的，但是我们又不能一刀拦死这样有可能会错失新风险的发现

其实最大的问题就是我们需要在这两者之间去做一个平衡，原理很简单，我们只需要加一个 watchdog，但是我们需要搭配奖惩机制、以及软提醒（类似 hint ）。

当 worker 消费一个图谱已经达到 300s 的时候，watchdog 就会进行介入，会有一套基于 fact、tool 调用成功率、拿到有效信息、是否有高价值突破的一个综合评分，当这个评分持续增加的时候我们会持续动态对 300s 进行额外的延长并且没有设定上限，但是反之如果如果我们没有持续的获得有价值的信息，首先就会 Agent 追加一个 [SOFT\_WARN] 告诉他我们的有效时间不多了，然后就开始动态的时间缩短，因为基于我的观察通常当 Agent 陷入钻牛角尖的时候很多的信息都是无效甚至没有价值的，因为方向就错了，当时间持续缩短后，便会对这个 Worker 进行 [TERMINATE] 处理，然后回收这个 worker 中发现的信息回填到图中，这一步是为了不让这里的 worker 的结果白白的浪费，在我们的设计中图是唯一真相源，如果没有入图这个 worker 相当于就白打了

5.2 问题2: 长周期任务下图膨胀导致的上下文空间挤占

上一个问题里我们让图谱成为唯一真相源——worker 打出来的东西只有入图才算数。这个设计很干净，但它在长周期任务下会撞上一个直接的副作用：图会膨胀

我们要求图谱完整地记录整个演练过程——所有事实、假设、失败方向、立足点，因为\"可追溯\"和\"失败方向不重试\"都依赖它的完整性。但是，每一轮 worker 都要读取当前状态来决定下一步该干什么，而模型的上下文窗口是有限的。一个复杂目标跑久了，光是事实节点就可能上百条，再加上假设、失败记录、证据原文。如果把整张图信息全量投影压缩作为 Worker 的输入的话 就会面临几个问题：

1. 上下文被撑爆、token 成本飙升
2. 模型抓不住重点，效果下降

所以这里的问题很明显：\\图必须完整（为了可追溯和不重试），但喂给模型的视图必须精简（为了能用、用得起、不被噪声淹没）。\\

我的处理思路，是通过分层来解决（其实看openai 、claude 他们很多的上下文优化本质上都是分层，分层+说明书+索引，来最小程度来减少上下文，然后按需读取）

1.分层：记录摘要让 ai 自己基于引用来按需读取对应的证据

IOA 图永远是完整的、什么都不丢；但 worker 看到的不是图谱本身，而是每一轮根据当前图谱重新渲染出来的一份 blackboard 视图。压缩只发生在\\渲染这一层\\，绝不发生在事实的删除或截断上——图里的数据一条没少，少的只是\"这一轮渲染给模型看的内容\"。

而且视图本身是分层承载的：视图里每条事实只保留一行摘要，后面带一个引用即可，完整的请求响应、报文原文这些重量级内容留在证据文件里，模型需要细节时\\按需读取\\，而不是默认全量塞进上下文。

- `e582618e07e3d6a95c4a3d1a0bc21ae2` target.com backend is powered by PHP/5.5.25 — this outdated PHP version may have known vulnerabilities, and the OAuth callback processing logic in PHP could be more susceptible to p… (phase=explore; round=6; category=tech; from=bb9fd643ca037f74461dcbfa04130b2b) [evidence: artifacts/evidence/by-category/tech.md]- `c07b1478daa363512df1852f55c99ddb` Weibo OAuth callback /index/weibo on id.amap.com does NOT exhibit open redirect with state/ref/redirectUri parameter injection when given a fake auth code — all return same '非法请求（100）' response. Howe… (phase=explore; round=6; category=auth; from=bb9fd643ca037f74461dcbfa04130b2b) [evidence: artifacts/evidence/by-category/auth.md]

2.分类：不同类型的信息选择不同的裁切、压缩方式

光精简还不够，我们需要把高价值重要的体现出来，让他不被埋没

1. 人工提供的 hint 最为第一优先级，\\全量保留、一条不折叠\\，这类信息不会被压缩
2. 失败方向也要保留，让模型知道哪些路已经失败了（实际场景下模型重复测试的情况算是挺高频发生的了）
3. 常规 fact 放最后，只看最近一批，海量的 fact 是膨胀的主要来源，基本上一个 1h-2h的测试中会出现80-100+的 fact，全量塞入的话肯定是不可接受的，所以这里其实就是取舍问题。

5.3 问题3: 意图的生成与消费失衡

我们目前的思路本质是 “先探索出方向、再围绕方向持续深挖”。我们所有的意图都是基于 fact 来生成的，这样会有两个问题：

1. fact 遗漏问题，有的路径我们探索到了，也写到图中了，但是没有生成对应的意图从而导致路径遗漏
2. 意图过多导致无法消费的问题，意图过多且没有分级，从而导致效率不够

这两个问题所带来的代价也很大：1. 路径的缺失 2. 成本的提升

问题一：fact 遗漏

在原来的设计里，\\一个方向要进入工作队列，唯一的途径是被当成某个 fact 的后续意图写出来。\\ 也就是说，意图是 fact 的\"附属品\"——你得先确认一个 fact，才能顺带挂上\"接下来往哪走\"。

问题就出在这个\"绑定\"上。实际探索中，worker 经常会\\看到\\一个值得跟进的点，但这一轮并没有把它确认成 fact——它可能只是个一个还没验证的可疑接口（例如接口 403）、一个小线索。在旧设计下，这种\"看到了但没坐实成 fact\"的东西，是没有任何途径进入队列的。于是就出现了遗漏：路径明明被探到了，但因为没有转化成带后续意图的 fact，它就从队列里消失了。

改造核心就是一句话：\\把\"一个值得探索的方向\"和\"一个已确认的 fact\"解耦——让方向不必再依附于 fact 才能进队列。\\

具体做法是新增了一条独立的通道：worker 除了写 fact，还可以单独标记 \"这里有个在范围内的面值得跟进\"（notable observation），这条标记\\不需要它先确认成 fact\\。引擎拿到这条标记后，会把它落成图里一个独立的、待探索的意图节点（把这类标成 unresolved\_surface，意思是\"尚未定性的面\"）

这里有个刻意的设计决定：\\这类意图不产生 fact，只产生一个\"待探索\"的标记。\\ 因为一个旁路观察只是说\"这个面值得后面有人来看一眼\"，它还没经过验证，不能算事实——必须等后面真有 worker 去验证了它的影响，才谈得上确认 fact 或 finding。这样既补上了遗漏，又不会让没验证的线索污染到事实层。

改造之后，一个方向进入队列就有了\\两条互相独立的途径\\：一条是老路——跟在已确认 fact 后面的后续意图；另一条是新增的——不依赖 fact 的旁路观察。老路就是按原有逻辑消费执行，后面就是将可能遗漏的面进行补充

问题二：意图过多无分级

第二个缓解措施比较简单，我们设置优先级即可，让 agent 在写入的时候自己判断，这个意图的价值 [高 - 中 - 低]，然后下游 worker 消费过程中优先消费高优先级的，这样有更高的概率先在对的路径上做深度探索

5.4 问题4: 业务安全——拦住 Agent 的危险操作

我们这个逻辑其实是最大程度发挥 LLM 本身的能力，所以在演练期间必然会存在 Agent 自己编写 python脚本、自己编写一些执行的命令，当频次达到一定数量级的时候必然会存在例如误触 delete 接口、修改篡改业务数据等情况出现。

在实际测试过程中我不止一次的发现了这类的情况，当 Agent 从 Js 中发现了一些 delete 相关的接口，他会去做调用，但是这样就很危险很容易导致业务数据受损

这里我直接用了 claude 的 hook 机制，通过 hook 机制的方式来进行引导，然后针对风险问题进行拦截，当然这只是缓解的措施，因为 ai 生成的内容很灵活，我们无法确保 100% 的所有的风险操作拦截，但是我们可以利用 claude code 、codex 中自动审计的机制。

在 claude agent sdk 中我们可以定义一些规则和逻辑，auto 模式，这样的话也能起到一定的缓解，而且也会更加的优雅

总结

在写这篇文章的时候，我的本意就是想着记录我日常遇到的一些坑，因为在 ai 应用开发的过程中最大的问题就是测试的不够多，以及我们修改如何避免过拟合的问题，很多问题其实就是 token 烧出来的，我们遇到了这类情况，然后修改通用的落地来提升我们能力的平均水平，然后走真实环境的 benchmark 来确保能力提升是正向的。

所以这篇文章中我记录了一些我实际落地的坑点，希望能对读者有帮助，也欢迎各位一起来讨论，探索更好的理念、设计方案

截止目前其实仍然还有很多问题我还在思考如何解决中，下面的这些都没有经过验证所以我就没放在文中：

1. 如何最大程度的发挥出 claude code 的能力，比如说 dynamic workflow，针对例如 swagger docs 下多 api 场景下，其实可以利用 claude workflow 来去进行解决
2. 如何做到自动化剪枝，目前的意图优先级 [高-中-低] 只是临时的手段，并不能解决根本的问题
3. 如何更好的有一套评分体系来引导，在我的场景下 cors、csrf 这类完全考虑，我甚至不希望他去发现这块的问题 -> 引入 xx 打分标准，用实际结果来衡量引导 -> 如何更好的引入还在思考中
4. 过程中的重大发现没有利用充分 -> 需要基于重大成果来做针对性的深度利用
5. 如何实现深层的 fuzz ？ -> 白帽子场景下多层路由、深度 fuzz 才有可能发掘出更多的风险
6. .....

参考链接

https://mp.weixin.qq.com/s/Rb9HeZRPBu-bkG\_iFV5RZQ

https://mp.weixin.qq.com/s/2rEqFLvkxvYWM3gW170C2w

https://github.com/wgpsec/hunxiang

https://mp.weixin.qq.com/s/nzgX4OoqjJ75vkH4mlQJAw