AI 驱动的渗透测试流水线：13 小时 34 个漏洞的实战复盘

Disclaimer: 本文所有渗透测试均在获得书面授权的前提下进行，文中涉及的目标信息已严格脱敏。本文仅用于安全研究和技术交流，请勿用于非法用途。

0x00 背景与动机

一次完整的 Web 渗透测试通常涉及十余种工具的交替使用——nmap 完成端口扫描后，输出需要手动整理给 nuclei；Burp 中观察到的可疑请求，需要手工复制给 sqlmap 做进一步验证。每个工具有各自的参数体系和输出格式，工具之间的上下文是断裂的。

这个过程本身并不复杂，但高度重复且容易遗漏。真正需要安全研究员投入精力的——攻击面分析、攻击链构造、漏洞利用策略判断——反而被大量的工具操作所稀释。

我们尝试用一种不同的方式来组织这个流程：将工具编排交给 AI，让研究员回归到分析和决策本身。

具体而言，我们以 Claude Code 作为交互入口和编排中枢，通过 MCP（Model Context Protocol）协议同时对接两个工具后端：

HexStrike AI MCP — 封装了 150+ 安全 CLI 工具，运行在 Docker 容器中
Burp Suite MCP — PortSwigger 官方 MCP server，提供代理、Repeater、Scanner、Collaborator 能力

操作员用自然语言描述意图，AI 选择合适的工具、构造参数、解析输出并串联上下文，最终生成结构化的渗透测试报告。

我们将这套环境的 Docker 化部分开源在 unisecTeam/pentestAIO，本文是对整个流水线的设计思路与实战复盘。

0x01 架构总览

整个系统分为三层：

Host (操作员)
├── Claude Code CLI              ← 操作员唯一交互入口
│   ├── CLAUDE.md                ← 渗透测试 SOP（指导 AI 行为）
│   └── MCP Client
│       ├── hexstrike-ai MCP ──HTTP──→ Docker 容器 Flask API (:8888)
│       └── burp MCP ─────HTTP──→ Burp Suite MCP Server (:9876)
│
├── Burp Suite (GUI)             ← 代理 :8080, MCP :9876
│
└── Docker Container (--network=host)
    ├── HexStrike Flask API      ← 接收 MCP 指令，调度 CLI 工具
    └── 40+ CLI Tools
        nmap, masscan, nuclei, httpx, ffuf, gobuster, feroxbuster,
        sqlmap, nikto, wpscan, hydra, amass, subfinder, katana ...

为什么选择 MCP 而非直接执行命令

直接让 AI 通过 docker exec nmap ... 执行命令是可行的，我们也保留了这条降级路径。但 MCP 提供了几个重要的结构性优势：

结构化输入输出 — MCP 工具定义了参数 schema，AI 无需记忆每个 CLI 工具的参数格式；返回值为结构化 JSON，省去了对文本输出的正则解析
安全边界 — MCP server 可以在参数层面做校验和过滤，比直接暴露 shell 更加可控
可组合性 — 多个 MCP server 可以并存，Claude Code 根据场景自动选择。HexStrike 负责工具执行，Burp 负责流量分析，职责分明

为什么用 Docker 隔离

渗透测试工具链体量庞大（Kali 全量安装超过 15GB），且部分工具需要 root 权限和 raw socket。Docker 容器的价值在于：

环境一致性 — docker compose up 即可拉起全套工具链，不影响主机环境
安全隔离 — 工具运行在容器内，即使 AI 构造了错误命令也不会损害主机
可复现 — 团队共享同一份 Dockerfile，消除”在我机器上能跑”的问题

我们选择 --network=host 模式，使容器共享主机网络栈。这样容器内工具可以直接扫描目标，也可以通过 127.0.0.1:8080 走主机上的 Burp 代理，无需额外的网络配置。

0x02 双 MCP 协同：HexStrike + Burp

这是整个架构中最关键的设计：两个 MCP server 之间没有直接通信通道，Claude Code 作为唯一的 orchestrator 在它们之间传递上下文和协调执行。

HexStrike MCP

