pentest-playbook

渗透测试操作手册技能

涵盖从被动侦察到漏洞利用和报告的完整生命周期，共 7 个阶段的渗透测试流程。内容提炼自政府、健康科技、金融科技、电子商务、ISP 和 SMB 领域的 100 多个目标。这是“元操作手册”——它会告诉你在测试的每个阶段该做什么，以及每个阶段应加载哪些技能。

适用场景

• 开始一项针对未知目标的新渗透测试。
• 需要适用于任何类型目标的标准工作流。
• 完成表面侦察后——本操作手册会告诉你接下来该做什么。
• 培训——了解专业渗透测试的完整生命周期。

7 阶段流程

阶段	名称	重点	关键技能	时长
1	被动侦察	OSINT、子域、泄露信息、技术栈	subdomain-enumeration、offensive-osint	30-60 分钟
2	主动侦察	端口扫描、在线主机、技术检测	port-mass-scan、port-service-discovery、web2-recon	30-60 分钟
3	Web 枚举	敏感文件、.env、CORS、JS 密钥	web-enumeration、cors-credential-wordpress、js-secrets-extraction	20-40 分钟
4	框架漏洞利用	WordPress、Laravel、Spring、.NET	hunt-wordpress、hunt-laravel、hunt-springboot、hunt-aspnet	30-60 分钟
5	云与基础设施	Firebase、Supabase、S3、Cloud Functions	hunt-firebase、hunt-supabase、cloud-iam-deep	30-60 分钟
6	深度漏洞利用	SQLi、SSRF、RCE、ATO、攻击链	hunt-sqli、hunt-ssrf、cross-attack-chains	1-4 小时
7	报告与修复	文档、PoC、CVSS 评分	report-writing、triage-validation、evidence-hygiene	1-3 小时

各阶段流程

阶段 1 — 被动侦察

# 1. Subdomain enumeration
subfinder -d $TARGET -silent | tee subs.txt
curl --max-time 30 --connect-timeout 10 -s "https://crt.sh/?q=%.$TARGET&output=json" | jq -r '.[].name_value' >> subs.txt

# 2. Tech stack detection via response headers
curl --max-time 30 --connect-timeout 10 -sI "https://$TARGET" | grep -iE "server|x-powered-by|x-aspnet|x-generator|x-runtime"

# 3. Google dorks
# site:$TARGET filetype:env DB_PASSWORD
# site:$TARGET "-----BEGIN RSA PRIVATE KEY-----"

# 4. GitHub code search (SA keys, .env, credentials)
# See google-dorks-catalog skill for full list

阶段 2 — 主动侦察

# 1. Port scan (top 1000 ports)
rustscan -a $TARGET --ulimit 5000 -g | tee ports.txt

# 2. HTTP probe on alive hosts
cat subs.txt | httpx -silent -status-code -title -tech-detect | tee live.txt

# 3. CORS quick test
curl --max-time 30 --connect-timeout 10 -skI "https://$TARGET/wp-json/wp/v2/users" -H "Origin: https://evil.com" | grep -i "access-control"

阶段 3 — Web 枚举

运行完整的 web-enumeration 技能——检查 200 多种敏感文件路径、提取 .env、绕过路径遍历防护、枚举 vHost。

阶段 4 — 框架漏洞利用

根据检测到的框架加载相应的 hunt-* 技能：

• WordPress：hunt-wordpress + wp-mass-recon
• Laravel：hunt-laravel
• Spring Boot：hunt-springboot
• ASP.NET：hunt-aspnet

阶段 5 — 云与基础设施

• Firebase：hunt-firebase（API 密钥 → Firestore → Storage）
• Supabase：hunt-supabase（anon 密钥 → 绕过 RLS）
• Cloud IAM：cloud-iam-deep（SA 密钥 → GCP 令牌 → IAM 策略）
• Docker：docker-privesc（如果可以访问容器）

阶段 6 — 深度漏洞利用

使用 cross-attack-chains 技能串联发现的问题。5 条已确认的攻击链（A-E）可以将单个中危/高危问题转化为严重影响。

阶段 7 — 报告

漏洞赏金项目使用 report-writing 技能，客户交付物使用 redteam-report-template。提交前应用 triage-validation 的 7 项问题检查关卡。

横向转向决策点（关键方法论）

当暴力破解 / 直接攻击没有结果时，不要继续硬攻——转向横向发现。 这是渗透测试中最重要的判断。

切换攻击向量的触发条件 — 了解何时切换方向

