recon-scope-triage

何时使用此技能

在以下情况下触发：

• 目标品牌是常见词／词典词或通用术语（例如 apex、summit、vertex、nova、core、orbit、pulse、unity……）
• 收到 ASM 报告、侦察导出文件、泄露凭据组合、仓库列表、存储桶列表或移动应用列表，需要据此采取行动
• 对于组织规模而言，“Critical”计数高得不合常理（数百个）
• 工具声称某项资产归目标所有，但却没有证据

此技能用于避免两种失误：

1. 浪费本次行动的资源，对并非目标的资产进行测试／分类。
2. 攻击无辜的第三方，仅仅因为它也使用了这个名称——这超出了范围，也会造成实际伤害。

规则：默认将所有权视为未证实。只有具体的所有权信号将资产与目标关联起来时，该资产才属于目标——绝不能仅凭扫描器匹配了关键词就认定归属。

---

冲突来源（关键词匹配为何会误报）

侦察来源	冲突原因	所有权验证方式
GitHub 仓库	搜索结果匹配了仓库名称／主题／字符串中的品牌词	仓库所有者是该组织的 GH 组织；提交来自组织邮箱；代码引用了该组织的真实域名／基础设施。随机用户创建的 <word>-backend 仓库 = 噪声。
云存储桶（S3/GCS）	存储桶名称属于全局命名空间；<word>-static、<word>-data、<word>-public 可能归其他人所有	存储桶内容引用了目标；存储桶名称与已确认的目标子域名相符（x.target.com ↔ x-public），且内容也吻合；ACL／所有者元数据。通用内容（其他语言、其他行业）= 并非目标所有。
移动应用	商店搜索匹配了应用名称／包名中的品牌词	发布者账号属于该组织；包名反向 DNS 对应一个自有域名（com.<owneddomain>.app）；开发者证书；应用调用自有 API 主机。成熟的 ASM 工具会输出“apps_accepted=0”／所有权置信度字段——请查看。
泄露数据集／凭据组合	邮箱本地部分或域名包含品牌词	仅接受与自有域名完全匹配的情况（@target.com），不接受 @<word>group.com／@something<word>.com。包含该词的其他域名属于其他组织。
错拼抢注域名	根据名称生成的排列变体	这些是防御性／品牌保护发现，不属于攻击范围——记录后继续。
Stack／论坛／粘贴站命中项	正文中出现品牌词	正文引用了目标的真实域名／子域名／员工／机密信息。所有权置信度 < 阈值 = 排除。

---

Web“Critical”分类——软 404 检查

自动检测到的 .env／.git／actuator／管理面板“Critical”绝大多数都是软 404：SPA／框架的兜底路由会对所有路径返回 HTTP 200（或 403）。在确认之前，请逐一验证：

# the "finding"
curl -s -o /tmp/a -w "%{http_code} %{size_download}\n" https://host.target.com/.env
# a junk control on the same host
curl -s -o /tmp/b -w "%{http_code} %{size_download}\n" https://host.target.com/zzz-nonsense-$RANDOM
# identical byte length / body  →  FALSE POSITIVE (catch-all), discard
cmp -s /tmp/a /tmp/b && echo "SOFT-404 false positive" || echo "differs — investigate"

真实暴露的内容类型和特征与兜底响应不同（.git/config 以 [core] 开头；.env 包含 KEY=value；phpinfo 页面包含 XHTML transitional 文档类型声明和 PHP Version）。实际存在的 .php／phpinfo.php 返回的正文比垃圾对照项更大／不同，这就能区分真实暴露与软 404。

---

分类工作流

1. 首先确认规范的自有域名集合（SOW／项目域名 + 已验证的子域名 + 已验证的 Entra／Okta／Google 租户品牌名）。这是所有权判断的锚点。
2. **对每种资产类别，按照上方的验证方式进行核实。**没有信号 → 隔离，不要测试。
3. **仅根据自有资产重新统计严重性数量。**报告变化量——“Critical 从 N 个降至 M 个（经所有权和软 404 分类后）”本身就是一项关于 ASM 项目的发现。
4. 明确隔离冲突项（创建 loot/quarantined_<source>.txt），以便审计时能确认你已发现这些项目并选择不将其作为目标。
5. **指出元发现：**如果提供的 ASM／侦察数据源大多是误报，就会导致所有者的修复预算分配不当，并掩盖真实风险——应将其记录为发现（Medium／Strategic）。

---

反模式

• 相信工具标注的“所属”状态。 工具会通过关键词匹配，但无法证明所有权。请进行核实。
• 因为某个目标“出现在报告里”就将同名第三方列为目标。 这超出范围，而且会造成实际伤害。组合行 user@<word>company.com 中的邮箱属于另一家公司的员工。
• 将软 404 报告为信息暴露。 务必运行无关路径对照测试。
• 将拼写仿冒、缺少安全标头或品牌名称冲突的仓库算作攻击性发现。 这些都是防御性问题、卫生问题或噪声，只会充实报告内容，却损害可信度。
• 为了“节省时间”而跳过分类。 不做分类，你就会把整个测试周期花在他人的资产上，最终一无所获。

---

为什么这很重要（校准）

对于品牌名称是常见词语的目标，预计自动化工具标记为“所属”的资产大多是名称冲突：

• 仓库只是包含这个词语的无关开源项目（广告拦截列表、爬虫、学生项目、另一家公司的 SDK）。
• 移动应用由名称相同的完全不同的公司发布——银行、信用社、约会应用、大麻药房、居家护理服务都是现实中常见的名称冲突类别。（好的 ASM 工具会告诉你它接受为所属的资产数量为 0。）
• 云存储桶位于全局命名空间中，存放着某个无关组织的内容（其他语言的文档、演示／示例数据、其他行业的文件）。
• 数据泄露组合数据里充斥着来自名称相似但不同公司的邮箱（<word>group.com、<region><word>.com）。

在针对一个词典词汇品牌的真实测试中，排除这些噪声后，唯一真正属于目标且严重性较高的发现，只能通过手动技术手段发现（从 JS 包发现 API，参见 hunt-spa-api）——数百条扫描器标记为“严重”的结果中都没有它。先做分类，才能让测试有所成效，而不是白费力气地追查。

---

相关技能与链路

• triage-validation — 资产所有权分类（本技能）应先于发现有效性分类（7 问关卡）。先确认所有权，再确认有效性。
• redteam-mindset — “默认采取积极行动”意味着探测每个属于目标的在线攻击面；本技能定义哪些攻击面属于目标，避免在名称冲突上浪费持续投入。
• hunt-spa-api — API 主机通过所有权分类后，可按此方法进行测试。
• offensive-osint / osint-methodology — 将 OSINT 得出的所有权锚点（已验证域名、租户品牌、开发者账号）提供给本分类流程。