子域名收集全攻略：从被动发现到主动爆破的完整实践

做安全测试或者资产盘点的时候，我最怕听到一句话：“目标没几个子域名，随便测测就行。”说这话的人往往在后面的测试里被自己的信息盲区狠狠坑一把。子域名收集这件事，表面上看是跑几个工具拼字典，实际上决定了你对目标资产暴露面的认知上限，也直接决定了后续测试是从“已知范围”出发还是从“盲人摸象”开始。

这篇内容我按“被动收集—主动爆破—关联挖掘—自动化整合”这条主线，把这些年用过的子域名收集方法完整梳理一遍。既有直接能抄的命令和工具，也讲清楚每个姿势的原理和适用场景，同时把所有踩过的坑一并列出来。适合刚入门信息收集的新手，也适合觉得自己流程不够系统的老手对照着查漏补缺。

1. 子域名收集的意义与合规边界

1.1 子域名暴露了真正的攻击面

很多人觉得子域名无非就是www、mail、api这几个前缀，实际测试中完全不是这么回事。一个中型企业的子域名数量动辄成百上千，而且历史遗留的子域名往往比在用的还多。这些子域名背后可能挂着测试环境、后台管理系统、旧版本的 API 网关、内部使用的 GitLab、未做鉴权的跳板机、第三方云厂商的存储桶，甚至直接是某个开发同事临时开的云主机。

我举个实际例子，之前做某企业授权测试时，目标主站example.com防护做得滴水不漏，WAF、态势感知、主机加固全都有。但通过证书透明度日志和字典爆破，找到一个dev.example.com，上面跑着一个未打补丁的旧版 Tomcat 管理后台，弱口令直接进去了，然后通过内网穿透拿到整个业务网段权限。这类路径在红队实战里是最常见的突破口，而它的起点就是一次高质量的子域名收集。

换句话说，子域名收集的完整度直接决定了你对目标资产暴露面的判断。收集得全，你就能找到防护薄弱的老旧资产；收集得少，你就只能在别人精心布置的正面防线上硬碰硬。

1.2 收集子域名的合法前提与测试原则

在展开所有姿势之前，必须先强调合规边界。子域名收集本身属于信息收集手段，技术上是中性的，但使用场景必须严格限定在：

• 企业自有资产的梳理与安全加固
• 获得书面授权的渗透测试、红队演练、攻防演习
• 安全研究中对公开信息的整理分析

任何未经授权对他人系统进行扫描、探测、爆破的行为，都可能触及相关法律法规。即便只是 DNS 查询和字典枚举，也会产生实际的网络请求，可能被目标的安全设备记录。我在所有项目中坚持一个原则：先确认授权范围，再开始收集；授权范围之外的一律不碰。这一点希望每个做安全的人都能刻在脑子里。

另外还有一条行业惯例值得提一下：大多数子域名收集手段都基于公开数据（证书日志、DNS 记录、搜索引擎缓存），这类被动收集的合规风险相对较低；而主动爆破、批量 DNS 查询这类行为会产生大量流量，优先级和强度需要根据授权书内容严格控制。后面讲到的每个姿势，我都会标注清楚属于被动还是主动，方便你按场景取舍。

2. 被动收集：不碰目标的“捞鱼”技术

被动收集的思路是“不直接给目标发请求，从第三方数据源把已经存在的子域名捞出来”。优势是隐蔽、高效、几乎不会触发目标防护，劣势是覆盖面取决于数据源的丰富程度。真正的高手做收集，一定是被动优先，主动补漏。

2.1 证书透明度日志查询

证书透明度（Certificate Transparency，CT）是目前被动收集中信息量最大、最值得优先使用的方法。CA 机构签发 TLS 证书时，会把证书信息写入公开的 CT 日志，任何人可以查询某个域名下签发过的所有证书。这意味着只要某个子域名申请过 HTTPS 证书，它就会在 CT 日志里留下记录。

查询 CT 日志的方式有不少，最直接的是通过crt.sh这个在线平台，也支持命令行拉取。比如查询example.com的所有子域名：

curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

这条命令里%25是通配符%的 URL 编码，sort -u做去重。实际使用中你会发现 crt.sh 的响应有时候比较慢，尤其是查询大域名时数据量巨大。我的习惯是配合超时重试，或者直接用下面这几个替代接口：

