recon-a-domain-passively

被动侦察一个域名

将一个域名转化为一份有据可查的组织互联网暴露资产图谱，并找出其背后的所有者。相关技术在其他技能中介绍；此工作流的价值在于顺序、清单和停止规则。一开始就要避免两种失败模式：耗费数小时枚举，最后产出 400 个主机名，却没有归属信息、日期或优先级——这算不上图谱；以及不知不觉转为主动操作，因为一次“只是检查它是否在线”的探测就会让被动侦察的说法站不住脚。在第 2 步之前，而不是执行过程中，先确定被动边界。

顺序逻辑

每个阶段的结果都会为下一阶段提供输入，顺序从成本最低、最隐蔽的操作开始：

顺序	阶段	原因
1	注册信息和 DNS	确定边界。没有根域名集合和注册人信息，就不知道范围内包含什么
2	扩展名称空间	仅使用历史数据源。不花钱、不接触目标，并会生成供后续所有环节使用的候选列表
3	解析和清点	将名称转换为地址，而基础设施查询正是以地址为输入
4	基础设施和服务	需要阶段 3 的地址。仅使用第三方扫描数据
5	内容、历史记录、代码、技术栈	需要前面阶段获取的主机名和组织名称作为搜索词，并复用已收集的材料
6	所有者归属	上述阶段发现的注册人、租户和组织名称是此阶段的输入

将阶段 1–5 作为循环执行，而不是单向流程。每个阶段都会产生新的筛选条件，应返回阶段 1 或 2 使用。满足第 7 步的停止规则后，即可停止循环。

第 1 步 — 授权范围

以书面形式说明：目标（哪些域名和网段在范围内，以及明确排除哪些相邻目标）、目标、涉及的司法管辖区和被动边界——具体说明是否允许 DNS 解析、字典暴力枚举，以及与目标进行任何 HTTP 通信。阅读 ../../ETHICS.md。如果避免被发现很重要，请先使用 investigate-without-getting-made 做好归属信息卫生，再查询任何内容。

完成标准： 已写明目标、目标、范围外列表、司法管辖区和被动边界，并且清楚三种灰色活动中哪些可以执行。

第 2 步 — 注册信息和 DNS 基线

对范围内的每个根域名运行 who-owns-this-domain。需要获取注册商、日期和状态、名称服务器、完整记录集，以及 TXT、MX、DKIM 和 CAA 暴露的邮件和 SaaS 特征。如果注册信息已被隐藏，则在同一轮中查询历史 WHOIS。

完成标准： 每个根域名都有一条带检索时间戳的注册记录、完整记录集，以及从其 DNS 中提取的第三方供应商名称列表。

第 3 步 — 扩展名称空间

运行 find-hidden-subdomains。优先使用证书透明度和被动 DNS，因为这些方式免费、有历史记录且不可见。除了域名，也将第 2 步发现的组织名称提供给它——按证书主题搜索可以找到兄弟域名和收购得来的域名，这些域名可能从未出现在任务说明中。

完成标准： 已获得去重后的候选主机名列表，并为每个名称记录来源和首次发现日期；所有新发现的根域名都已返回第 2 步处理。

第 4 步 — 解析并开始清点

对每个候选项进行分类：解析为某个地址、解析为第三方 CNAME，或无法解析。现在就建立清单，而不是等到最后——给已收集的列表补充来源信息，正是发现结果丢失时间戳的原因。字段模式和每行所需字段见 reference/asset-inventory.md。

完成标准： 每个候选项都已归入三个类别之一，并带有解析时间戳；每个可解析的主机都有 IP 和 ASN；每个第三方 CNAME 都已归属到具名供应商。

第 5 步 — 基础设施与服务

对第 4 步中的地址和网段运行 find-exposed-servers。只查询扫描平台，不进行端口扫描或服务探测。利用证书和网站图标线索，找出与目标共享基础设施但不共享 DNS 的主机，并记录任何看起来像是意外暴露的内容。

完成标准： 每个范围内的 IP 都记录了观测到的端口和服务及其扫描日期；每个网段都根据其 RIR 记录确定了所有者；仅通过证书或网站图标线索发现的任何基础设施都已加入清单并完成归属评级。

