官网：http://securitytech.cc/
如何寻找真实的 Bug Bounty 目标 | 实时渗透与工作流解析
阶段 1：目标选择（Target Selection）
第一步也是最关键的一步，就是进行目标选择。
在本次示范中，我们会使用 GitHub 仓库中提供的一些 Google Dorks 搜索语句。
Google Dorks 的作用： 它可以通过高级搜索语法过滤结果，找到更具体、更有价值的目标。我会先演示一个示例，然后展示我通过这种方法找到的目标，并进入实战环节。
阶段 2：利用 Google Dorking 寻找最新赏金项目
我们从 GitHub 复制以下 Google dork：
"security.txt" AND "PGP" AND (bounty OR reward)
然后在 Google 中点击 工具 > 任意时间 > 最近一周 进行过滤。
你也可以利用时间过滤功能，找到最新更新的赏金项目，减少竞争，例如新开放的子域、更新后的 VDP。
示例图：
在结果中我们看到只有少量来自 FireBounty 和 MoneyLead 的目标，这说明这些赏金都是更新较新的、竞争较低的目标。
如果你需要更多、更加系统化的搜索方法，我的新课程中有完整的搜索流程（20 多小时），涵盖从选目标到挖洞再到提交的整个过程。
阶段 3：初步测试目标（paymenttools.com）
开始针对目标进行实战测试。
我们访问 paymenttools.com 的联系页面，然后使用 GitHub 仓库中的 PoC：
<img src\x12="x" onerror="javascript:alert(1)" />
将其填入 first name 与 surname 字段。
结果表明： 在联系页面没有触发 XSS。 登录页面同样无法绕过认证。
阶段 4：枚举攻击面（Attack Surface Enumeration）
接下来我们在 Kali 中导出 paymenttools.com 作为目标，然后使用 subfinder 找隐藏子域，输出到 domain1.txt。
然后使用 assetfinder 输出到 domains2.txt。
阶段 5：提取隐藏的认证路径（Authentication Paths）
在登录页面，我们尝试解码 URL 参数。
解码后发现：
https://account.paymenttools.com
然后我们回到 DevTools → Network，随便提交一次登录请求，出现 401 Unauthorized。
但重要的是，我们发现请求地址：
https://paymenttools.eu.auth0.com/usernamepassword/login
所以认证端点是：
https://paymenttools.eu.auth0.com/
https://account.paymenttools.com/
https://paymenttools.eu.auth0.com/usernamepassword/login
https://paymenttools.eu.auth0.com/
阶段 6：整合子域并找出存活主机
将 domain1.txt 与 domains2.txt 合并为 domains.txt，然后使用 httpx 探测存活主机输出到 live.txt。
打开 live.txt，里面就是所有活跃的隐藏子域（视频中做了打码）。
阶段 7：手动检查发现的子域
进入部分子域会发现“页面不存在”。
但我们继续打开多个子域，其中一个的 javascript 文件仍无突破。
在同一个子域，我们也发现了：
/css/tailwind.css
依旧是死路。
继续反复访问我们感兴趣的子域，终于找到一个新的子域跳转到了：
REWE Group 的登录页
阶段 8：版本指纹识别与 CVE 检查
我们检查 REWE Group 是否存在相关 CVE，结果发现：
CVE-2021-31537
虽然该漏洞只影响其特定版本，我们仍需判断其当前版本是否相同。
通过 DevTools 搜索资源文件，找到：
/auth/resources/cispy/login/rewe-group.v2/js/main.js
说明该系统极可能仍使用 v2 资源。
阶段 9：深度链接与递归式探索（Recursive Exploration）
按照同样方式继续挖掘子域的深层链接，最终 Jackson 找到：
一个暴露的 AWS S3 Bucket
其中包含一些敏感文件（例如订单文件等）。
该漏洞已负责任披露。
阶段 10：总结建议
持续 fuzz 子域非常关键，尤其是针对 政府站点，这类站点常常隐藏大量未公开的子域，一旦找到敏感资源，往往能获得高额赏金。
挖洞愉快，Peace ✌️
