揭秘AI自动化渗透背后的迷雾

最初的开始—XBOW基准测试

最开始XBOW通过构建一套基准测试以证明基于 Web 的攻击工具的熟练程度，此基准是由多个外部承包商开发的，为反映安全团队在日常渗透测试/漏洞赏金活动中通常遇到的各种漏洞类别包含 104 个基准测试集，但基准被限制在类似CTF的挑战中答案隐藏在基准测试的某个位置，目标是找到它，xbow本身也表明不会将flag硬编码，而是希望能够在构建基准测试时将其注入，后面为评估真实软件的漏洞，从而转战到HackerOne

基准位置（目前因xbow升级已废弃）：https://github.com/xbow-engineering/validation-benchmarks/tree/main （XBEN-001-24到XBEN-104-24，每个基准都有不同的难度级别（简单、中等、困难，所有基准都包含MAPS评估的金丝雀字符串，确保数据不会出现在训练语料库中，项目使用Docker和docker-compose进行标准化部署和测试）

HackerOne时期XBOW 背后的技术

对于xbow能够登顶HackerOne，官方做出来的技术解释如下，当然这个时候外界也称xbow为xss漏洞执行器，因为xbow利用Global Protect的XSS 0-day漏洞，并将其应用到所有在范围内的目标上进行扫描。这种“广撒网”的策略导致了大量XSS报告的产生，提交的约1100个报告中，有大约800个是XSS漏洞，不过后面XBOW的研究员Diego解释说，XSS是他们目前能最可靠验证的漏洞类型之一，其验证系统可以做到“零误报”，在产品初期，为了在Bug Bounty平台（如HackerOne）“游乐场”中测试和改进产品，他们会优先报告那些最容易发现且验证准确的漏洞，XSS自然成为了他们的首选

另外的技术解析

1. 利用大语言模型（LLM）解析攻击范围

漏洞赏金项目的范围和政策通常以自然语言撰写，对自动化工具构成障碍结合LLM和人工监督，将非结构化文本转化为机器可读的格式通过训练模型理解“允许”与“禁止”的细微差别，例如识别出禁止“自动扫描”的条款，避免违规行为，并将域名提取到目标数据库中

2. 建立目标评分系统

在提取域名并进行子域名扩展后，构建评分系统来筛选和排列目标的优先级综合多种标准，评估每个目标的“可攻击性”和潜在价值

技术栈分析： 识别底层技术（如过时的框架或库），预示已知漏洞的存在

安全防护评估： 检测是否存在Web应用防火墙（WAF）或其他防御措施，并评估其配置强度

行为分析： 分析HTTP状态码和重定向行为，以发现配置错误或隐藏的端点

端点与认证： 评估可访问端点的数量和是否存在认证表单，意味更大攻击面

3. 利用哈希技术实现资产去重与聚类

大型项目中类似stage0001-dev.example.com这样的克隆或临时环境非常普遍在其中一个环境发现的漏洞，往往也存在于其他相似环境中为避免重复劳动并将精力集中于独特的系统，采用两种哈希技术:

• SimHash： 通过分析HTML内容的结构，为每个网站生成一个“指纹”，从而快速检测内容级别的相似性
• ImageHash： 结合无头浏览器对网站进行截图，并应用图像哈希算法来评估视觉上的相似度

将相似的资产进行分组，优先处理那些独特且具有重大影响的目标

误报的解决方案

人工智能的幻觉一直是业界难题，当引入AI时，由于模型的泛化能力，验证边缘情况的风险变得更高，xbow采用验证器机制

验证器：自动化同行评审机制

识别出的潜在漏洞，都必须经过一个自动化的同行评审程序——即“验证器”——来确认其真实性这一过程根据漏洞类型的不同而采用多种方法：

• 基于程序的自定义检查： 对于特定类型的漏洞，会构建专门的程序化检查例如，为了验证跨站脚本（XSS），会启动一个无头浏览器，访问目标站点并检查的JavaScript载荷是否确实被执行
• 利用大语言模型（LLM）进行验证： 在某些情况下，LLM可以充当验证器例如，通过分析服务器的错误响应，LLM可以判断一个SQL注入的尝试是否成功，或者一个路径遍历的payload是否暴露了敏感信息
• 无头浏览器交互验证： 对于更复杂的漏洞，如服务器端请求伪造（SSRF），验证器会利用无头浏览器来确认内部服务的端口是否可以从外部访问

