渗透测试信息收集全流程：从子域枚举到源码泄露的实战指南

1. 信息收集到底在收什么：先给攻击面画一张地图

去年接了一个授权测试项目，目标只有一个主域名。按客户的说法，"系统没几个，应该很快就能测完"。结果从子域名枚举开始就收不住，最后挖出的资产数量是客户预期的大约三倍。

那次让我更确定了一件事：信息收集做得扎不扎实，直接决定后续渗透的天花板。很多新手拿到目标就急着打开扫描器，跑了半天只得到一个IP和几个开放端口，然后就卡住了。问题不在于扫描器不行，而是没有先把"信息地图"画完整。

所谓全方位信息收集，本质上是把目标从"一个域名"展开成"一张网"——这张网里包含所有关联的子域名、每个子域名对应的主机和端口、Web服务的技术栈指纹、暴露的目录结构和源码文件，以及维系整个系统运转背后的组织人员信息。每一条信息单独看可能价值不大，但关联起来就是一条清晰的攻击路径。

我习惯把信息收集分成六个层面来做：

• 域名资产层：主域名、子域名、关联域名、历史解析记录
• 网络暴露层：IP、端口、服务、协议
• 应用识别层：Web框架、CMS、容器、中间件、WAF
• 内容挖掘层：目录结构、备份文件、源码泄露、配置文件
• 代码层：泄露源码中的硬编码凭据、内部路径、注释信息
• 人员层：域名注册人、邮箱规则、组织架构、技术选型线索

这篇文章就把我平时实践中沉淀下来的这套流程完整拆开讲，每个环节该用什么思路、什么工具、怎么判断结果的价值，尽量不带废话，全部是可落地的操作。

适合谁看？正在入门安全测试但不知道怎么系统化收集信息的新人，以及已经会跑几个工具但觉得"跑完也不知道下一步干嘛"的朋友。这篇文章解决的就是这个问题——让收集到的每一条信息都能变成后续可利用的线索。

2. 子域名挖掘：别只依赖爆破，关键是关联思维

子域名收集是信息收集的第一块拼图。它的意义不只是"多发现几个域名"，而是极大扩充攻击面。很多时候主站防护做得很严，但某个测试环境下挂着的子域名还跑着旧版本框架，从那里绕就是常规打法。但很多人在这个环节就犯了懒，只用一个工具跑一遍字典，跑完就换个环节，这种习惯会漏掉大量隐藏资产。

2.1 被动收集信息源：证书透明日志是金矿

先说被动收集，它的核心逻辑是"不直接碰目标，从第三方平台捞数据"。这里最值得优先处理的是证书透明日志（Certificate Transparency, CT），因为HTTPS站点为了签发证书，会被证书签发机构公开记录到日志里，攻击者可以利用这些公开记录找到目标域名下的所有子域。

常见的做法有几种：

• crt.sh 网页查询，直接搜索%target.com（需要把百分号编码成%25更精确）
• 用ct-exposer、certspotter这类API工具自动拉取
• subfinder一把梭，它聚合了多个数据源，命令也简单

以 subfinder 为例：

subfinder -d example.com -all -silent -o subs.txt

加上-all会启用所有数据源，拉到的量通常比默认多一倍以上。实测经验是，crt.sh 是最容易出惊喜的，因为很多企业会为内部测试环境、研发环境、预发布环境也申请证书，这些子域往往比正式站点更容易被突破。

除了CT日志，DNS历史解析记录也值得查。有些平台可以查某个域名曾经的解析记录，包括已经关停的服务器IP，这些IP可能还开放着其他服务，或者关联到目标公司的其他资产。DNS历史解析往往是被忽略但产出很大的一个数据源。

2.2 主动爆破：字典与泛解析的坑

被动收集拿到的子域通常有限，想进一步扩展就要上主动爆破。这块的两个核心变量是字典质量和解析验证。

工具方面，我常用的是dnsx配合一个聚合字典，或者用gobuster dns模式：

gobuster dns -d target.com -w dict.txt -t 50

这里想多说一句关于工具选择的建议：很多人现在还喜欢用 layer子域名挖掘机 这种GUI工具，它确实方便，双击打开就能跑，界面直观，跑完直接给你表格。我承认早期我也用，但它的字典太老了，近几年新建的系统和命名风格它基本不认识。新项目建议直接用命令行工具配自己的字典，效果明显好。layer作为快速出结果的工具可以补充着看，但不要作为唯一依赖。

爆破环节有三大坑要避开：