# 使用 Censys 的 CT 查询 curl -s "https://search.censys.io/api/v2/certificates/search?q=names%3Aexample.com&per_page=100" # 使用 Google 的 Certificate Transparency 接口 curl -s "https://certificate.transparency.googleapis.com/v1beta1/domains/example.com/at-version"

CT 日志的价值不仅仅是“拿到子域名列表”，更关键的是能发现那些已经不再使用但证书未过期的“僵尸子域名”，这类域名往往是最容易出问题的历史遗留资产。

2.2 搜索引擎与第三方测绘平台

搜索引擎收录也是被动收集的重要渠道。Google、Bing 都支持site:语法，能找出被搜索引擎爬虫收录的二级域名。比如：

site:example.com -www

这个语法能排除www主站，把其他被收录的子域名列出来。国内环境的话，微步在线、奇安信鹰图、钟馗之眼等平台也都有子域名查询功能，覆盖的数据源有时比国外平台更贴近实际。不过要注意，搜索引擎收录存在滞后性，新上线的子域名可能要过几周甚至几个月才会被爬虫发现，所以它只能作为辅助手段，不能当主力。

第三方测绘平台本质上是“别人提前帮你收集好了”。这些平台通过长期全球扫描积累了大量域名与 IP 的对应关系，查询时只需要一个 API 调用。以 FOFA 为例，语法大致是：

domain="example.com"

返回结果会包含子域名、对应 IP、开放端口、标题等信息，等于把收集和指纹识别一步做完了。这类平台的优点是信息量大、速度快，缺点是免费额度有限，而且有部分数据是扫描器推断出来的，可能存在误报，需要交叉验证。

2.3 DNS 历史记录与被动 DNS 数据

还有一种被动收集思路容易被忽略：查询 DNS 历史记录。一个子域名可能在某个时间点解析到某个 IP，后来业务下线、IP 释放、域名被重定向，但 DNS 历史数据里仍然有记录。

SecurityTrails和DNSDumpster都是常用的 DNS 历史查询平台。SecurityTrails 的 API 返回的数据很详细，会列出每个子域名在历史不同时间段的解析记录；DNSDumpster 则提供可视化的域名-IP 关系图，适合做资产梳理时画拓扑用。

被动 DNS 数据的另一个来源是威胁情报平台。一些恶意域名检测平台会存储全球 DNS 解析记录，查询某个根域名时能返回关联的所有子域名。这类平台包括 VirusTotal 的 Domain 页面、AlienVault OTX、ThreatMiner 等。我实际测试的感受是，这些平台的数据源和 CT 日志有交叉，单独用哪一个都不够全，把多个源的结果合并去重之后，覆盖度能提升 30% 以上。

3. 主动收集：字典爆破与枚举的正确姿势

被动收集做完，拿到的子域名数量基本能覆盖目标暴露面的 60% 到 70%。剩下的部分就得靠主动枚举来补，也就是字典爆破和 DNS 查询。主动收集的本质是“猜”，猜得准不准，全看字典质量和过滤策略。

3.1 字典爆破的核心思路

字典爆破的原理很简单：准备一份常见子域名词典，逐个拼到根域名前面，然后构造 DNS 查询（A 记录、CNAME 记录等），如果返回了解析结果，说明这个子域名存在。

admin.example.com -> 解析成功 api.example.com -> 解析成功 nonexist123.example.com -> 解析失败

这里最核心的变量是字典的质量。很多人直接用网上找的“通用大字典”，几千几万个词往里砸，结果不是漏掉真实存在的子域名，就是被泛解析干扰到怀疑人生。我的经验是，字典需要分场景定制：

• 通用前缀：www、mail、ftp、ssh、api、app、dev、test、stage、prod、admin、manage、portal、oa、erp、crm、wiki、git、jenkins、grafana、kibana等，这类词覆盖大多数常见业务场景。
• 业务关键词：结合目标公司的名称、产品线、品牌词做组合。比如公司叫“某某云”，那cloud、yun、pan、store这类词汇优先级就要提高。
• 数字和短词：v1、v2、test1、new、old、backup、temp、bak这类容易出现在测试环境和备份系统的前缀，实战里经常能漏出惊喜。
• 工具自带字典：不少工具自带基础字典，SecLists的subdomains-top1million-5000.txt就是常用的参考字典，可以基于它做增删。

