autopentest-AI

AutoPentest

一个代理渗透测试MCP服务器，使用完整的OWASP web安全测试指南和PortSwigger web安全学院技术参考，自动进行web应用程序渗透测试。

将它指向一个目标——它抓取你的应用程序，映射每个端点，然后生成角色专用代理（Scout、Analyzer、Exploiter、Reporter）来测试XSS、SQLi、SSRF、SSTI、IDOR等。没有误报——每一项发现都有真实、可重复的证据支持，每个阶段都有质量门强制证明。包括31个PortSwigger技术指南、12个供应商的自适应WAF规避、跨阶段漏洞链和风险加权端点优先级。使用API Claude Code运行它，或者使用Ollama模型完全离线。

把它想象成： 高级pentester的方法论被编码到MCP服务器中——109个OWASP测试、31个PortSwigger攻击技术指南、68多个MCP工具、27个安全工具、4个专门的代理角色、7个结构化阶段、自动质量保证和零上下文最终审查。

______________________________________________________________________

目录

• 为什么选择AutoPentest？
• 建筑
• 特性
• 代理角色系统
• 快速开始
• 用法
• 测试阶段
• 安全工具
• WSTG知识库
• PortSwigger技术指南
• 质量保证体系
• 基准测试
• 示例报告
• 配置
• 多域测试
• 故障恢复
• 项目结构
• 需求
• 常见问题解答
• 免责声明

______________________________________________________________________

为什么选择AutoPentest？

手动渗透测试很彻底，但速度很慢。自动扫描仪很快，但很浅。AutoPentest弥合了这一差距：

|功能|手动Pentest |自动扫描仪|自动Pentest| |------------|:-:|:-:|:-:| |完整的OWASP WSTG覆盖范围|取决于测试人员|部分| 109测试 | |业务逻辑测试|是|否| 是 | |多步开发|是|有限| 是 | |漏洞链接|是|否| 是 | |循证调查结果|是|模板输出| 可再现的curl命令 | |一致的质量|变化|是| 阶段关卡+最终裁判 | |速度|天数|分钟| 小时 | |跨域身份验证（SSO/OIDC）|手动设置|通常会失败| 自动化处理 |

______________________________________________________________________

建筑

┌─────────────────────────────────────────────────────────────┐
│                  LLM Orchestrator (Claude)                  │
│                                                             │
│  Reads CLAUDE.md workflow, manages phases,                  │
│  spawns role-specialized subagents                          │
└──────────┬──────────┬──────────┬──────────┬─────────────────┘
           │          │          │          │
     ┌─────▼────┐ ┌───▼─────┐ ┌──▼───────┐ ┌▼─────────┐
     │  Scout   │ │Analyzer │ │Exploiter │ │ Reporter │
     │  (recon) │ │ (vuln   │ │ (proof)  │ │ (QA /    │
     │          │ │  disc.) │ │          │ │  judge)  │
     └──────────┘ └─────────┘ └──────────┘ └──────────┘
           │          │          │          │
           │     MCP  │          │     MCP  │
           ▼          ▼          ▼          ▼
┌──────────────────────────┐  ┌──────────────────────┐
│  WSTG MCP Server         │  │  Playwright MCP      │
│  (68+ tools)             │  │  (Browser Testing)   │
│                          │  │                      │
│  ◦ 109 WSTG tests        │  │  ◦ DOM XSS proof     │
│  ◦ 31 technique guides   │  │  ◦ Clickjacking      │
│  ◦ Task tree             │  │  ◦ JS-rendered auth  │
│  ◦ Knowledge graph       │  └──────────────────────┘
│  ◦ WAF evasion           │
│  ◦ Tool output parser    │
│  ◦ Results verification  │  docker exec
│  ◦ Context compression   │       │
│  ◦ Endpoint priority     │       ▼
│  ◦ Quality gates         │  ┌──────────────────────┐
│  ◦ Report generation     │  │  autopentest-tools   │
└──────────────────────────┘  │  (Docker Container)  │
                              │                      │
                              │  27 security tools:  │
                              │  nuclei, sqlmap,     │
                              │  dalfox, katana,     │
                              │  ffuf, nmap ...      │
                              │                      │
                              │  Burp proxy          │
                              │  passthrough         │
                              └──────────────────────┘

它是如何工作的：

1. 克劳德代码 读取 CLAUDE.md 获取完整的pentest方法论，并协调7个阶段的工作流程
2. 角色专业分代理人 （侦察员、分析器、漏洞利用者、报告者）使用专用提示模板、工具指南和反模式执行重点任务
3. WSTG MCP服务器 （68多种工具）提供OWASP测试程序、31个PortSwigger技术指南、分层任务树、知识图、WAF规避、端点优先级、结果验证、上下文压缩、质量门和报告生成
4. Docker容器 运行所有27个安全工具——流量可选择通过Burp Suite进行被动监控
5. 剧作家MCP 处理基于浏览器的测试（DOM XSS、点击劫持、JS呈现的登录页面）