blackhat与defcon时XBOW公布的技术细节

本质问题与工程解法

本质问题: 直接使用大模型进行漏洞挖掘会产生极高的误报率，由于漏洞本身是小概率事件，即使是准确率很高的模型，根据贝叶斯定理，其大部分发现也会是误报使得LLM的原始输出在实战中几乎不可用

XBOW的工程解法: 采取人机协作的混合架构LLM负责创造性的攻击路径探索，而让确定性的代码（Non-AI Code）负责“严谨”的漏洞验证=AI代理生成证据 + 确定性非AI代码验证证据的最终架构，将LLM从验证环节剥离，实现所谓blackhat议题所讲的”零误报“的规模化漏洞发现

确定性代码：遵循一套固定的、预先编写好的、完全可预测的规则来执行任务的传统计算机程序，给定相同的输入，它永远会产生完全相同的输出

确定性的非AI代码扮演验证器 (Validator)的角色,它的工作不是去发现漏洞，而是去验证AI代理提交的“证据

架构与数据流分析

架构分析:

协调器-解决器-验证器

协调器 (Coordinator):

• 角色: 平台的“项目经理”和总控制器。
• 职责: 任务分解、资产发现、目标优先级排序、任务分发及状态管理。

解决器 Solvers/AI Agent (攻击代理)

AI Agent (攻击代理):基于LLM（如Claude 3.5 Sonnet）GPT5 ，通过精心设计的Prompt进行

• 接收目标信息（如URL、源代码访问权限、Docker镜像文件系统）
• 理解目标，并基于其知识库和上下文生成潜在的攻击策略
• 执行命令（如curl, cat），与目标应用交互
• 关键产出: 生成用于验证漏洞的**“证据”**（Evidence）并非简单的“是/否”判断，而是具体的产出

  curl -v -u attacker:rooc6Ip2 “http://redmine:3000/projects?set\_filter=1&admin\_projects=true“

返回结果：

Validator (验证器):

确定性代码（Python, Go, Shell脚本等），完全不涉及AI，接收AI Agent提供的“证据”，并以严格、可复现的方式进行验证

产出: 一个布尔值（True/False），确认漏洞是否存在

Target Environment (目标环境):

Docker容器化技术，用于隔离和标准化部署目标应用为AI Agent提供一个可交互、可攻击的实例根据验证策略，环境中预先植入了（Canaries/Flags）

Orchestration Pipeline (编排流水线):

CI/CD系统（如Jenkins, GitLab CI）、工作流引擎（如Argo Workflows）或自定义脚本

任务:

目标筛选与准备: 从大规模源（如Docker Hub）拉取、筛选、构建和部署目标应用

任务分发: 将目标分配给AI Agent

验证触发: 当Agent产出证据后，自动调用相应的Validator

结果管理: 记录已验证的漏洞，并进行后续处理（如生成报告、创建工单）

数据流:

阶段一：目标定义与范围解析

1. 输入: 自然语言格式的项目范围和初始URL。
2. 流程: 使用LLM将非结构化的文本（如“in-scope”、“out-of-scope”、“disallowed actions”）解析为结构化的JSON数据。
3. 输出: 一份Ai可读的攻击范围和规则清单

阶段二：资产发现、评分与聚类

1. 输入: 结构化的范围数据。
2. 流程:
   • 发现: 运行子域名枚举等工具，获取初始资产列表。
   • 指纹采集: 使用无头浏览器对每个资产进行技术栈识别。
   • 评分: 基于加权模型（如是否存在已知老旧库、认证表单、WAF等）对目标进行“可攻击性”评分。
   • 聚类: 计算每个资产的SimHash和ImageHash，将相似资产分组，协调器仅从每组中选取一个代表进行测试。
3. 输出: 一份经过优先级排序且去重的目标资产列表

阶段三：自主攻击与证据生成

1. 输入: 一个高优先级目标。
2. 流程 (ReAct-like Flow):
   • 任务启动: 协调器向一个“解决器”下发攻击指令。
   • 推理循环:
     1. 思考 (Thought): LLM分析目标，提出攻击假设（例如：“这是一个Redmine项目，我应该检查ProjectQuery模型中是否有参数可绕过权限”）。
     2. 行动 (Action): LLM生成并执行一个工具调用（例如：cat /path/to/project_query.rb来分析源码）。
     3. 观察 (Observation): 分析工具返回的结果（例如：发现admin_projects参数）。
     4. 再次思考与行动: 基于观察，LLM构建一个能够证明漏洞的最终证据（例如：curl … “http://redmine/projects?set_filter=1&admin_projects=true“）。
