一套可留证的渗透测试工作流
原创
Aaron
Aaron
Aaron与安全的那些事
2026年10月15日 12:36
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
渗透测试里有一类问题很常见：端口扫出来了，接口也找到了，但真正影响安全边界的那段逻辑藏在客户端、打包脚本、插件或二进制里。
这时，单靠扫描器不够。扫描器能告诉你“哪里值得看”，却未必能说明“这段代码为什么会把数据送到这里”；反过来，逆向分析也不等于完成一次渗透测试，它还需要把疑点放回真实服务、真实权限和真实网络边界里验证。
最近公开的三个开源项目，刚好把这条链路拆成了三段：
reverse-skill：负责分诊和作战骨架，先判断目标类型，再初始化范围、时间线和证据目录。REA：负责把二进制、JavaScript/Electron、.NET、网页和运行行为拆成可解释的线索。PentAGI：负责在隔离的 Docker worker 中编排资产发现、工具调用、结果记忆和报告。
它们合起来，不是“按一下按钮自动黑进目标”，而是一套更适合项目交付的工作方法，本文讲述：先搞懂目标，再做受控验证；每一步都能回到原始证据。
三个工具的角色定义
1. reverse-skill：条条道路通罗马，应该选哪条？
reverse-skill 更像一个路由和作战契约集合，不是一个独立扫描器。
它的价值在于把容易被忽略的前置工作固定下来：目标是什么类型，当前机器有哪些工具，授权范围是什么，网络模式是什么，哪些动作在当前 case 里被允许，最后哪些证据要进入报告。
公开文档里的主线很清楚：任务先经过规则和路由，再进入 case-init；scope、timeline、Evidence、Finding 和报告之间有明确的关系。授权状态和网络配置没有准备好时，只能做只读规划，不能直接对目标执行动作。
这一步看似不“刺激”，却是很多报告失真的源头。没有范围文件，后面很容易出现两个问题：一是把不在授权范围内的资产扫进去，二是做完一堆动作，却说不清哪一步产生了结论。
2. REA：把“我感觉”变成具象化
REA 的定位是连接分析工具与工作流的逆向连接器。公开资料显示，它可以使用 Hopper、Ghidra 或 IDA 等原生分析引擎，也可以直接分析 JavaScript、Electron、.NET 和网页目标；同一套能力既可以走 MCP，也可以从 CLI 使用。
它返回的重点不是一句“这段代码不安全”，而是函数、调用关系、伪代码、运行观察、原始输出和覆盖限制。对安全测试来说，这些东西很重要，因为最终要回答的不是“模型认为危险吗”，而是：
- 哪个入口触发了这段逻辑？
- 参数从哪里来，经过了哪些边界？
- 敏感操作发生在客户端、主进程还是服务端？
- 结论来自静态代码、运行时观察，还是作者推断？
REA 官网公开的案例也体现了这种方法。DX-Ball 案例从声音调用追到位置转声道的函数，再用原始 x86 测试和编译后的函数字节做核对；Notion 案例从渲染层一路追到 Electron 的 preload、IPC 和主进程剪贴板桥；TH04 案例则从 DOS 程序的指令恢复角度计算，再与维护中的 C++ 实现和编译结果比较。
这里的共同点是“追踪 + 复核”，不是“反编译完就算完成”。
3. PentAGI：把疑点放回网络和服务里验证
PentAGI 是自托管的多智能体渗透测试平台。根据公开 README，它把资产发现、研究、工具调用、记忆、监控和报告组织成 flow，并将 20 多种专业安全工具放到隔离的 Docker 环境中执行。
它适合处理的是“目标已经明确，下一步要验证什么”的工作。例如：
- 只对授权实验网的指定主机做端口和服务识别；
- 根据已经确认的入口检查认证、授权和输入边界；
- 对一个已知的服务指纹，补充配置、版本和暴露面的验证；
- 把命令、输出、时间和产物整理进一份可以复测的流程记录。
PentAGI 不是 CALDERA 那样的预定义攻击模拟平台，也不应该被当作无人监督的攻击按钮。
一次项目应该怎样串起来
下面用一个常见的授权场景说明：客户交付了一个 Electron 客户端和它对应的测试环境，希望确认“复制、导入和导出”这几个功能有没有把敏感数据带到不该去的地方，同时验证服务端是否正确校验权限。
第一步：先写范围，再开工具
不要直接把客户给的信息丢给工具。先建一个 case，把授权、资产、动作边界和交付目标写下来。
一个最小的给AI的 scope.md 可以是这样：
case: electron-lab-001
auth:
status:granted
reference:client-authorization-2026-017
network_profile:lab_only
targets:
-name:desktop-sample
path:./samples/client.asar
-name:api-lab
url:https://api.lab.example.test
ports:[443,8443]
time_window:\"2026-10-15 09:00-18:00 Asia/Shanghai\"
limits:
rate:low
concurrency:2
destructive_actions:false
stop_conditions:
-leavethelabnetwork
-authenticationstateisunclear
-targetownerrequestsstop
deliverables:
-timeline.md
-evidence/INDEX.md
-report.md
然后让路由层把目标分成两条线：客户端走逆向和运行时观察，API 走服务识别和权限验证。这里的“分成两条线”不是把工作拆给两个互不相干的工具，而是让后面的证据能汇合到同一个问题上：客户端传了什么，服务端信了什么。
在 reverse-skill 仓库里，公开文档给出的工作习惯可以概括成下面几步。不同平台的脚本后缀可能不同，执行前以仓库当前版本和本机工具索引为准：
# 在 reverse-skill 仓库目录执行
bash skills/scripts/refresh-tool-index.sh
bash skills/scripts/master-route.sh \\\\
--hint \"自有 Electron 应用 + 授权实验 API 的安全评估\"
bash skills/scripts/case-init.sh \\\\
--case-name electron-lab-001 \\\\
--preset offline-sample
bash skills/scripts/case-guard.sh work/electron-lab-001
如果目标是 Windows，使用仓库提供的 PowerShell 入口，并把授权范围写入对应的 case 文件。
第二步：用 REA 先回答“客户端到底做了什么”
REA 的安装入口是公开的 npx rea-agents setup。它会让使用者选择要接入的客户端、审阅拟修改的配置，并在需要时单独确认 Hopper 安装或连接。安装完重启对应客户端，再做 readiness 检查。
如果目标是原生二进制，先确认可用 provider：
npx rea-agents setup
rea providers --json
rea capabilities --json
rea doctor --provider ghidra --json
一个从粗到细的原生分析顺序可以是：
rea analyze ./samples/client \\\\
--provider ghidra --json > work/electron-lab-001/analysis.json
rea search ./samples/client \"clipboard\" \\\\
--provider ghidra --json > work/electron-lab-001/search-clipboard.json
rea function ./samples/client main \\\\
--provider ghidra --json > work/electron-lab-001/function-main.json
rea xrefs ./samples/client 0x1000 \\\\
--provider ghidra --json > work/electron-lab-001/xrefs-1000.json
如果交付的是 JavaScript 或 Electron 包，先看应用图和模块关系，再沿着具体能力追踪。下面的 client.asar 是示例路径，实际执行时替换成授权样本：
rea analyze-javascript-application \\\\
./samples/client.asar --json \\\\
> work/electron-lab-001/app-evidence.json
这一步要记录的不是“找到了 clipboard 字符串”，而是类似这样的事实：
E-001
入口：renderer export button
调用链：renderer -> preload -> IPC -> main -> clipboard API
观察：IPC 参数包含文档片段和格式字段
待验证：来源校验是否只在 renderer，服务端是否有独立授权判断
证据：app-evidence.json / function-main.json
REA 的公开 CLI 文档还支持 snapshot。对同一个目标、同一个 provider、同一组参数，保存快照可以减少重复分析，也方便复测时比较结果：
rea analyze ./samples/client \\\\
--provider ghidra \\\\
--snapshot work/electron-lab-001/client-analysis.json \\\\
--json
快照是分析结果的复用手段，不是结论缓存。目标字节、参数或 provider 变化后，必须重新确认覆盖范围。
第三步：把逆向线索翻译成 PentAGI 的验证任务
逆向得到的线索要尽量写成“能被验证的假设”，而不是把一大段伪代码原样塞给 PentAGI。
比如，把“客户端有一个 IPC 剪贴板桥”翻译成：
★
在
api.lab.example.test的 443 和 8443 端口内，验证当前测试账号能否访问另一个测试账号的文档导出接口；只使用提供的两个账号和测试数据，不修改数据，不上传文件，不尝试持久化；记录请求路径、状态码、响应字段、时间和复现条件；如果发现权限边界不明确，立即停止并标为待人工确认。
PentAGI 的 flow 描述应该把以下内容写清楚：
目标：api.lab.example.test
授权：client-authorization-2026-017
范围：443, 8443；仅 lab_only 网络
账号：tester-a、tester-b，均为测试账号
允许：低速服务识别、已知接口的权限验证、读取无害测试数据
禁止：删除/修改数据、口令喷洒、持久化、扩大网段、绕过 MFA
停止：出现真实用户数据、越出目标主机、速率异常、授权不确定
交付：flow 日志、原始响应、证据 ID、复现步骤、限制说明
PentAGI 的安装文档建议先通过 provider 和 embedding 检查，再启动完整 flow。一个最小的本地部署起步顺序是：
mkdir -p pentagi && cd pentagi
curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/.env.example
cp .env.example .env
# 按组织策略填写 provider 和数据库等配置后
docker compose up -d
docker compose logs -f pentagi
# 先验证模型的基本完成、JSON 和工具调用能力
ctester -config ./examples/configs/custom-openai.provider.yml
# 如果改过 embedding，再运行对应的 embedding 检查
etester
PentAGI 官方文档特别提醒了 Docker 权限问题：
把宿主机 Docker socket 直接交给自动化 worker，会让 worker 获得接近宿主机 root 的控制能力。
第四步：把结果升格成可复测的发现
测试报告里最危险的一句话是“存在越权”。它可能是真的，也可能只是客户端显示了一个按钮、接口返回了统一错误，或者测试账号本身权限配置不完整。
更稳妥的做法是把结果拆成五层：
- 观察：原始响应、调用链、日志或函数行为是什么。
- 证据：哪些文件、命令、时间和输出可以复核。
- 假设：为什么这可能影响认证、授权、机密性或完整性。
- 验证：在什么前置条件下复现，使用什么无害测试数据。
- 结论：影响、置信度、限制和修复建议。
可以给每条证据一个稳定 ID：
{
\"id\": \"E-002\",
\"source\": \"pentagi-flow-17\",
\"target\": \"api.lab.example.test:8443\",
\"observed_at\": \"2026-10-15T11:20:00+08:00\",
\"action\": \"GET /v1/test-documents/42\",
\"result\": {
\"status\": 200,
\"contains\": [\"document_id\", \"owner_id\", \"content\"]
},
\"precondition\": \"tester-b token, document 42 owned by tester-a\",
\"safety\": \"read-only test data\",
\"limitations\": [
\"仅验证测试租户\",
\"未尝试批量枚举\",
\"未验证生产配置\"
]
}
随后再写 Finding，而不是把 Finding 当成工具输出：
F-001：对象级授权校验缺失（待修复）
证据：E-002、E-003
影响：具备有效登录态的低权限账号可读取其他测试账号对象
前置条件：知道对象 ID；测试租户开启该接口
验证状态：已在隔离测试环境复现
不确定性：尚未覆盖生产网关和缓存层
建议：服务端按当前主体重新加载对象并执行所有权/租户校验，不能依赖客户端隐藏入口
复测：使用 tester-a 创建对象，tester-b 访问同一对象应返回 403 或等价拒绝结果
使用手册
安装前
reverse-skill：先读当前版本的 README、平台说明和README_AI.md，确认脚本入口、许可证和工具索引方式。REA：准备 Node.js/npm；原生目标再准备 Hopper、Ghidra 或 IDA 之一；Linux 注意进程检查依赖。PentAGI：准备 Docker Compose、至少一个可用的模型 provider、embedding 配置和隔离 worker；不要把生产密钥直接写进文章里的命令。
第一个 case
- 先建立
scope.md、timeline.md、evidence/INDEX.md。 - 先做目标分类和工具 readiness，不要一上来全量安装工具。
- 先用 REA 解决一个具体问题，例如“哪个进程最终调用了剪贴板 API”。
- 把逆向线索改写成 PentAGI 能执行、能停止、能留证的验证任务。
- 先做低速、只读、测试数据验证，再考虑更高风险的动作；风险动作需要额外授权，不由工具默认升级。
- 交付前检查证据 ID、原始输出、时间线、复现条件和限制是否互相对应。
常见失误
把 REA 的伪代码当成最终真相。 伪代码要回到汇编、调用关系和运行结果核对；不能只根据命名推断业务含义。
把 PentAGI 的报告当成已验证漏洞。 报告是执行记录和分析草稿，最终严重性需要人工检查范围、前置条件、影响和复现路径。
把“本地分析”理解成“所有数据都留在本地”。 REA 的目标文件可以在本机分析，但解释这些结果的模型 provider 仍可能在云端；要按组织政策决定是否允许上传代码片段、日志和请求数据。
让自动化 worker 直接控制宿主机 Docker。 这是部署层面的高风险配置，应该在上线前就改掉，而不是等到发生越界后再补救。
只留结论，不留失败尝试。 失败的 provider、未覆盖的函数、被停止的 flow 和未确认的权限边界，都应该进入 timeline 或限制说明。它们决定了别人能否正确理解“没有发现问题”到底意味着什么。
最后
这三个项目真正有价值的地方，不是把渗透测试变成一段更长的自动执行脚本，而是把过去容易散掉的工作重新接起来：
reverse-skill让项目先有范围和路线；REA让客户端和二进制里的线索可解释、可追踪；PentAGI让网络侧验证有隔离、有日志、有产物。
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论