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作为快速出结果的工具可以补充着看但不要作为唯一依赖。爆破环节有三大坑要避开泛解析问题目标域名可能配置了泛解析随便打个不存在的子域名也能解析出IP。解决办法是先用一个随机字符串测试如果有解析结果说明存在泛解析这时所有结果都要拿这个基线IP去对比解析到相同IP的直接丢弃。字典陈旧纯靠网上找的老字典基本只能跑出一些主流命名。建议结合目标网站的命名习惯动态扩展比如目标用了dev-和test-前缀就手动加上staging-、pre-、alpha-、prod-这类变体。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 targetTCP全端口扫描在授权测试里成本可控建议直接跑全端口。用--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 常见高危服务与默认配置的坑有经验的人看到某些端口会直接进入重点深挖模式。以下这些我几乎每次遇到都会多花时间端口服务常见利用点22SSH弱口令、旧版本漏洞、密钥泄露3306MySQL弱口令、未授权访问6379Redis未授权写计划任务、SSH公钥9200Elasticsearch未授权访问、任意文件读取老版本27017MongoDB未授权访问7001WebLogic反序列化、未授权访问8080/8443常见Web中间件管理后台暴露、默认口令11211Memcached未授权访问如果你之前的经验还在一遍遍人工核对这些端口建议把上面的表固化成自己的 namp 脚本或者一个检查清单每次扫描后直接用脚本过滤出高危端口人工只对命中项做深度验证。有一个细节容易被忽略UDP端口。默认扫描只跑TCP但SNMP161、TFTP69这类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、/.envLaravel加/storage/logs/laravel.log、/vendorSpring 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 505.2 状态码判断与备份文件处置扫描结果出来之后不能见到200就觉得有发现。状态码要从业务角度解读状态码含义后续动作200文件存在且可访问直接浏览器打开逐条确认内容301/302存在但可能跳转看Location指向哪里有时候指向后台登录页401/403存在但被访问控制拦截记录备用可能通过改路径绕过或爆破认证500路径可能触发了程序错误值得深挖可能是未过滤参数导致404大概率不存在忽略遇到.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.lastnamedomain.com、flastnamedomain.com、firstnamedomain.com等。通过网上公开的新闻稿、论文署名、招聘信息拿到两三个真实姓名和邮箱对应关系就能归纳出规则进而反查或推断更多人的邮箱。这一步的信息来源主要有官网页脚、联系方式页面招聘信息里 HR 的邮箱App发布信息里的技术支持邮箱员工的公开技术博客、GitHub主页推断出的邮箱列表可以在后续授权测试里用于身份认证相关的弱口令验证注意只能在授权范围内。在真实项目中内部某个账号往往是撕裂突破口的关键。6.3 人员身份的边界问题人员信息收集的红线一定要清楚只能利用公开渠道的数据不做主动社攻不做未经授权的定位跟踪不涉及无关第三方。所有收集到的人员信息只能用来辅助技术测试比如确认资产归属、归纳密码规则、识别目标基础设施的来源。以我的经验人员信息在授权测试中最有意义的用法是确认资产归属和“关联资产线索”。例如当你发现一个子域名解析到不知名的IP不确定是不是目标资产时通过创始人邮箱、域名注册历史或者ICP备案信息就能快速确认归属从而把人力和时间投放在正确的地方。7. 把碎片拼成攻击路径信息的关联与优先级排序六类信息都收集完之后最大的挑战不再是找信息而是找关联。信息是碎片化的攻击路径是线性的只有把域名的归属、服务的技术栈、人员的身份串联起来才能确定下一步最值得投入的方向。7.1 一个完整实战案例的串联逻辑拿一次授权的实战项目举例从主域名example.com出发通过CT日志和子域爆破拿到了47个子域名端口扫描发现git.example.com开放了80端口是一个GitLab服务指纹识别确认GitLab版本为13.1.0这个版本存在未授权访问问题目录扫描时在git.example.com找到/explore页面可直接访问能列出内部项目列表在暴露出的一个项目中发现了docker-compose.yml和.env文件里面包含数据库地址和账号通过.env里的命名规则推断出目标内部系统管理员极可能使用同一套密码逻辑之后在授权范围内验证了管理后台弱口令最终进入后台完成测试这个链路里的每一环往前推都是信息收集的成果。没有CT日志就没有GitLab子域没有版本指纹就不会想到查未授权漏洞没有目录扫描就找不到项目文件没有.env泄露就推不出密码习惯。信息收集的最终产物不是一堆数据而是一条清晰的攻击链。7.2 优先级排序先打哪个目标当我面对几十个资产时会按高价值-易突破矩阵给目标排序高价值-易突破比如后台登录页弱口令嫌疑排最前可能是突破口高价值-难突破比如主站带WAF记录备用等有了更多的边界条件后再回看低价值-易突破比如闲置的子域名站点顺带扫一遍拿到更多信息再升级低价值-难突破基本跳过不值得耗时间有了排序再动手时就不会漫无目的地到处试漏洞而是先纵深、再横向能把有限的时间花在刀刃上。7.3 信息的整理工具与笔记习惯最后说信息整理。做这一行最忌讳扫过就忘我自己的习惯是每个目标建一个统一的目录资产表格、扫描工具输出、字典、截图全部归档。记录时用Markdown按资产维度写关键信息比如用户名、IP、版本都要标记出来方便检索。常用的整理工具组合markdown笔记记录整体进度和线索资产清单用表格Excel或CSV均可每行一个子域/IP列包含端口、指纹、备注命令输出保存为文本方便后续grep截图单独建目录按目标子域命名这套习惯看上去不起眼但在项目周期长、资产数量多的情况下能直接决定你最后交报告的效率。写在最后的一点经验我做信息收集这些年最大的体会是工具的熟练度远没有信息组织能力重要。同一个nmap、同一个ffuf新手和老手跑出来的结果相差悬殊的原因就在于老手知道哪些端口要深挖知道什么样的指纹值得记录知道什么状态的目录结果才是有效资产。建议刚开始做信息收集的朋友不要指望一个工具能一键拿权限。把这个流程当成一门手艺去打磨每次项目做完回看一遍自己当时整理的资产表问问自己如果重来一次我会在哪一步多花时间哪一步其实是白费力。带着这个复盘习惯做三五个项目你对信息收集的理解会上一个台阶。