hunt-misc 是一个面向漏洞赏金与安全测试的技能（skill），用于指导“杂项（MISC）”类漏洞的挖掘。资料显示其由 225 份公开漏洞赏金报告构建，适用场景为对任意目标进行杂项类漏洞排查。
一、用途与价值定位 该技能针对的漏洞类别涵盖访问控制失效、信息泄露、会话/认证逻辑缺陷以及安全配置错误，这些类别通常产生较高赏金，因为其直接对应业务影响：数据暴露、账户接管、权限提升和基础设施失陷。
二、高价值目标与资产类型 资料给出的高价值目标包括：具有角色层级的 SaaS 平台（如 Shopify、GitHub、GitLab），任何 owner/admin/staff/guest 之间的边界都是权限提升面；身份/认证流程（邀请链接、密码重置、SAML SSO、OAuth token scope）；多租户系统（一个租户访问另一租户数据）；内部 API（LFS 端点、pre-receive 钩子、假定调用方可信的内部 GraphQL/REST）；域/DNS 管理功能（转移控制、子域委派）；令牌/凭据管理（PAT scope、部署密钥、配置字段中存储的 API 令牌）。 付费最多的资产类型包括：核心产品 API（而非营销子域）、企业/自托管版本（GitHub Enterprise、GitLab EE）、合作伙伴/协作者邀请系统、OAuth 应用集成与 webhook 端点。
三、攻击面信号 URL 模式关注项包括 /admin//transfer、/invitations/、/partners//accept、/api/v/repos//lfs/、/-/settings/integrations/sentry、/api/v*/user/installations、/hooks/pre-receive/、/reset-password?token=、/auth/saml/callback、/api/v/packages/pypi/* 等。响应头信号包括 X-Request-Id（pitchfork/Rack，检查头注入）、X-Shopify-Shop-Api-Call-Limit、X-GitLab-*。JS 模式中关注硬编码内部 API 路径（如 fetch('/internal/api/）、graphql { installations(、“scope”: []（空 scope 令牌）、“permissions”: {"contents": "read"}（最小 scope PAT）。技术栈信号包括 Ruby/Rack 中间件（pitchfork 的 CRLF 注入风险）、企业实例启用 SAML SSO、PyPI 代理/镜像配置（依赖混淆）、Sentry 错误追踪集成字段（SSRF/令牌泄露向量）、多角色邀请系统。
四、分步挖掘方法（要点） 映射所有角色/权限边界，枚举每个角色层级（owner → admin → staff → guest → removed）并记录各角色应可见内容。标记纪律：通过注入唯一令牌/标识符探测角色边界时，标记必须是唯一随机字母数字串（8 位以上，无英文单词，无协议关键词）。坏标记如 test、marker、attacker、evil、admin、AAAA；好标记如 cpmark987abc、x4hd2k9pq。在主张任何反射前，先在无标记的基线响应中搜索该标记，若其自然出现则更换标记。正文差异规则：权限绕过主张需要响应正文差异，而非仅状态码；返回 200 且正文与基线逐字节相同不构成绕过。始终并排比对正文后再主张绕过；仅凭状态码的主张是平台上最常见的被判为 N/A 的类别。 此外还包括：端到端测试邀请流程（未完成验证即接受邀请、篡改邀请令牌、以不同用户接受邀请测试是否授予访问）；测试移除后访问（将用户加入资源后移除，测试其会话/令牌是否仍授予访问，尤其在从公司/组织移除后）；模糊测试令牌 scope 强制（创建最小或无 scope 的 PAT/令牌，调用应要求更高 scope 的 API）；测试跨租户资源访问（以租户 A 身份，通过操纵 ID、路径或头尝试读写租户 B 资源）；探测内部/未公开 API 端点（LFS 端点、内部 GraphQL 操作、pre-receive 钩子环境、webhook 投递日志）；检查 SAML/SSO 逻辑（剥离签名、修改 NameID、重放断言、操纵 XML 命名空间测试签名验证绕过）；审计配置字段以发现 SSRF/令牌外泄（管理设置中任何 URL 字段，如 Sentry DSN、webhook URL、代理 URL）；测试密码重置与邮箱验证流程（跳过验证步骤、测试重置令牌是否限定单一用户、测试令牌重用）；检查 HTTP 头注入点（任何经 Ruby/Rack 中间件传入响应头的用户可控输入，测试 CRLF 序列）；验证 DNS/子域卫生（枚举子域、检查悬空 CNAME、验证 SPF/DMARC/DKIM）；测试包注册表代理配置（通过转发到公共注册表发现依赖混淆）。
五、Payload 与检测模式 资料提供了多类命令示例，包括：CRLF/头注入（Ruby Net::HTTP、Rack/pitchfork）的 curl 测试命令；通过邀请绕过的权限提升；令牌 scope 绕过（GitHub/GitLab PAT）；通过配置 URL 字段的 SSRF（Sentry 集成）；ReDoS 检测（Ruby URI 解析器、IPAddr、基于时序的检测）；源码侦察的 grep 模式（SAML 签名验证、弱 scope 检查、无验证的邀请接受、内部 API 路由）；悬空子域/DNS 检查（过时 DNS 记录、SPF 检查）。所有命令均以 curl、ruby、grep、dig 等形式给出。
六、常见根因 资料列出的根因包括：软删除未使权限失效；邀请接受缺少验证门；令牌 scope 仅在签发时检查而非使用时；基于角色的访问控制仅在 UI 层检查；SAML XML 解析怪癖；配置/URL 字段被信任为内部；Ruby 通过字符串插值的头注入；代理/镜像配置将全部请求转发上游；pre-receive 钩子环境暴露特权上下文；多设备会话设计与会话固定混淆；将服务器策略响应误判为基于状态的存在性预言机（如 SharePoint 的 download.aspx?SourceUrl= 对 .ashx/.asmx/.svc/.config 扩展名返回相同“被阻止”响应，看似文件存在预言机实为扩展名黑名单）。
七、绕过技巧 资料以表格形式给出防御与绕过的对应关系，涵盖邀请邮箱验证、API 端点角色检查、SAML 签名验证、PAT scope 强制、用户移除时的令牌撤销、头值输入净化、将内部 API 限制为 localhost、ReDoS 正则加固、依赖固定、子域声明验证等。
八、Gate 0 验证 在编写报告前需回答三问：攻击者现在能做什么（必须是具体动作）；受害者失去什么（必须对应真实资产）；能否在 10 分钟内从零复现（写出确切步骤，如需前置条件须明确说明并验证攻击者实现该条件的现实性）。
九、真实影响示例 资料给出三个场景：场景 A 未验证的合作伙伴邀请导致权限提升（Shopify 类）；场景 B 移除后跨租户数据持久化（Shopify/GitLab 类）；场景 C SAML 签名绕过导致账户接管（GitHub Enterprise 类）。
十、链式与组合（高级挖掘） 资料强调高级工作将原语组合成多步攻击以达成影响。例如链 1——软删除 + 移除后会话持久化 → 跨租户 PII，利用“移除成员”端点仅翻转 active=false 或删除成员行但不使会话或令牌失效的根因，先以将被移除的员工身份登录并捕获会话 cookie/PAT，由组织管理员通过正常流程移除该用户，随后重新发起相同 API 调用。资料原文在此处截断。
限制说明：资料未提供该技能的安装方式、平台归属、收费信息或具体代码仓库结构，相关事实暂未提供。