EXPERIMENT DESIGN · 黑盒渗透 Agent

钱该花在「找入口」
还是「打入口」？

两个可执行的实验：把黑盒渗透的预算拆成侦察与利用，找到预算分配的拐点；再算清侦察工具到底替代了哪一类 token。

方案一　侦察预算占比 → flag 提取数 / TVR，画曲线找拐点

方案二　侦察工具梯度 → 探索 token vs 解析 token 的替代

基准：XBOW Validation Benchmark · 104 题 · 严格 flag 判定按 → 开始

Overview

方案一是前提，方案二是深化

方案一 · 预算分配

侦察占比 → 拐点在哪

方案二 · 工具配置

拐点预算下工具怎么配

工程结论

钱往哪投 + 工具替代了什么

01方案一先做

R-low / R-mid / R-high 三档
用 TVR 和 flag 提取数画曲线
锚定 Decoupling 的 90% vs 50% 断层

02方案二做深化

在方案一确定的拐点预算上
做 T0 / T1 / T2 / T3 工具梯度
重点算探索 token 与解析 token 的替代

最小可行路径资源有限就先做方案一的三档对比，直接产出「可指导实践的预算分配规则」；方案二作为后续。

锚点 · 01

断层：利用能到 90%，侦察卡在 50%

90.0%

利用成功率

前提：漏洞上下文准确

50.0%

针对性漏洞召回率 TVR

前提：自主黑盒侦察

黑盒渗透的能力天花板在侦察侧，不在利用侧

🚧论文点名的失败主因

failures in parsing
unstructured telemetry
解析非结构化遥测数据失败

🧩架构各有 niche

多 agent 隔离 → 反序列化等长序列交互
单体 / 图驱动 → 短链注入、跨会话访问控制
→ 本实验固定架构，只变预算

Decoupling Reconnaissance and Exploitation · arXiv:2606.25332 / DIMVA 2026

锚点 · 02

成本侧：侦察只占 10–20%，但多花钱不一定更好

💰Shannon 的成本拆分

Recon

$6–10

分析 + 利用

$32–43

侦察 15–20 分钟
分析 + 利用占 60–70%

绝对花费不高 —— 但它在总预算中占比是否合理、边际收益何时衰减，现有系统都没报过

📉AWE vs MAPTA（XBOW）

$7.73

AWE 成本

51.9%

解决率

$21.38

MAPTA 成本

76.9%

解决率

成本 ×2.8，解决率只涨 ×1.5
成本与效果不是单调关系

本实验要做的事把「总成本」拆成侦察预算与利用预算，找分配拐点。

基准 · 黑盒条件

XBOW：104 题，严格 flag 判定

📊公开排行榜（黑盒）

Decepticon

98.08%

Strix

96.15%

PentestGPT

86.5%

商业 XBOW

~85%

MAPTA

76.9%

告诉你「上限区间」在哪，但不需要复现 —— 目标是找拐点，不是冲榜

🔒黑盒条件

104 个 Web 应用 CTF 挑战 · 3 个难度层级
判定：严格 flag 提取，没有部分得分

description: 一个站点的管理后台…
tags: idor, ssti
# 不给源码 / 配置 / 服务内部信息

Agent 必须自己发现端点、参数、sink 和 payload

方案一 · 固定变量

四个变量必须先钉死

🧠模型

低拒答、成本可控
DeepSeek V4 Flash
或 Qwen 中尺寸

避开 GPT / Claude 的拒答干扰；AWE 显示换模型的差异集中在多步推理类

🔁Harness

统一 agent 循环：
侦察→假设→利用→验证

不混多 agent 与单体架构，否则预算效应会被架构差异掩盖

✅判定

严格 flag 提取
不依赖 LLM 自评

与 XBOW 官方判定口径一致

🔂重复

每配置 × 预算 × 样本
跑 3 次
温度 0.2–0.3

报均值和方差，不报单次最漂亮的结果

方案一 · 自变量

不要只设总预算 —— 把预算分配当自变量

R-low

侦察 20%

利用 80%

只做浅层端点枚举和基础爬取，剩余 80% 全部用于利用

R-mid

侦察 50%

利用 50%

允许一轮较完整的侦察：目录发现、参数枚举、基础浏览器交互

R-high

侦察 80%

利用 20%

深度侦察：多轮爬取、动态渲染、交互式分析，利用预算仅 20%

为什么是这三档如果 TVR 停在 50%，意味着一半的利用预算花在「没找到正确入口」的空转上：R-low 模拟侦察不足、靠利用硬试；R-high 模拟侦察过度、挤占利用；R-mid 是中间地带。

方案一 · 因变量

三个方向都要测，成本必须拆开报

🔍侦察侧

可攻击入口数
带参数的端点、表单、API 路径

侦察精度
被利用阶段证实为真攻击面 / 总发现入口

针对性漏洞召回率 TVR
与 Decoupling 的 50% 基线直接对齐

🎯利用侧

flag 提取数
主指标

入口 → flag 转化率
侦察发现的入口有多少真的变成胜利

💵成本结构

总 token / 总 API 成本

侦察 token 占比 vs 利用 token 占比

每次成功 flag 的侦察成本、利用成本
分开报，而不是只报总成本

方案一 · 核心产出

画曲线、找拐点，而不是报单点

侦察预算占比 → flag 提取数

侦察预算占比 → TVR

①R-low

TVR 显著低于 50%
利用预算浪费在猜错入口

②R-low → R-mid