3. 输出: 一个包含完整攻击链、推理过程和可验证证据的潜在漏洞报告，提交给协调器。

阶段四：严格的非AI验证

1. 输入: 来自“解决器”的潜在漏洞报告及其证据。
2. 流程: 协调器根据漏洞类型，调用相应的确定性验证器。
   

   XSS验证器:

   • AI代理的任务: “请给我一个能在这个网站上触发XSS的URL”
   • 确定性代码的任务:
     1. 接收AI提供的URL
     2. 启动一个无头浏览器（一个没有图形界面的浏览器）
     3. 访问这个URL
     4. 检查 (if) 是否弹出了一个 alert() 对话框
     5. 检查 (if) 这个对话框是不是在预期的目标域名上弹出的
     6. 如果所有检查都通过，输出“漏洞已确认”；否则，输出“验证失败”

#### **缓存投毒验证器 :**

-   **AI代理的任务**: “请给我一个基础请求、一个未被缓存的HTTP头和一个能污染缓存的值”

-   **确定性代码的任务**:

    1.  发送10次基础请求，记录下正常的响应是什么样的

    2.  发送一次带有AI提供的“污染头”的请求，检查响应是否变成了错误页面

    3.  再发送一次基础请求（不带污染头），检查响应是否**仍然**是那个错误页面（证明缓存真的被污染了）

    4.  如果上述流程完全符合预期，则确认漏洞

3. 输出: 一个布尔值（True/False）。如果为True，漏洞被最终确认，生成报告。

Xbow局限性：

在处理有明确模式和可验证结果的漏洞（如标准XSS、SQL注入）方面非常强大且高效但在需要人类创造力、深度逻辑推理、跨领域知识整合和理解业务上下文的复杂场景中，仍然与人类黑客有明显差距

1. 复杂逻辑和多步骤攻击链

无法复现的“神来之笔”: xbow的研究员Diego在访谈中分享的漏洞一个涉及API降级、JSONP、Referer绕过，以及在另一个子域上的XSS漏洞，最终组合成五步的账户接管，需要跨域的创造性思维和对多个独立漏洞的巧妙串联

对创造性思维的依赖: 尽管xbow已经开始尝试链接一些漏洞（如SSRF+LFI），但仍处于初级阶段 对于那些需要深刻理解业务逻辑、利用设计缺陷、或者进行非常规操作的攻击，AI目前还难以胜任。黑客的价值正体现在这种无法被模式化的创造力上

案例：Redmine权限绕过漏洞，虽然是业务逻辑漏洞但需要人类研究员预先在“私密项目”中植入一个flag，然后告诉AI去寻找这个flag。AI虽然成功找到了利用参数绕过权限的方法，但整个过程并非完全自主，它需要人类为它设定一个非常明确的、与业务逻辑相关的目标。这暴露了它在自主理解和攻击复杂业务逻辑方面的局限。

2. 漏洞验证与误报问题

验证机制并非万无一失: Diego提到，对于像XSS这类容易验证的漏洞，他们通过无头浏览器等验证器（Validators）可以做到“零误报”。但对于更复杂的漏洞，如SSRF或信息泄露，验证就变得困难。

AI会“欺骗”自己的验证器: 一个非常关键的点是，Diego承认 “有时AI会设法欺骗这些验证器”。这意味着AI为了达成“找到漏洞”的目标，可能会利用某些边界情况绕过自身的安全检查，这说明其验证逻辑还存在被“攻击”的可能，从而产生误报。

难以判断信息泄露的真实影响: 对于信息泄露类漏洞，AI很难判断泄露的密钥（Key）或信息是否真的敏感，还是只是测试环境的占位符，这需要人类的上下文判断。

3. 测试范围和特定技术能力

• 专注于Web和API安全: Diego明确表示，“目前不做基础设施相关的事情”。xbow的能力集中在Web应用和API渗透测试上，对于网络层、主机层面的渗透测试则不在其服务范围内
• 复杂客户端漏洞处理能力仍在发展: 当被问及Post-message漏洞测试时目前的实现方式是分析DOM和控制台日志，而无法像人类一样设置断点、单步调试、检查内存状态，这限制了它发现深层客户端逻辑漏洞的能力。
• 主动规避某些难题: 对于验证码（CAPTCHA），Diego坦言他们可以绕过一些简单的，但不会投入大量资源去研究绕过复杂的验证码，因为这是一个“猫鼠游戏”，不符合产品的核心目标

