做安全测试或者资产盘点的时候我最怕听到一句话“目标没几个子域名随便测测就行。”说这话的人往往在后面的测试里被自己的信息盲区狠狠坑一把。子域名收集这件事表面上看是跑几个工具拼字典实际上决定了你对目标资产暴露面的认知上限也直接决定了后续测试是从“已知范围”出发还是从“盲人摸象”开始。这篇内容我按“被动收集—主动爆破—关联挖掘—自动化整合”这条主线把这些年用过的子域名收集方法完整梳理一遍。既有直接能抄的命令和工具也讲清楚每个姿势的原理和适用场景同时把所有踩过的坑一并列出来。适合刚入门信息收集的新手也适合觉得自己流程不够系统的老手对照着查漏补缺。1. 子域名收集的意义与合规边界1.1 子域名暴露了真正的攻击面很多人觉得子域名无非就是www、mail、api这几个前缀实际测试中完全不是这么回事。一个中型企业的子域名数量动辄成百上千而且历史遗留的子域名往往比在用的还多。这些子域名背后可能挂着测试环境、后台管理系统、旧版本的 API 网关、内部使用的 GitLab、未做鉴权的跳板机、第三方云厂商的存储桶甚至直接是某个开发同事临时开的云主机。我举个实际例子之前做某企业授权测试时目标主站example.com防护做得滴水不漏WAF、态势感知、主机加固全都有。但通过证书透明度日志和字典爆破找到一个dev.example.com上面跑着一个未打补丁的旧版 Tomcat 管理后台弱口令直接进去了然后通过内网穿透拿到整个业务网段权限。这类路径在红队实战里是最常见的突破口而它的起点就是一次高质量的子域名收集。换句话说子域名收集的完整度直接决定了你对目标资产暴露面的判断。收集得全你就能找到防护薄弱的老旧资产收集得少你就只能在别人精心布置的正面防线上硬碰硬。1.2 收集子域名的合法前提与测试原则在展开所有姿势之前必须先强调合规边界。子域名收集本身属于信息收集手段技术上是中性的但使用场景必须严格限定在企业自有资产的梳理与安全加固获得书面授权的渗透测试、红队演练、攻防演习安全研究中对公开信息的整理分析任何未经授权对他人系统进行扫描、探测、爆破的行为都可能触及相关法律法规。即便只是 DNS 查询和字典枚举也会产生实际的网络请求可能被目标的安全设备记录。我在所有项目中坚持一个原则先确认授权范围再开始收集授权范围之外的一律不碰。这一点希望每个做安全的人都能刻在脑子里。另外还有一条行业惯例值得提一下大多数子域名收集手段都基于公开数据证书日志、DNS 记录、搜索引擎缓存这类被动收集的合规风险相对较低而主动爆破、批量 DNS 查询这类行为会产生大量流量优先级和强度需要根据授权书内容严格控制。后面讲到的每个姿势我都会标注清楚属于被动还是主动方便你按场景取舍。2. 被动收集不碰目标的“捞鱼”技术被动收集的思路是“不直接给目标发请求从第三方数据源把已经存在的子域名捞出来”。优势是隐蔽、高效、几乎不会触发目标防护劣势是覆盖面取决于数据源的丰富程度。真正的高手做收集一定是被动优先主动补漏。2.1 证书透明度日志查询证书透明度Certificate TransparencyCT是目前被动收集中信息量最大、最值得优先使用的方法。CA 机构签发 TLS 证书时会把证书信息写入公开的 CT 日志任何人可以查询某个域名下签发过的所有证书。这意味着只要某个子域名申请过 HTTPS 证书它就会在 CT 日志里留下记录。查询 CT 日志的方式有不少最直接的是通过crt.sh这个在线平台也支持命令行拉取。比如查询example.com的所有子域名curl -s https://crt.sh/?q%25.example.comoutputjson | jq -r .[].name_value | sort -u这条命令里%25是通配符%的 URL 编码sort -u做去重。实际使用中你会发现 crt.sh 的响应有时候比较慢尤其是查询大域名时数据量巨大。我的习惯是配合超时重试或者直接用下面这几个替代接口# 使用 Censys 的 CT 查询 curl -s https://search.censys.io/api/v2/certificates/search?qnames%3Aexample.comper_page100 # 使用 Google 的 Certificate Transparency 接口 curl -s https://certificate.transparency.googleapis.com/v1beta1/domains/example.com/at-versionCT 日志的价值不仅仅是“拿到子域名列表”更关键的是能发现那些已经不再使用但证书未过期的“僵尸子域名”这类域名往往是最容易出问题的历史遗留资产。2.2 搜索引擎与第三方测绘平台搜索引擎收录也是被动收集的重要渠道。Google、Bing 都支持site:语法能找出被搜索引擎爬虫收录的二级域名。比如site:example.com -www这个语法能排除www主站把其他被收录的子域名列出来。国内环境的话微步在线、奇安信鹰图、钟馗之眼等平台也都有子域名查询功能覆盖的数据源有时比国外平台更贴近实际。不过要注意搜索引擎收录存在滞后性新上线的子域名可能要过几周甚至几个月才会被爬虫发现所以它只能作为辅助手段不能当主力。第三方测绘平台本质上是“别人提前帮你收集好了”。这些平台通过长期全球扫描积累了大量域名与 IP 的对应关系查询时只需要一个 API 调用。以 FOFA 为例语法大致是domainexample.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 主流爆破工具对比与选择工具选型是很多人纠结的点我把用过的主流工具做了一张对比表方便你按场景选择。工具类型核心特性适用场景subfinder被动收集调用大量 API 源速度快配置简单首选快速收集amass被动主动OWASP 项目接口丰富支持数据源扩展大型目标全面收集oneforall被动主动国内开发者维护内置字典和子功能较多中文目标资产收集puredns主动爆破精确处理泛解析支持大规模字典字典爆破主力massdnsDNS 查询引擎万级 QPS高速批量解析底层解析引擎layer子域名挖掘机主动爆破老牌图形化工具操作门槛低快速验证少量域名关于最后这个工具需要多说两句。Layer子域名挖掘机在早期安全圈里确实流传很广图形界面开箱即用不少新手是从它入门的。但问题也很明显一是年久失修内置字典和去重逻辑已经跟不上现在的目标环境二是这类闭源工具流传版本鱼龙混杂无法确认有没有被植入后门在测试环境里使用风险极高。我的建议是如果你只是临时验证一两个域名的解析情况可以用它图个方便真正做完整的子域名收集流程还是用开源工具链更稳妥毕竟你能看到它到底发了什么请求、执行了什么逻辑。4. 关联挖掘从已收集域名继续深挖很多人的子域名收集做到第三步就停了其实还有几层姿势能把结果质量再拉高一个档次。核心思路是“从已拿到的信息反查和关联”。4.1 域名注册信息反查与兄弟域名通过已收集子域名的 IP 做反查是发现“兄弟域名”的经典手法。同一个 IP 上可能绑定了多个域名这些域名往往属于同一家企业或同一个业务集群。实现上可以用Robtex、ViewDNS.info这类平台的反查接口也可以用Shodan的reverse DNS查询。操作逻辑是拿到已确认的子域名解析 IP 列表对每个 IP 做 PTR反向指针查询得到该 IP 绑定的域名列表把域名列表里属于同一主域的其他二级域名合入结果集注意这里有个效率问题几十个子域名解析出的 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 # 子域名收集工作流示例 TARGETexample.com OUTDIRsubdomain_$TARGET mkdir -p $OUTDIR # 阶段一被动收集 subfinder -d $TARGET -all -silent $OUTDIR/passive.txt curl -s https://crt.sh/?q%25.$TARGEToutputjson | 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 文件丢给客户后面的人根本不知道这些域名对应什么业务。一个合格的结果输出至少应该包含字段说明子域名完整域名去掉协议和路径解析 IP当前解析的 IP 列表多个 IP 用逗号分隔CNAME如果有 CNAME记录目标域名用于判断 CDN 或第三方托管HTTP 状态码存活验证后的访问状态码标题页面标题快速判断业务类型指纹信息Web 服务器、中间件、技术栈等来源被动收集、爆破、JS 提取等方便复测和溯源备注是否疑似接管、是否有敏感路径、是否内部系统等实操中我一般输出为 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 记到自己的笔记里。不同项目之间同一个企业下面可能有多个不同根域名比如主站和子公司它们的子域名记录经常有交叉。比如一个母公司下多个品牌域名通过自有历史数据做关联经常能提前发现目标自己都没梳理出来的资产。这一点在大型企业资产盘点时特别有用。子域名收集永远没有一个“最全”的终点每次换一个数据源、换一份字典、换一种关联思路都可能发现新的遗漏资产。但有一个相对确定的结论把被动收集做扎实、把爆破字典调对口、把多源结果交叉验证到位、再结合人工经验去判断这四步到位你的子域名收集水平已经能超过八成做安全测试的人。剩下的功夫就是在一次次实战里不断积累对目标行业、目标业务的理解这比任何一个工具都值钱。