在不接触目标的前提下完成域名被动侦察与资产测绘

当你需要研究、画像某个域名/网站/IP，或在不惊动对方的情况下调查可疑站点时，用一套有序的被动侦察流程产出可辩护的资产清单与归属结论。

适用场景

解决思路

1. 先写下授权范围：明确主体（哪些域名和网段、哪些相邻目标被排除）、目标、涉及司法辖区，以及被动边界——特别是是否允许 DNS 解析、字典爆破和任何对目标的 HTTP 接触；阅读 ETHICS.md；若被察觉有影响，先用 investigate-without-getting-made 做好归属卫生。
2. 按“最便宜且最安静优先”的顺序执行：1) 注册与 DNS 基线；2) 名称扩展（仅用存档来源）；3) 解析与清单；4) 基础设施与服务；5) 内容、历史、代码与技术栈；6) 所有者归属。把 1–5 阶段当作循环而非直线，每阶段产生的新选择器都回灌到阶段 1 或 2，直到满足第 7 步的停止规则。
3. 阶段 2：对每个在范围内的 apex 运行 who-owns-this-domain，获取注册商、日期与状态、nameserver、完整记录集，以及 TXT、MX、DKIM、CAA 暴露的邮件与 SaaS 指纹；若注册信息被隐去，同一轮拉取历史 WHOIS。完成标准：每个 apex 都有带检索时间戳的注册记录、完整记录集，以及从 DNS 中提取出的具名第三方供应商列表。
4. 阶段 3：运行 find-hidden-subdomains，先查 Certificate Transparency 和 passive DNS（免费、有历史、不可见）；把阶段 2 得到的组织名称连同域名一起作为输入，证书主体搜索能发现简报里没有的兄弟域名和被收购域名。完成标准：得到去重后的候选主机名列表，每个名字记录来源和首次出现日期，新发现的 apex 域名回灌阶段 2。
5. 阶段 4：把每个候选分类为解析到地址、解析到第三方 CNAME、或不解析；立即建立资产清单而不是最后再补，事后给已收集列表补溯源会让发现丢失时间戳；schema 和每行字段见 reference/asset-inventory.md。完成标准：每个候选归入三类之一并带解析时间戳，每个可解析主机有 IP 和 ASN，每个第三方 CNAME 归属到具名供应商。
6. 阶段 5：对阶段 4 得到的地址和网段运行 find-exposed-servers，只查询扫描平台——不做端口扫描、不做服务探测；用证书和 favicon 枢轴捕捉与目标共享基础设施但不共享 DNS 的主机，并记录任何看似无意暴露的内容。完成标准：每个在范围内 IP 有带扫描日期的观测端口与服务，每个网段有来自 RIR 记录的所有者，仅通过证书或 favicon 枢轴发现的基础设施已加入清单并完成归属分级。
7. 阶段 6：按顺序查三类来源——用 read-deleted-pages 看过去的地产（退役主机名、旧员工页、暴露路径、CDN 前基础设施引用）；用 google-like-a-spy 看已发现主机上当前被索引的内容（文档、目录列表、配置、被遗忘的门户）；用 secrets-in-git-history 查阶段 2–5 暴露的组织名、GitHub 组织 slug、云租户标签和项目 ID。若图像重要（跨站点网络复用的 logo、冒充办公室的图库照片），运行 find-the-original-image，共享图像能在 DNS 和注册信息之外把站点关联起来。
8. 阶段 6 续：从已掌握材料组装技术栈——存档副本和扫描记录中的 header 与 cookie、证书签发者、CNAME 目标、JavaScript 与资源路径、CSP 指令、favicon 哈希，以及阶段 2 的 SaaS 指纹；需要看实时页面时，改读第三方扫描结果而不是直接抓取。完成标准：对高优先级主机名完成存档与索引内容审查，代码暴露已记录或排除，新主机名回灌阶段 4，技术栈按主机记录且每个结论标注所依据的工件，版本标记为“声称”而非“已验证”。
9. 阶段 7：用五条标准判断地图是否完成——连续两个新来源未产生新资产（饱和而非穷尽才是信号）；每个发现的名称都已解析或分类，每个可解析主机都有所有者和归属等级；命名约定没有无法解释的空缺（如 web01 和 web03 在清单中，就必须交代 web02）；阶段 2 的每个具名供应商和租户都已产出资产或被排除；阶段 1 的目标能由清单回答。未通过的标准直接指出该重入哪个阶段；全部通过，或把剩余缺口写成明确声明的局限而非隐含。
10. 阶段 8：若注册人、证书主体、RIR 再分配或租户标签指向法律实体而非个人，域名工作结束，转入企业调查——把实体名和司法辖区交给 x-ray-a-company，把注册与受益所有权问题交给 who-really-owns-it，把找回的邮箱交给 what-an-email-reveals；不要试图从 DNS 工件推断公司结构，DNS 显示的是运营者而非股东。完成标准：每个所有者侧选择器都路由到正确技能，或记录为死胡同并注明原因。
11. 阶段 9：运行 write-the-intel-brief，先写资产清单，再写归属链，然后写任何看似无意暴露的内容，最后写阶段 7 的局限。完成标准：每条断言都能追溯到带来源和时间戳的清单行，每个发现都带置信度等级。
12. 分别对清单和归属做置信度分级：确认资产——位于你已验证注册信息的域名下，或位于按名称再分配给目标的网段上，或提供目标可证明控制的证书，并有第二个独立来源佐证；可能资产——一个强基础设施指纹（共享 DKIM 密钥、相同邮件租户标签、相同提供商分配的 nameserver 对、独特 favicon 或正文串）且无矛盾；未确认——共享主机或 CDN 地址、捆绑证书名、仅 org: 归属，或未见过底层记录的聚合器结果。技术技能中的逐技术标准更具体时优先。
13. 避免常见错误：不要因枢轴导致范围蔓延（不在阶段 1 主体列表中的是应报告的发现，不是要启动的工作流）；不要悄悄漂移成主动侦察（解析、爆破和 HTTP 探测处于连续谱上，被动采集器常有一个 flag 之遥的主动模式）；不要做无归属的清单（共享主机、CDN 地址和捆绑证书会把不属于目标的资产挂到目标上，未分级的清单行是负债；目标仅使用的有漏洞 SaaS 租户是供应链发现，必须如此表述）；不要把陈旧数据当当前数据（存档、CT 和扫描记录都是历史的，无日期的发现不算发现）；不要在第一个安静时刻停下（没有新结果通常意味着一个来源饱和，而非地产已测绘）；不要过度收集（存档页中的员工姓名和 SNMP 联系人属个人数据，只收集目标所需）。
14. 遵守法律与 ToS：从第三方数据集被动收集在多数司法辖区属合法研究，边界是对目标的流量和访问非公开系统；从历史 WHOIS 找回的注册人数据即使曾经公开，在 GDPR 下仍是个人数据，需有合法依据并最小化；扫描平台和存档条款限制批量再分发——引用发现，不要重新发布数据集；发现的暴露只授权向运营者或相关 CERT 报告，别无其他；在尽职调查中，确认你持有客户对所做范围的书面授权，“我们的客户要收购他们”不是来自目标的授权。

适用边界 · 注意事项

• 需要主动探测、端口扫描或直接接触目标系统时（本流程明确禁止向目标发包）。
• 没有合法授权或合法依据处理注册人个人数据、或客户未书面授权该范围时。
• 目标仅通过共享主机/CDN 或捆绑证书关联、无法获得第二独立来源佐证时，不应给出确认级归属结论。