漏洞赏金第一步:信息搜集与资产梳理实战指南

发布时间:2026/10/21 23:51:39
漏洞赏金第一步:信息搜集与资产梳理实战指南
信息搜集做得好不好直接决定你后面能不能挖到洞。很多人兴致勃勃报名漏洞赏金上来就去点目标网站结果点半天什么都没发现就觉得是自己技术不行。其实问题根本不在技术而在信息搜集这一步没做扎实。目标有哪些域名、哪些IP段、哪些端口开着、跑着什么服务这些底层资产没摸清楚后面所有测试都是蒙着眼睛打靶。这篇先从信息搜集讲起。我不是要给你贴一张工具清单就完事而是想把每个环节背后的思路、以及我在实际项目中用到的判断方法一起说透。适合刚入坑漏洞赏金、或者虽然会跑工具但不知道下一个命令该敲什么的人看。看完你至少能独立对一个授权目标完成一轮系统的资产梳理知道自己下一步该测什么。1. 信息搜集到底在搜什么——先把四个资产维度搞清楚1.1 为什么第一步必须是信息搜集漏洞赏金本质是在目标授权的范围内找出可能被利用的安全弱点。而弱点藏在资产里你连资产有哪些都不知道弱点自然也无从谈起。很多新手有个误区觉得信息搜集就是“多扫几个目录”“多跑几个字典”属于打杂活。实际完全相反信息搜集的质量决定后续测试上限。举个容易理解的例子你去找一个人如果只知道对方名字找起来效率很低。但如果你知道他常活动的区域、开的车、用的手机型号找到他的可能性就高得多。资产越多越大暴露面就越宽你能测试的方向就越多。同一个目标有人只看到一个官网首页有人能看到十几个子域名、三个旁站、两个测试环境、若干历史备份文件后面这位能挖到的内容显然更多。信息搜集还有一个目的找到目标的边界与优先级。不是所有资产都值得投入同等精力。一个无人维护的旧系统往往比主站更容易出现漏洞所以在梳理阶段就要把高价值目标标记出来。这一步做得好后续几个小时你就是有方向地深挖而不是漫无目的地乱试。1.2 四个维度域名、IP、端口、指纹我做信息搜集习惯把资产分成四个维度也可以说四个层级。从大到小依次是域名资产、IP资产、端口与服务、Web指纹与中间件。这四个维度不是并列关系而是层层递进的关系。域名资产解决的是“目标有哪些对外服务的名字”包括主域名、子域名、可能被遗忘的测试域名。IP资产解决的是“这些名字背后对应哪些服务器”。有了IP还要看这个IP开放了哪些端口端口决定你能从哪些服务下手。最后是指纹也就是跑在端口上的具体技术栈什么中间件、什么框架、什么语言、有没有WAF。这个顺序之所以重要是因为每层都在收窄范围。比如你拿到一个主域名先枚举出50个子域名再解析出20个真实IP扫端口发现其中5台开了非常规服务最后通过指纹确认其中2台跑着旧版本框架。此时你的测试清单已经从“一个官网”变成了“两个具体的高危目标”。如果没有层级化思路很容易在第一步就被一堆域名淹没不知道从哪里开始。2. 域名和子域名怎么收集——别只知道用字典硬跑2.1 基础信息先从DNS记录挖起收集域名资产第一步不是枚举子域名而是先把目标根域名的基本信息搞清楚。根域名是主域名本身比如目标站点的主域名。拿到它之后先做一次DNS记录梳理。我常用的命令是dig比nslookup输出更清晰。看A记录、MX记录、NS记录、TXT记录几类就够了。# 查询A记录 dig A target-domain.com short # 查询MX记录看邮件系统指向哪里 dig MX target-domain.com short # 查询NS记录看DNS服务商 dig NS target-domain.com short # 查询TXT记录很多企业会留SPF和验证信息 dig TXT target-domain.com short为什么要查这些基础记录因为能帮你判断目标的技术背景。MX记录可能暴露邮件网关的提供商NS记录告诉你DNS托管在哪里TXT记录里偶尔会残留一些内部标识或第三方验证码。更重要的是这些记录本身能帮你快速判断后面拿到的新子域名有没有价值、是不是真实资产。另外也别忽视WHOIS信息虽然很多域名开启了隐私保护但历史WHOIS、注册邮箱在个别情况下还能看出一些关联资产线索。2.2 子域名枚举证书透明度和DNS爆破子域名是漏洞赏金里最核心的资产来源。主站防护通常做得严格但子域名里经常藏着测试环境、后台入口、API网关。枚举子域名的主流方式有三种证书透明度查询、DNS字典爆破、以及通过公开数据源汇总。证书透明度是我优先级最高的方式。因为任何站点要上HTTPS就得向CA机构申请证书而证书申请记录是公开的。通过证书日志就能找到大量曾经申请过证书的域名。常见做法是去crt.sh查询。# 用curl拉取crt.sh的结果并用jq解析 curl -s https://crt.sh/?q%25.target-domain.comoutputjson | jq -r .[].name_value | sed s/\*\.//g | sort -u这条命令会输出目标域名下所有关联的证书域名。我在实际使用中会并行查几次因为crt.sh偶尔响应慢或者少返回数据多试几次能把遗漏补回来。注意输出里可能包含通配符域名如“*.target-domain.com”清理掉星号再排序去重就行。DNS爆破则是拿一个常用子域名字典去猜。这种方式依赖字典质量好的字典应该包含常见业务场景词比如admin、test、dev、api、gateway、jenkins、gitlab、grafana、staging等。工具上我用subfinder做第一轮快速收集它的数据源多跑完基本能覆盖大部分常见子域名。2.3 把找到的子域名做去重和筛选枚举完子域名下一步不是急着访问而是先停止、去重、整理。这一步很多人忽略结果就是重复测试、漏掉资产。我会把所有域名汇总到一个文本文件排序去重然后做一次存活探测。# 合并所有子域名结果并去重 cat subfinder.txt crtsh.txt dnsbrute.txt | sort -u all_subs.txt # 用httpx探测存活Web服务 httpx -l all_subs.txt -ports 80,443,8080,8443 -title -status-code -follow-redirectshttpx的输出会直接列出哪些域名有HTTP响应、状态码是什么、标题是什么。这一条命令跑完你的测试范围就清晰了哪些子域名是存活的、哪些是纯内网域名、哪些已经不再解析。根据状态码还可以初步判断业务类型301跳转通常是域名迁移403可能是访问控制401则大概率有基础认证后面值得重点看。3. 从域名到IPCDN识别和真实IP排查3.1 域名解析与CDN判断子域名整理完之后把存活的域名解析到IP你就能看到目标的真实网络布局。解析可以用在线平台批量查也可以命令一行搞定但我更建议手动看几个关键域名因为里面有细节。# 批量解析域名对应的IP while read domain; do ip$(dig short $domain | grep -E ^[0-9]\. | head -1) echo $domain - $ip done all_subs.txt domain_ip.txt做完解析第一件事就是判断有没有CDN。方法很简单看同一个域名在不同地区解析出来的IP是不是一致。或者直接看响应头如果出现类似“x-cache: HIT”“via: 1.1 varnish”“CF-Cache-Status”这类字段基本可以判断前面有CDN。有一个基础判断原则CDN节点IP段往往比较固定而且解析出来的IP地理位置和目标服务器实际所在区域对不上。为什么识别CDN很关键因为在测试时打CDN节点和打源站完全是两回事。CDN会过滤掉大量攻击流量你看到的永远是缓存页面和通用错误页根本接触不到后端真实服务。而如果找到了源站真实IP可能直接访问到后台、绕过WAF、继续深挖漏洞。真实IP怎么找历史DNS记录、邮件头里的来源IP、多地区DNS解析对比都是常见思路。这里我强烈提醒一句整个过程必须在授权范围内未经授权的测试本身就是越界行为。3.2 端口扫描先快速发现再精准识别拿到IP列表后就该看端口了。我的习惯是先做一次全端口快速扫描定位开放端口再用慢速精准扫描去识别服务版本。不要一上来就对全部端口做完整TCP扫描那样耗时太长而且大量常规端口对你的测试没有帮助。先说快速发现我日常用的是masscan速度非常快适合大批量IP做端口地毯式探测。扫描要控制速率不能直接把目标网络打挂这是基本职业素养。# 快速全端口发现 masscan -iL ip_list.txt -p 1-65535 --rate 2000 -oJ masscan_output.jsonmasscan跑完很快但它只告诉你开放的端口不告诉你服务版本。所以下一步拿masscan的结果喂给nmap做精准识别。nmap的优势是有强大的指纹库可以通过banner和服务特征判断具体软件及版本号。# 根据masscan输出定向扫描开放端口 nmap -sC -sV -p 22,80,443,8080,8443,9000,3306,6379 -iL open_ips.txt -oN nmap_result.txt端口扫描会产出一批信息这时就要有筛选能力。我按优先级把端口分成几档Web服务端口80、443、8080、8443、8000、8888直接关联Web渗透优先级最高数据库端口3306、5432、6379、27017如果暴露在外网几乎等于送出高危漏洞远程管理端口22、3389、5900则需要识别是否存在弱口令可能其他非常规高位端口一旦开放通常代表业务系统自建服务更能出好东西。3.3 旁站和C段资产同一个IP上可能绑着很多不同域名这就是旁站。排查旁站的意义在于A站防护严格但和它共用一台服务器的B站可能很脆弱打穿B站之后横向渗透或者利用同权限环境A站也就守不住了。所以看到目标IP之后多看看这个IP还绑了哪些域名、这个IP所在的C端还存活了哪些其他IP。C段的判断没有多高深就是一个网段内的相邻IP。一般用在线资产测绘平台或者本地工具批量查询即可。但我想说一个经验不是每个C段都值得看。如果目标用的是云厂商的高防IP或负载均衡同一个C段里大概率全是其他无关客户的机器扫了意义也不大。要优先对待独立IP、传统机房IP的C段做延伸这类资产被忽视的概率更高。4. 识别Web指纹知道对方用的什么货4.1 HTTP响应头和页面特征判断技术栈Web指纹识别的目的是搞清楚Web服务背后的技术栈版本然后脑子里马上浮现出“这个版本有哪些已知弱点”。新手最容易忽略这一步直接拿目录扫描结果看一堆200和403却不知道每个页面背后的框架和语言是什么。先学会手工看响应头。浏览器F12切到网络面板随便访问一个目标页面点击请求记录查看响应头字段。“Server”字段直接告诉你Web服务器类型比如Apache、Nginx、IIS、Cloudflare。“X-Powered-By”字段如果配置没隐藏会直接暴露PHP版本或ASP.NET版本。“Set-Cookie”也能透露信息不同语言的SessionID命名规则不一样。比如某些Java应用的Cookie会带JSESSIONIDPHP应用通常带PHPSESSID。页面本身的特征也很重要。不同框架有默认的登录页结构、默认图标、固定路径名。比如某些后台系统默认就是“/admin/login”某些框架的报错页有特定布局和链接地址。我平时会把“系统名称 页面特征”一起记下来比单个字段准确得多。4.2 用工具批量识别指纹手工作业效率低批量资产自然要用工具。我常用whatweb做第一轮批量抓取它能把HTTP头、Cookie、页面关键字、框架特征整合输出速度快还不需要额外配置。# 批量识别Web指纹 whatweb -i alive_urls.txt --log-jsonwhatweb_result.json输出完看结果时重点看三类信息第一是Web服务器类型与版本第二是内容管理系统或开发框架比如出现WordPress、ThinkPHP、Spring Boot等关键特征第三是是否有安全设备特征例如出现WAF拦截页面特征。指纹识别阶段发现任何旧版本、停止维护的框架就应该立刻标记成高优先级资产紧接着去搜索对应版本公开漏洞。4.3 识别WAF和防护设备WAF识别可以单独拎出来说因为在做后续目录扫描和参数测试时判断当前是否被WAF拦截非常重要。你发送的请求一旦触发规则返回的页面可能是一张拦截页但新手常误以为自己找到了漏洞。识别WAF的手段有很多最简单的就是发一个明显的恶意测试请求比如在URL后面拼上常见的Payload特征看响应内容是不是出现拦截提示。工具方面wafw00f可以帮你做初步判断它通过识别响应头特征和页面内容来猜测WAF类型支持很多常见产品。但我自己用下来觉得工具判断只能当参考手工确认更靠谱。如果你发现目标存在WAF后续的目录扫描就应该降低并发速率并且考虑用更贴合业务场景的路径字典避免触发高频访问限制。另外WAF也有盲区——它对静态资源、对特定API接口的检测力度往往不同这也是后续测试时可以留意的点。5. 目录与敏感文件在目标身上翻翻口袋5.1 目录扫描的思路与参数选择域名、IP、端口、指纹都有了接下来做的事情是把Web应用内部的路由结构摸一遍。目录扫描虽然叫“目录”但实际上它是通过字典请求大量路径观察哪些路径返回有效状态码从而推断有哪些隐藏页面、备份文件、管理入口、API接口。我日常用ffuf或者dirsearch两者各有优势。dirsearch开箱即用字典体验好ffuf速度快可定制性更强适合和过滤规则搭配使用。不管选哪个参数上有一条核心建议不要一上来就开几百并发。很多WAF和运维监控对高频请求非常敏感扫到一半IP就被封了。我通常先用中等速率扫一轮静态字典再根据结果手动补几个业务路径。# ffuf目录扫描示例速率控制合理 ffuf -u https://target-domain.com/FUZZ -w dict.txt -t 50 -mc 200,301,403,401 -o ffuf_result.json关于状态码的解读说一下我自己的经验200当然是找到了页面301/302是跳转要跟着看看跳到哪里403可能是目录存在但不允许访问这种反而值得重点标注很多备份目录和管理路径就是403401代表有认证等于告诉你“这里有东西你还没权限进去”。有些框架对不存在的路径统一返回200此时需要对比页面内容长度找异常点。响应大小完全一样的“200”基本是通配响应可以过滤掉响应大小明显不同的200才是真正有价值的路径。5.2 历史快照和公开代码中的线索目录扫描只能看现状历史快照却能让你看到这个站点过去的样子。web.archive.org保存了大量网站的旧页面我经常在里面找到已经下线但仍有价值的路径、旧版JS文件、以及曾经暴露出的内部接口。一个接口以前存在不代表现在不存在很多开发只是把入口取消了后端功能还留着。做法很简单在archive.org上搜索目标域名按时间线逐条看旧快照重点抓取快照里的页面源代码和JS文件链接。JS文件往往是信息搜集的高价值目标里面经常硬编码API接口地址、内部请求路径、甚至是测试账号的线索。找到JS文件后我习惯用工具从中提取URL和敏感关键字。5.3 GitHub和网盘等公开渠道的搜索最后别忽略公开代码托管平台的搜索。很多程序员习惯把配置文件和代码推到公开仓库里面常常包含数据库连接串、API密钥、内部IP和域名。GitHub的代码搜索支持限定域名和路径的语法可以直接搜目标主域名。举个例子搜索目标主域名时加上扩展名限定能快速筛选出包含配置信息的文件。# GitHub代码搜索思路限定目标域名和常见敏感文件 site:github.com target-domain.com password site:github.com target-domain.com filename:config.php site:github.com target-domain.com filename:.env这条思路的意义在于你搜索的不是目标网站本身而是目标公司员工公开发布过的代码。如果发现什么敏感信息第一时间截图并记录来源然后走目标SRC的合法反馈渠道。我想强调公开渠道搜集信息也必须在授权范围内使用不能拿着找到的信息去做未授权操作。6. 把信息整理成资产清单——这是很多高手爱做却不讲的细节6.1 资产清单的整理模板信息搜集做到这一步你手里可能有几百个子域名、几十个IP、几千个端口和指纹数据。但这些都是原材料不整理就是一堆数字。一个合格的赏金猎人必须能把原材料加工成一份可以直接指导测试的资产清单。我会用表格来管理字段包括域名、IP、端口、服务、Web指纹、备注、优先级。整理顺序按优先级排高优先级的放最上面。我的资产清单大致长这样域名IP端口服务指纹优先级备注admin.target-domain.com10.0.0.8443HTTPS某后台框架高401认证test.target-domain.com10.0.0.128080HTTPNginx Java高测试环境static.target-domain.com10.0.0.580HTTPApache低CDN节点api.target-domain.com10.0.0.98443HTTPSSpring Boot高存在API文档不要小看这个整理过程。你会发现很多人在测试时东看一眼西看一眼就是因为没有资产清单导致思路混乱。有了清单你的测试顺序就有了优先从“高优先级 已确认技术栈版本”的资产开始。我个人习惯配合一个笔记软件整理每条资产下面挂上截图、请求包、发现时间后面写报告的时候直接调用效率高很多。6.2 优先级怎么判断优先级不是拍脑袋要基于几个明确信号来判断。第一技术栈版本是否老旧。旧版本框架通常有公开漏洞优先级直接拉高。第二是否属于测试环境、后台入口、API网关。这类资产防护往往弱于主站。第三是否已出现401、403这类访问控制提示说明存在“未授权”的可能性。第四是否处于CDN或WAF保护范围内。没保护的直接IP和端口测试阻力小价值高。第五是否出现非常规高位端口和数据库端口这类一旦弱口令收益极大。还有一个我常用的优先级信号服务是否包含文件上传功能。凡是出现上传点、导入导出功能、富文本编辑器的资产我都会额外加一颗星。文件上传类漏洞杀伤力大而且经常出现在后台、旧系统中。6.3 信息搜集的边界与合规备注这一节我说几句实在话。做信息搜集和漏洞赏金必须始终在授权范围内开展。目标有没有SRC项目、测试范围包含哪些域名和IP、授权有效期到什么时候这些信息开工前就要确认清楚。未授权扫描、未授权测试不但违背平台规则也可能撞上法律红线。哪怕你是为了提升技术也请一定合法合规。很多公开的漏洞赏金项目会在页面上写明测试范围跟着范围走才能玩得长久。7. 常见问题与排查技巧实录7.1 信息搜集常见问题速查表这部分我整理了一下在自己的踩坑经历中反复出现的几个问题按“问题、原因、解决办法”列个表方便你对照排查。问题常见原因解决办法子域名枚举结果很少字典太小、数据源没配置完整换大字典配全被动数据源多查几次证书透明度域名解析出来的IP全是CDN目标所有流量都走CDN查历史DNS、邮件头、部分旧子域名的解析记录端口扫描结果多到离谱没有先区分目标业务类型先看Web端口和管理端口再按服务名称筛选目录扫描全是200但内容都一样框架统一返回200通配响应对比响应长度过滤掉通配响应whatweb识别不出指纹响应头配置严格隐藏明显特征手工看页面源码、Cookie命名、JS框架特征访问目标突然跳验证码请求频率太高触发防护降并发、加延时、减少同一时刻的扫描范围扫出来的资产太多不知道测哪个没有做优先级排序按版本老旧、后台入口、测试环境、WAF绕过情况分层排序7.2 两个值得反复体会的经验第一个经验信息搜集的“度”比“量”更重要。工具能扫出一千个资产但你的精力只够深测二十个。宁可花时间把二十个高价值资产测透也不要在一千个低价值资产上空转。我见过很多人信息搜集做了几天手里一堆数据真正开工测试时却毫无头绪就是因为“量大但没筛选”。每跑完一个工具都做一次整理标注优先级把工具输出变成决策依据。第二个经验记录越权越好。这里的“越权”不是指越权漏洞而是指越权记录一切看起来不寻常的信息奇怪的请求参数、异常的响应头、非标端口上的服务、旧的API版本。这些信息单独看可能没用但到了利用阶段可能正好是绕过防护的关键。我后来翻自己挖洞成功案例发现不少突破口都来自信息搜集阶段记录的某个“不起眼的小细节”。不要嫌麻烦第一次扫描后的记录很可能就是最终报告的起点。8. 结尾从清单到测试的一步之遥信息搜集不是一个可以跳过的阶段也不是一个能一步到位的阶段。我个人的体会是第一次做尽调时不用想着做得“完美”先跑通流程理解每个工具输出的含义然后把资产清单建起来就已经赢过大部分新手了。后面的测试、利用都建立在这张清单上。如果这一篇看懂了建议你立刻找一个授权目标练手。先跑子域名再解析IP再扫端口再做指纹然后整理成清单。等你完整走完一轮就会发现自己对“目标”的理解完全不一样了。下一篇我会接着写信息搜集的进阶部分包括JS文件深挖、API资产识别、以及基于指纹的漏洞快速匹配思路到时再聊。