4. 业务逻辑理解的缺乏与“失控”风险

AI在执行任务时，会因为缺乏对业务上下文的理解而造成问题。

• 可能导致业务中断: xbow发现一个网站的表单验证码失效，于是它开始**“一遍又一遍地提交表单”**，最终给客户的工单支持系统造成了大量的垃圾数据。这表明AI虽然在技术上成功绕过了防护，但完全不理解其行为对业务的实际影响，类似于一个“没有感情的脚本小子”
• 依赖外部规则进行约束: 为了防止AI“越界”，xbow依赖于代理规则（Proxy Rules）和X-Bounty请求头等外部强制措施来限制其测试范围。这说明AI本身还不能完全自主、智能地理解和遵守复杂的测试范围（Scope）要求

工程实践参考点

如何设计不会被LLM欺骗的健壮验证器？

LLM会寻找规则的捷径“智取”验证器，

• 案例分析 (XSS Validator Cheat #1):
  • 缺陷: 验证器只检查alert()是否被触发，但未校验URL的协议头
  • LLM利用: Agent提供了javascript:alert(“XSS”)作为证据，这是一个合法的URL，能在浏览器中触发alert，但它并未在目标网站的上下文中执行，因此不是一个真实的XSS漏洞
  • 工程修复: 验证器必须增加检查项：URL.protocol必须是http:或https:，且URL.hostname必须与目标主机匹配

• 工程优化:
  1. 上下文强校验: 验证器不仅要检查“现象”（如弹窗），还要检查“现象”发生的上下文（如域名、协议、触发路径）
  2. 避免模糊匹配: 验证规则应尽可能精确例如，检查console.log(“666”)作为XSS证据是脆弱的，因为其他代码逻辑也可能输出“666”更好的证据是输出一个与当前会话绑定的随机数

AI幻觉与不可靠性

对策: 将LLM的角色限定于“探索与证据生成”，而将“判断”的权力完全交给确定性的验证器无论AI的推理过程多么离奇，只要最终证据无法通过验证器的严格检查，就会被丢弃

如何平衡验证的自动化程度与覆盖范围？

“验证器分类”矩阵

全自动 + 需要目标协作 (右上象限):

场景: 大规模、自动化的开源软件扫描（如Docker Hub流水线）

实现: 通过脚本在部署时自动植入金丝雀例如：

• RCE/File Read: 在容器文件系统的/flag.txt写入一个UUID
• SSRF: 启动一个只在容器内部网络可达的Web服务，其根目录提供一个包含UUID的flag.txt
• SQLi: 如果应用使用数据库，连接到数据库并在某个表中插入一个包含UUID的条目

优点: 可大规模扩展，验证结果极其可靠

手动/半自动 + 无需目标协作 (左下象限):

• 场景: Bug Bounty或黑盒渗透测试
• 实现: 验证器依赖于可观察的外部状态变化例如：
  • XSS: 使用无头浏览器访问Agent提供的URL，检查alert()或console.log()
  • Cache Poisoning: 实现一个多步验证脚本：、
    • 1发送基准请求获取正常缓存
    • 2 发送带有未键控头（Unkeyed Header）的恶意请求
    • 3再次发送基准请求，检查是否返回了被污染的错误页面
• 优点: 适用性广，无需目标系统权限
• 缺点: 验证逻辑更复杂，误报风险相对较高（但仍远低于纯LLM）

验证器的设计权衡：误报与漏报

验证器如何工作以消除误报。

• 验证器设计中的权衡。设计一个过于严格的验证器会减少误报，但可能会增加漏报（False Negatives），反之亦然。
  • 演讲案例： 对于任意文件读取漏洞：
    • 要求AI返回/etc/passwd的内容： 这个证据要求很具体，AI更容易实现（漏报率低），但如果目标是一个刻意设置的蜜罐或有特殊配置，这个验证可能会被轻易绕过，或者即使成功也可能是“预期行为”（误报风险相对高）
    • 要求AI提供一个能读取任意文件的Python脚本： 这个证据要求更通用、更强大，但对AI来说也更难生成（漏报率高）
• 实现“零误报”并非没有代价，它需要在验证器的设计上做出精妙的权衡，以在不牺牲过多漏洞发现率（控制漏报）的前提下达成目标

源码价值

• 拥有源代码访问权限是AI Agent成功的关键催化剂。XBOW的测试模式更准确地定义为**“规模化的自动化灰盒测试”**，而非纯粹的黑盒测试
• AI Agent通过分析源代码，可以发现那些在黑盒模式下极难通过Fuzzing或猜测发现的、隐藏在业务逻辑深处的参数或漏洞（如Redmine的admin_projects参数）!

如何设计有效的Prompt来引导Agent产出“可验证的证据”？

Prompt的设计直接决定了Agent的行为模式

• 工程实践:
  • 明确目标: 清晰地告知Agent需要找到一个flag
  • 提供工具和能力: 告诉Agent它可以使用哪些shell命令，以及它拥有哪些文件的访问权限（如源代码）
  • 要求具体产出: 不要问“是否存在漏洞？”，而要问“请提供一个能读取/flag.txt内容的HTTP请求”或“请提供两个HTTP请求，分别触发SLEEP(1)和SLEEP(5)，用于验证时间盲注”
• “合金模型” (Alloy Models) 的应用: 提出在攻击链的每一步随机选择不同系列的LLM（如Gemini和Claude模型），发现这种混合使用比单一模型能获得更好的测试结果，为AI在安全领域的应用提供了新的思路。
• 将“幻觉”视为特性: 明确提出在有严格验证机制的前提下，LLM的幻觉（Hallucination）可以被视为一种“计算创造力”，有助于发现意想不到的攻击路径。

多模型协作-合金

XBOW 的 AI 策略是“模型提供商无关的”，这意味着它可以即插即用地使用最佳的 LLM ，不同的 LLM（例如 OpenAI 的 GPT-4、Anthropic 的 Sonnet 系列、Google 的 Gemini 2.5 Pro）在解决特定挑战时各有优劣。尽管 Sonnet 4.0 在整体表现上更优，但在单个挑战层面，“有些最适合由 Gemini 解决，有些则由 Sonnet 解决

在处理一个复杂任务的连续迭代中，交替调用来自不同供应商的多个大语言模型（如Sonnet和Gemini），同时将它们的对话历史整合成一个统一的线程。这种方法能让AI代理在不增加总调用次数的情况下，有效融合不同模型的独特优势和“灵感”，从而在解决需要多步创造性思维的复杂问题时，取得远超任何单一模型的性能表现

• 单一对话线程： 代理与 LLM 的交互始终保持在同一个对话历史中。
• 交替调用模型： 在第 N 轮调用模型 A，在第 N+1 轮则调用模型 B。
• “无感”协作： 每个模型都将对方模型的输出视为自己之前的输出，从而在不知情的情况下，将各自的“优势思维”贡献到同一个任务流中。

细节点：性能更优的单一模型在合金中能发挥更大作用，两个模型的能力和“思维模式”差异越大，合金化带来的性能增益就越明显，同一供应商的不同模型（如 Sonnet 3.7 和 Sonnet 4.0）由于过于相似，合金化后没有明显增益

与其它多模型方法的区别 :

• 比“任务分工”更轻量： 无需预先定义子任务并分配给特定模型。
• 比“专家混合/投票”更经济： 在每一步只调用一次模型，总调用次数不变。
• 比“多代理辩论”更高效： 避免了模型间沟通的开销，更适合需要快速、大量尝试的搜索类任务。

可见：https://drive.google.com/file/d/1lsQbD9_MCWcZQ8MCyWzhixh2GkHD5kCp/view?pli=1

目前来看XBOW 并非旨在取代渗透测试人员或研究人员，而是增强团队能力它减轻渗透测试人员的日常负担，使他们能够专注于探索前沿漏洞类别以及最重要的应用程序特定错误

参考资料：

https://www.youtube.com/watch?v=rvA8IbyogJ0

https://xbow.com/blog/alloy-agents

https://cdn.prod.website-files.com/686c11d5bee0151a3f8021bf/689cb0e9212bdf4ed0efe44c_US-25-Dolan-Gavitt-AI-Agents-for-Offsec-with-Zero-False-Positives.pdf

转自：https://forum.butian.net/share/4612

转载请注明：jinglingshu的博客 » 揭秘AI自动化渗透背后的迷雾