1. 泛解析问题：目标域名可能配置了泛解析，随便打个不存在的子域名也能解析出IP。解决办法是先用一个随机字符串测试，如果有解析结果，说明存在泛解析，这时所有结果都要拿这个"基线IP"去对比，解析到相同IP的直接丢弃。
2. 字典陈旧：纯靠网上找的老字典，基本只能跑出一些主流命名。建议结合目标网站的命名习惯动态扩展，比如目标用了dev-和test-前缀，就手动加上staging-、pre-、alpha-、prod-这类变体。
3. CNAME记录：有些子域解析到了CDN或第三方云服务（比如xxxx.example.com.cdn.cloudflare.net），这类域名后续扫描时要单独标记，因为它们不指向目标自己的服务器，指纹和漏洞利用的逻辑也不同。

2.3 关联资产：从一个IP反查更多域名

子域名收集的另一个思路是反向关联。拿到一批解析IP后，把每个IP丢回去反查还有哪些域名绑定在上面，经常能发现"隐藏资产"。比如目标的一个IP上可能同时托管着七八个域名，有的域名在证书信息里查不到，但通过IP反查或者证书重新关联就能发现它们。

这一步实操时可以用dnsx的-resp选项把所有解析结果和IP一起输出，然后对每个IP做反向PTR查询，或者用平台的数据做反查。我每次做完这一步都会多出不少子域。这些域名往往比从字典里跑出来的更有价值，因为它们和主站共用基础设施，归属关系更明确。

做完子域收集后，我会把结果按"解析IP + Web状态码 + 标题"归档，方便后面环节直接使用。这是整个信息收集流程中每步都要坚持的习惯：边收集、边整理、边标注。

3. 端口与服务识别：比端口号更重要的是服务版本

子域名和IP拿到手后，紧接着就是端口扫描。这一步的目标很直接：搞清楚目标服务器对外开放了哪些服务，并且尽量识别出服务版本。版本号就是后续漏洞检索的关键词，没有版本号，几千个CVE你根本不知道该查哪个。

3.1 nmap 的扫描策略与参数搭配

端口扫描这块绕不开 nmap。新手经常犯的错是一条命令打天下，比如只会nmap -sS 1.2.3.4，拿到一堆端口号就完事了。实际项目里我一般这样分阶段操作：

第一步，快速全端口发现：

nmap -sS -T4 --min-rate 5000 -p- -oN tcp_full.txt target

TCP全端口扫描在授权测试里成本可控，建议直接跑全端口。用--min-rate可以提高发包速率，缩短等待时间，但网络不稳时结果可能漏报，所以速率要量力而行。

第二步，对开放端口做定向识别：

nmap -sS -sV -sC -O -T4 -p 22,80,443,8080,8443,3306,6379,9200,27017 target

这里几个参数的作用是：

• -sV：探测服务版本号，必开
• -sC：跑默认的NSE脚本（主要包括banner、HTTP头抓取、常见弱配置检测等）
• -O：操作系统指纹识别

实际项目中全端口扫完再单独对开放端口跑-sV，因为如果一开始就带-sV扫全部65535个端口，耗时太长。先快扫定位漏洞面，再精准识别，效率最高。

3.2 常见高危服务与默认配置的坑

有经验的人看到某些端口会直接进入"重点深挖模式"。以下这些我几乎每次遇到都会多花时间：

如果你之前的经验还在一遍遍人工核对这些端口，建议把上面的表固化成自己的 namp 脚本或者一个检查清单，每次扫描后直接用脚本过滤出高危端口，人工只对命中项做深度验证。

有一个细节容易被忽略：UDP端口。默认扫描只跑TCP，但SNMP（161）、TFTP（69）这类UDP服务一旦暴露，信息收集效果会非常惊人。mib文件的system信息直接能把设备型号、系统版本、联系人邮箱全捞出来。UDP扫描慢且准确率波动大，我一般对重点资产做定向UDP扫描：

nmap -sU --top-ports 200 -T4 target

这种扫描经常是UDP服务发现的重要来源，虽然慢，但收获值得。

3.3 端口扫描的结果处理：输出格式与服务分类

很多人在这一步扫完直接截图完事，但后面如果碰到几十个IP、几百个端口，人工去翻扫描结果非常痛苦。我习惯把扫描结果转成结构化格式，用-oA参数同时输出三种格式（normal、XML、grepable），然后一个简单的 grep 就能把开放端口列表提取出来：

grep "open" tcp_full.gnmap | awk '{print $2, $3}' | sort -u

把结果按服务类型（HTTP类、数据库类、远程管理类、消息队列类）分组归档，后续每个类别走不同的利用链逻辑。这一步虽然花五分钟，但能让后面所有环节的效率提升一倍不止。