______________________________________________________________________

特性

全面的OWASP覆盖范围

• 109个WSTG测试用例 从信息收集到API测试的12个类别
• 每个测试都包括分步CLI程序、特定于上下文的有效载荷、检测标准和严重性量规
• 使用条件触发器对测试进行优先级排序（必须/应该），因此不会跳过任何相关内容

31个端口旋转攻击技术指南

• 来源于 PortSwigger网络安全学院 --检测方法、利用技术、有效载荷、备忘单和WAF绕过模式
• 按漏洞类（SQLi、XSS、SSRF、JWT、OAuth等）组织，以便在测试期间直接使用
• 集成到每个测试阶段——代理在测试每个漏洞类之前自动加载相关技术指南
• 特定于数据库/平台的有效载荷表（SQLi的Oracle vs MySQL vs PostgreSQL vs MSSQL，SSTI的Jinja2 vs Twig vs Freemarker等）
• 按旁路级别组织的WAF旁路模式（基本→ 中间的→ 高级）

27个预配置的安全工具

• 所有工具都预装在一个Docker镜像中-- make setup 你准备好了
• 按阶段组织的工具：发现、注入测试、身份验证、加密、API测试
• 用于被动流量监控的自动Burp Suite代理集成

结构化7阶段工作流程

• 阶段0： 应用程序发现和映射
• 第一阶段： 信息收集与侦察
• 第二阶段： 配置和部署测试
• 第三阶段： 身份、身份验证、授权和会话管理
• 第四阶段： 输入验证测试（流水线XSS/SSQLi/SSRF流水线）
• 第五阶段： 错误处理、密码学、业务逻辑、客户端和API测试
• 第6阶段： 覆盖范围验证和报告
• 第7阶段： 终审评审与补救

质量保证体系

• 自动相位门 --每个阶段在继续之前都必须通过质量检查
• 质量审核员 每个阶段过渡的子代理都会识别差距并提出改进建议
• 终裁 --零上下文代理像外部QA审查员一样，对整个参与进行冷审查
• 排气门 --“不易受攻击”需要证明测试工作足够（最低限度的技术和绕过尝试）

循证调查结果

• 每个发现都需要可重复的curl命令和完整的请求/响应证据
• 三级分类： 已探索（已证实的影响）、潜在（被控制阻止）、失败（控制保持）
• 抗幻觉框架 --“无漏洞=无发现”在各个级别强制执行
• 在记录任何发现之前，验证每个漏洞类别的证据清单

角色专业分代理人

• 4个专用角色 使用集中的提示模板、工具指南和反模式：

- 侦察兵 --仅侦察，在不发送有效载荷的情况下绘制攻击面（阶段0-1） - 分析器 --使用金丝雀/目击者有效载荷识别潜在的接收器，构建利用队列（第2-5阶段分析） - 剥削者 --消耗分析器输出，用证据证明利用，记录确认的发现（第4阶段利用） - 记者 --质量审查和最终评判，在不发送请求的情况下审查数据（QA+事后报告）

• 分析和利用之间的验证检查点可防止浪费精力
• 每个角色都有明确的允许/限制工具列表和输入/输出合同

管道开采（第四阶段）

• 3独立 两级管道 并行运行：XSS、注入（SQLi/CMDi）、SSRF/SSTI
• 每个管道：分析器（发现→ 分析→ 队列）→ 验证检查点→ 漏洞利用者（exploit→ log)
• 每个管道都加载其PortSwigger技术指南，以了解检测方法、备忘单和WAF绕过模式
• 跨所有管道共享WAF情报
• 13种水槽类型的上下文感知见证有效载荷

自适应WAF规避

• 自动WAF指纹识别 根据响应标头、正文和状态代码，确定12家WAF供应商（Cloudflare、AWS WAF、Akamai、Imperva、ModSecurity、F5、FortiWeb、Sucuri、Barracuda、Wordfence、NAXSI、Citrix）
• 供应商特定的旁路有效载荷 按复杂性级别组织（基本→ 中间的→ 高级）
• 通过可交付系统在所有代理之间共享WAF情报
• 代理在第一个块响应时自动识别WAF，并切换到定制的旁路有效载荷

跨阶段知识图

• 实体关系图 跟踪端点、参数、技术、发现、Cookie、域和用户角色
• 自动漏洞链 通过具有7个预定义链模式的BFS路径查找：

