1. 项目概述：为什么子域名挖掘是安全评估的基石

在渗透测试或安全评估的初期，信息收集的广度和深度直接决定了后续攻击面的宽度。而子域名挖掘，正是打开目标资产大门的第一把钥匙。一个主域名背后，往往隐藏着数十、数百甚至上千个子域名，它们可能是开发环境、测试服务器、管理后台、API接口，甚至是因配置疏忽而暴露的内部系统。这些“影子资产”的安全防护通常弱于主站，却可能拥有同等甚至更高的业务价值，因此成为了攻击者最青睐的入口点。

“子域名挖掘全攻略”这个标题，精准地概括了从入门到进阶的完整路径。它不仅仅是运行几个扫描工具那么简单，而是一个融合了主动探测、被动情报收集、数据关联分析的系统性工程。基础扫描能快速勾勒出目标轮廓，而像证书透明（Certificate Transparency, CT）日志追踪这类高级技巧，则能从公开的、看似无关的海量数据中，挖掘出那些常规扫描难以触及的、新增的或临时性的资产。对于安全从业者而言，掌握这套组合拳，意味着你能比攻击者更早、更全面地发现潜在风险点。

2. 核心思路与工具选型：构建分层侦查体系

子域名挖掘不能依赖单一方法，我习惯将其构建为一个分层递进的侦查体系。这个体系的核心思路是：先被动，后主动；先广撒网，后精准打击；先自动化，后人工验证。

2.1 被动信息收集：利用互联网的“记忆”

被动收集的核心优势在于隐蔽性高，不会直接与目标服务器交互。我们利用的是互联网上已有的公开记录和第三方服务。

1. 搜索引擎语法（Google Hacking）：这是最基础却常被低估的方法。利用site:example.com -www可以搜索非www子域。结合inurl:,intitle:等语法，有时能发现意想不到的后台或特定应用路径。虽然搜索引擎结果有延迟且不完整，但它能提供一些独特的、可能未被其他工具收录的线索。

2. 第三方聚合平台与API：这是效率最高的被动收集方式。工具如subfinder,amass,assetfinder的核心能力就是调用数十个这样的数据源。

   • 安全DNS记录：如 SecurityTrails, Censys, Shodan。它们不仅提供子域名，还常附带历史DNS记录、关联IP、开放端口甚至横幅信息。
   • 威胁情报平台：如 VirusTotal, AlienVault OTX。一个域名或IP若曾被标记为恶意，其关联的子域名信息也会被收录。
   • 证书透明度日志：这是本文的重点之一，后文会详细展开。Spyse, Censys, crt.sh 都提供基于CT日志的域名查询。
   • 代码托管平台：在GitHub, GitLab 搜索目标公司名称、域名，可能在配置文件、源码注释或部署脚本中发现内部子域名。

注意：过度依赖单一API存在风险。一是API有速率限制和查询配额；二是数据源本身可能不完整或存在误差。因此，组合使用多个工具和数据源是保证覆盖率的关键。我通常会用amass enum -passive -d example.com先跑一遍，它能集成非常多的数据源。

2.2 主动枚举与扫描：直接与目标对话

当被动收集的信息趋于平缓后，就需要主动探测来发现那些未被公开收录的资产。

1. 字典爆破：这是最经典的方法。工具如gobuster,ffuf,dnsgen配合一个强大的子域名字典进行爆破。

   • 字典质量决定成败。不要只用工具自带的通用字典。我通常会融合多个来源：Seclists的subdomains-top1million-*.txt，自己从以往项目中积累的行业特定词汇（如oa,mail,vpn,dev,staging,api），以及通过altdns工具基于已发现的子域名生成排列组合（如dev-example-com,example-com-dev）。
   • 命令示例：ffuf -w subdomains.txt -u “http://FUZZ.example.com” -mc 200,403,401 -t 100。这里不仅关注200状态码，403（禁止访问）和401（未授权）同样有价值，它们证实了该子域名的存在，只是访问受限。

2. DNS区域传送漏洞检测：如果目标DNS服务器配置不当，可能允许任何人进行区域传送，从而一次性获取其所有DNS记录。虽然现在较少见，但检查一下是标准流程：dig axfr @ns1.example.com example.com。

3. 网络空间测绘引擎的主动模式：像fscan这类综合扫描工具，虽然其主要功能是端口和服务扫描，但其内置的域名解析和HTTP探测模块，也可以作为一种补充性的主动发现手段。当你有一个IP段时，可以反查域名，有时能发现绑定在该IP上的未知子域名。

2.3 证书透明日志追踪：挖掘“隐藏”资产

这是当前最高效的进阶技术之一。证书透明（CT）是一项为了监控和审计SSL/TLS证书签发而设立的标准。全球主要的证书颁发机构（CA）在签发证书时，必须将证书记录提交到公开的CT日志服务器。

为什么CT日志是子域名挖掘的金矿？