关于WAF和扫描干扰的问题，后面单独拿出一节细说，这里先记住一个原则：扫描结果要带着"可疑状态"一起记录，比如全端口只开了80，但响应很慢，或者有很多filtered状态，这类迹象说明可能有防火墙拦截，结果未必是完整真相。

4. Web指纹识别：别被"表面信息"带偏方向

端口扫描之后，凡是标着HTTP服务的端口都值得做一次指纹识别。指纹识别的价值在于快速判断技术栈，从而定下后续漏洞测试的方向。比如认清是 ThinkPHP 还是 Laravel，直接用对应的框架漏洞知识去验证；认清是 Nginx 还是 IIS，也决定了是否能套用特定中间件的历史漏洞。

4.1 静态指纹与行为指纹的配合

Web指纹信息的获取来源可以分为两类：

静态指纹，通常藏在响应里，包括：

• HTTP响应头：Server、X-Powered-By、Set-Cookie中的命名习惯
• HTML源码的meta标签、generator信息、版权声明
• favicon.ico 文件的哈希值，不同框架的默认图标哈希不同
• 特定目录文件：比如/robots.txt、/wp-json出现说明是WordPress，/actuator出现说明是Spring Boot
• 静态资源路径特征：如/static/js/app.js或/assets/vendor/结构的差异

行为指纹，需要发送特定请求或观察交互特征才能判断，例如：

• 默认错误页面的格式（404页面、500页面都很有识别性）
• 特定路径上的响应差异（如/_ignition/execute-solution在Laravel调试模式下的响应）
• Cookie的生成规则

工具层面，Wappalyzer方便但偏向被动识别，适合前端调研；ehole、WebFinder这类工具直接对目标列表批量识别框架、CMS、WAF，效率很高，适合在拿到一批Web资产后批量跑。如果你经常做这类工作，建议把自己常用工具的指纹规则收集起来，沉淀成自己的小工具箱，比每次都现查准确得多。

4.2 版本号确认与误报处理

指纹识别里最典型的一个坑是指纹命中了但版本判断错误。比如X-Powered-By: PHP/7.4.33看着很清楚，但如果后端套了CDN或者反向代理，这个响应头很可能是CDN节点自己生成的，并不能反映真实后端版本的完整情况。另一个常见误区是把框架识别等同于漏洞识别，比如识别出目标用的是低版本ThinkPHP，但目标站点可能打了安全补丁，需要通过具体接口行为验证才能下定论。

所以每次指纹识别我都要求自己对关键资产做一次"二次验证"：把识别的结果和实际请求特定路径的返回内容比对，确认真实性。比如识别出目标是某CMS后，去请求这个CMS的默认后台路径和特定静态文件（例如主题目录里的CSS），看是否存在，如果路径和文件都存在，指纹基本可以确认。

4.3 指纹到漏洞的映射思路

指纹确定的下一步不是立刻上漏洞扫描器，而是手动查一下这个版本是否存在已知漏洞。这一步在信息收集阶段做的好处是，能让后续漏洞验证更有针对性。

举个实际场景：识别出某站点用了Spring Boot 2.2.x，那么就要重点检查是否命中/actuator/env或/actuator/heapdump等路径的返回情况。识别出目标是phpMyAdmin 4.x，就要去看有没有对应的越权或者SQL注入已知漏洞。这种"指纹驱动"的漏洞预测，比通扫所有CVE高效得多。

还有一个习惯要养成：把指纹信息记录进资产表。每个Web资产一行，列出：URL、状态码、指纹结果、WAF类型、中间件版本。后面做目录扫描时，某些指纹信息能直接指导字典的选择，比如识别出是ThinkPHP，那字典里就应该加入ThinkPHP相关的备份文件名和调试页面路径。

5. 目录扫描与源码泄露：信息收集的高潮环节

目录扫描是最容易出"意外收获"的一步。子域名和端口告诉我们目标暴露了哪些服务，指纹告诉我们这些服务用什么技术写的，而目录扫描要解决的是——目标忘了藏起来的那些文件和路径。备份文件、配置文件、源码压缩包大部分都能在无认证的情况下直接读取。

5.1 字典决定了扫描的上限

目录扫描工具本身差异不大，dirsearch、御剑目录扫描、ffuf都行，真正拉开差距的是字典。好字典能覆盖常见路径、框架默认路径、备份文件名、技术栈特定后缀等。

这里给出一个我长期维护出来的字典基础结构：