flag 快速上升
侦察边际收益远高于利用

③R-mid → R-high

曲线趋平甚至下降
入口已覆盖，利用被挤

方案一 · 预期结论

拐点位置，就是你要产出的实践结论

由于利用能力上限（约 90%）远高于自主侦察召回率（约 50%），在拐点之前，每单位侦察预算的边际产出高于利用预算；越过拐点后递减，更多预算应转回利用。

💡可操作的启发式

把侦察预算推到 TVR 不再显著上升的位置，然后停手。

⚠️边界条件（必须写清）

· 依赖「利用能力 ≫ 侦察召回率」这个前提
· 目标简单、入口极少 → 拐点提前
· 攻击面极宽、动态路由、复杂 JS → 拐点后移
· XBOW 是 CTF，≠ 真实企业应用 → 适用范围是中小规模 Web 应用黑盒

方案二 · 锚点

工具的价值：是替代探索，还是增加开销？

Decoupling 点名主因是非结构化遥测解析失败 —— 于是假设：浏览器自动化的价值不在它「更高级」，而在于它把原始遥测（HTML / JS / 网络响应）转成 agent 可消费的结构化信息，从而减少「反复猜、反复试」的无效探索。

Headless Chrome 渲染 Nike 页面

639,000

tokens

简化提取只需

725

tokens　≈ 881 倍

⚖️反向风险

浏览器自动化可能用「解析成本」
替换「探索成本」

探索少了
但读输出贵了

净效应是正还是负，现有系统都没有拆分报告过 —— 这就是本实验要算的账。

方案二 · 自变量

工具梯度：固定模型、固定拐点预算、固定子集

T0裸侦察

仅 HTTP 客户端，agent 手动枚举路径和参数

替代：—

增加：—

T1目录发现

T0 + 目录爆破 / 路径猜测工具

替代：盲目猜路径的探索 token

增加：工具输出的解析 token

T2浏览器自动化

T1 + 无头浏览器：渲染 JS、抓动态端点、解析表单

替代：反复猜端点、试参数的探索 token

增加：DOM / 截图 / 网络日志的解析 token

T3结构化流水线

T2 + 端点/参数/表单结构化成可传递产出

替代：阶段间传递的信息损耗 token

增加：结构化本身的轻量开销

T3 的依据Decoupling 强调「阶段解耦」：侦察发现了入口但利用阶段没用上，侦察 token 就白花了。T3 减少的是阶段间的信息丢失，不是新增侦察能力。

方案二 · 核心因变量

把侦察 token 拆成两笔账

🧭探索 token

枚举路径 · 发送探测请求
猜参数 · 构造 payload 尝试

花在「找」上

📖解析 token

阅读 HTTP 响应 · 从 HTML/JS 提取端点
理解应用结构 · 筛选工具输出

花在「读」上

Δ净侦察成本　= Δ探索 token 减少 − Δ解析 token 增加

这才是方案二区别于「A 工具比 B 工具好」的关键 —— 不是比分数，是比这笔账的正负。

方案二 · 关键判断

三种可能的结果，分别意味着什么

＝净效应为零

T1 显著减少探索 token
但解析 token 增加幅度相近

目录发现只是把「猜」变成「读」，没真正省钱

＋净效应为正

T2 大幅减少探索 token
解析 token 增加有限

动态渲染直接暴露了原本要反复试才能发现的端点 → 真实效率增益

−净效应为负

T2 解析 token 暴增
（见 639K 的例子）

即使探索下降，总成本也可能上升 → 用钱买召回，预算受限时未必划算

方案二 · 预期结论

工具省不省钱，取决于它替代的是哪类 token

📁目录发现工具

主要把「猜」变成「读」
净收益有限

不要指望它显著降低成本

🌐浏览器自动化

价值取决于输出是否结构化裁剪

未裁剪的浏览器输出，可能吞掉探索侧省下的全部收益

工程指导对于预算敏感的黑盒渗透，盲目上浏览器自动化可能是负优化。更好的策略：先优化 T0/T1 的探索策略，或者对浏览器输出做结构化裁剪 —— 只把端点 / 参数 / 表单字段 / API 路径喂给 agent，而不是把整个 DOM 塞进去。

边界：T2 的效应高度依赖目标应用的 JS 复杂度 —— 静态 HTML 应用 T0/T1 可能已足够；大量客户端渲染、动态路由的应用，探索替代效应会显著放大。分难度报告可部分揭示这个边界。

执行顺序 · 局限

先做哪个，以及这个实验不能证明什么

①最小可行路径

先做方案一的 R-low / R-mid / R-high 三档对比
用 TVR 和 flag 提取数画出曲线
→ 直接锚定 Decoupling 的 90% vs 50% 断层
→ 结论最接近「可指导实践的预算分配规则」

②方案二作为后续

在方案一确定的拐点预算上
做 T0 / T1 / T2 / T3 工具梯度
重点分析探索 token 与解析 token 的替代

⚠️需要提前承认的局限

· XBOW 是 CTF 基准，不是真实企业应用
· Decoupling 的 50% 召回率是在它自己的 70 个测试床上测的，你的 agent 在 XBOW 上的实际基线可能不同
· 结论适用范围：中小规模 Web 应用的黑盒场景，不能直接外推到大型企业系统

实验的价值不在于复现某个数字，而在于在严格控制的条件下，把「预算往哪投」和「工具替代了什么」这两个黑盒渗透里最贵的决策变量暴露出来。