1. 实时性：新申请的子域名SSL证书几乎会立刻出现在日志中，早于DNS传播和搜索引擎收录。
2. 全面性：无论是公开服务还是内部系统（如测试、预发布环境），只要申请了公开信任的SSL证书（如Let‘s Encrypt, DigiCert），其域名就会留下记录。
3. 关联性：一张证书可能包含多个域名（SAN，主题备用名称），通过一个已知域名，可能挖出一批关联子域名。

实操工具与步骤：

1. 在线查询：访问crt.sh，输入%.example.com，可以查询所有包含example.com的证书记录。这是最快捷的方式。
2. 命令行工具：
   • certspotter：监控指定域名的证书签发情况。
   • amass的CT模块：amass enum -active -d example.com -brute -ct中的-ct选项会启用CT日志收集。
   • ️一个我常用的技巧：使用curl和jq直接调用crt.sh的API进行自动化处理，可以方便地集成到自己的脚本中。

   curl -s “https://crt.sh/?q=%.example.com&output=json” | jq -r ‘.[].name_value’ | sed ‘s/\*\.//g’ | sort -u

   这条命令能快速提取并去重所有子域名。

3. 实操流程：构建自动化侦查流水线

纸上谈兵终觉浅，下面我将分享一套我日常使用的、从简单到复杂的自动化侦查流程。这套流程的目标是：输入一个根域名，输出一份经过初步验证的、去重的子域名列表，并附带基本的存活验证和标题信息。

3.1 第一阶段：快速初探与资产轮廓绘制

目标：在5-10分钟内，获取目标最可能存在的子域名清单。

1. 工具组合拳（被动）：

   # 使用subfinder进行快速被动收集 subfinder -d example.com -silent -o subfinder.txt # 使用assetfinder（Project Discovery） assetfinder —subs-only example.com > assetfinder.txt # 使用amass仅进行被动枚举 amass enum -passive -d example.com -o amass_passive.txt

2. 结果合并与去重：

   cat subfinder.txt assetfinder.txt amass_passive.txt | sort -u > passive_subdomains.txt

   此时，passive_subdomains.txt已经是一份不错的初始列表了。

3.2 第二阶段：深度挖掘与扩展

目标：基于初始列表，进行字典爆破和CT日志深度挖掘，扩大战果。

1. 基于已知子域名的智能扩展：

   # 使用altdns生成排列组合 altdns -i passive_subdomains.txt -o altdns_wordlist.txt -w words.txt # 使用dnsgen生成更多变体 cat passive_subdomains.txt | dnsgen - > dnsgen_wordlist.txt # 合并生成的新字典 cat altdns_wordlist.txt dnsgen_wordlist.txt | sort -u > generated_wordlist.txt

2. 字典爆破：

   # 使用ffuf进行DNS解析验证（速度极快） ffuf -w generated_wordlist.txt -u “http://FUZZ.example.com” -H “Host: FUZZ.example.com” -mr “failed” -t 200 -o ffuf_dns.json # 从结果中提取存活的子域名 jq -r ‘.results[].host’ ffuf_dns.json | sort -u > brute_subdomains.txt

3. 证书透明日志深度查询：

   # 使用crt.sh API，并尝试获取历史记录（-id参数） curl -s “https://crt.sh/?q=%.example.com&output=json” | jq -r ‘.[].name_value’ | sed ‘s/\*\.//g’ | sort -u > ct_subdomains.txt

3.3 第三阶段：存活验证与信息增强

目标：确认哪些子域名是真正可访问的，并收集初步的Web信息。

1. HTTP/HTTPS存活验证： 单纯DNS解析成功不代表Web服务存活。使用httpx或httprobe进行快速探测。

   # 合并所有发现的子域名 cat passive_subdomains.txt brute_subdomains.txt ct_subdomains.txt | sort -u > all_subdomains.txt # 使用httpx进行并发探测，获取状态码和标题 httpx -l all_subdomains.txt -title -status-code -tech-detect -o httpx_results.txt -threads 100

   httpx的-tech-detect参数能初步识别技术栈（如Nginx, WordPress, React），这对后续测试很有帮助。

2. 结果整理： 最终，你会得到一份格式清晰的报告，包含子域名、IP地址、状态码、页面标题和技术指纹。这为后续的漏洞扫描（如使用nuclei）或深度渗透测试提供了精确的目标列表。

4. 高级技巧与深度关联分析

当基础挖掘完成后，真正的“狩猎”才刚刚开始。以下是一些能让你从普通测试者中脱颖而出的深度技巧。

4.1 利用ASN与IP段进行反向拓展

一个大型企业的资产往往集中在特定的自治系统号（ASN）或IP地址段内。

1. 通过已知IP查找ASN：whois 8.8.8.8 | grep -i “origin”。
2. 通过ASN查找所有IP段：可以使用amass intel -asn ASxxxxx或去RIR（如APNIC）网站查询。
3. 对整个IP段进行反向DNS解析：使用masscan扫描段内HTTP/HTTPS端口，然后尝试解析这些IP的反向DNS记录，常常能发现未直接关联到主域名的其他业务域名或子域名。

