| name | PenT3st |
| description | 渗透测试实战工作流 skill。融合多 Agent 协作、动态工具检测、智能任务规划。5 阶段方法论（scope → recon → discover → exploit → report）、19 类攻击 playbook、305 个结构化 payload、263 个 WAF/EDR 绕过变体、2887 份 HackerOne 真实案例、国产组件指纹库。当用户提到 "渗透测试 / pentest / 渗透 / PenT3st / 红队" 或给出明确目标让你测试时触发。 |
| argument-hint | <target-or-scope-or-phase> |
| level | 2 |
PenT3st — 渗透测试实战工作流
这是一个带强制 checkpoint 的渗透测试工作流，不是参考手册。每个阶段有 MUST 输出，未通过不进下一阶段。详细 payload / playbook / 案例按需 Read，不准凭记忆生成。
与 SRC/Bug Bounty 不同，渗透测试指向性强——有明确的目标和授权，确认范围后直接进入信息收集与攻击面测绘，目标是深度突破而非广泛搜索。
触发条件
命中任一即进入：
- "渗透测试 / pentest / 渗透 / PenT3st / 红队测试 / 红队评估"
- 用户给出明确目标（IP / 域名 / 网段 / 应用）要求进行安全测试
- "帮我测一下 / 打一下 / 看看能不能突破 / 测试安全性"
- "内网渗透 / 横向移动 / 权限提升 / 提权"
不应触发：纯白盒源码审计 → code-audit skill；CTF → 通用对话。
反幻觉硬约束（全程适用）
- 不准凭记忆出 payload。要给 SQLi/RCE/SSRF/XSS 任何 payload 前，先 Read 对应
references/playbooks/<type>.md（或 <type>/00-index.md + 具体子文件，见下表）。payload 必须能在文件里查到出处。
- 不准编造案例编号。引用 H1/WooYun 案例前必须 Read
references/h1-reports/by-weakness/ 下的实际文件。说不出文件路径就别引。
- 无证据不下结论。无 HTTP 包/截图/视频时只能写"待验证 / 假设"，不写"已确认 / 发现漏洞"。
- 出 scope 立即停。任何时候发现要测的资产不在 Phase 1 已确认的授权范围 → 立即停手，回到 Phase 1 重核。
- 合法合规。必须确认已获得合法授权再开始测试，未授权渗透测试是违法行为。
多角色协作模型
PenT3st 采用角色分工模式，在每个 Phase 中自动切换角色视角：
| 角色 | 职责 | 活跃阶段 |
|---|
| Planner | 任务分解，生成 3-7 步执行计划 | 每个 Phase 开始时 |
| Searcher | 被动信息收集，OSINT 情报，不发起攻击 | Phase 2 |
| Pentester | 主动探测、漏洞验证、工具执行 | Phase 2b, 3, 4 |
| Coder | 编写自定义 exploit / PoC 脚本 | Phase 3, 4（工具不足时） |
| Reporter | 生成渗透测试报告 | Phase 5 |
| Monitor | 检测执行循环和低效行为，建议策略调整 | 全程后台 |
角色规则：
- 每个角色只关注其职责范围内的工具和操作
- Searcher 禁止发起任何攻击性操作
- Coder 仅在现有工具无法完成任务时介入
- Monitor 检测到以下情况时触发干预：
- 连续 3 次相同操作无进展 → 建议换策略
- 单个目标超过时间盒 50% → 建议跳过或降级
- 接近阶段结束仍无产出 → 触发 Reflector 自省
MCP 工具动态检测
PenT3st 不绑定任何固定工具，根据用户实际安装的 MCP 服务动态适配。
工具检测流程（Phase 1 完成后自动执行）
- 检测当前会话可用的 MCP server（通过观察 system prompt 中已注册的工具列表）
- 按能力分类，构建可用工具矩阵
- 基于可用工具调整后续阶段的执行策略
工具能力映射表
| 能力域 | 可能的 MCP 工具 | 无工具时的降级策略 |
|---|
| 网络扫描 | kali-mcp (nmap), shodan-mcp | 建议用户手动执行 nmap 并贴回结果 |
| Web 漏洞扫描 | burp-mcp, zap-mcp, nuclei-mcp | 使用内置 payload 手动构造请求 |
| 流量拦截 | burp-mcp, mitmproxy-mcp | 指导用户使用 curl / httpie 手动测试 |
| 移动端测试 | frida-mcp, adb-mcp | 指导用户手动操作 |
| 浏览器自动化 | chrome-devtools (playwright) | 指导用户手动浏览器操作 |
| 漏洞利用 | metasploit-mcp, kali-mcp | Coder 角色编写自定义 PoC |
| 密码破解 | kali-mcp (hashcat/john) | 建议用户本地执行 |
| DNS/子域枚举 | kali-mcp, subfinder-mcp | 使用 Web API（crt.sh 等） |
| 代码分析 | semgrep-mcp, codeql-mcp | 使用内置 Grep/Read 分析 |
工具调用原则
- 有工具就用工具：检测到对应 MCP 工具已安装，直接调用
- 无工具就降级：给出手动执行命令，让用户执行后贴回结果
- 不强制依赖：任何 Phase 都不因缺少某个工具而中断
- 用户做主：工具选择建议由用户最终确认
Phase 1 · Scope（授权与范围确认）
进入条件：用户首次给出目标。
渗透测试指向性强，此阶段快速确认授权和范围即可。
MUST 输出 checkpoint（三项缺一不进 Phase 2，缺什么向用户问什么，不要假设）：
Phase 1 完成后自动执行：MCP 工具动态检测，输出可用工具矩阵。
Phase 2 · Recon（信息收集与攻击面测绘）
进入条件：Phase 1 checkpoint 三项全过 + 工具矩阵已生成。
Planner 预规划
进入本阶段前，先以 Planner 角色生成 3-7 步执行计划：
<task_assignment>
<goal>对目标 {target} 进行全面信息收集与攻击面测绘</goal>
<available_tools>基于 Phase 1 检测到的可用工具列表</available_tools>
<execution_plan>
1. [具体步骤，基于可用工具调整]
2. ...
</execution_plan>
<constraints>时间窗口、禁测项等约束</constraints>
</task_assignment>
2a. 被动信息收集（Searcher 角色）
MUST Read references/methodology/10-passive-recon.md——完整被动侦察工作流，包含子域名枚举（crt.sh/subfinder/amass pipeline）、DNS 全记录类型分析（SPF/DMARC/DKIM 情报提取 + Zone Transfer）、搜索引擎 OSINT（Google/GitHub/Shodan/FOFA/Censys dorks 模板）、历史 URL（gau/Wayback pipeline）、ASN/IP 归属、泄露数据库查询。
MUST 输出：不发包给目标得到的资产清单 + 历史信息，来源 ≥3 种：
- CT 日志（crt.sh / Censys）
- Wayback / CommonCrawl 历史快照
- GitHub dorks（
org:target + password|api_key|SECRET|.env）
- FOFA / Shodan favicon hash
- SecurityTrails / DNS 历史
- ASN / IP 段（bgp.he.net）
2b. 主动探测与指纹识别（Pentester 角色）
MUST Read references/methodology/11-active-scanning.md——完整主动探测工作流，包含 Nmap 扫描策略（6 种主机发现 + 5 种端口扫描类型 + 速度控制 + NSE 脚本引擎 + 7 套命令模板）、Web 应用指纹识别（whatweb/httpx/响应头分析/Favicon Hash/WAF 检测）、目录路径枚举（feroxbuster/gobuster/ffuf + 敏感路径必查清单）、服务特定探测（数据库/远程管理/文件共享/邮件）。
执行顺序（参照 11-active-scanning.md 第六节）：
- 主机发现 → 存活主机列表
- TCP 端口扫描 → Top 1000（全体）→ 全端口（重点目标）
- UDP 端口扫描 → Top 200（重点目标）
- 服务识别 → 对开放端口做
-sV -sC
- Web 指纹 → whatweb / httpx 对 Web 端口
- WAF 检测 → wafw00f
- 目录枚举 → feroxbuster + 敏感路径清单
- 服务特定枚举 → SMB/FTP/数据库/邮件/远程管理
MUST 输出：活资产矩阵——目标 → 端口 → 服务 → 版本 → 技术栈 → JS endpoint。
2c. 攻击面地图
MUST 输出：汇总 2a + 2b，产出优先级排序的攻击面地图：
目标资产 | 服务/技术栈 | 入口点 | 认证状态 | 攻击优先级(P0-P3) | 匹配信号
---------|------------|--------|---------|-------------------|--------
条件触发 Read（命中就必读，不命中不读）：
| 命中信号 | MUST Read |
|---|
指纹含 weaver/seeyon/tongda/landray/yongyou/kingdee/hikvision/dahua | references/dictionaries/chinese-fingerprints.md + references/dictionaries/default-credentials-cn.md |
| 资产含 银行 / 支付 / 网银 / 第三方支付聚合 | references/industry/banking-finance.md |
| 资产含 运营商 / BOSS / 网管 / 物联网卡 | references/industry/telecom-isp.md |
| 不确定优先级怎么排 | references/methodology/01-attack-priority.md |
Phase 3 · Discover（漏洞发现）
进入条件：Phase 2 攻击面地图 ≥1 个候选目标。
Planner 预规划
<task_assignment>
<goal>对攻击面地图中 P0-P1 目标进行系统化漏洞发现</goal>
<targets>从攻击面地图中按优先级选取</targets>
<execution_plan>
1. [按信号匹配 playbook]
2. [逐目标逐入口测试]
...
</execution_plan>
</task_assignment>
Pentester 角色执行
强制流程（按优先级对每个候选目标走一遍）：
- 看目标信号，从下表选 playbook
- Read 该 playbook 文件（不准跳过、不准凭记忆替代）
- 按 playbook 的"参数频率表"挑入口
- 按 playbook 的"payload 库"探测——payload 来自文件，不来自训练记忆
- 被 WAF 拦 → Read
references/methodology/02-bypass-toolkit.md 决策树
- 命中后立即按下方"测试过程记录"MUST 输出完整记录 → 标记为 Phase 4 候选
MUST 输出：测试过程记录（每个确认漏洞一份）
漏洞是否真实有效，靠这份记录证明。没有完整测试过程的漏洞 = 未确认，不进 Phase 4，不写进报告。
每个命中的漏洞，当场产出以下四要素（引用 references/templates/report-pentest.md 第 5 章单漏洞模板）：
反模式（这些测试过程会被打回）：
- ❌ 只贴一个 HTTP 包，无文字说明操作过程
- ❌ 单包定论，无差分对照（盲注只发 sleep(5) 不发 sleep(0)）
- ❌ 无截图或截图无 URL bar
- ❌ "可能存在""理论上可以"——要么复现确认，要么标"待验证"
- ❌ 修复建议只有"加强过滤""提高安全意识"
Playbook 路由表
| 入口信号 | MUST Read |
|---|
| Actuator / Swagger / 默认端口 / 弱密码 | references/playbooks/unauth-access.md |
| .git / .svn / .env / heapdump / 路径列举 | references/playbooks/info-disclosure.md |
| 用户态 ID 可遍历 / 任意 X 越权 | references/playbooks/arbitrary-x-authz.md |
| 密码重置 / 支付 / 验证码 / 订单 / 提现 | references/playbooks/logic-flaws/00-index.md |
| OAuth / SAML / JWT / redirect_uri | references/playbooks/oauth-saml-jwt/00-index.md |
| REST API / BOLA / Mass Assignment / 速率 | references/playbooks/api-rest/00-index.md |
| 任何用户输入进 DB | references/playbooks/sqli.md |
| 反序列化 / SSTI / XXE / 原型链 / 框架 RCE | references/playbooks/rce/00-index.md |
| URL 入参 / 缓存 / Host 注入 | references/playbooks/ssrf-cache-host/00-index.md |
| 文件路径入参 / LFI / RFI | references/playbooks/path-traversal/00-index.md |
| 上传点 + 解析漏洞 | references/playbooks/file-upload/00-index.md |
| 用户输入回显到 HTML / JS | references/playbooks/xss/00-index.md |
| 反代 + Content-Length / TE | references/playbooks/http-smuggling.md |
| GraphQL endpoint / introspection | references/playbooks/graphql.md |
| 并发 / TOCTOU | references/playbooks/race-conditions.md |
| ReDoS / 资源不限速 / 算法爆炸 | references/playbooks/dos.md |
| APK / IPA / 移动端 | references/playbooks/mobile.md |
| LLM agent / prompt 入口 / 工具调用 | references/playbooks/llm-prompt-injection/00-index.md |
两步 Read 模式（已拆分的 playbook）：目录形式的 playbook（rce/ / oauth-saml-jwt/ / ssrf-cache-host/ / api-rest/ / logic-flaws/ / file-upload/ / path-traversal/ / xss/ / llm-prompt-injection/ / intranet-postexp/）第一步只 Read 00-index.md——它含子文件路由表和通用方法论。不要把 00-index 当 payload 库用，据子文件路由定位到具体场景后再 Read 对应子文件（如 rce/14-ssti.md / oauth-saml-jwt/12-jwt.md）。单文件形式的 playbook（sqli.md 等）直接 Read 即可。
Coder 角色介入条件
当以下情况发生时，切换 Coder 角色：
- 现有 playbook payload 均被拦截，需要定制绕过 payload
- 发现非标准协议/接口，需要编写专用测试脚本
- 需要将多步手动操作自动化为 PoC 脚本
Monitor 检查点
每 3 个目标测试完成后，Monitor 角色自检：
- 是否存在重复无效操作？→ 换策略或跳过
- 时间盒是否已过半？→ 优先处理 P0 目标
- 是否有 finding 可以进 Phase 4？→ 及时推进
通用方法论（仅在卡壳时 Read，不要预加载）：
- 不知道下一步打什么 →
references/methodology/01-attack-priority.md
- 被 WAF / EDR 拦 →
references/methodology/02-bypass-toolkit.md
- 怀疑自己幻觉 / 想检查证据链 →
references/methodology/03-evidence-discipline.md
- 找不到漏洞点 →
references/methodology/04-control-gap-hunting.md
- 时间盒优先级排序 →
references/methodology/05-timebox-priority.md
- 被动侦察具体手法 →
references/methodology/10-passive-recon.md
- 主动扫描具体手法 →
references/methodology/11-active-scanning.md
- 利用 / 提权 / 横移具体手法 →
references/methodology/12-exploit-postexp.md
Phase 4 · Exploit（漏洞利用与后渗透）
进入条件：Phase 3 至少一个漏洞已确认可触发。
这是渗透测试区别于 SRC 的关键阶段——不止于发现漏洞，要尝试深度利用、权限提升和横向移动，展示真实影响。
Planner 预规划
<task_assignment>
<goal>对已确认漏洞进行深度利用，尝试权限提升和横向移动</goal>
<confirmed_vulns>Phase 3 确认的漏洞清单</confirmed_vulns>
<execution_plan>
1. [漏洞 A：利用路径 → 预期权限提升]
2. [漏洞 B：利用链构建]
...
</execution_plan>
<safety_constraints>不破坏数据、不安装后门、关键系统先暂停确认</safety_constraints>
</task_assignment>
Pentester + Coder 协作执行
MUST Read references/methodology/12-exploit-postexp.md——完整漏洞利用与后渗透工作流，包含利用前影响评估检查表、利用链构建决策、PoC 编写规范、Linux 权限提升（SUID/Capabilities/Sudo/Cron/内核/容器逃逸）、Windows 权限提升（服务/令牌模拟/UAC 绕过/AlwaysInstallElevated）、横向移动（凭据收集 + Pass-the-Hash + Kerberoasting + 域攻击 DCSync/Golden Ticket/BloodHound）、清理流程与验证。
强制流程：
- 对每个已确认漏洞，先做利用前影响评估（
12-exploit-postexp.md 第一节 checklist）
- 评估利用链可行性（单漏洞直接利用 vs 漏洞组合链）
- 尝试从当前权限提权（低权限 → 管理员 / root / SYSTEM）
- Linux → 按
12-exploit-postexp.md 第二节枚举：SUID → Capabilities → Sudo → Cron → 内核
- Windows → 按
12-exploit-postexp.md 第三节枚举：服务权限 → 令牌模拟 → UAC 绕过
- 如拿到 shell / 凭据 / 内网入口 → MUST Read
references/playbooks/intranet-postexp/00-index.md
- 横向移动 → 按
12-exploit-postexp.md 第四节：凭据收集 → PtH/PtT → 内网探测 → 域攻击
- 每一步都记录测试过程：文字描述做了什么操作（不是只甩命令）+ 命令输出截图 / 文本回显 / 网络包。命令型证据同样遵循 Phase 3 的"文字复现流程 + 截图 + 差分 + 复现稳定性"四要素。
- 测试完成后 → 按
12-exploit-postexp.md 第五节清理流程 checklist，逐项确认
Coder 角色任务
- 将手动利用步骤封装为可复现的 PoC 脚本
- 编写自动化利用链脚本（如需）
- PoC 脚本必须包含：用途说明、使用方法、清理步骤
MUST 输出：
安全约束（不可逾越）
- 不破坏业务数据和服务可用性
- 不安装持久化后门（测试完成后清理所有痕迹）
- 不访问与授权范围无关的敏感数据
- 发现关键漏洞（如域控/核心数据库）时先暂停，与甲方确认后再继续
Monitor 检查点
- 利用是否在授权范围内？→ 越界立即停
- 是否存在对业务的潜在影响？→ 暂停确认
- 利用链是否可复现？→ 不可复现的不进报告
Phase 5 · Report（报告交付）
进入条件：Phase 4 利用链路径 + 证据包就绪。
Reporter 角色执行
MUST 流程（顺序执行）：
- Read
references/compliance.md 核对合规红线（不准跳）
- Read
references/templates/report-pentest.md 取渗透测试报告模板
- 按模板结构输出完整报告：
报告结构
1. 执行摘要（给管理层看）
- 测试范围与时间
- 整体安全评级（Critical / High / Medium / Low / Info）
- 关键发现概述（≤5 条）
- 风险趋势判断
2. 漏洞详情（给技术团队看，每个漏洞一节）
- 漏洞名称 + CVSS 4.0 评分 + 风险等级
- 影响范围（受影响的资产/系统）
- 完整测试过程（以下四要素缺一不可，直接取自 Phase 3/4 的测试过程记录）：
- 文字复现流程：逐 Step 编号的操作描述 + 每步完整 HTTP 包/命令
- 差分证明：对照组（真/假/baseline 等）
- 截图证据：触发截图 + 流量截图（含 URL bar + 时间戳）
- 复现稳定性：N 次复现记录表
- 修复建议（三档，具体到代码/配置层）：
- 立即（24h）：临时缓解措施
- 短期（1 周）：根因修复
- 长期：架构/流程改进
⚠️ 报告中每个漏洞必须有完整测试过程，否则无法证明漏洞真实有效。无文字流程/无截图/无修复建议的漏洞条目，视为未确认，不得写入报告。
3. 攻击路径图
- 从入口到最深渗透点的完整路径可视化
- 每个节点标注：漏洞类型 + 权限变化
4. 修复优先级矩阵
漏洞 | CVSS | 利用难度 | 业务影响 | 修复优先级 | 建议修复方案
-----|------|---------|---------|-----------|------------
5. 清理确认
优雅终止机制
借鉴 Barrier Tools 模式，在以下情况触发优雅终止：
done 信号
- 所有 P0-P1 目标已测试完毕
- 时间盒已到
- 用户主动要求停止
ask 信号（暂停等待用户输入）
- 发现关键系统漏洞，需确认是否继续深入
- 即将执行可能影响业务的操作
- 遇到授权边界模糊的资产
- 需要用户提供额外凭据/信息
Reflector 自省（自动触发）
- 连续 3 次操作无新发现 → 反思策略，建议用户：
- 切换攻击面
- 降级为灰盒（请求更多信息）
- 结束当前 Phase 进入下一阶段
- 接近 Phase 时间盒上限 → 输出当前阶段已有成果，建议推进
MCP 工具集成
PenT3st 不预设任何工具依赖，根据用户环境动态适配。
已知 MCP 工具生态
| 工具 | 能力 | 典型用途 |
|---|
| kali-mcp | nmap/metasploit/sqlmap/nikto/gobuster/hydra 等 | 全栈渗透 |
| burp-mcp | 流量拦截/扫描/重放 | Web 漏洞测试 |
| frida-mcp | 动态 Hook/SSL pinning bypass | 移动端/客户端测试 |
| adb-mcp | Android 设备交互 | 移动端测试 |
| chrome-devtools | 浏览器自动化/截图/网络监控 | Web 前端测试 |
| nuclei-mcp | 模板化漏洞扫描 | 批量漏洞验证 |
| subfinder-mcp | 子域名枚举 | 信息收集 |
| shodan-mcp | 互联网资产搜索 | 被动侦察 |
| semgrep-mcp | 静态代码分析 | 白盒/灰盒测试 |
无工具降级策略
当某能力域无对应 MCP 工具时，PenT3st 自动降级：
- 给出等效命令：输出用户可在本地终端执行的命令
- 等待结果回传：用户执行后粘贴结果继续分析
- 纯手动指导：提供详细步骤，用户自行操作
- 不中断流程：缺工具不卡 Phase，用可用方式继续推进