HexStrike AI 是一个面向 AI Agent 的安全工具框架，通过 Flask API 暴露 150+ 安全工具的调用接口。其 MCP server（hexstrike_mcp.py）以 stdio 模式运行在主机上，将 Claude Code 的 MCP 调用翻译为 HTTP 请求发往容器内的 Flask API。

核心工具映射：

MCP 函数	底层 CLI 工具	用途
`nmap_scan()`	nmap	端口扫描、服务识别
`nuclei_scan()`	nuclei	模板化漏洞扫描
`ffuf_scan()`	ffuf	Web 模糊测试
`sqlmap_scan()`	sqlmap	SQL 注入检测
`httpx_scan()`	httpx	HTTP 探测、指纹识别
`subfinder_scan()`	subfinder	子域名枚举
`feroxbuster_scan()`	feroxbuster	递归目录发现
…	…	共 150+

Burp MCP

PortSwigger 官方提供的 MCP server （PortSwigger/mcp-server），直接与 Burp Suite 通信。主要能力包括：

Proxy History 分析 — AI 可以检索 Burp 代理历史中的请求/响应，识别被动漏洞
Repeater — 精确修改和重放 HTTP 请求，用于漏洞验证
Active Scanner — 对指定端点发起 Burp 主动扫描
Collaborator — 用于 OOB（Out-of-Band）漏洞检测

在渗透测试场景下，使用 Burp MCP 还有个很有意思的的点，在于撰写报告时可以直接用它去发请求，然后测试人员截图，极大提升了报告梳理的效率。

编排策略

Claude Code 遵循 CLAUDE.md 中定义的工具选择优先级：

标准扫描 → 优先使用 HexStrike MCP（结构化 JSON 输出，便于后续处理）
需要记录流量 → 使用 Burp MCP 的 send_request，或让 HexStrike 工具通过 --proxy http://127.0.0.1:8080 将流量引入 Burp
MCP 未暴露的高级参数 → 降级到 docker exec pentest-aio <command>
Burp 专属操作 → 始终使用 Burp MCP

CC 并非机械地轮询工具，而是根据当前阶段和已有信息选择最合适的执行通道。

0x03 CLAUDE.md：给 AI 定义渗透测试 SOP

CLAUDE.md 是 Claude Code 的项目级指令文件，置于工作目录根下，每次会话自动加载。我们用它定义了完整的渗透测试 SOP（Standard Operating Procedure），使 AI 在开始工作时就具备清晰的流程框架和行为边界。

安全护栏

这是我们投入精力最多的部分。AI 参与渗透测试，安全边界的可靠性是前提。

Scope 强制校验：AI 在发起任何扫描前，必须读取 results/scope.json 验证目标处于授权范围内。文件不存在则中止操作并询问操作员。

{
  "targets": ["172.18.12.15"],
  "ports": "all",
  "notes": "内网渗透测试，已获授权"
}

Exploit gating：AI 可以自动完成漏洞分析和 PoC 构造，但发送 exploit payload 必须经过人工确认。AI 会展示完整的 payload 内容、目标地址及预期影响，等待操作员明确授权后才执行。

Safety hook：通过 Claude Code 的 hook 机制，在 Bash 命令执行前拦截危险操作（rm -rf、dd、mkfs 等），从系统层面提供兜底保护。

五阶段工作流

Phase 0: 初始化
  ↓ 确认范围、检查工具可用性、验证 MCP 连接
Phase 1: 侦察
  ↓ 子域名、端口、技术指纹、目录、API 文档
Phase 2: 漏洞扫描
  ↓ nuclei 模板扫描、Burp 主动扫描、OWASP Top 10 检查
Phase 3: 漏洞利用（人工门控）
  ↓ PoC 构造、Repeater 验证、攻击链串联
Phase 4: 报告
  ↓ Markdown 报告 + .docx 模板填充

结构化输出

所有发现统一使用 JSON schema 记录，确保格式一致且便于后续处理：

{
  "id": "VULN-001",
  "title": "越权访问 - 用户数据泄露",
  "severity": "Critical",
  "cvss_score": 9.1,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
  "type": "CWE-862",
  "reproduction_steps": ["1. ...", "2. ..."],
  "remediation": "...",
  "tools_used": ["curl", "nuclei"]
}

工作区目录结构