爆破过程中有个参数需要重点控制：并发数。并发太高，DNS 服务器直接把你限流或者丢包；并发太低，几万词的字典要跑到天荒地老。我用puredns或massdns时，一般把并发控制在 1000 到 2000，同时开启重试机制。这个值不是固定的，建议根据网络状况和目标 DNS 的响应速度动态调整。

3.2 泛解析的识别与过滤

泛解析是主动爆破里最恶心的问题。所谓泛解析，就是域名配置了*.example.com的解析，任何不存在的子域名都会被解析到一个固定的 IP（通常是负载均衡器或者宣传页）。这时候你爆破出来的“有效子域名”可能大部分是假的。

泛解析的识别方法很简单：先随机生成一个几乎不可能存在的子域名（比如qwertyuiop12345.example.com），解析一下看是否返回结果。如果返回了，说明目标开了泛解析。

过滤策略我提供一个实操过的方案：通过massdns拿到的爆破结果，先记录每个子域名解析到的 IP，然后和随机生成的泛解析 IP 做比对，解析到相同 IP 且域名特征明显是随机词的，直接过滤掉。注意，有些目标配置了多条泛解析记录，比如*.test.example.com和*.example.com各自指向不同 IP，所以过滤时要按“IP 分组统计 + 域名后缀特征”双重判断。

泛解析的存在也让“字典质量”变得更重要。如果目标开了泛解析，爆破结果的含金量就取决于字典里的词和目标实际业务词的匹配度，穷举式的超大字典在泛解析面前效率会急剧下降。

3.3 主流爆破工具对比与选择

工具选型是很多人纠结的点，我把用过的主流工具做了一张对比表，方便你按场景选择。

关于最后这个工具需要多说两句。Layer子域名挖掘机在早期安全圈里确实流传很广，图形界面开箱即用，不少新手是从它入门的。但问题也很明显：一是年久失修，内置字典和去重逻辑已经跟不上现在的目标环境；二是这类闭源工具流传版本鱼龙混杂，无法确认有没有被植入后门，在测试环境里使用风险极高。我的建议是，如果你只是临时验证一两个域名的解析情况，可以用它图个方便；真正做完整的子域名收集流程，还是用开源工具链更稳妥，毕竟你能看到它到底发了什么请求、执行了什么逻辑。

4. 关联挖掘：从已收集域名继续深挖

很多人的子域名收集做到第三步就停了，其实还有几层姿势能把结果质量再拉高一个档次。核心思路是“从已拿到的信息反查和关联”。

4.1 域名注册信息反查与兄弟域名

通过已收集子域名的 IP 做反查，是发现“兄弟域名”的经典手法。同一个 IP 上可能绑定了多个域名，这些域名往往属于同一家企业或同一个业务集群。

实现上可以用Robtex、ViewDNS.info这类平台的反查接口，也可以用Shodan的reverse DNS查询。操作逻辑是：

1. 拿到已确认的子域名解析 IP 列表
2. 对每个 IP 做 PTR（反向指针）查询，得到该 IP 绑定的域名列表
3. 把域名列表里属于同一主域的其他二级域名合入结果集

注意这里有个效率问题：几十个子域名解析出的 IP 可能只有几个，所以先对 IP 做去重，能减少大量无效查询。另外，CDN 背后的 IP 反查出的域名可能属于 CDN 厂商，过滤时需要结合域名后缀判断是否属于目标资产。

4.2 JS 文件与页面源码中的域名泄露

前端代码里泄露内网域名，是我在实战中命中率很高的一个信息收集姿势。现在的 Web 应用前端代码动不动就几百 KB，里面引用的 API 地址、WebSocket 地址、资源域名，经常藏着新子域名。

推荐的工具是subjs和LinkFinder，它们的原理都是拉取目标页面后自动提取 JS 文件中的 URL 和域名。我经常配合使用的一个命令流程是：

# 先收集 JS 文件 URL cat urls.txt | subjs # 再从 JS 内容中提取子域名 cat js_urls.txt | unfurl -u domains

其中unfurl是一个提取 URL 各个部分的工具，很轻量。如果嫌命令行麻烦，手动打开浏览器开发者工具，在网络面板搜索http关键字，也能从请求列表里看到页面实际调用的内部域名。这个方法对 SPA（单页应用）特别有效，因为前端代码会把部分配置暴露在打包产物中。

4.3 子域名接管漏洞检测

