recon-planning
- Repo stars 552
- Author updated Live
- Author repo yaklang
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @yaklang · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: recon-planning
description: > 定义渗透测试的系统化工作流程。以侦查(Recon)为起点,通过信息收集确定攻击面, 制定优先级驱动的测试计划,最终执行针对性的漏洞测试。 ┌─────────────┐ ┌────────…
category: other
runtime: no special runtime
---
# recon-planning output preview
## PART A: Task fit
- Use case: > 定义渗透测试的系统化工作流程。以侦查(Recon)为起点,通过信息收集确定攻击面, 制定优先级驱动的测试计划,最终执行针对性的漏洞测试。 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Phase 1 │ │ Phase 2 │ │ Phase 3 │ │ Phase 4 │ │ Phase 5 │ runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “1. 渗透测试工作流程 / 1.1 Phase 1: 侦查 (Recon) / 1.2 Phase 2: 范围确定 (Scoping)” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> 定义渗透测试的系统化工作流程。以侦查(Recon)为起点,通过信息收集确定攻击面, 制定优先级驱动的测试计划,最终执行针对性的漏洞测试。 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Phase 1 │ │ Phase 2 │ │ Phase 3 │ │ Phase 4 │ │ Phase 5 │ runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “1. 渗透测试工作流程 / 1.1 Phase 1: 侦查 (Recon) / 1.2 Phase 2: 范围确定 (Scoping)” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “1. 渗透测试工作流程 / 1.1 Phase 1: 侦查 (Recon) / 1.2 Phase 2: 范围确定 (Scoping)”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: recon-planning
description: > 定义渗透测试的系统化工作流程。以侦查(Recon)为起点,通过信息收集确定攻击面, 制定优先级驱动的测试计划,最终执行针对性的漏洞测试。 ┌─────────────┐ ┌────────…
category: other
source: yaklang/yaklang
---
# recon-planning
## When to use
- > 定义渗透测试的系统化工作流程。以侦查(Recon)为起点,通过信息收集确定攻击面, 制定优先级驱动的测试计划,最终执行针对性的漏洞测试。 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “1. 渗透测试工作流程 / 1.1 Phase 1: 侦查 (Recon) / 1.2 Phase 2: 范围确定 (Scoping)” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "recon-planning" {
input -> user goal + target files + boundaries + acceptance criteria
context -> 1. 渗透测试工作流程 / 1.1 Phase 1: 侦查 (Recon) / 1.2 Phase 2: 范围确定 (Scoping)
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 渗透测试侦查与任务规划
定义渗透测试的系统化工作流程。以侦查(Recon)为起点,通过信息收集确定攻击面, 制定优先级驱动的测试计划,最终执行针对性的漏洞测试。
1. 渗透测试工作流程
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Phase 1 │ │ Phase 2 │ │ Phase 3 │ │ Phase 4 │ │ Phase 5 │
│ 侦查 Recon │────>│ 范围确定 │────>│ 任务规划 │────>│ 漏洞测试 │────>│ 报告输出 │
│ │ │ Scoping │ │ Planning │ │ Testing │ │ Reporting │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
1.1 Phase 1: 侦查 (Recon)
目标:尽可能全面地收集目标的信息,绘制攻击面地图。
侦查是整个渗透测试最关键的阶段。不充分的侦查会导致遗漏关键资产和攻击面。
1.2 Phase 2: 范围确定 (Scoping)
目标:根据侦查结果,确定实际测试范围和优先级。
1.3 Phase 3: 任务规划 (Planning)
目标:为每个测试目标制定具体的测试计划。
1.4 Phase 4: 漏洞测试 (Testing)
目标:按计划执行漏洞测试,发现并验证安全漏洞。
1.5 Phase 5: 报告输出 (Reporting)
目标:整理发现,输出完整的渗透测试报告。
2. Phase 1 详解:侦查技术矩阵
2.1 被动侦查
不直接与目标交互,从公开信息中收集情报。
| 侦查类型 | 方法 | 产出 |
|---|---|---|
| 子域名枚举 | DNS 暴力枚举、证书透明度日志(CT Log)、搜索引擎 | 子域名列表 |
| DNS 记录 | 查询 A/AAAA/CNAME/MX/TXT/NS/SOA 记录 | IP 地址、邮件服务器、SPF/DKIM 配置 |
| WHOIS 查询 | 域名注册信息、IP 归属 | 注册人、注册商、IP 范围 |
| Web 搜索 | 搜索引擎 Dork(site:、inurl:、filetype:) | 敏感文件、管理后台、信息泄露 |
| 历史记录 | Wayback Machine、缓存页面 | 旧版本页面、已删除内容 |
| 代码仓库 | GitHub/GitLab 搜索 | 泄露的凭据、API Key、内部配置 |
| 社交工程情报 | LinkedIn、企业官网 | 技术栈、组织架构 |
2.2 主动侦查
直接与目标系统交互,获取技术细节。
| 侦查类型 | 工具/方法 | 产出 |
|---|---|---|
| 端口扫描 | SYN 扫描(synscan)、全连接扫描 | 开放端口列表 |
| 服务识别 | 服务指纹扫描(servicescan) | 服务类型、版本信息 |
| Web 爬虫 | 爬取目标站点(crawler/crawlerx) | URL 列表、参数、表单、API 端点 |
| 目录扫描 | 常用路径字典爆破 | 隐藏目录、备份文件、配置文件 |
| 指纹识别 | HTTP Header、Cookie、HTML 特征 | Web 框架、CMS、中间件版本 |
| SSL/TLS 分析 | 证书信息、支持的协议和密码套件 | 证书域名、过期时间、弱配置 |
2.3 搜索引擎 Dork
Google Dork 常用语法:
site:target.com # 限定域名
site:target.com filetype:pdf # PDF 文件
site:target.com inurl:admin # 管理后台
site:target.com intitle:"index of" # 目录浏览
site:target.com ext:sql|bak|conf # 敏感文件扩展名
site:target.com "error"|"warning" # 错误信息
"target.com" password|secret|key # 凭据泄露
inurl:".git" site:target.com # Git 仓库暴露
2.4 端口扫描策略
快速扫描(Top 端口优先)
Top 20 常用端口: 21,22,23,25,53,80,110,111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080
全端口扫描
- TCP 全端口 1-65535 扫描
- UDP 常用端口扫描(53, 67, 68, 69, 123, 161, 500, 514, 1900, 5353)
服务识别优先级
- Web 服务(80, 443, 8080, 8443, 8000, 8888)
- 数据库服务(3306, 5432, 1433, 1521, 6379, 27017)
- 远程管理(22, 3389, 5900, 5985)
- 文件共享(21, 445, 873, 2049)
- 邮件服务(25, 110, 143, 993, 995, 587)
3. Phase 2 详解:范围确定
3.1 资产分类
根据侦查结果将资产分类:
| 资产类型 | 示例 | 测试优先级 |
|---|---|---|
| Web 应用 | 主站、API、管理后台 | 高 |
| 数据库服务 | MySQL、Redis 暴露 | 高 |
| 远程管理 | SSH、RDP 暴露 | 中 |
| 邮件服务 | SMTP、IMAP 暴露 | 中 |
| 辅助服务 | DNS、NTP、SNMP | 低 |
| 静态资产 | CDN 资源、纯静态页面 | 低 |
3.2 优先级评估标准
高优先级判定条件:
- 直接面向互联网的 Web 应用
- 存在已知漏洞版本的服务
- 管理后台/API 暴露
- 包含敏感数据的数据库服务
- 使用弱认证或默认凭据的服务
3.3 攻击面地图
为每个目标绘制攻击面:
- 域名/子域名 → IP 地址 → 开放端口 → 服务类型 → 版本
- Web 应用 → URL 列表 → 参数 → 功能点(登录、上传、搜索等)
- API → 端点列表 → 请求方法 → 参数 → 认证方式
4. Phase 3 详解:任务规划
4.1 OWASP Top 10 检查矩阵
针对每个 Web 应用,按 OWASP Top 10 (2021) 制定测试计划:
| 编号 | 类别 | 测试方法 | 关联 Skill |
|---|---|---|---|
| A01 | Broken Access Control | 越权测试(水平/垂直)、IDOR、目录遍历 | - |
| A02 | Cryptographic Failures | TLS 配置检查、敏感数据传输分析 | code-review |
| A03 | Injection | SQL/命令/模版注入测试 | sql-injection, command-injection, template-injection |
| A04 | Insecure Design | 业务逻辑漏洞、缺失的安全控制 | - |
| A05 | Security Misconfiguration | 默认配置、不必要的功能、错误的 CORS | code-review |
| A06 | Vulnerable Components | 版本指纹比对、CVE 匹配 | - |
| A07 | Authentication Failures | 弱密码、暴力破解、Session 管理缺陷 | - |
| A08 | Software/Data Integrity | 反序列化、供应链安全 | code-review |
| A09 | Logging/Monitoring | 日志注入、监控覆盖度评估 | - |
| A10 | SSRF | 服务端请求伪造测试 | - |
4.2 任务编排策略
按风险排序
- 高危快速检查(已知漏洞版本、默认凭据、未授权访问)
- 注入类漏洞测试(SQL 注入、命令注入、XSS)
- 认证与授权测试(越权、Session、密码策略)
- 业务逻辑测试(支付、权限、流程绕过)
- 配置与加密测试(TLS、CORS、Header)
按功能模块
- 登录/注册模块 → 暴力破解、SQL 注入、XSS、CSRF
- 搜索功能 → SQL 注入、XSS
- 文件上传 → 文件类型绕过、路径穿越、RCE
- API 接口 → 认证绕过、注入、越权
- 管理后台 → 未授权访问、提权、命令执行
- 用户输入/展示 → 存储型 XSS、SSTI
4.3 测试计划模板
目标: [域名/IP]
类型: [Web 应用/API/服务]
技术栈: [语言/框架/中间件/数据库]
侦查发现: [开放端口、功能模块、已知组件版本]
测试任务:
1. [任务名称] - 优先级: [高/中/低]
方法: [具体测试方法]
工具: [使用的工具或 Skill]
预期时间: [估算]
2. [任务名称] - 优先级: [高/中/低]
...
5. Phase 4 详解:测试执行
5.1 测试原则
- 先自动后手动:先用自动化工具扫描,再对发现进行手动验证
- 先低危后高危:避免高危操作导致服务异常
- 先探测后利用:确认漏洞存在后再尝试利用
- 记录一切:每个测试步骤和结果都要记录
5.2 Web 应用测试流程
1. 爬虫扫描 → 收集 URL/参数/表单
2. 被动分析 → 检查 Header/Cookie/JS 文件
3. 参数测试 → 对每个参数进行 Fuzz 测试
4. 功能测试 → 针对业务逻辑进行测试
5. 认证测试 → 测试登录、Session、权限
6. 漏洞验证 → 手动确认自动发现的漏洞
5.3 测试结果分级
| 级别 | 描述 | 示例 |
|---|---|---|
| 严重 (Critical) | 可直接获取系统控制权 | RCE、SQL 注入获取管理员凭据 |
| 高危 (High) | 可获取大量敏感数据 | SQL 注入(只读)、任意文件读取 |
| 中危 (Medium) | 可影响部分用户或功能 | 存储型 XSS、CSRF、越权 |
| 低危 (Low) | 有限的安全影响 | 信息泄露、反射型 XSS(需交互) |
| 信息 (Info) | 安全建议 | 缺少安全 Header、版本信息泄露 |
6. Phase 5 详解:报告输出
6.1 报告结构
1. 执行摘要
- 测试范围和时间
- 关键发现汇总
- 整体安全评级
2. 发现详情
- 漏洞描述
- 影响分析
- 重现步骤
- 修复建议
3. 技术附录
- 测试方法说明
- 工具列表
- 完整的测试日志
6.2 漏洞描述模板
标题: [漏洞类型] - [位置]
严重程度: [Critical/High/Medium/Low/Info]
CVSS: [评分]
CWE: [CWE 编号]
描述:
[漏洞的技术描述]
影响:
[被利用后的潜在影响]
重现步骤:
1. [步骤 1]
2. [步骤 2]
3. [步骤 3]
证据:
[请求/响应截图或数据]
修复建议:
[具体的修复措施]
7. 侦查检查清单
- 子域名枚举完成
- DNS 记录收集完成
- 端口扫描完成(至少 Top 1000)
- 服务识别和版本探测完成
- Web 爬虫扫描完成
- 技术栈指纹识别完成
- 搜索引擎 Dork 搜索完成
- 攻击面地图绘制完成
- 资产分类和优先级评估完成
- 测试计划制定完成
- OWASP Top 10 检查矩阵对照完成
Decide Fit First
Design Intent
How To Use It
Boundaries And Review