• 通用目录：admin、backup、test、upload、sql、phpmyadmin
• 文件类型：.bak、.swp、.conf、.sql、.tar.gz、.zip、.env、.DS_Store
• 框架相关：根据指纹结果动态添加路径，比如ThinkPHP加/runtime、/.env，Laravel加/storage/logs/laravel.log、/vendor，Spring Boot加/actuator、/error
• 备份文件常见命名：web.rar、site.zip、backup.sql、db.bak、1.php，这些看似笨拙的命名在某些防水墙防御较差的历史项目里出现率很高

像御剑目录扫描这类工具自带的字典适合快速起步，但用了两个月后你会发现，沉淀自己的专属字典才是效率提升的拐点。把每次扫出来的有效路径回填进字典，日积月累你的字典会越来越贴合实战。

扫描的速度和线程也要控制好。设个并发阈值，比如--threads 100，太快容易触发WAF封IP，太慢浪费时间。如果目标有WAF，可以适当随机化User-Agent、加延时，必要时用代理池。ffuf的-ac参数可以自动校准响应大小，过滤掉通用404页面，这个非常实用：

ffuf -u https://target.com/FUZZ -w dict.txt -ac -t 50

5.2 状态码判断与备份文件处置

扫描结果出来之后，不能见到200就觉得有发现。状态码要从业务角度解读：

遇到.bak、.swp、.sql这种备份文件时，先下载到本地分析而不是直接在浏览器里看一眼。很多备份文件能直接暴露数据库账号密码，或者整站代码。我一般会在本地用vim、grep、strings快速翻一遍，寻找硬编码的密码、内部API地址、OSS密钥等。

5.3 源码泄露：从 git 到完整源码

源码泄露场景里最典型、利用价值最高的是Git目录泄露。很多开发者习惯把项目直接git init后放在Web目录里，线上更新也直接在服务器上pull，于是整个.git目录完全对外暴露。

判断方法特别简单：访问https://target.com/.git/config，如果能返回内容，说明Git目录泄露。即使返回403，只要.git/HEAD的内容是ref: refs/heads/master这类字符串，也能判定泄露存在。

传统手工利用方式是挨个请求.git目录下的每个对象文件再拼接，比较费时。工具方面，我常推荐GitHack以及GitDorker这套组合。GitHack 适合快速拉取：

python3 git_hack.py https://target.com/.git/

它会自动重建工作区，把能拿到的源码文件还原出来。Githack跑完不代表源码完整，.git目录里如果缺少部分对象的哈希文件（比如服务器开启了压缩传输或摘除了历史记录），对应的文件会确实无法恢复。这时再配合git log --all --reflog和git fsck --lost-found去找游离对象，经常能挖出不少历史版本中的敏感信息。

Git泄露之后，重点检查这几个文件：

• .env：环境变量里经常有数据库账号、Redis密码、JWT密钥
• config/：数据库配置文件
• docker-compose.yml：能暴露内部端口和容器结构
• .git/config：可能有远程仓库地址，甚至凭据

除了Git，还有几类常见的源码泄露也要纳入扫描计划：.svn泄露（老项目频繁出现）、.DS_Store泄露（Mac开发者上传目录时遗漏）、WEB-INF/web.xml泄露（Java Web项目）、.hg泄露（Mercurial仓库）。它们各有一套对应的利用工具，但原理都是类似的——版本控制或系统文件被Web服务器当普通静态文件暴露了。

6. 人员信息收集：从域名到人的最后一步

信息收集做到这里，再往下一步就是从"系统资产"扩展到"人员资产"。这部分很多人觉得和法律风险打擦边球而完全略过，但在授权渗透测试中，人员信息的收集是分离的、合法的——通过公开渠道整理目标组织的域名注册信息、联系方式、组织架构和开发者习惯，目的不是做恶意社工，而是发现身份相关或口令相关的突破口。

6.1 Whois与域名历史的线索

从域名开始反查Whois是最基本的动作。找到注册人名称、企业地址、联系电话、邮箱后，可以进一步反查这个注册人拥有的其他域名。很多企业内部系统不会挂在主域名下，而是挂在基于个人邮箱注册的域名下，顺着这条线能发现一批"灰色资产"。

历史Whois和DNS解析记录同样重要。一个域名很可能早年注册时留过旧邮箱、旧地址，后来改过一遍；或者域名曾绑定过某个开发环境IP，这些历史数据里都可能有线索。用网上现成的域名历史查询服务或者专业API平台都可以获取。

6.2 邮箱命名规则与域名反查

收集到人员姓名后，下一个有价值的动作是确认企业邮箱的命名规则。主流的命名方式有firstname.lastname@domain.com、flastname@domain.com、firstname@domain.com等。通过网上公开的新闻稿、论文署名、招聘信息拿到两三个真实姓名和邮箱对应关系，就能归纳出规则，进而反查或推断更多人的邮箱。

