子域名信息收集的目的

攻击者拿到一个主域名，域名比如 example.com，信息下一步几乎一定是收集翻它的子域名。原因很直接：主站往往被防护得最严，域名WAF、信息CDN、收集严格的域名安全团队盯着，但子域名经常是信息另一回事。很多企业的收集主站固若金汤，可 test.example.com、域名dev.example.com、信息admin.example.com 这些地方，收集可能连基本的域名身份验证都没做全。子域名信息收集的信息核心目的，就是收集找到这些被忽略的入口。

我见过一个真实案例。某中型公司的官网做了全套防护，渗透测试时正面硬打毫无进展。后来通过证书透明度日志（crt.sh）拉了一份子域名列表，发现一个叫 old-portal.example.com 的站点。打开一看，是五年前上线的员工门户，用的是早已停止维护的框架，登录页面甚至还有默认管理员账号。从发现到拿到服务器权限，前后不到二十分钟。主站安全团队花了上百万做的防护，被一个没人记得的子域名绕过去了。

子域名收集不只是找漏洞入口。它能帮你画出目标的真实资产边界。一个公司对外宣称只有三个业务系统，但通过 DNS 枚举、搜索引擎语法、SSL 证书关联，你可能会发现几十甚至上百个解析记录。这里面有测试环境、有内部工具的外网映射、有收购子公司留下的遗留系统、有市场活动临时上线的页面。每多一个子域名，就多一个可能被利用的攻击面。资产测绘的意义在于，你知道的比对方以为你知道的要多。

还有一种情况是子域名接管。当某个子域名指向了一个已经下线的云服务，但 DNS 记录没有及时清理，攻击者就可以在对应的云平台上注册同名资源，直接接管这个子域名。这种漏洞不依赖目标自身的代码缺陷，纯粹是配置疏忽。我跟踪过一批这类案例，金融和电商行业尤其常见。一个被接管的子域名可以用来钓鱼、投毒、甚至绕过主域名的 CSP 策略。收集子域名的过程，本身就是在筛查这类配置风险。

从信息关联的角度看，子域名还能暴露技术栈和组织结构。比如 git.example.com 可能指向自建的 GitLab，jira.example.com 说明用了 Atlassian 的产品，vpn.example.com 暗示了远程接入方式。把这些子域名按命名规律归类，能大致推断出目标内部的部门划分和运维习惯。有些公司用城市名做子域名前缀，有些用项目代号，有些用员工姓名缩写。这些细节在后续的社会工程学攻击或密码喷洒中，价值极高。

做子域名收集时，被动和主动要结合。被动方式包括查证书透明度日志、看公开的 DNS 数据集、跑搜索引擎和 GitHub 搜索。主动方式就是 DNS 字典爆破、区域传送尝试、以及基于已有子域名的递归枚举。很多人只做被动收集就停了，觉得够用。但实际测试中，字典爆破经常能挖出被动方式漏掉的内部命名。当然，主动方式会产生流量，可能触发告警，得看具体场景决定用不用。

工具方面，amass、subfinder、assetfinder 这些都能用。但我更想说的是，工具输出之后的人工筛选比工具本身重要。一个子域名列表可能有几千条，其中大部分是 CDN 边缘节点或泛解析产生的噪音。你得会看 DNS 响应类型，会判断哪些是真实业务，哪些只是负载均衡的别名。这个过程没有捷径，靠的是对目标业务的理解和一点直觉。

说到底，子域名信息收集不是为了凑数量。它的目的是在攻击面里找到那个最薄弱的环节，或者至少，把目标的真实轮廓摸清楚。一个安全团队如果连自己有多少子域名在线上都不知道，那防御就无从谈起。而对攻击者来说，每一个被遗忘的子域名，都是一扇没上锁的门。