<project-root>/
├── CLAUDE.md                    ← 渗透测试 SOP
├── .mcp.json                    ← MCP 配置
├── results/
│   ├── available-tools.json     ← 容器内工具清单（自动生成）
│   ├── scope.json               ← 授权范围
│   ├── recon/                   ← 侦察阶段输出
│   ├── vuln/                    ← 漏扫阶段输出
│   └── exploit/                 ← 利用阶段输出
├── evidence/{VULN-ID}/          ← 按漏洞 ID 归档的证据
├── templates/*.docx             ← 报告模板
└── scripts/                     ← 辅助脚本

报告生成

Phase 4 中，AI 首先生成 Markdown 格式的完整渗透测试报告。如果 templates/ 目录下存在 .docx 模板，AI 会使用 Claude Code 内置的 /docx skill 自动完成模板填充——读取模板结构（标题、表格、占位符），将漏洞发现映射到对应章节，生成格式化的 Word 文档。这个过程不依赖外部 Python 库或第三方工具，是 Claude Code 原生支持的能力。

0x04 实战：某公司招聘管理系统渗透测试

以下是使用这套流水线对一个即将上线的内部系统进行渗透测试的实战记录，全程除了几次人工的决策和接管外，直到往结果上贴图，都没有人工的介入。

目标概述

项目	内容
目标	`http://172.18.12.15/`
系统	某公司招聘管理系统
测试类型	内网渗透测试（黑盒 + 灰盒）
技术栈	Vue.js + Spring Boot (JeecgBoot) + MySQL 5.7 + nginx
测试账号	3 个不同权限角色（求职者 / 人力 / 部门）
测试周期	13 小时（含报告）

漏洞发现汇总

13 小时测试期间，共发现 34 个安全漏洞：

严重程度	数量	典型漏洞
严重	6	全量用户数据越权泄露、任意文件读取（root 权限）、生产配置凭据泄露、数据库直连
高危	11	JDBC SSRF + 反序列化、SQL 注入、Swagger 文档未授权、Druid 弱口令、简历水平越权修改
中危	12	存储型 XSS、签名密钥泄露、用户枚举、定时任务信息泄露
低危	2	版本信息泄露、前端配置泄露
信息	1	多余端口暴露

亮点发现

以下选取几个有代表性的发现展开，重点关注 AI 在测试过程中的编排逻辑和推理能力。

越权发现：3 角色 × 200+ 端点的权限矩阵

系统基于 JeecgBoot 框架，AI 在侦察阶段通过 Swagger 文档识别了 200+ 个 API 端点。随后自动执行了一项系统性的测试：使用 3 个不同权限的测试账号逐一访问所有端点，对比每个端点在不同角色下的响应差异。

测试结果表明，最低权限的求职者账号可以通过 /sys/user/list 获取系统全部 900+ 个用户的详细信息（含真实姓名、手机号、邮箱、工号），通过简历列表接口获取全部 400+ 份简历的完整 PII（含身份证号）。

这类”权限矩阵穷举”对人工而言耗时且枯燥，但恰恰是 AI 能稳定发挥的场景——不会遗漏端点，不会混淆角色，每一条测试都留有完整记录。

攻击链：文件读取 → 配置泄露 → 数据库接管 → 内网 SSRF

这是本次测试中最具深度的一条攻击链。AI 在发现第一个入口点后，基于已有信息逐步推进：

STEP 1: 发现 getCarouselImage 接口存在路径穿越（无过滤，可读取任意文件）
  ↓ 验证：读取 /etc/shadow 成功 → 确认 Java 进程以 root 权限运行
STEP 2: 读取 /proc/self/cmdline → 获取 JAR 路径和工作目录
  ↓ 推理：Spring Boot 项目，配置文件通常位于同目录
STEP 3: 读取 application-prod.yml → 获取数据库密码、邮件凭据、API Key 等
  ↓ 关联：数据库端口 3306 在侦察阶段已被 nmap 标记为对外开放
STEP 4: 使用泄露凭据直连 MySQL → 获得业务库的 ALL PRIVILEGES
  ↓ 推理：JimuReport 存在 API 数据集功能，可通过修改 api_url 触发 SSRF
STEP 5: 修改 jimu_report_db 表中的数据集 URL → 触发服务端 HTTP SSRF

从一个图片接口的路径校验缺失，到最终实现内网 SSRF 和数据库完全控制，每一步的推进都是 AI 基于已知信息做出的合理推断。关键决策点（如是否实际连接数据库）均经过操作员授权确认。

值得注意的是，AI 能够将跨阶段的信息有效关联——Phase 1 中 nmap 发现的 3306 端口开放，在 Phase 3 中与配置文件泄露的凭据结合，形成了完整的利用路径。这种上下文保持能力是传统工具链难以提供的。

跨会话协同：JAR 包代码审计赋能渗透测试

在上述攻击链的 STEP 2 中，AI 通过文件读取获取了目标系统的 JAR 包路径。我们通过文件读取接口将 JAR 包下载到本地，随后开启了一个独立的 Claude Code 会话，专门用于对这个 JAR 包进行代码审计。

这个代码审计会话产出了一份结构化的审计报告，涵盖了以下关键发现：

JWT 签名机制：通过反编译 JwtUtil.class 和 ShiroRealm.class，确认 JWT signing secret 是用户的数据库密码哈希（LoginUser.getPassword()）。这个发现直接支撑了后续的 JWT 伪造尝试。
Shiro 过滤链配置：识别出哪些路径被设为 anon（匿名可访问），为权限测试提供了精确的目标清单
JimuReport 端点清单：从代码层面确认了 testConnection、queryFieldBySql 等高危端点的存在及其参数结构

审计报告随后被导入回渗透测试的 Claude Code 会话中。AI 读取报告后，将代码层面的发现与黑盒测试中的观察进行交叉验证，显著提高了后续测试的针对性和效率。

这种”黑盒渗透 + 白盒审计”的跨会话协同模式，是我们在实践中自然形成的工作方式：两个 Claude Code 会话各有侧重，通过文件系统共享中间产物，最终形成互补。

JDBC SSRF 与 Rogue MySQL 反序列化验证

JimuReport 的 /jmreport/testConnection 端点允许低权限用户发起任意 JDBC 出站连接。AI 识别该端点后，结合其对 JDBC 攻击模式的理解，提出了完整的利用路径：

在攻击机启动 Rogue MySQL Server（伪造 MySQL 协议服务端）
通过 testConnection 使目标服务器反向连接到攻击机
Rogue MySQL Server 在握手阶段返回恶意序列化数据（ysoserial payload）

操作员确认后执行验证。目标服务器成功建立了到攻击机的 TCP 连接，Rogue MySQL Server 接收到了来自 172.18.12.15 的连接请求。ysoserial CC5 payload 触发后返回了非标准错误码 2121，表明反序列化链被部分执行。

进一步测试确认 MySQL 和 PostgreSQL 两种 JDBC 驱动均可使用，且低权限用户还能通过 /sys/dataSource/add 注册指向攻击机的恶意数据源——多个独立的漏洞点在 AI 的分析下被关联为一条完整的攻击链。

宝塔面板凭据链：从文件读取到服务器管理

这条攻击路径展示了 AI 如何利用对运维工具的知识来扩展攻击面。

在 nmap 侦察阶段发现 888 端口返回 nginx 403 时，AI 注意到这是宝塔面板（BT Panel）的默认 phpMyAdmin 端口。这个判断在后续的文件读取阶段得到了验证。AI 针对性地读取了宝塔面板的关键文件：

读取路径	获取内容
`/www/server/panel/data/default.db`	SQLite 数据库：管理员密码哈希 `MD5("admin")`、MySQL root 密码
`/www/server/panel/config/api.json`	API 密钥、Bind Token
`/www/server/panel/data/admin_path.pl`	安全入口路径

这些信息组合起来意味着：如果能通过 SSRF 访问到 127.0.0.1:8888（宝塔面板端口，防火墙仅放行本地访问），就可以使用已获取的 API 密钥调用面板 API，实现远程命令执行。

AI 在这里的价值不仅在于执行文件读取操作本身，更在于它知道”宝塔面板的数据库在哪、配置文件在哪、API 认证机制是什么”——这些运维侧的知识帮助它在获得文件读取能力后，迅速定位到高价值目标。

JWT 伪造：一次有价值的”失败”

并非所有攻击路径都能走通，但走不通的路径同样有价值。

AI 发现 AES 加密密钥泄露后，自动评估了 JWT 伪造的可行性：

分析 JWT 结构：HS256 签名，payload 仅含 username + exp
逐一尝试 AES Key、JeecgBoot 默认密钥（10+ 个）、Shiro 默认密钥 → 均失败
使用 rockyou.txt 字典（14M 条目）暴力破解 → 失败

最终，通过前述代码审计确认 JWT Secret 为用户的数据库密码哈希后，AI 从 InnoDB 数据文件中提取了 admin 的密码哈希，成功伪造了签名有效的 Token。然而系统额外实现了 Redis Token 白名单机制——伪造的 Token 不在 Redis 缓存中，请求被拦截。

这个案例值得记录，原因有两点：其一，AI 展现了系统性的穷举能力，不会因为几次失败就放弃一条攻击路径；其二，“走到最后一步被防御机制拦截”本身就是有意义的安全发现——它表明该系统的 JWT 安全依赖于 Redis 白名单这一单点，如果 Redis 存在未授权访问（本例中 Redis 无密码但仅监听 localhost），则整条防线将被突破。

nginx 配置错误 + 文件上传：潜在的 RCE 组合

最后一个值得提及的发现是一个尚未完全串通、但攻击路径清晰的潜在 RCE 组合。

AI 通过文件读取获取了 nginx 站点配置，发现 Vue.js 前端目录（纯静态 SPA）中误启用了 PHP-FPM。与此同时，文件上传接口虽然阻止了 .php 扩展名，但 AI 通过测试发现 PHP 短标签（<?=...?>）可以绕过内容检测，成功上传到服务器。

这两个独立发现如果结合——将含有 PHP 短标签的文件写入 nginx 处理的目录——理论上可以实现远程代码执行。虽然在本次测试中上传目录与 PHP-FPM 处理路径不一致，未能完成最后一步，但 AI 仍然将这两个发现关联起来，在报告中标注为”需要关注的组合风险”。

这体现了 AI 在安全评估中一个有用的特质：它不仅逐个报告漏洞，还会尝试在发现之间建立联系，即便这些联系尚未被完整验证。

0x05 效果评估

AI 显著提效的环节

环节	人工耗时（估）	AI 辅助耗时	提效原因
端口扫描 + 指纹识别	30min	5min	自动编排 nmap → httpx → whatweb
252 个 API 端点的权限矩阵测试	4-6h	40min	批量请求 + 自动对比响应差异
nuclei 模板扫描	20min	5min	自动选择模板集、解析结果
攻击链串联（文件读取→配置→DB）	需要同等思考	关联更快	AI 在上下文窗口内持有全部阶段的发现
报告撰写	4-8h	1h	结构化数据自动填充模板

仍然需要人工介入的环节

Exploit 确认与发送 — 这是设计层面的选择，不应全自动化
业务逻辑漏洞 — AI 能发现技术层面的访问控制缺陷，但”这个字段是否构成敏感信息泄露”需要业务上下文支撑
复杂利用链的实际执行 — 如 Rogue MySQL Server 搭建、gadget chain 选择、序列化 payload 调试等，AI 提供了路径，但执行仍依赖操作员
威胁建模 — 泄露的邮箱/电话可能带来的社会工程学风险，需要结合组织背景做综合判断

关于误报与漏报

在本次测试中，AI 的误报率接近于零——每个发现均附有实际的请求/响应证据，证据不成立的发现不会进入报告。漏报方面，AI 可能遗漏需要深度业务理解的逻辑漏洞（如复杂审批流程的绕过），这是当前 LLM 在渗透测试场景中的固有局限。此外，AI 在初期对部分信息泄露类漏洞的严重程度评估偏保守，经人工调整后修正了评级。

0x06 经验与踩坑

MCP 超时处理

大范围扫描（如 masscan 全端口、nuclei 全模板集）容易触发 MCP 的默认超时（30s）。我们将 mcp.json 中的 timeout 调至 300s，并在 CLAUDE.md 中引导 AI 对大范围任务进行拆分执行。

多角色 Token 管理

3 个测试账号对应 3 套 JWT Token，AI 需要在上下文中准确维护当前使用的角色，切换时容易混淆。我们的做法是将所有账号信息记录在 results/scope.json 中，AI 在每次发送请求前明确标注当前使用的角色。

Docker network=host 的取舍

--network=host 使容器共享主机网络栈，容器内的工具可以访问主机上的所有服务。这在渗透测试场景下是优势（工具可直接走 Burp 代理），但也意味着容器内的进程理论上可以访问主机服务。对安全性要求更高的部署场景，建议改用 bridge 网络 + 显式端口映射。

两个 MCP 的协同边界

HexStrike 和 Burp 的能力存在部分重叠（均可发送 HTTP 请求），各自也有盲区：

Burp 更擅长：流量分析、被动漏洞检测、精确 payload 构造
HexStrike 更擅长：批量扫描调度、CLI 工具编排、结构化结果输出

AI 在多数情况下能够合理选择，但在需要精确控制请求编码或处理复杂的多步 HTTP 交互时，有时需要操作员提示切换到 Burp Repeater。

CLAUDE.md 的迭代过程

CLAUDE.md 并非一次成型，而是经历了多轮迭代：

V1：基本的工具列表和安全规则 → AI 能用工具但不知道该按什么顺序组织工作
V2：加入五阶段工作流和输出规范 → 流程清晰了，但阶段间的衔接不够自然
V3：加入 Session Start Checklist、Resumability 和工作区目录规范 → AI 能够跨会话保持进度

一个关键体会是：CLAUDE.md 本质上是给 AI 写的 playbook，它的具体程度直接决定了 AI 行为的可控性和一致性。

有兴趣的读者可以联系 Unisec Team 获取有关系统提示词的详细信息。

0x07 当前局限

不擅长的漏洞类型

内存破坏类（Buffer Overflow、Use After Free 等）— 需要二进制分析和调试能力，不在当前工具链覆盖范围内
复杂业务逻辑漏洞 — 需要对业务流程有深入理解，AI 缺乏必要的领域上下文
时序敏感型漏洞 — 如条件竞争（Race Condition），需要精确的并发控制

MCP 覆盖盲区

HexStrike 的 150+ 工具覆盖面较广，但部分 MCP 函数暴露的参数不够完整。nmap 的 NSE 脚本参数、sqlmap 的 tamper 脚本选择等高级功能，仍需降级到 docker exec 直接调用。

大模型幻觉

在渗透测试中，幻觉的代价较高——一个不存在的漏洞会浪费操作员的验证时间，也会损害报告的可信度。我们通过两个机制缓解这一风险：

Evidence-first — CLAUDE.md 要求每个发现必须附有实际的请求/响应证据
结构化输出 — JSON schema 强制填写 reproduction_steps，无法给出复现步骤的发现会被标记为待验证

本次测试中未观察到幻觉导致的误报，但这仍然是需要持续关注的风险，尤其是在目标系统较为复杂的场景下。

0x08 未来计划

集成更多 MCP — 如 Caido MCP（轻量级 Burp 替代方案）、自定义 fuzzer MCP 等
多目标并行测试 — 当前每次只能测试一个目标，计划通过多容器实例支持并行
知识库积累 — 将历史测试中的 payload 模式、WAF 绕过技巧沉淀为可复用的上下文
报告模板扩展 — 适配更多甲方的 .docx 报告模板

0x09 总结

AI 不会取代渗透测试工程师，但它正在改变渗透测试的工作方式。

这套流水线的核心思路是：AI 负责工具编排与上下文管理，研究员负责判断与决策。AI 承担工具调度、参数构造、结果解析、跨阶段信息关联等重复性工作；操作员把控范围确认、exploit 授权、攻击路径判断、报告审核等需要专业判断的环节。

在本次实战中，这套方案帮助我们在 13 小时内完成了从侦察到报告的完整渗透测试流程，发现了 34 个安全漏洞（含 6 个严重、11 个高危），并构建出多条跨阶段的攻击链。其中，AI 的上下文保持能力和系统性穷举能力是最显著的效率提升点。

工具是手，模型是脑，操作员是方向。三者协同，才是这套流水线的真正价值所在。

开源地址：unisecTeam/pentestAIO

致谢：本项目基于 HexStrike AI by @0x4m4 构建，感谢其开源贡献。