# Targeted Pentest

> 用于 pentest-agent 的 targeted-pentest 子 agent，在已锁定的 hypothesis_id、kind 与 entry_point 上执行单假设定向验证。适用于 Web、API、认证、浏览器端、服务端、Node.js 与 CVE 线索的验证场景；在同一假设内完成基线确认、payload 研究、最小化利用、证据收集、结论判定与 goal 提交。不用于宽泛 recon、不切换到其他假设、也不做与当前假设无关的发散测试。

- Skill: `m-sec-org/targeted-pentest` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add m-sec-org/targeted-pentest`
- Raw SKILL.md: https://api.skillmd.com/api/skills/m-sec-org/targeted-pentest/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: m-sec-org (https://skillmd.com/u/m-sec-org)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/m-sec-org/targeted-pentest

---


# 定向验证

## 角色定位
- 你只验证一个已锁定的假设。
- payload 研究、编码/解析差异、bypass 尝试，都属于当前技能内部步骤，不是单独阶段。
- 先拿最小可证实原语，再决定是否继续到更强证明。
- 一旦得到足够的 `verified` 证据或目标证明，立即收束并提交，不继续横向发散。

## 工作流
1. **对齐假设**：读取 `scope.md`、`run-policy.json`、输入证据与锁定的 `hypothesis_id`，明确成功条件、前置条件、允许动作。
2. **建立基线**：为当前入口保存至少一组正常请求/响应、认证状态、角色状态、关键参数与预期行为。
3. **选择最小验证路径**：优先验证最小原语，例如单次越权读取、单个模板求值、单次内部请求、单个 token 伪造、单个执行信号。
4. **在同一假设内收敛 payload**：按当前入口逐步调整编码、语法、parser 差异、过滤绕过和环境前提，但不要切换到其他入口或其他漏洞方向。
5. **做出结论**：把当前结果判定为 `verified`、`rejected` 或保留为 `candidate`。无法稳定复现时，不要夸大。
6. **提交并停止**：写清证据链、影响证明与 `goal`，然后结束。

## 参考导航
按信号读取最少必要的 reference，不要把整套资料一次性读完。

- SQL 注入：读 [references/sql-injection.md](references/sql-injection.md)
- 服务端注入、SSTI、SSRF、XXE、命令注入、GraphQL、文件读取与路径问题：先读 [references/server-side.md](references/server-side.md)
- 需要更强服务端利用链、文件上传到执行、特定 parser 或框架技巧：再读 [references/server-side-exec.md](references/server-side-exec.md) 与 [references/server-side-exec-2.md](references/server-side-exec-2.md)
- 遇到高级 parser 差异、框架细节、路径绕过、WeasyPrint、Docker API、特殊服务端链：读 [references/server-side-advanced.md](references/server-side-advanced.md) 与 [references/server-side-advanced-2.md](references/server-side-advanced-2.md)
- 反序列化与竞态：读 [references/server-side-deser.md](references/server-side-deser.md)
- XSS、DOM、缓存、客户端路由、管理员机器人、前端链：先读 [references/client-side.md](references/client-side.md)
- CSP、Unicode、postMessage、CSS exfil、浏览器怪异行为：再读 [references/client-side-advanced.md](references/client-side-advanced.md)
- 认证、授权、IDOR、开放重定向、访问控制：读 [references/auth-and-access.md](references/auth-and-access.md)
- JWT/JWE：读 [references/auth-jwt.md](references/auth-jwt.md)
- OAuth/OIDC、SAML、CORS、基础设施认证链：读 [references/auth-infra.md](references/auth-infra.md)
- Node.js、原型链污染、VM 逃逸：读 [references/node-and-prototype.md](references/node-and-prototype.md)
- 版本泄露、banner、依赖线索、已知漏洞：读 [references/cves.md](references/cves.md)
- 已有原语但需要长表格式技巧库、历史链路或补充样例时：最后再读 [references/field-notes.md](references/field-notes.md)

## 常见链路形态
- 仅在同一 `hypothesis_id`、同一 `entry_point` 附近延展，不要为了追链而切到新主线。
- 隐藏路由或鉴权绕过 -> 内部文件或配置读取 -> token、密钥或目标数据泄露
- XSS 或 HTML 注入 -> 管理员机器人或高权限上下文 -> 敏感操作或秘密泄露
- 路径遍历或上传点 -> 源码、配置或会话材料泄露 -> 会话伪造或进一步执行
- SSRF -> 元数据或内部 API -> 凭据泄露 -> 更强控制能力
- SQLi 或 NoSQLi -> 身份绕过或数据读取 -> 二阶段模板、上传或管理面利用

## Deep-Dive Notes

Use [references/field-notes.md](references/field-notes.md) once you have confirmed the challenge is truly web-heavy and you need the long exploit catalog.

- Recon, SQLi, XSS, traversal, JWT, SSTI, SSRF, XXE, and command injection quick notes
- Deserialization, race conditions, file upload to RCE, and multi-stage chain examples
- Node, OAuth/SAML, CI/CD, Web3, bot abuse, CSP bypasses, and modern browser tricks
- CVE-shaped playbooks and older challenge patterns that still show up in modern CTFs

## Common Flag Locations

- Files: `/flag.txt`, `/flag`, `/app/flag.txt`, `/home/*/flag*`
- Environment: `/proc/self/environ`, process command line, debug config dumps
- Database: tables named `flag`, `flags`, `secret`, or seeded challenge content
- HTTP: custom headers, archived responses, hidden routes, admin exports
- Browser: hidden DOM nodes, `data-*` attributes, inline state objects, source maps

## 验证原则
- 只围绕输入的 `hypothesis_id` 工作，不改方向，不补开新主线。
- 只在当前 `entry_point` 附近收敛；如果必须换入口才能继续，说明当前假设没有被当前证据充分支持。
- 如果发现更细粒度的机制名词，把细节写进 evidence 或备注，不要改锁定的 `kind`。
- 先最小验证，再考虑更强证明；不要一开始就追求最长利用链。
- 保持低影响、可复现、可审计；每一步都要能回放。
- 如果当前测试更像 recon，请停止扩展，回到证据与判定。

## 结论标准
- `verified`：同一假设、同一入口下，已拿到稳定且可复现的确认性证据。
- `rejected`：已获得足够证据表明这条假设不成立，或当前入口不支持该机制。
- `candidate`：存在信号，但还不足以稳定复现或不足以下结论。
- `goal.achieved=true`：只在已拿到目标证明时设置，例如 flag、明确的目标数据、或系统要求的终局证据。
- `goal.achieved=false`：机制可疑、部分确认、或仅验证到中间原语时使用，不得伪造终局证明。

## 证据标准
- 保存完整请求/响应对、时间戳、认证状态、账户角色、前置步骤与关键参数。
- 保存成功与失败对照，特别是状态码、响应体差异、延时信号、回显位置、内部错误或副作用。
- 记录 payload 变体与观察结果，避免重复试同一类无效方法。
- 所有 `evidence_refs` 必须指向可追溯文件，不要只写口头总结。

## 提交契约
- 结束前必须且只能调用一次 `submit_sub_agent_output`。
- `hypotheses` 必须且只能包含 1 条记录，并匹配输入的锁定 `hypothesis_id`。
- `candidate_findings` 可以是 `candidate|verified|rejected`，但必须保持在同一 `kind` 与 `entry_point` 上。
- `goal` 为必填：`{ achieved, proof, evidence_refs }`。
- 当 `goal.achieved=true` 时，至少要有一个 `verified` finding，且 `goal.evidence_refs` 必须能在 `evidence_refs` 中追溯。
- 可选 Markdown 说明仅供人工阅读，不是机器真相源。