用途
hunt-ato 是一份账户接管（Account Takeover，简称 ATO）漏洞挖掘的分类学与实操指南。它的核心观点是：ATO 是一个“目的地类别”，而不是单一漏洞——下面每一条路径都是一种原语（primitive），只有当你能证明从攻击者 A 的会话/IP/设备接管了一个你不控制的第二个账户（测试账户 B）时，它才升级为严重（Critical）漏洞。仅能把自己锁出账户，或必须已经同时持有受害者密码和会话才成立的路径，不算独立的 ATO。
主要能力（9 条以上路径）
路径 1：密码重置投毒（Host 头）。在 POST /forgot-password 中替换 Host 头，或添加 X-Forwarded-Host、X-Host、X-Forwarded-Server，或使用双 Host 走私。重置邮件根据请求 Host 头构建链接，从而指向攻击者域名。确认方式是 OOB（带外），把头指向 Burp Collaborator 或唯一 DNS 名并读取真实邮件，而非依据反射的头推断。
路径 2：重置令牌经 Referer / 开放重定向泄露。重置页面加载第三方资源时，浏览器会把含 token 的完整 URL 作为 Referer 发送给所有跨源主机；也测试把 token 带入开放重定向的 302 页面。证明方式是在 Network 面板或 Collaborator 中捕获含完整 token 的出站请求。
路径 3：可预测/弱重置令牌。针对 6 位数字 OTP 式重置码且无限速的情况，用 ffuf 爆破；对基于时间的令牌，采集 5 个令牌做差分，判断是否为 md5(时间戳) 或顺序整数。文档强调：仅报告 /forgot-password 的限速问题通常会被拒，影响在于令牌猜测而非请求洪泛。
路径 4：令牌不过期/复用/跨账户。测试过期（请求后等 2 小时是否仍有效）、复用（用一次后再用是否仍有效）、多令牌（请求 token#1 后再请求 token#2，token#1 是否仍有效）、跨账户（交换 userid/email 参数后 B 的令牌能否重置 A 的密码，即重置中的 IDOR）。
路径 5：无重认证的邮箱修改。若修改邮箱无需当前密码、无需 OTP、也无需向旧地址发送确认链接，则可触发密码重置，使重置邮件落到攻击者邮箱，实现 ATO。最强变体连新地址确认都跳过。
路径 6：JWT 操纵。包括 (a) alg:none 去掉签名；(b) RS256→HS256 密钥混淆，用服务器公钥作为 HMAC 密钥重签；(c) 弱 HMAC 密钥离线爆破（hashcat -a 0 -m 16500）；(d) kid 注入（路径穿越到 /dev/null 或 SQL 注入）。文档给出 CVE-2015-9235、CVE-2016-10555 作为依据，并强调伪造令牌必须能作为受害者 B 访问特权端点才算影响；若服务器忽略伪造的 sub 而依赖会话 cookie，则 JWT 不是信任边界，不构成漏洞。
路径 7：无二次验证的密码修改 + 登录预言机。密码修改端点接受新密码且无需当前密码/MFA 时，配合 cookie 窃取（XSS、会话固定、令牌泄露）即可从任意设备/IP 接管 B。另可用登录响应时间差或响应长度差作为预言机，找出有效密码。
路径 8：社交恢复/安全问题滥用。安全问题答案熵低且常无限速，可爆破恢复答案端点；也可测试答案是否在 /api/me 或恢复页源码中回显；问题本身可能泄露可被 OSINT 获取的 PII。
路径 9：OAuth redirect_uri 处的 SSO 子域接管。枚举提供方是否接受 *.target.com 子域；用子域枚举找出悬空子域（CNAME 指向已下线的 Heroku/S3/Azure/GH-Pages）；在云厂商处认领该主机并托管记录 ?code= 的回调；向受害者 B 发送构造的授权 URL，使其 code/token 落到攻击者认领的子域。确认需 OOB：授权码必须真正到达你认领的主机。文档提醒要 JSON 解析 OAuth 错误体，不要子串匹配 access_token（AADSTS50076 等响应中 claims 字段含字面 access_token 子串但不可用）。
路径 10：预账户/未验证账户接管。受害者账户处于待处理/未验证状态（邀请未接受、注册邮件未确认、无邮箱记录）时，先认领该身份（注册或绑定自己控制的邮箱），再让受害者完成 SSO/OTP 登录并继承攻击者预置的状态，或在邮箱绑定后触发重置。
路径 11：基于标识符的无密码/魔法链接滥用。无密码注册/魔法登录/OTP 登录端点仅凭可枚举标识符（手机/邮箱）就设置或重置密码（或签发会话），且无令牌步骤。枚举标识符以证明可触达任意账户。
使用方式
文档以路径为单位组织，每条路径给出具体的 HTTP 请求示例、命令行工具用法（ffuf、hashcat、curl、python3 jwt 等）和确认方法。使用时应逐条对照测试，并遵循文档给出的“误报排除”提示（例如读取真实邮件而非反射头、确认服务端确实无当前密码/MFA 门禁、JSON 解析错误体等）。
适用场景
适用于 Web 应用、API、OAuth/SSO 集成、JWT 认证体系、密码重置与账户恢复流程的安全测试与漏洞挖掘。文档还给出与其他技能的链式组合：hunt-idor（路径 5 + IDOR = Critical）、hunt-mfa-bypass（路径 7 需同时绕过 MFA 才 Critical）、hunt-oauth（路径 9）、hunt-api-misconfig（路径 6 细节）、hunt-host-header（路径 1）、offensive-osint（路径 8 倍增器）、security-arsenal（各类攻击表）、triage-validation（严重性门槛前的验证）。
限制
文档明确 ATO 严重性分级门槛：Critical 需零/低受害者交互（Host 头重置投毒、JWT 伪造到受害者端点、宽松 redirect_uri 授权码窃取、IDOR 驱动的邮箱修改→重置）；High 需一次邮件点击或已有会话/cookie；Medium 需钓鱼加主动用户交互；Low 为需 MitM 或仅影响自身账户。文档强调在声称 Critical 前应运行 Pre-Severity Gate，并用 10 分钟全新浏览器走查（从攻击者 A 会话接管测试账户 B）来区分可付费的 Critical 与被拒的 Self-XSS 级别。