这一步的信息来源主要有：

• 官网页脚、联系方式页面
• 招聘信息里 HR 的邮箱
• App发布信息里的技术支持邮箱
• 员工的公开技术博客、GitHub主页

推断出的邮箱列表，可以在后续授权测试里用于身份认证相关的弱口令验证（注意只能在授权范围内）。在真实项目中，"内部某个账号"往往是撕裂突破口的关键。

6.3 人员身份的边界问题

人员信息收集的红线一定要清楚：只能利用公开渠道的数据，不做主动社攻，不做未经授权的定位跟踪，不涉及无关第三方。所有收集到的人员信息只能用来辅助技术测试，比如确认资产归属、归纳密码规则、识别目标基础设施的来源。

以我的经验，人员信息在授权测试中最有意义的用法是"确认资产归属"和“关联资产线索”。例如当你发现一个子域名解析到不知名的IP，不确定是不是目标资产时，通过创始人邮箱、域名注册历史或者ICP备案信息就能快速确认归属，从而把人力和时间投放在正确的地方。

7. 把碎片拼成攻击路径：信息的关联与优先级排序

六类信息都收集完之后，最大的挑战不再是"找信息"而是"找关联"。信息是碎片化的，攻击路径是线性的，只有把域名的归属、服务的技术栈、人员的身份串联起来，才能确定下一步最值得投入的方向。

7.1 一个完整实战案例的串联逻辑

拿一次授权的实战项目举例：

1. 从主域名example.com出发，通过CT日志和子域爆破拿到了47个子域名
2. 端口扫描发现git.example.com开放了80端口，是一个GitLab服务
3. 指纹识别确认GitLab版本为13.1.0，这个版本存在未授权访问问题
4. 目录扫描时在git.example.com找到/explore页面可直接访问，能列出内部项目列表
5. 在暴露出的一个项目中发现了docker-compose.yml和.env文件，里面包含数据库地址和账号
6. 通过.env里的命名规则，推断出目标内部系统管理员极可能使用同一套密码逻辑
7. 之后在授权范围内验证了管理后台弱口令，最终进入后台完成测试

这个链路里的每一环，往前推都是信息收集的成果。没有CT日志就没有GitLab子域，没有版本指纹就不会想到查未授权漏洞，没有目录扫描就找不到项目文件，没有.env泄露就推不出密码习惯。信息收集的最终产物不是一堆数据，而是一条清晰的攻击链。

7.2 优先级排序：先打哪个目标

当我面对几十个资产时，会按"高价值-易突破"矩阵给目标排序：

• 高价值-易突破（比如后台登录页+弱口令嫌疑）：排最前，可能是突破口
• 高价值-难突破（比如主站带WAF）：记录备用，等有了更多的边界条件后再回看
• 低价值-易突破（比如闲置的子域名站点）：顺带扫一遍，拿到更多信息再升级
• 低价值-难突破：基本跳过，不值得耗时间

有了排序，再动手时就不会漫无目的地到处试漏洞，而是"先纵深、再横向"，能把有限的时间花在刀刃上。

7.3 信息的整理工具与笔记习惯

最后说信息整理。做这一行最忌讳"扫过就忘"，我自己的习惯是每个目标建一个统一的目录，资产表格、扫描工具输出、字典、截图全部归档。记录时用Markdown按资产维度写，关键信息比如用户名、IP、版本都要标记出来，方便检索。

常用的整理工具组合：

• markdown笔记记录整体进度和线索
• 资产清单用表格（Excel或CSV均可），每行一个子域/IP，列包含端口、指纹、备注
• 命令输出保存为文本，方便后续grep
• 截图单独建目录，按目标子域命名

这套习惯看上去不起眼，但在项目周期长、资产数量多的情况下，能直接决定你最后交报告的效率。

写在最后的一点经验

我做信息收集这些年，最大的体会是：工具的熟练度远没有"信息组织能力"重要。同一个nmap、同一个ffuf，新手和老手跑出来的结果相差悬殊的原因就在于，老手知道哪些端口要深挖，知道什么样的指纹值得记录，知道什么状态的目录结果才是有效资产。

建议刚开始做信息收集的朋友，不要指望一个工具能"一键拿权限"。把这个流程当成一门手艺去打磨：每次项目做完，回看一遍自己当时整理的资产表，问问自己"如果重来一次，我会在哪一步多花时间，哪一步其实是白费力"。带着这个复盘习惯做三五个项目，你对信息收集的理解会上一个台阶。