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

信息搜集做得好不好，直接决定你后面能不能挖到洞。很多人兴致勃勃报名漏洞赏金，上来就去点目标网站，结果点半天什么都没发现，就觉得是自己技术不行。其实问题根本不在技术，而在信息搜集这一步没做扎实。目标有哪些域名、哪些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.com&output=json" | 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-redirects

httpx的输出会直接列出哪些域名有HTTP响应、状态码是什么、标题是什么。这一条命令跑完，你的测试范围就清晰了：哪些子域名是存活的、哪些是纯内网域名、哪些已经不再解析。根据状态码还可以初步判断业务类型，301跳转通常是域名迁移，403可能是访问控制，401则大概率有基础认证，后面值得重点看。

3. 从域名到IP：CDN识别和真实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.json

masscan跑完很快，但它只告诉你开放的端口，不告诉你服务版本。所以下一步拿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会带JSESSIONID，PHP应用通常带PHPSESSID。

页面本身的特征也很重要。不同框架有默认的登录页结构、默认图标、固定路径名。比如某些后台系统默认就是“/admin/login”，某些框架的报错页有特定布局和链接地址。我平时会把“系统名称 + 页面特征”一起记下来，比单个字段准确得多。

4.2 用工具批量识别指纹

手工作业效率低，批量资产自然要用工具。我常用whatweb做第一轮批量抓取，它能把HTTP头、Cookie、页面关键字、框架特征整合输出，速度快还不需要额外配置。

# 批量识别Web指纹 whatweb -i alive_urls.txt --log-json=whatweb_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可能是目录存在但不允许访问，这种反而值得重点标注，很多备份目录和管理路径就是403；401代表有认证，等于告诉你“这里有东西，你还没权限进去”。有些框架对不存在的路径统一返回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指纹、备注、优先级。整理顺序按优先级排，高优先级的放最上面。

我的资产清单大致长这样：

不要小看这个整理过程。你会发现，很多人在测试时东看一眼西看一眼，就是因为没有资产清单导致思路混乱。有了清单，你的测试顺序就有了：优先从“高优先级 + 已确认技术栈版本”的资产开始。我个人习惯配合一个笔记软件整理，每条资产下面挂上截图、请求包、发现时间，后面写报告的时候直接调用，效率高很多。

6.2 优先级怎么判断

优先级不是拍脑袋，要基于几个明确信号来判断。第一，技术栈版本是否老旧。旧版本框架通常有公开漏洞，优先级直接拉高。第二，是否属于测试环境、后台入口、API网关。这类资产防护往往弱于主站。第三，是否已出现401、403这类访问控制提示，说明存在“未授权”的可能性。第四，是否处于CDN或WAF保护范围内。没保护的直接IP和端口，测试阻力小，价值高。第五，是否出现非常规高位端口和数据库端口，这类一旦弱口令，收益极大。

还有一个我常用的优先级信号：服务是否包含文件上传功能。凡是出现上传点、导入导出功能、富文本编辑器的资产，我都会额外加一颗星。文件上传类漏洞杀伤力大，而且经常出现在后台、旧系统中。

6.3 信息搜集的边界与合规备注

这一节我说几句实在话。做信息搜集和漏洞赏金，必须始终在授权范围内开展。目标有没有SRC项目、测试范围包含哪些域名和IP、授权有效期到什么时候，这些信息开工前就要确认清楚。未授权扫描、未授权测试，不但违背平台规则，也可能撞上法律红线。哪怕你是为了提升技术，也请一定合法合规。很多公开的漏洞赏金项目会在页面上写明测试范围，跟着范围走，才能玩得长久。

7. 常见问题与排查技巧实录

7.1 信息搜集常见问题速查表

这部分我整理了一下在自己的踩坑经历中反复出现的几个问题，按“问题、原因、解决办法”列个表，方便你对照排查。

7.2 两个值得反复体会的经验

第一个经验：信息搜集的“度”比“量”更重要。工具能扫出一千个资产，但你的精力只够深测二十个。宁可花时间把二十个高价值资产测透，也不要在一千个低价值资产上空转。我见过很多人信息搜集做了几天，手里一堆数据，真正开工测试时却毫无头绪，就是因为“量大但没筛选”。每跑完一个工具，都做一次整理，标注优先级，把工具输出变成决策依据。

第二个经验：记录越权越好。这里的“越权”不是指越权漏洞，而是指越权记录一切看起来不寻常的信息：奇怪的请求参数、异常的响应头、非标端口上的服务、旧的API版本。这些信息单独看可能没用，但到了利用阶段，可能正好是绕过防护的关键。我后来翻自己挖洞成功案例，发现不少突破口都来自信息搜集阶段记录的某个“不起眼的小细节”。不要嫌麻烦，第一次扫描后的记录，很可能就是最终报告的起点。

8. 结尾：从清单到测试的一步之遥

信息搜集不是一个可以跳过的阶段，也不是一个能一步到位的阶段。我个人的体会是，第一次做尽调时不用想着做得“完美”，先跑通流程，理解每个工具输出的含义，然后把资产清单建起来，就已经赢过大部分新手了。后面的测试、利用，都建立在这张清单上。

如果这一篇看懂了，建议你立刻找一个授权目标练手。先跑子域名，再解析IP，再扫端口，再做指纹，然后整理成清单。等你完整走完一轮，就会发现自己对“目标”的理解完全不一样了。下一篇我会接着写信息搜集的进阶部分，包括JS文件深挖、API资产识别、以及基于指纹的漏洞快速匹配思路，到时再聊。