收集到足够多的子域名之后，别忘了做一轮接管检测。子域名接管（Subdomain Takeover）的原理是：某个子域名的 CNAME 记录指向了第三方托管服务（如 GitHub Pages、AWS S3、Heroku），但托管服务上对应的资源已经被释放，此时攻击者可以重新注册资源，让域名解析到自己控制的内容，实现对该子域名的完全控制。

检测的核心思路是检查“已解析但是没有任何有效内容”的子域名。实操中我用subjack和nuclei的接管检测模版：

# subjack 检测 subjack -w subdomains.txt -t 100 -timeout 30 -o takeover.txt # nuclei 检测 nuclei -l subdomains.txt -t http/takeovers/

这里要提醒的是，检测结果需要人工复核。有些托管服务返回的报错页面和可接管状态的报错非常接近，但实际服务仍在使用，只是返回了特定的 404 页面；还有些 CDN 服务商对未配置资源的返回页面从设计上就长得很“可接管”。我见过最离谱的一次误报，是一个内部系统用的自定义 404 页面长得跟某个第三方服务的释放页面一模一样，差点被当成接管点提进报告，还好复核时多看了一眼响应头。所以自动化检测结果必须经过人工确认，这一点在输出基线报告时尤其重要。

5. 自动化整合与工作流设计

单点姿势掌握之后，要把流程串成自动化流水线，效率和覆盖率才会有质变。一个完整的子域名收集流程至少包含：数据源汇总、去重过滤、验证存活、输出整理四个阶段。

5.1 一个可落地的半自动化流程

我用了一个 Bash 脚本把被动收集、主动爆破和验证串起来。这个流程不复杂，胜在结构清晰，你可以按自己环境调整。

#!/bin/bash # 子域名收集工作流示例 TARGET="example.com" OUTDIR="subdomain_$TARGET" mkdir -p $OUTDIR # 阶段一：被动收集 subfinder -d $TARGET -all -silent > $OUTDIR/passive.txt curl -s "https://crt.sh/?q=%25.$TARGET&output=json" | jq -r '.[].name_value' | sort -u >> $OUTDIR/passive.txt # 阶段二：去重并生成基础字典 sort -u $OUTDIR/passive.txt -o $OUTDIR/passive_uniq.txt # 阶段三：主动爆破（结合已有子域名和字典） puredns bruteforce wordlist.txt $TARGET -r resolvers.txt -q > $OUTDIR/brute.txt # 阶段四：合并所有结果 cat $OUTDIR/passive_uniq.txt $OUTDIR/brute.txt | sort -u > $OUTDIR/all_subs.txt # 阶段五：存活验证 httpx -l $OUTDIR/all_subs.txt -title -status-code -web-server -tech-detect -o $OUTDIR/alive.txt echo "收集完成，存活结果: $OUTDIR/alive.txt"

这里步骤五用的httpx是目前我用下来最顺手的存活验证工具，支持并发请求、状态码、标题、Web 框架指纹识别，一个命令能同时完成存活验证和基础指纹收集，省去后续很多重复请求。

5.2 结果去重与多源交叉验证

多数据源合并后的去重不是简单去个字符串就完了，有几个细节值得注意：

• 大小写归一化：DNS 解析对大小写不敏感，WWW.Example.COM和www.example.com是同一个域名，去重前统一转小写。
• 通配符条目处理：有些数据源会返回*.example.com或*.dev.example.com这类通配符条目，这类记录本身不是具体的子域名，但能从侧面说明该层级下有其他子域名。我通常把通配符条目单独存一个文件，作为字典扩充的线索，不直接并入结果。
• 去尾点处理：部分数据源返回的域名末尾会带一个点（FQDN 格式），需要统一去掉。
• 正则过滤：用正则过滤掉明显的无效格式，比如包含空格、引号、括号的异常记录。这些格式异常数据很多是 CT 日志里证书的 SAN（使用者备用名称）字段解析异常产生的。

多源交叉验证还有一个妙用：同一个子域名如果只在某个单一数据源出现，可信度要打折扣；如果出现在 CT 日志和一个被动数据源里，同时爆破字典也能解析，那基本可以确认它是真实存活的资产。

5.3 输出格式与报告整理

子域名收集结果最终要落到报告里。我见过的报告千奇百怪，有的就是一个 txt 文件丢给客户，后面的人根本不知道这些域名对应什么业务。一个合格的结果输出至少应该包含：