- XSS+缺少CSP，XSS+弱cookie（无HttpOnly），开放重定向+OAuth回调 - IDOR+管理员角色，SSRF+云元数据，无锁定+无MFA，CORS+敏感端点

• 当链接显著增加影响时，严重性升级
• 在整个测试过程中填充，在第4阶段后查询以进行链发现

分层任务树

• 持久的树结构（阶段作为分支，测试作为叶子）可以防止LLM深度优先偏差和上下文丢失
• 主代理保持战略宏观视野；子代理仅更新其分配的叶子节点
• 自动传播：当所有子项完成时，父项自动完成
• 知情决策的阶段级完成百分比

端点风险优先级

• 按风险对端点进行评分和排序，以进行优先测试——首先测试最高风险
• 评分因素：参数计数、技术风险指标、污染链置信度、工具收敛、身份验证要求、可注入参数名称
• 集成到第0阶段端点图生成中

工具输出解析

• 13个内置解析器 用于常见的CLI工具（nmap、nucleus、sqlmap、ffuf、httpx、whatweb、testssl、nikto、dalfox、katana、gau、wapiti、commix）
• 将原始工具输出压缩3-5x，同时保留关键发现、终点和错误
• 可配置的详细程度：摘要（~15行）、详细（~50行）、完整（完整解析输出）

CLI工具结果验证

• CLI工具输出质量的自动验证--检测空输出、代理错误、权限问题和可疑结果
• 每个工具10个验证器 （nmap、nucleus、sqlmap、ffuf、feroxbuster、testssl、dalfox、wapiti、katana、httpx）以及更正的命令建议
• 当工具产生空的或可疑的输出时，验证器会建议修复（例如，添加 -Pn 对于nmap，删除代理env变量，尝试不同的标志）
• 集成到工具执行工作流中——代理调用 verify_tool_result() 每次CLI工具运行后

渐进式上下文压缩

• 阶段总结 （约500-800字）当相位门通过时自动生成——以压缩形式捕获发现、覆盖率、工具结果和攻击面
• 通过用结构化摘要替换原始历史数据，防止长期参与中的上下文降级
• get_engagement_summary() 将所有阶段摘要合并为一个概述，以注入新的子代理提示
• 摘要作为可交付成果存储——任何下游代理都可以访问，而不需要完整的参与历史记录

反事实分析（第二遍发现）

• 在Analyzer完成并发现漏洞后 第二分析器 生成了“假设这些漏洞已修复”的指令
• 反事实分析器搜索 额外的 漏洞：不同的端点、不同的参数、不同的注入上下文、逻辑缺陷
• 结果将附加到现有的漏洞利用队列中（通过端点+参数和自动递增的ID进行自动合并和重复数据删除）
• 基于PenHeal消融研究，在反事实提示下，漏洞覆盖率提高了71%

多域支持

• 自动检测和处理SSO/Outh/OIDC/SAML
• 按域范围注册、爬网和测试
• 用于跨域会话持久化的Cookie jar管理
• 6级身份验证失败升级（替代授权→ PKCE → 无头浏览器→ 令牌提取→ 用户配置→ 未经身份验证）

碰撞安全参与管理

• 加的 findings.md 和 progress.log 在撞车事故中幸存下来
• 具有回滚功能的Git工作区检查点
• 中断时自动恢复 — resume-prompt.md 在每个检查点自动生成完整上下文（目标、凭据、当前阶段、剩余测试、范围）。粘贴到新会话中，以继续您停止的位置
• 中期检查点粒度——跟踪一个阶段内完成的测试，而不仅仅是阶段级状态
• 每个MCP工具调用的完整审计跟踪，带有时间戳

专业报道

• Markdown报告，包括执行摘要、严重性调查结果、测试覆盖率矩阵和工具覆盖率
• 按类别覆盖百分比和差距分析
• 记录漏洞链分析
• 包括终审法官意见和质量说明

______________________________________________________________________

代理角色系统

AutoPentest使用4个专门的代理角色，而不是通用的子代理。每个角色都有一个专门的提示模板，其中包含重点工具指导、输入/输出契约和反模式。

管道是如何工作的

第4阶段（最高影响测试）对每个漏洞类别使用两阶段管道：

┌──────────────────────────────────────────────────────────────┐
│                    Pipeline 1: XSS                           │
│                                                              │
│  Analyzer (75 turns)          Exploiter (75 turns)           │
│  ┌─────────────────────┐      ┌─────────────────────┐        │
│  │ Discover endpoints  │      │ Load Analyzer queue │        │
│  │ Send canary payloads│─────▶│ Attempt exploitation│        │
│  │ Build exploit queue │ gate │ Prove impact        │        │
│  │ Save deliverable    │      │ Log findings        │        │
│  └─────────────────────┘      └─────────────────────┘        │
│                          ▲                                   │
│               validate_exploitation_queue()                  │
└──────────────────────────────────────────────────────────────┘