第 6 步 — 内容、历史、代码与技术栈

按以下顺序使用三个来源：

• 使用 read-deleted-pages 查看该资产过去的情况：已停用的主机名、旧员工页面、暴露路径、CDN 之前的基础设施引用。
• 使用 google-like-a-spy 查看你找到的主机目前被索引的内容——文档、目录列表、配置、被遗忘的门户。
• 使用 secrets-in-git-history 检查第 2 至第 5 步发现的组织名称、GitHub 组织 slug、云租户标签和项目 ID。

如果图像很重要——例如在一组网站上重复使用的徽标，或冒充办公室的图库照片——运行 find-the-original-image。当 DNS 和注册信息无法关联网站时，共享图像可以将它们联系起来。

然后根据你目前掌握的信息整理技术栈：归档副本和扫描记录中的标头与 Cookie、证书颁发者、CNAME 目标、JavaScript 和资源路径、CSP 指令、网站图标哈希，以及第 2 步中的 SaaS 特征。如果需要查看在线页面，请读取第三方对该页面的扫描结果，而不是自行获取页面。

完成标准： 已审查优先级最高的主机名对应的归档和索引内容；已记录代码暴露情况，或确认不存在代码暴露；新增主机名已重新经过第 4 步；已按主机记录技术栈，并注明每项结论所依据的证据，将版本标记为声称的版本而非已验证版本。

第 7 步 — 判断资产图谱是否已完成

完整性需要判断，因此请依据以下标准进行评估：

• 连续两个新来源都没有发现新资产。这表示已达到饱和，而非穷尽。
• 每个发现的名称都已解析或分类，每个可解析的主机都有所有者和归属评级。
• 命名惯例中不存在无法解释的缺口：如果清单中有 web01 和 web03，就必须说明 web02 的情况。
• 第 2 步中提到的每个供应商和租户都已发现相关资产，或已排除。
• 可以根据清单回答第 1 步中的目标。

未通过的标准会明确指出需要重新进入哪个阶段。

完成标准： 五项标准全部通过，或将剩余缺口作为明确说明的限制记录，而非含糊带过。

第 8 步 — 移交所有者调查

如果注册人、证书主体、RIR 重新分配信息或租户标签指向的是法人实体而非个人，则域名调查已完成，应开始企业调查：将实体名称和司法管辖区交给 x-ray-a-company，将注册信息和受益所有权问题交给 who-really-owns-it，并将找回的电子邮件交给 what-an-email-reveals。不要试图根据 DNS 证据推断企业结构——DNS 显示的是运营方，而非股东。

完成标准： 每项所有者侧线索都已交由合适的技能处理，或已记录为无法继续的线索并说明原因。

第 9 步 — 撰写报告

运行 write-the-intel-brief。先列出资产清单，再说明归属链，然后列出任何看起来像是意外暴露的内容，最后说明第 7 步中的限制。完成标准： 每项论断都能追溯到清单中带有来源和时间戳的一行记录，且每项发现都标有置信度等级。

问题所在

• 通过转向不断扩大范围。 枚举会没完没了地产生同级域名，每个看起来都像下一个目标。如果它不在步骤 1 的主题列表中，就应作为发现报告，而不是启动新的工作流。
• 悄然转向主动探测。 解析、暴力破解和 HTTP 探测各有不同程度，工具也模糊了界限——被动收集工具只需一个标志就能切换到主动模式，而一个不慎设置的标志就会让本次任务不再符合被动探测的说法。
• 清单没有归属判定。 共享主机、CDN 地址和捆绑证书会把并非目标所有的资产关联到目标，而未评级的清单条目就是一种风险。类似地，目标只是使用的易受攻击 SaaS 租户属于供应链发现，必须据此表述。
• 将过时数据当作当前数据呈现。 存档、CT 和扫描记录都是历史数据，未注明日期的发现不能算发现。
• 在首次出现平静时就停止。 通常没有新结果意味着某个来源已饱和，而非整个资产范围已完成映射——步骤 7 正是为捕捉这一点而设。
• 过度收集。 存档页面和 SNMP 联系人中的员工姓名属于个人数据。只收集目标所需的内容，不多收。