实操中我一般输出为 CSV，字段用逗号分割，方便导入 Excel 或禅道。输出到 CSV 时记得统一字符集为 UTF-8，否则中文标题会在部分系统里乱码，这个坑我踩过不止一次。

6. 常见问题排查与避坑心得

6.1 泛解析误判导致结果“虚胖”

这是最常见的翻车现场。爆破出来的子域名几万个，但其中 90% 是被泛解析污染的无效结果。处理方案前面提过，我再补充一个更细的操作思路：把爆破结果按解析 IP 分组，如果某个 IP 下挂了海量随机命名的域名，那这个 IP 大概率是泛解析地址；再结合随机域名是否包含有意义的业务词（如admin、api）做二次过滤。有时候目标会设置泛解析“白名单”，只对不在白名单内的前缀返回固定 IP，这时候需要对比泛解析 IP 和白名单域名解析的 IP，逐条核对。

6.2 速率过于激进导致查询超时或者封禁

DNS 爆破本质上就是高频查询。在某些严格环境下，目标 DNS 服务器的 QPS 限制触发后，后续查询会全部超时，表现为爆破结果后半段全是失败记录，但前半段正常。排查时看爆破时间线，如果失败集中在后半段，基本能确认是速率问题。解决方法是降并发、加重试，或者换用更本地的 DNS 解析源。我自己常用的解析源是各大云厂商公共 DNS 混搭，并通过dnsvalidator每次先校验一批可用解析源的可靠性。

6.3 数据源接口报错导致结果缺失

CT 日志平台和第三方测绘平台都有访问频率限制，短时间内连续请求很容易被拦截。遇到接口报错不要死磕，换个数据源或者降低请求频率，让脚本做“指数退避重试”更稳妥。另外，crt.sh的查询有时候会返回空结果，并不是真没有数据，而是查询超时或者数据库负载高，换个时间点再跑一次往往就有数据了。

6.4 工具误报与蜜罐干扰

最后提一个被很多人忽略的点：有些目标和安全设备会故意在 DNS 层做“蜜罐”。它们可以监测到哪些 IP 在批量查询自己的子域名字典，这是最早暴露测试行为的渠道之一。尤其是规模大的攻防演练场景，目标的安全团队确实会盯着 DNS 请求日志做预警。所以做主动收集前，务必确认授权范围是否允许，并且严格控制爆破强度和时段。被动收集则相对安全，因为它不直接触碰目标系统。

6.5 Layer子域名挖掘机这类老工具的后续使用建议

关于老牌工具“Layer子域名挖掘机”，我再说点实际建议。如果你手头确实有这个工具，并且只是快速验证少量域名，可以用，但要注意几点：一是不要直接用它内置的字典跑大型目标，字典陈旧导致漏报严重；二是运行前先对文件做病毒扫描，这类停更多年的闭源工具在社区里的传播链极不透明；三是它的结果最好再经过puredns或者massdns的验证，不能直接当最终结论。从效率角度讲，同样是图形界面操作，我更推荐直接用OneForAll这类开源项目跑一套完整流程，覆盖面、准确率和可解释性都不是老工具能比的。

7. 最后的实战心得

关于子域名收集，我自己后期最大的转变是从“收集完就开测”变成“收集完先梳理、再验证、再做交集分析”。花半个小时把结果整理成清晰的资产列表，提炼出哪些是老旧系统、哪些是第三方托管、哪些是内部应用，后续的渗透测试方向会清晰非常多。急急忙忙拿着一个爆破出来的列表就到处打点，反而容易被安全设备盯上，而且浪费时间在无效目标上。

另外一个小技巧是：每次做完一个目标的子域名收集，把高价值子域名和对应 IP 记到自己的笔记里。不同项目之间，同一个企业下面可能有多个不同根域名（比如主站和子公司），它们的子域名记录经常有交叉。比如一个母公司下多个品牌域名，通过自有历史数据做关联，经常能提前发现目标自己都没梳理出来的资产。这一点在大型企业资产盘点时特别有用。

子域名收集永远没有一个“最全”的终点，每次换一个数据源、换一份字典、换一种关联思路，都可能发现新的遗漏资产。但有一个相对确定的结论：把被动收集做扎实、把爆破字典调对口、把多源结果交叉验证到位、再结合人工经验去判断，这四步到位，你的子域名收集水平已经能超过八成做安全测试的人。剩下的功夫，就是在一次次实战里不断积累对目标行业、目标业务的理解，这比任何一个工具都值钱。