全方位信息收集子域名、端口、指纹、目录、源码泄露、人员信息做授权测试这几年我每次拿到一个目标第一件事从来不是急着扫漏洞而是先搞信息收集。说得直白点信息收集决定了你后续测试的天花板——子域名、端口、指纹、目录、源码泄露、人员信息这一套下来目标在你的视野里基本就是透明的。但很多人把信息收集理解成“跑几个工具就完事”结果要么收集了一堆废数据要么漏掉了真正有价值的东西。这篇文章我想把完整的收集思路、工具选型、实操要点和踩过的坑一次说清楚希望对正在做安全评估或者想系统入门的朋友有帮助。这篇内容适合两类人一是刚接触授权渗透测试的新人想搞明白“拿到一个目标后究竟先干什么”二是已经有一定经验但收集过程比较零散的测试人员可以对照自己的流程查漏补缺。我不会只堆工具命令而是把每个环节背后的判断逻辑讲清楚这样你换任何工具、任何场景都能套用。1. 信息收集到底在收集什么1.1 从资产角度理解目标的真实边界很多人提到信息收集第一反应就是“扫端口”“跑目录”这没错但视野太窄了。信息收集的本质是回答一个问题这个目标在网络空间里到底有哪些资产它们之间是什么关系一个企业的线上资产往往远比你想的多。主域名下的业务系统只是冰山一角水面以下还藏着测试环境、旧版本系统、内部管理平台、第三方外包项目、云存储桶、GitHub上的代码仓库、移动App的后端接口、甚至还可能有运维人员临时开的高危端口。这些都是“资产”也都是潜在入口。我习惯把信息收集分成三个层次来看基础资产层根域名、子域名、IP段、CDN归属、ICP备案信息。这一层解决的是“目标有哪些网络资产”。暴露面层端口、服务、Web指纹、目录结构、源码泄露。这一层解决的是“这些资产开了什么口子”。人与组织层邮箱命名规则、GitHub账号、招聘信息、技术栈偏好。这一层解决的是“背后的团队怎么做事可能留下什么痕迹”。三层信息互相印证才能形成完整的攻击面地图。比如通过ICP备案找到公司名再通过搜索引擎找到该公司的GitHub组织号在代码仓库里发现内部系统的域名前缀然后再去枚举子域名——这种链路式收集比单纯跑一遍工具高效得多。1.2 一个典型的授权测试前收集流程我自己在项目里会按下面的顺序推进每一步的结果都会成为下一步的输入确认授权范围明确哪些域名、IP段允许测试。这一步没有商量的余地范围外的一律不碰。先做被动收集查ICP备案、Whois、证书透明度日志、历史DNS记录这些不需要直接触碰目标风险低、信息量大。做主动子域名枚举用字典爆破和接口查询两条腿走路拿到尽量全的子域名列表。将子域名批量解析为IP结合CDN识别筛出真实IP段再对存活主机做端口扫描。对扫描出的Web服务做指纹识别判断中间件、CMS、开发框架筛选高价值目标。对Web应用做目录枚举和敏感文件探测重点关注源码泄露、备份文件、管理后台。最后从公开渠道收集人员信息主要是为了验证弱口令策略、钓鱼演练和社工防护。这一套完整走下来少则一天多则一周取决于资产规模。但值得因为后续的漏洞挖掘基本都是在这个框架里做选择题——你收集得越充分越知道自己该打哪里。2. 子域名收集从根域开始的资产摊牌2.1 子域名为什么值得花时间子域名是扩大攻击面最直接的途径。主站可能防御做得滴水不漏但某个子域可能挂着三年前的老系统或者是一个无人维护的测试页面一个年久失修的Struts2就足够撬开整道防线。我从实践中得出的经验是子域名的数量和企业的安全意识、IT管理规范程度成反比。管理规范的团队子域名多但都纳管了信息及时更新管理混乱的团队子域名更多但大部分是“僵尸资产”连负责人都不清楚。而这些僵尸资产恰恰是安全评估中最容易出问题的地方。举个例子之前一次授权测试里主站的指纹是Nginx Java Spring Boot补丁打得很全折腾半天没找到突破口。后来做子域名枚举翻出一个内部的CI/CD平台老旧版本存在未授权访问漏洞顺藤摸瓜直接找到了内网配置文件。所以凡是说“信息收集不重要直接扫漏洞”的基本都是没吃过资产不全的亏。2.2 常用工具与实操要点子域名收集我常用的工具有这些Subfinder被动收集为主聚合了多个证书透明度和DNS数据源速度快、对环境依赖小是我最常用的工具。Amass功能最全支持主动和被动模式还能做关联图分析但配置复杂、跑起来慢。OneForAll国内团队维护的集大成者集成了多数据源导出报告友好适合做持久化收集。Layer子域名挖掘机Windows下的经典图形化工具自带字典和接口查询对新手友好但字典偏旧建议手动替换。这里分享一个我固定的组合用法# 第一步被动收集 subfinder -d example.com -all -recursive -o subfinder.txt # 第二步主动爆破字典可换成自己积累的高频子域名字典 puredns bruteforce subnames.txt example.com -r resolvers.txt -w puredns.txt # 第三步合并去重 cat subfinder.txt puredns.txt | sort -u all_subs.txt # 第四步批量探测存活并识别Web服务 httpx -l all_subs.txt -title -status-code -tech-detect -o live_subs.txt很多人喜欢一上来就上Layer或者御剑这类图形化工具界面直观、点点鼠标就出结果这没问题。但要注意两点一是这类工具自带的字典往往很多年没更新枚举结果会漏掉大量新出现的命名习惯比如用dev-api、gitlab、rancher这类带技术堆栈关键词的子域二是它们大多依赖本地字典做爆破没用上证书透明度Certificate Transparency这个信息量巨大的来源。如果你还没用过crt.sh强烈建议去试一下。CA机构会把签发的每一个SSL证书记录到公开的CT日志里而证书里往往包含一堆子域名和泛域名。搜索%.example.com就能拉出一大堆对方自己可能都忘了的子域名。这一招在授权测试里几乎是最有效率的被动收集方式。2.3 泛解析和CDN干扰的处理子域名收集最让人头疼的就是泛解析目标把*.example.com都解析到同一个IP导致你爆破出来的几百个“子域名”其实都是同一个服务器数据看起来很多实际全是噪声。验证方法很简单随便解析一个几乎不可能存在的名字比如asdkfjkhsajdhf.example.com看它是否返回IP。如果返回了说明存在泛解析。这时候需要在批量验证时把“返回IP与泛解析IP相同”的结果全部标记为噪声。CDN干扰是另一个常见坑。子域名套了CDN后你解析出来的IP是CDN节点不是真实源站直接对这个IP做端口扫描会发现意义不大。我一般会通过历史DNS记录比如SecurityTrails、证书信息、子域名的MX记录关联来尝试定位真实IP但前提仍然是“授权范围内”不要为了一味找源站而打到范围外的CDN厂商节点上去。3. 端口与服务摸清每台主机到底开了什么3.1 端口扫描工具怎么选拿到IP或IP段之后端口扫描是必须做的一步。端口就相当于服务器的门和窗你总得知道哪些门是开着的、里面跑的是什么服务才知道从哪进。工具选择上我个人的排序是Nmap全能型选手扫描、版本探测、脚本扫描一条龙。缺点是速度慢尤其是大网段全端口扫描时。Masscan最快号称能在几分钟内扫完整个互联网的某个端口适合第一步快速摸端口但准确性一般需要配合Nmap复核。RustScanRust写的极速扫描器能在几秒内扫完全部65535个端口扫完自动调用Nmap做服务识别是我现在用的最多组合。NaabuProjectDiscovery家的速度快、结果干净也支持管道输出。我常用的组合指令# 第一步快速发现开放端口 rustscan -a 1.2.3.4 --range 1-65535 -- -sV # 或者用 Masscan 扫大量IP注意要限速避免对目标造成压力 masscan -p1-65535 --rate 1000 -iL ip.txt -oG masscan_out.gnmap这里有个经验第一轮别只扫常见端口。很多安全人员习惯用-p-之外的默认端口列表比如只扫80、443、22、3306之类的这样做会漏掉大量小众服务。一次真实测试里目标在TCP 25734端口上跑着一个自定义的License服务这个端口既不在常见端口列表里也不是任何通用协议Nmap默认情况下根本不会扫到但它却是一个重要的暴露面。所以只要是授权范围内的测试端口扫描就应该全端口覆盖宁可慢一点不能漏。3.2 指纹识别知道服务长什么样端口扫出来了下一步是识别这些端口上跑的服务和版本。指纹识别的任务是回答三个问题这是什么服务/中间件/框架什么版本有没有已知的公开漏洞与之匹配Web指纹识别我常用的工具Wappalyzer浏览器扩展适合人工分析单个站点能识别前端框架、Web服务器、分析工具、CMS等。WhatWeb命令行工具规则多可以批量跑。EHole棱洞国内安全团队开源的指纹识别工具支持FOFA、Hunter语法批量识别能力强。TideFingerTide团队维护的指纹库覆盖面广含POC信息。Nmap的-sV和--scriptvuln直接与服务交互提取版本再调内置脚本辅助判断。指纹识别的原理并不复杂本质上是特征匹配从HTTP响应头、首页HTML、特定路径的静态文件、favicon的哈希值、Cookie名、错误页面的关键字等维度提取特征与指纹库比对。所以指纹识别不准确也很常见——比如目标站点套了一层CDN/云WAF把真实响应头改写掉了或者站点做了URL重写导致指纹特征路径被隐藏。实战中我喜欢双轨并行先用自己的工具矩阵批量跑一遍再人工抽样2-3个关键目标用浏览器和Wappalyzer确认。要知道工具告诉你说“这是Spring Boot”不代表你不需要再确认一下路径/actuator是否可访问工具没识别出CMS类型也不代表它就不是CMS——可能只是被二次开发改得面目全非。3.3 把端口、服务、漏洞初步关联起来指纹识别的最终目的不是出一张好看的报告表格而是为下一步漏洞测试提供线索。当你识别出以下信息时大脑里应该立刻浮现该关注哪些CVE或配置问题Nginx版本老查是否存在越界读取、目录穿越类漏洞。Apache Shiro关注密钥是否默认rememberMe反序列化。Spring Boot检查/actuator/env、/actuator/heapdump等端点是否暴露。ThinkPHP 5.x关注公开的RCE链。WebLogic关注后台弱口令和反序列化。自定义服务端口尝试协议交互、找开发文档往往存在逻辑漏洞。比如目标识别出是Spring Framework且版本可能偏旧那么近期的CVE-2024-38819这类目录遍历漏洞就值得重点关注因为Spring的URL解析和静态资源映射机制一旦配置不当确实容易出现绕过授权访问敏感文件的问题。指纹的价值就是把这种“哪里可能有问题”的优先级排出来而不是你对着一个IP段盲目尝试。4. 目录扫描与源码泄露隐藏资产的黄金地带4.1 目录扫描不是暴力猜名字端口扫完、指纹识别完能直接打的漏洞可能已经发现了几个。但真正的宝藏经常藏在Web应用的目录和文件里。很多团队把目录扫描简单理解成“拿字典跑一遍路径”其实不然。目录扫描的核心是“枚举未公开的路径和文件”字典质量决定上限。我自己的做法是先用通用字典扫一遍比如Dirsearch自带的common.txt、Directory-list-2.3-medium.txt覆盖最常见的路径命名。根据指纹识别结果替换专业字典识别到ThinkPHP就测/index.php的模块和控制器路径识别到Nginx就重点搜/.git/、/.svn/识别到Tomcat就测/manager/html、/host-manager。结合站点功能做人工推导。比如站点有上传功能就去试常见上传目录的路径有静态资源CDN就尝试列目录。留意robots.txt、sitemap.xml、crossdomain.xml、security.txt这些“看似公开但信息量巨大”的文件很多站点会在这里暴露后台入口或禁止搜索引擎抓取的敏感路径。工具方面我常用的有dirsearch、ffuf、御剑和gobuster。这里多说一句ffuf是后起之秀速度极快而且支持从Burp的请求原文生成Fuzz模板能模拟真实用户访问路径误报率比纯字典暴力扫描低很多。我已经把大部分常规目录枚举交给了ffuf。# ffuf 基本用法 ffuf -u https://example.com/FUZZ -w wordlist.txt -mc 200,301,302,403 -ac # 如果指纹识别出是PHP站点可以指定扩展名 ffuf -u https://example.com/FUZZ -w wordlist.txt -e .php,.bak,.txt,.html -mc 200,301,302-ac这个参数能自动根据响应内容过滤掉泛解析或统一404页面强烈建议打开能省掉大量人工核对时间。4.2 源码泄露的常见泄露面和利用方法源码泄露是目录扫描里最值得兴奋的发现之一因为它意味着你有可能直接获得整站代码后续做代码审计就是降维打击。常见的泄露类型和我的处理方法如下.git目录泄露如果站点存在/.git/目录且允许访问说明开发部署时把版本库整个提交上去了。这种情况下直接用工具把源码拉下来分析。# 方案一GitHacker 自动还原 githacker --url http://target.com/.git/ --output-folder result/ # 方案二git-dumper git-dumper http://target.com/.git/ repo/实践中..git目录可能是残缺的有些对象文件缺失。遇到这种情况可以先下载/.git/config、/.git/HEAD、/.git/index确认仓库完整性再用git fsck检查丢失对象。如果只是部分丢失大部分代码依然能恢复出来。.svn目录泄露老项目常见用dvcs-ripper工具可以恢复.svn中的文件版本历史。虽然现在SVN用得少了但存量系统里仍然偶尔能遇到。备份文件泄露这是最容易被忽视但命中率极高的一类www.zip、site.tar.gz、backup.sql、web.bak、index.php.bak。字典里务必包含这些常见的备份命名而且扫到.bak这类文件时不要只下载看内容有些备份是完整代码压缩包拉下来本地解压后信息量巨大。编辑器临时文件比如Vim的.swp文件访问/.index.php.swp.DS_Store文件macOS下访问目录元数据可能暴露目录文件列表。.DS_Store泄露在真实站点上比想象中常见一旦拿到整个目录结构直接就出来了。错误信息泄露故意构造一个不存在的路径触发框架的Stack Trace有时错误信息里会带上绝对路径、数据库连接串、内部IP。这不算严格意义上的“源码泄露”但信息价值不亚于源码。4.3 从“有目录”到“可利用”扫出来一堆目录不算完事真正的判断才刚刚开始。我的习惯是先用指纹判断这个站是什么语言和框架再决定这些目录是不是有意义。比如一个纯前端静态站就算扫出/admin里面可能只是一个假页面。对扫到的每个后台或上传目录做一次响应包对比。看状态码、Content-Length、响应内容的差异判断是真目录还是假目录。对确认存在的敏感路径再去搜索公开漏洞或做弱口令测试。比如扫到/actuator端点就要深入看它暴露了哪些信息扫到/api/swagger-ui.html说明API文档可能可以直接看这可是一手的好情报。这一步的核心不是“路径数量”而是把路径和漏洞之间的关联打通。扫出一百个目录但不知道每个目录的价值跟只扫出一个且马上确认可用后者的效率要高得多。5. 人员信息收集从技术资产到人5.1 人员信息在攻防里的作用与红线很多技术向的测试人员容易忽略人员信息这条线觉得“那是社工和钓鱼才需要的东西”。但在真实的授权攻防演练里人员信息往往能直接转化为突破口通过公开的邮箱命名规则推测管理员的邮箱验证弱口令策略是否有效通过GitHub上的个人代码发现密码硬编码通过招聘信息了解企业内部技术栈和系统名。但这里必须先划一条红线所有人员信息收集必须基于公开来源且必须在授权和法律法规允许的范围内进行。不能去入侵邮箱、不能撞库、不能使用任何非公开渠道获取公民个人信息。我在这里写的内容更多是提醒防守方“信息已经暴露到什么程度”以及帮助授权测试方在合规范围内完成钓鱼演练、口令安全检测等任务不是教人肉搜索。5.2 公开渠道能收集到什么程度最常见的公开来源和对应的利用思路ICP备案信息能确认企业主体名称、域名归属、负责人姓名历史备案信息可能暴露更多域名。注意现在备案信息已对部分字段做脱敏很多企业会用代持主体所以不能只当唯一数据源。Whois信息老域名常能查到注册人邮箱、联系方式。某些情况下同一个邮箱可能同时出现在多个域名下方便做资产关联但需要注意隐私保护服务的干扰。搜索引擎语法site:github.com 公司名、site:pastebin.com 域名、site:*.example.com filetype:pdf能挖到员工发布的文档、分享的PPT、公开的代码片段甚至内部系统截图。GitHub代码搜索用域名、公司英文名、内部系统名当关键字搜代码经常能在公开仓库里找到硬编码的AccessKey、内部API地址、数据库连接串。这一步的命中率取决于公司的代码管理规范越是小团队越容易翻车。招聘网站和社交平台职位描述会写“熟悉Kubernetes”“负责XX系统运维”配合员工动态可以推测企业内部的技术栈和目标系统名称为后续口令喷洒字典提供关键词。公开邮箱命名从收到的邮件、PDF元数据、GitHub提交记录里提取员工邮箱归纳出名字拼音域名或工号域名这种固定规则。有了规则再加上收集到的员工姓名就能构造出一批潜在邮箱列表用于授权范围内的钓鱼演练或弱口令检测。5.3 从防御视角看人员信息保护每次做完这类信息收集我都会给防守方提几条改进建议这里也写出来供参考代码仓库强制开启成员私有可见防止员工个人仓库里带入公司代码。在CI/CD流程里加入密钥扫描防止AccessKey和数据库密码被提交到远端仓库。对外发布的文档、PPT统一脱敏尤其是内部系统截图上的URL和Hostname要涂掉。邮箱命名规则尽量与个人隐私隔离工号不要和登录账号直接挂钩。定期用搜索引擎语法自查搜site:github.com 公司英文名、site:网盘类型 公司名这类内容及时发现泄露。技术预防只是一半另一半是意识。人员信息的泄露通常不是某一个系统漏洞造成的而是很多个小疏忽叠加的结果。测试者的价值就是把这种叠加效应演示出来让企业知道自己的暴露面到底有多大。6. 实操常见问题与排查技巧实录6.1 子域名收集结果大量失效怎么办跑完Subfinder和爆破发现几千个子域名结果httpx一验证活着的不到几十个。这种情况太常见了原因往往有三一是泛解析导致的假域名被后续验证清掉了二是很多子域名仅在企业内网DNS解析公网访问不通三是部分老子域名已经停止解析但历史信息仍被各类数据源收录。处理办法第一对所有结果统一做DNS解析和HTTP探测不只要看是否返回还要看返回的IP是否属于目标段、标题是否符合业务特征第二把“解析到CDN、解析到第三方云厂商”的单独归类别一股脑全丢进扫描池第三对存活结果再做一次二级/三级子域名的递归枚举往往还能挖出更深层的资产。6.2 端口扫描结果与预期相差很大有时候明明目标是个大企业结果全端口扫描只发现两三个端口明显不正常。排查方向一是源IP被目标的安全设备限制大量探测请求被静默丢弃二是扫描速率太快触发反制中间链路丢包严重三是目标真的把大部分端口都用防火墙封了只允许白名单来源访问。应对时我会把扫描参数调成更保守的速率换不同的扫描源IP再对比不同来源的结果差异。但也要强调一点——如果目标明确有WAF或IDS且授权范围没有包含抗测试那就不要强行对抗记录当前观测结果即可。安全测试的目的是证明风险不是证明你能绕过所有防御。6.3 目录扫描全是200的假象这是新人最容易卡住的点字典里随机编造的路径也返回200导致整个扫描结果没有任何区分度。原因通常是目标Web框架做了统一路由任何不存在的路径都返回首页或自定义404页面并且HTTP状态码依然是200。我习惯用-ac或-fs参数解决。先用ffuf跑一次随机路径记录“假200”页面的特征Content-Length、特定关键字、响应头然后在正式扫描时用-fs 长度过滤掉这些响应。也可以直接配置--match-codes 200,301,302但加入--filter-size把明显一致的页面大小去掉。人工验证时还可以配合浏览器去访问几个结果看页面渲染出来的内容是否真的对应路径。6.4 Git源码泄露后发现恢复不了.git目录存在但不一定完整直接git clone或git-dumper可能中途报错。常见的坑git-dumper只能下载它能识别到的对象文件如果服务器限制了并发或断连文件列表就不全。.git/objects/pack里的打包对象很大恢复工具可能超时。一些服务器对/.git/做了限制只允许访问部分文件。我的替代方案是先用curl逐个确认关键文件是否存在比如/.git/config、/.git/HEAD、/.git/index和/.git/logs/HEAD再用支持断点续传的工具比如wget递归下载整个.git目录最后在本地用git fsck --lost-found尝试找回悬空对象。只要index和logs在很多被删掉的历史文件也能通过git show恢复出来。6.5 指纹识别误报与漏报指纹工具给出的结果不能全信。比如识别到X-Powered-By: PHP/7.2但实际前端是Nginx反代到后面多台PHP机器版本号是其中某一台的再比如识别出WordPress但主题被深度定制目录结构全改了直接套用WordPress的POC大概率是无效的。应对办法是基于多个特征交叉验证。比如判断一个站点是不是ThinkPHP我会同时看响应头、/index.php的默认欢迎页、特定错误页面的签名以及若干静态文件是否存在。多特征同时命中才敢下结论单特征只作为线索不做决策。写在最后的一点体会做了这么多年的评估我的感受是信息收集不是一个一次性的前置步骤而是一条贯穿整个测试周期的线。最初收集的数据可能在测试中段突然派上用场比如你扫出的某个不起眼的子域名恰好是主站某个功能页面的API后端。所以我在每个项目里都会维护一张资产信息表第一时间记录新发现随时补充和更新。另外这也是我在实际项目里总结出的一个很实用的推进原则先被动、后主动先广度、后深度先通用、后定制。被动信息能解答的问题就不要提前去打草惊蛇广度收集能筛掉的目标就不要浪费深度测试的时间。把信息收集的每个动作都当成一次推理你的效率和对目标的掌控感都会完全不同。