三条管道（XSS、注入、SSRF/SSTI）并行运行。Analyzer和Exploiter之间的验证检查点确保只有格式良好的漏洞利用队列才能继续进行。

角色边界

每个角色都有通过提示强制执行的明确工具限制：

• 侦察兵 无法呼叫 log_finding() 或发送攻击有效载荷
• 分析器 可以记录配置发现（缺少标头、弱Cookie），但不能记录注入类发现
• 剥削者 无法创建新队列--它们消耗Analyzer生成的内容
• 记者 无法向目标发送HTTP请求--它们仅审查数据

对于CTF挑战和小型应用程序（\ | | **Ssrfmap** |SSRF利用| -r request.txt | | **nosqli** |NoSQL注入| -u | | **crlfuzz** |CRLF注入/HTTP拆分| -u | | **走私者** |HTTP请求走私| -u ` |

身份验证和会话（第3阶段）

密码学和API（第5阶段）

基础设施（第二阶段）

浏览器自动化

______________________________________________________________________

WSTG知识库

12个OWASP类别中的109个测试用例，每个都有特定于CLI的过程：

每个测试文件包括：

• 分步CLI程序（curl命令、工具调用）
• 按旁路级别（基本、中级、高级）组织的有效载荷
• 带有严重性评估量规的检测标准
• 附有参考的补救指南

______________________________________________________________________

PortSwigger技术指南

31攻击技术参考指南来源于 PortSwigger网络安全学院，按漏洞类别组织，以便在实际渗透测试中直接使用。

包含什么

另外11个：点击，WS，CACHEPOIS，CACHEDEC，DESER，INFO，BUSL，PROTO，API，LLM，SKILLS。

如何使用

技术指南通过 get_technique_guide() MCP工具：

Phase 2 → CORS guide for CONF-13 testing
Phase 3 → AUTHN, AUTHZ, CSRF, JWT, OAUTH guides for auth/session testing
Phase 4 → SQLI, XSS, CMDI, SSTI, SSRF, PTRAV, XXE guides for input validation
Phase 5 → DOM, CLICK, GRAPHQL, RACE, UPLOAD guides for client-side & business logic

每个并行测试代理在测试前自动加载其相关技术指南，提供：

• 探测有效载荷 --注入什么来识别漏洞
• 开采技术 --按攻击方法和分步程序组织
• 备忘单 --用于快速参考的数据库/平台特定语法表
• WAF旁路模式 --编码、混淆和过滤规避策略

添加自定义指南

看 docs/adding-knowledge-base-resources.md 有关向知识库添加新技术指南的说明。

______________________________________________________________________

质量保证体系

AutoPentest有一个多层QA系统，可以防止浅层测试：

1.相位门（自动）

在每个阶段之后， phase_gate_check() 验证：

• 所有MUST优先级测试均已执行
• 达到最低覆盖阈值
• 工具覆盖范围足够
• 不存在关键差距

被阻止的阶段无法继续 直到所有问题都得到解决。

2.质量审核员（每个阶段）

在每个阶段过渡中都会产生一个子代理：

• 检查16种已知的防图案（橡胶冲压、N/A级联、发现膨胀）
• 识别未经测试的端点和参数
• 建议漏洞链接机会
• 推荐阻塞测试的替代方法

3.终审法官（岗位报告）

一个零上下文代理，以全新的眼光审查已完成的参与：

• 分析所有域的覆盖完整性
• 检测N/A级联及其根本原因
• 验证发现质量和证据完整性
• 识别未命中的攻击面
• 作出判决： 通过, 有条件通行证，或 失败

4.排气门

将漏洞标记为“不可利用”需要工作量证明：

|Vuln类|最小技巧|最小旁路尝试次数| |------------|:-:|:-:| | XSS | 3 | 5 | |SQL注入|3|5| |命令注入|3|5| |SSTI|2|3| |SSRF|3|5| |路径遍历|3|5|

5.证据核对表

在记录任何发现之前，要验证证据要求：

• 可复制的curl命令
• 完整的HTTP请求和响应
• 实际开采证明（非理论影响）
• 正确的分类级别（已开发与潜在）

6.实时互动记录

每次MCP工具调用都会自动记录到 engagements//logs.txt 包含完整的参数、结果和执行持续时间。跑 tail -f logs.txt 在单独的终端中实时查看所有代理活动。通过自动工具包装器实现100%覆盖，无需手动仪器。

7.相位门定时

相位门强制要求呼叫之间至少间隔60秒（CTF模式下为15秒），以防止过早完成相位。如果连续闸门之间发生的工作事件少于3个，则闸门间工作验证会发出警告。

______________________________________________________________________

基准测试

AutoPentest包括与 XBOW验证基准 --104个CTF风格的Docker挑战被用作AI渗透测试代理基准测试的行业标准。

基准分数（参考）

用法

# Setup (one-time)
cd benchmarks/xbow && make setup

# Solve with AutoPentest (MCP server + CLAUDE.md + CTF mode)
make solve ID=XBEN-001-24

# Solve with raw Claude (baseline — no MCP, no methodology)
make solve ID=XBEN-001-24 RAW=1

# Solve by vulnerability tag
make solve-tag TAG=sqli

# Solve all 104 challenges
make solve-all

# Full baseline run for comparison
make solve-all RAW=1

# Score the latest run
make score

# Compare autopentest vs raw runs side-by-side
make compare

求解器有两种模式：

• 自动测试 （默认）：从项目根运行Claude代码，加载 .mcp.json （配备68多种工具的MCP服务器）和 CLAUDE.md （pentest方法）。测量AutoPentest的全部功能。
• 原始 (RAW=1)：在没有MCP服务器或方法的情况下运行裸克劳德代码。衡量AutoPentest相对于原始LLM能力的附加值的基线。

每个挑战都是一个Docker Compose应用程序，在构建时注入一个标志。从Claude的输出中提取标志决定了通过/失败。结果按挑战、标签和难度级别进行评分。

CTF模式

对于CTF挑战和小型应用程序，启用CTF模式以放松质量关卡：

mode: ctf
target:
  url: https://target.com

CTF模式减少了相位门定时（15秒vs 60秒），跳过了QA审查员的要求，并将完成阈值减半，同时保持了发现质量和证据标准。

______________________________________________________________________

示例报告

来自pentest的完整示例报告 PortSwigger的杜松子酒和果汁店 （一个故意易受攻击的应用程序）包含在存储库中：

查看完整报告

报告内容

该报告展示了AutoPentest的输出与真实目标的对比，在所有严重程度级别上有23个发现：

报告结构

1. Executive Summary         — Target scope, finding summary, domain architecture
2. Detailed Findings         — Each finding with description, evidence (curl commands), and remediation
3. Vulnerability Chaining    — Cross-finding analysis (e.g., XSS + no CSP = severity upgrade)
4. Test Coverage Matrix      — Per-category WSTG coverage (100% across 12 categories)
5. Tool Coverage Matrix      — 27/27 tools tracked, 8 actively run

示例查找（SQL注入）

从报告中可以看出——一个具有充分利用证据的关键SQL注入发现：

FINDING-017: SQL Injection in /catalog category parameter — Full Data Extraction

Severity: Critical
WSTG Reference: WSTG-INPV-05

The category parameter is vulnerable to UNION-based SQL injection.
The attacker can:
  1. Inject a single quote to cause a 500 error (confirming injection)
  2. Use UNION SELECT with 8 columns to extract arbitrary data
  3. Enumerate tables: PRODUCTS, TRACKING, USERS
  4. Extract credentials from the USERS table

Evidence (reproducible curl command):
  curl -sk "https://ginandjuice.shop/catalog?category='+UNION+SELECT+1,USERNAME,PASSWORD,
  1,1,USERNAME,1,USERNAME+FROM+USERS+LIMIT+10--"

每个发现都包括可重复的curl命令、完整的请求/响应证据和可操作的补救指南。

______________________________________________________________________

配置

参与配置（YAML）

配置驱动的渗透测试跳过交互式问题并确保一致性：

target:
  url: https://app.example.com
  scope: [app.example.com, api.example.com]

authentication:
  login_type: sso                    # form | sso | api | manual | none
  login_url: https://app.example.com/login
  credentials:
    username: testuser
    password: secret123
  sso:
    provider: keycloak               # keycloak | auth0 | okta | azure_ad
    auth_domain: auth.example.com
    realm: myrealm
    client_id: my-app

rules:
  avoid:
    - { type: path, url_path: "/logout", description: "Skip logout" }
    - { type: endpoint, method: DELETE, url_path: "/api/admin/*", description: "No destructive admin ops" }
  focus:
    - { type: path, url_path: "/api", description: "Prioritize API" }

reporting:
  tester_name: "Security Team"

MCP服务器配置

这 .mcp.json 文件注册了两个MCP服务器：

{
  "mcpServers": {
    "wstg-pentest": {
      "command": "uv",
      "args": ["--directory", "./server", "run", "server.py"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}

Burp Suite集成（可选）

通过Burp Suite Professional进行被动流量监控：

1. 启动Burp Suite并启用代理 所有接口 (0.0.0.0:8080)
2. Docker容器自动路由流量通过 host.docker.internal:8080
3. 所有HTTP请求都会出现在Burp的代理历史记录中，以便手动查看

______________________________________________________________________

多域测试

AutoPentest为具有多个域的应用程序提供一流的支持（例如，SPA前端+API后端+SSO提供商）：

自动检测

在阶段0期间，AutoPentest通过以下登录重定向检测跨域身份验证：

app.example.com → redirects to → auth.example.com/login
                 → after login → app.example.com/callback

所有域都会自动在作用域中注册其类型（app、auth_provider、api、cdn）。

每个域测试

每个WSTG测试都是按域评估的，而不仅仅是主域：

• 发现工具（katana、ffuf、nucleus）与之对抗 全部 领域
• 输入验证工具（sqlmap、dalfox）的目标端点位于 每 具有服务器端处理的域
• 只有在以下情况下，测试才“不适用” 不 域具有已测试的功能

跨域认证

支持的SSO协议：

• OAuth 2.0/OIDC （授权码、PKCE、密码授予、客户端凭据）
• 安全断言标记语言 （SP启动流）
• 钥匙斗篷, 身份验证0, 八月, Azure Active Directory
• 自定义SSO （使用cookie jar重定向链跟踪）

身份验证升级程序（6级）确保即使在复杂的身份验证流中也能进行测试。

______________________________________________________________________

故障恢复

AutoPentest旨在应对中断：

自动检查点

• 相位门自动保存PASS上的检查点
• git_checkpoint() 创建参与工作区的git快照
• 仅附加日志(findings.md, progress.log)在撞车事故中幸存下来

通过Resume-promput.md自动恢复（推荐）

每个检查点和相位门都会自动生成 engagements//resume-prompt.md --一个完整、独立的提示，包含新会话所需的一切：

• 目标URL、身份验证凭据和作用域
• 当前相位和剩余的具体测试（中间相位精度）
• Cookie jar状态和重新身份验证说明
• 避免/聚焦规则和端点映射引用

中断后恢复：

1. 打开一个新的Claude Code会话
2. 粘贴以下内容 engagements//resume-prompt.md
3. Claude完全从头开始——不需要手动上下文

检查点简历（备选）

Resume engagement pentest-2026-02-11-myapp

这将恢复：

• 所有发现和测试跟踪数据
• 覆盖率统计和相位门结果
• 范围登记和可交付成果
• 中期剩余测试（不仅仅是阶段级状态）
• 下一步操作说明

手动检查点

随时保存：

Save a checkpoint before starting Phase 4 exploitation

故障回滚

如果一个阶段产生了糟糕的结果，请回滚到上一个检查点：

Roll back the engagement to the last checkpoint

______________________________________________________________________

项目结构

autopentest-ai/
├── CLAUDE.md                          # Master pentest workflow (drives Claude Code)
├── .mcp.json                          # MCP server configuration
├── Dockerfile                         # Multi-stage Docker build (27 tools)
├── docker-compose.yml                 # Docker Compose alternative
├── Makefile                           # setup, start, stop, verify-tools, shell
│
├── server/
│   ├── server.py                      # FastMCP server (68+ MCP tools)
│   ├── task_tree.py                   # Hierarchical task tree (6 MCP tools)
│   ├── tool_parsers.py                # Tool output parsing (2 MCP tools, 13 parsers)
│   ├── endpoint_priority.py           # Endpoint risk prioritization (2 MCP tools)
│   ├── waf_evasion.py                 # Adaptive WAF evasion (3 MCP tools, 12 vendors)
│   ├── knowledge_graph.py             # Cross-phase knowledge graph (5 MCP tools)
│   ├── tool_verification.py           # CLI tool results verification (1 MCP tool, 10 validators)
│   ├── context_compression.py         # Progressive context compression (2 MCP tools)
│   └── pyproject.toml                 # Python dependencies
│
├── knowledge-base/
│   ├── web-security-testing-guide/    # OWASP WSTG knowledge base (109 test procedures)
│   │   ├── 01-information-gathering/  # 10 tests (WSTG-INFO-01 → 10)
│   │   ├── 02-configuration/          # 14 tests (WSTG-CONF-01 → 14)
│   │   ├── 03-identity-management/    # 5 tests  (WSTG-IDNT-01 → 05)
│   │   ├── 04-authentication/         # 11 tests (WSTG-ATHN-01 → 11)
│   │   ├── 05-authorization/          # 5 tests  (WSTG-ATHZ-01 → 05)
│   │   ├── 06-session-management/     # 11 tests (WSTG-SESS-01 → 11)
│   │   ├── 07-input-validation/       # 20 tests (WSTG-INPV-01 → 20)
│   │   ├── 08-error-handling/         # 2 tests  (WSTG-ERRH-01 → 02)
│   │   ├── 09-cryptography/           # 4 tests  (WSTG-CRYP-01 → 04)
│   │   ├── 10-business-logic/         # 10 tests (WSTG-BUSL-01 → 10)
│   │   ├── 11-client-side/            # 14 tests (WSTG-CLNT-01 → 14)
│   │   └── 12-api-testing/            # 3 tests  (WSTG-APIT-01 → 03)
│   └── portswigger-academy/           # 31 PortSwigger attack technique guides
│       ├── sql-injection.md           # UNION, blind, error-based, OOB, WAF bypass
│       ├── cross-site-scripting.md    # Reflected, stored, DOM, CSP bypass, filter evasion
│       ├── ssrf.md                    # URL schemes, cloud metadata, DNS rebinding
│       ├── ssti.md                    # Jinja2, Twig, Freemarker sandbox escapes
│       ├── jwt.md                     # Algorithm confusion, kid injection, JWK exploitation
│       ├── oauth.md                   # Auth code theft, redirect exploitation, scope upgrade
│       └── ... (31 total)             # One per vulnerability class
│
├── templates/                         # Testing guides and procedures
│   ├── input-validation-guide.md      # Phase 4 step-by-step procedures
│   ├── testing-strategies.md          # Test matrices, chaining, parallel strategy
│   ├── cli-tools-guide.md             # Tool setup and Docker management
│   ├── tools.md                       # Per-tool command reference
│   ├── quality-gates.md               # Phase quality checklists and anti-patterns
│   ├── cross-domain-auth-guide.md     # SSO/OIDC/SAML procedures
│   ├── source-code-analysis.md        # Security-focused code review template
│   ├── pipelined-testing.md           # Phase 4 pipelined exploitation strategy
│   ├── agent-roles/                   # Role-specialized subagent templates
│   │   ├── README.md                  # Role index and selection guide
│   │   ├── scout.md                   # Reconnaissance role (Phase 0-1)
│   │   ├── analyzer.md                # Vulnerability discovery role (Phase 2-5)
│   │   ├── exploiter.md               # Exploitation proof role (Phase 4)
│   │   └── reporter.md                # QA review + Final Judge role
│   ├── shared/
│   │   ├── honesty-framework.md       # Anti-hallucination guardrails
│   │   ├── exploit-classification.md  # Three-tier finding classification
│   │   ├── reproducibility.md         # Evidence format requirements
│   │   └── scope-rules.md            # Avoid/focus rule templates
│   └── wordlists/                     # Tech-specific fuzzing wordlists
│
├── benchmarks/
│   └── xbow/                              # XBOW benchmark suite (104 CTF challenges)
│       ├── runner.py                      # Challenge orchestration
│       ├── solver.py                      # Automated solver (Claude Code CLI)
│       ├── Makefile                       # solve, solve-all, score, compare
│       └── results/                       # Run reports
│
├── docs/
│   ├── ROADMAP.md                         # Competitive analysis + improvement roadmap
│   └── adding-knowledge-base-resources.md # Guide for adding new technique guides
│
├── configs/
│   ├── example-config.yaml            # Example engagement configuration
│   └── config-schema.md               # YAML schema documentation
│
├── scripts/
│   ├── install-tools.sh               # Docker build + container start
│   ├── browser-auth.py                # Headless Chromium auth (JS-rendered logins)
│   ├── pkce-auth.py                   # OAuth 2.0 PKCE flow automation
│   └── status.sh                      # Engagement status dashboard
│
└── engagements/                       # Runtime output (git-ignored)
    └── /
        ├── logs.txt                   # Live engagement log (tail -f to watch)
        ├── findings.md                # Append-only findings log
        ├── progress.log               # Timestamped event log
        ├── resume-prompt.md           # Auto-resume prompt (paste into new session)
        ├── report.md                  # Final pentest report
        ├── cookies.txt                # Cross-domain cookie jar
        └── tool-output/               # Raw CLI tool outputs

______________________________________________________________________

需求

支持的平台： macOS（苹果硅和英特尔）、Linux（x86_64和ARM64）

______________________________________________________________________

常见问题解答

Q： 这会取代人体渗透测试仪吗？

不是的。AutoPentest自动化了pentest的系统化、方法论驱动的部分。它擅长覆盖（确保没有遗漏任何内容）和一致性（每个测试都遵循相同的程序）。然而，复杂的业务逻辑、创造性开发链和依赖于上下文的风险评估仍然受益于人类的专业知识。把它看作是一种力量倍增器。

Q： 全面评估需要多长时间？

这取决于应用程序的大小和复杂性。一个典型的中型web应用程序（50-100个端点）需要几个小时。使用SSO的多域应用程序需要更长的时间。流水线第4阶段架构并行化了最耗时的测试。

Q： 我可以在没有Burp Suite的情况下运行这个吗？

对。Burp Suite是可选的，仅用于被动流量监控。所有HTTP请求都会通过 docker exec curl 所有安全工具都在Docker容器内运行。没有Burp，您将无法查看Burp代理历史中的流量，但所有测试功能都可以正常工作。

Q： PortSwigger技术指南是什么？

31个攻击参考指南，涵盖检测、利用技术、有效载荷、备忘单和WAF绕过模式，来源于PortSwigger Web安全学院。在测试过程中，代理会自动加载相关指南（例如，在测试SQL注入时的SQLi指南），以获取全面的技术和有效负载参考。看 docs/adding-knowledge-base-resources.md 添加自己的指南。

Q： 如何添加自定义单词表或有效载荷？

将单词表放入 templates/wordlists/ 它们将通过卷挂载在Docker容器内可用。中的WSTG测试文件 knowledge-base/ 也可以定制额外的有效载荷。要添加新的攻击技术指南，请按照中的说明进行操作 docs/adding-knowledge-base-resources.md.

Q： 我可以测试VPN背后的应用程序吗？

对。Docker容器继承了主机的网络（在Linux上 --network host)或通过以下方式到达主机 host.docker.internal （在macOS/Windows上）。如果您的VPN正在主机上运行，则容器可以到达受VPN保护的目标。

Q： 如果渗透测试中断（崩溃、使用限制、超时）会发生什么？

AutoPentest自动生成 resume-prompt.md 在每个检查点创建一个文件，其中包含继续所需的所有内容。打开一个新的Claude Code会话，粘贴以下内容 engagements//resume-prompt.md，测试将继续进行，包括中期进度、凭据、范围和剩余测试。

Q： 那么利率限制呢？

AutoPentest包括三层错误分类（瞬态/速率限制/永久）和自动回退。如果目标速率限制了请求，工具会自动减速。您还可以在配置中设置避免规则以跳过特定端点。

Q： 代理人的角色是什么？

AutoPentest使用4个专门的角色（侦察员、分析器、漏洞利用者、报告者），而不是通用的子代理。每个角色都有一个专门的提示模板，其中包含重点工具指导、限制工具列表和反模式。这可以防止代理将侦察、分析、利用和报告混为一谈，从而提高焦点和故障隔离。看 templates/agent-roles/README.md 完整的角色索引。

Q： WAF规避是如何工作的？

当有效负载被阻止时（403，阻止页），AutoPentest会自动根据响应特征对WAF供应商进行指纹识别，然后加载按复杂性级别组织的特定于供应商的旁路有效负载。支持12家WAF供应商（Cloudflare、AWS WAF、Akamai、Imperva、ModSecurity、F5等）。WAF情报通过可交付系统在所有代理之间共享。

Q： 什么是反事实分析？

在第一次分析过程发现漏洞后，AutoPentest可以生成第二个分析器，假设所有已知漏洞都已修补。这迫使代理寻找不同的攻击向量——不同的端点、参数、注入上下文和逻辑缺陷。结果将通过自动重复数据删除合并到现有的利用队列中。该技术基于学术研究（PenHeal消融研究），显示漏洞覆盖率提高了71%。

Q： 结果验证是如何工作的？

当CLI工具（nmap、nucleus、sqlmap等）产生空的或可疑的输出时 verify_tool_result() 该工具检测常见问题（代理错误、权限被拒绝、标记错误），并建议更正命令。这可以防止代理默默地将损坏的工具运行计数为“已完成”，这是自动渗透测试中的一种常见故障模式。

Q： 漏洞链是如何工作的？

知识图跟踪测试期间发现的实体（端点、参数、发现、Cookie、域）和关系。在阶段4之后， find_chains() 使用BFS发现多跳攻击路径，并检查7种预定义的链模式（例如，XSS+缺失的CSP、SSRF+云元数据、IDOR+管理员角色）。增加影响的链会触发自动严重性升级。

______________________________________________________________________

免责声明

此工具仅用于授权的安全测试。 仅对您有明确测试权限的应用程序使用AutoPentest。未经授权访问计算机系统是非法的。作者不对任何滥用此工具的行为负责。

始终确保您拥有：

• 应用程序所有者的书面授权
• 明确界定可以和不可以测试的范围
• 了解测试环境（生产与测试阶段）
• 为破坏性或敏感端点配置适当的避免规则

______________________________________________________________________

Built with Model Context Protocol