置信度评级

分别对清单和归属判定评级。同一主机可以是已确认的在线服务，同时又是目标的未确认资产；混淆这两者是域名侦察报告中最常见的错误。

• 已确认资产——位于你已验证注册信息的域名下，或位于按名称重新分配给目标的网段中，或提供目标明显控制的证书，且有第二个独立来源佐证。
• 可能是资产——存在一个有力的基础设施指纹（共享 DKIM 密钥、相同的邮件租户标签、相同的服务商分配的名称服务器对、独特的 favicon 或正文字符串），且没有相反证据。
• 未确认——共享主机或 CDN 地址、捆绑证书中的名称、仅凭 org: 归属的结果，或尚未查看底层记录的聚合器结果。

如果技术技能中的逐项技术标准更具体，则以其为准。

示例

任务：一位客户即将收购 meridian-freight.test，希望在签约前了解其面向互联网的资产范围。范围：顶级域名，以及注册人明显控制的任何域名。边界：允许解析，不允许暴力破解，不允许联系 HTTP 服务。

步骤 2：五年前注册，注册人信息已隐去，但国家为 NL；有一个 Microsoft 365 租户，以及指向支持台、身份提供商和 GitHub 组织的 TXT 令牌。该 GitHub 组织名称是整组记录中价值最高的信息，而获取它只需一次查询。

步骤 3 返回 74 个候选项，按证书主题搜索发现了 meridian-logistics-group.test，但它不在任务说明中。回到步骤 2：其 MX 记录中有相同的 M365 租户标签，因此由同一运营方管理。将其纳入范围，并通知客户。

步骤 4：31 个域名可解析，其中 9 个解析到第三方 CNAME——这是关联关系，不是资产。uat-portal 位于一个规模较小、不同于其他所有网段的荷兰托管网段中，因此它成了本次任务的主要线索。

步骤 5：五周前观察到该 UAT 主机的 443 和 3306 端口开放。此外还有 11 个主机共享同一个 favicon 哈希，起初看起来像是一个隐藏的资产范围，直到发现该哈希属于一个现成 CMS 主题——这是条死胡同，也正是跳过核查时会让报告虚增的情况。

步骤 6：GitHub 组织中的一个公开仓库包含 CI 配置，其中提到了两个 DNS 中不存在的内部主机名。它们无法解析，但仍然重要，因为收购方会继承这些系统。

步骤 7：连续第三个来源没有增加任何内容，web02 已有归属判定，所有供应商都已追查。工作完成，但需说明一个缺口——顶级域名的通配符证书意味着在它签发之后签发的子域名不会出现在 CT 中。步骤 8：荷兰注册人国家、同级域名以及证书主题中的集团名称都指向一种控股结构，因此将其归入 x-ray-a-company。

后续调查方向

选择器	前往
法律实体、集团名称、司法管辖区	x-ray-a-company、who-really-owns-it
电子邮件地址和电话号码	what-an-email-reveals、whose-number-is-this
从档案或元数据中找到的员工姓名	find-anyone
从代码仓库中找到的开发者账号	hunt-a-handle
从该公司中提取的文档	secrets-in-file-metadata
该域名邮箱遭泄露的情况	what-leaked-about-you
整套资产与实体，用于分析结构	graph-the-network

法律与服务条款说明

在大多数司法管辖区，从第三方数据集中被动收集信息属于合法研究；界限在于是否向目标发起流量，以及是否访问非公开系统。从历史 WHOIS 中恢复的注册人数据属于 GDPR 规定的个人数据，即使这些数据曾经公开过也不例外，因此你需要具备合法依据，并遵循数据最小化原则。扫描平台和档案库的条款限制批量再分发——可以引用调查结果，但不要重新发布数据集。发现信息暴露后，只能向运营方或相关 CERT 报告，不能采取其他行动。此外，在尽职调查中，请确认你已获得客户针对所执行范围的书面授权：“我们的客户要收购他们”并不构成目标方的授权。