信号	当前向量	切换至
已测试 100+ 个密码，均未命中	暴力破解（登录）	SSRF、CORS、子域名枚举、API 发现、源码泄漏、开放注册、Firebase/Supabase
MySQL/SSH 上所有常见凭据均失败	数据库/SSH 暴力破解	API 发现（扫描端口以寻找 HTTP 服务）、JS 包中的密钥、Firebase 配置、CORS 数据外泄
每个负载都遇到 WAF/403	Web 利用	CDN 绕过（发现源站 IP）、子域名枚举（staging/dev 可能没有 WAF）、非标准端口上的 API、HTTP 方法/标头篡改
速率限制 / 验证码 / 账号锁定	身份验证暴力破解	SameSite 绕过、OAuth 配置错误、MFA 疲劳攻击、密码重置投毒、SSO 令牌重用
所有 API 端点均返回 401/403	API 利用	OPTIONS 预检、方法篡改（GET→POST、PUT→PATCH）、切换内容类型（JSON→XML→表单）、标头注入（X-Forwarded-User、X-Original-URL）、JWT alg=none
SPA 对所有路径都返回相同 HTML	路径枚举	检查其他端口上的 API（8080、8443、3000、5000、8084）、从 JS 包提取路由、源映射、Firebase/Supabase、CORS 数据外泄
主应用未发现漏洞	应用利用	关联应用（相同 IP/证书/标头 → 相同代码）、子域名、staging/dev 实例、移动端 APK、CMS 管理面板、论坛/社区软件

横向发现检查清单（陷入僵局时执行）

某个攻击向量没有效果时，在断定目标安全之前，请按系统步骤检查以下内容：

1. 前 20 名之外的端口 — 对关键目标运行 nmap -p-，对 /24 网段运行 masscan
2. 非标准 API 端口 — 8080、8081、8084、8443、3000、5000、9090、9000
3. 子域名 — subfinder + crt.sh（staging、dev、admin、api、mail、cpanel、shop）
4. JS 包中的密钥 — Firebase API 密钥、AWS/GCP 凭据、内部端点、JWT
5. 开放注册 — wp-login.php?action=register、/signup、/register 端点
6. CORS 数据外泄 — ACAO 反射 + ACAC:true = 可在浏览器中读取已认证受害者的数据
7. Firebase / Supabase — JS 中的 API 密钥 → 匿名身份验证 → 读取 Firestore/RTDB
8. 错误日志 — /error_log、/debug.log、/wp-content/debug.log（通常包含 1 MB 以上的路径、SQL 和凭据）
9. 源码泄漏 — .git/HEAD、.env、sitemap.xml、robots.txt 禁止访问的路径、源映射
10. 关联应用排查 — 相同 IP / 证书 / 标头 → 其他路径上也可能存在相同的易受攻击代码模板

3 次尝试规则

在对任何单一攻击向量花费超过 5 分钟之前：

1. 尝试主要方法（例如，通过 multicall 测试 100 个密码）
2. 尝试一次横向切换（例如，检查是否开放注册）
3. 尝试一种创造性替代方法（例如，检查 CORS、Firebase、JS 密钥）

如果 3 次不同尝试均未奏效，该向量的成功概率很低。记录尝试过的内容，然后继续。不要用更多相同方法反复尝试同一向量——寻找性质截然不同的切入点。

反模式：暴力破解陷阱

"Let me just try 100 more passwords..."
"Maybe I need a bigger wordlist..."
"Let me try one more round..."

🚫 停止。 如果前 100 个定向密码都不起作用，接下来的 10,000 个也不会奏效（针对现实世界中的密码）。请改为：

• 检查是否根本没有任何身份验证（CORS 无需身份验证的端点）
• 检查是否开放注册（创建自己的账号）
• 检查身份验证是否使用了可伪造的 JWT（alg=none、弱 HMAC）
• 检查是否存在其他身份验证路径（SSO、OAuth、SAML）
• 完全转向其他目标

常见误区

• 不要跳过阶段 1。 许多关键发现来自被动侦察（源代码泄露、GitHub SA 密钥）。
• 阶段 2 不要花超过 15 分钟。 快速筛查即可——深度探测留到阶段 6。
• 操作安全不是可选项。 从一开始就使用 proxy-ns 或 proxychains + Tor。绝不要暴露你的源 IP。
• .env 不一定是发现项。 验证内容是否包含实际凭据（DB_、APP_KEY），而不是只有 SPA 兜底 HTML。
• 边做边记录。 不要等到阶段 7——你会忘记具体命令。
• 达到横向移动触发条件后，不要继续暴力破解。 每个向量最多尝试 100 个有针对性的密码，然后转向横向移动。

验证

• 每个阶段都有明确的退出标准（例如，“得分 >= 6 → 升级到阶段 6”）。
• 每项发现都必须能通过确切的命令复现。
• 所有发现都必须通过报告前的 7 问审核。