4.2 关联代码仓库与泄露情报

1. GitHub/GitLab监控：定期使用以下搜索语法：

   • “example.com” password
   • “api.example.com” key
   • “config” extension:yml example.com这些搜索可能直接泄露包含内部子域名的配置文件、API密钥或部署脚本。

2. JS文件分析：使用subjs、LinkFinder等工具，从目标网站的JavaScript文件中提取新的接口路径和子域名。现代前端应用常在JS中硬编码API地址。

4.3 整合Burp Suite进行被动流量收集

在测试过程中，将浏览器或移动端App的流量通过Burp Suite代理。Burp的“Target” -> “Site map”功能会自动记录所有经过它的主机、域名和URL路径。这种方法尤其适用于：

• 测试单页应用（SPA），其大量内容通过API动态加载。
• 捕获那些仅在用户执行特定操作（如点击某个按钮）后才请求的隐藏接口或子域名。
• 分析第三方脚本（如广告、统计、客服SDK）引入的新域名。

实操心得：我通常会专门为每个项目创建一个Burp Suite临时项目，在手动浏览测试目标各个功能时，同时进行被动收集。结束后，从站点地图中导出所有主机，与主动扫描结果进行合并去重，往往有惊喜。

5. 常见问题、排查技巧与避坑指南

在实际操作中，你会遇到各种问题。下面是我踩过坑后总结的一些经验。

5.1 扫描速度与稳定性问题

• 问题：字典爆破时速度慢，或请求大量超时。
• 排查与解决：
  1. 调整线程数：不是线程越高越好。过高的并发可能导致本地网络拥堵或触发目标WAF/IP封禁。从50-100线程开始，根据网络响应情况调整。ffuf中使用-t参数。
  2. 设置超时与延迟：使用-timeout参数设置合理的超时时间（如10秒），对于敏感目标，可以添加-delay参数在请求间加入短暂延迟。
  3. 使用可靠的DNS解析器：默认的本地DNS可能慢且不稳定。可以指定公共DNS，如-r “@8.8.8.8”（工具支持的情况下），或者使用massdns这类专门的高性能DNS解析工具先做一轮批量解析。

5.2 结果去重与误报处理

• 问题：结果中包含大量泛解析记录（如*.example.com指向同一个IP）、CDN节点域名，或者无法访问的域名。
• 排查与解决：
  1. 识别泛解析：如果随机生成的不存在子域名（如random123456.example.com）也能解析到IP，说明存在泛解析。需要从结果中过滤掉这些“噪音”，或者转为针对IP进行后续端口扫描。
  2. 过滤CDN域名：像*.s3.amazonaws.com、*.cloudfront.net这类域名是托管在云服务上的，通常不是目标的直接资产。可以维护一个常见的CDN、云服务、SAAS平台域名后缀列表进行过滤。
  3. 严格存活验证：DNS解析成功只是第一步，必须通过HTTP/HTTPS存活验证（状态码非NXDOMAIN、SERVFAIL、REFUSED等）来确认。httpx的-probe参数可以很好地完成这项工作。

5.3 法律与道德边界

这是最重要的一条。

• 问题：扫描行为可能被目标视为攻击，引发法律风险。
• 规避原则：
  1. 获取授权：在测试任何不属于你自己或未明确授权给你的资产前，必须获得书面授权。这是红线。
  2. 控制扫描强度：避免使用过于 aggressive 的字典和极高的并发，尤其是在非授权测试或对生产环境的监控中。考虑目标服务器的承受能力。
  3. 尊重robots.txt：虽然这不是强制标准，但在授权测试中，遵守robots.txt是一个良好的职业习惯。
  4. 明确测试范围：授权书中必须清晰定义测试的域名、IP范围和时间窗口。不要越界扫描。

5.4 数据管理与持续监控

• 问题：每次扫描结果散落各处，无法进行资产差异比对。
• 解决策略：
  1. 建立资产数据库：即使是简单的文本文件或电子表格，也要为每个目标建立档案，记录每次扫描的时间、使用的工具和结果文件。
  2. 使用版本控制：将结果文件（如all_subdomains_20231027.txt）用Git管理起来。这样，通过git diff可以清晰地看到资产的变化：哪些域名新增了，哪些域名下线了。
  3. 自动化与调度：对于需要持续监控的资产，可以编写Shell脚本或Python脚本，将上述工具链串联起来，并使用cron定时任务定期执行（例如每周一次）。将新发现的子域名自动发送到通知渠道（如钉钉、Slack、邮件）。

子域名挖掘是一个动态的、需要持续迭代的过程。没有一种方法能保证100%的发现率。核心在于建立一套适合自己的、多层次的工作流，并理解每种技术背后的原理和局限。从被动的数据聚合开始，到主动的暴力枚举，再到利用CT日志、代码仓库等旁路信息进行深度关联，每一步都在扩大你对目标数字资产的认知边界。最后，永远将合法合规与职业道德置于技术之上，让技能用于建设而非破坏。