失眠数羊做进攻性安全这一行，接到一个授权评估任务之后，我最先做的事往往不是打开扫描器，而是先把侦察和情报收集这一步做透。回头看这些年参与的评估项目，凡是前期侦察做得扎实的，后面漏洞挖掘和利用几乎是水到渠成；凡是草草拿工具扫一轮就开工的，大概率会在中途发现目标资产跟想象中完全不一样，再回头补数据，浪费时间不说，还容易漏掉真正关键的攻击面。“侦察和情报收集的进攻性安全工具”这句话，听起来像是某个工具仓库的一句话简介，但它背后涵盖的其实是整个渗透测试流程里最考验耐心、也最体现功力的阶段。这篇文章就围绕这个主题，把我自己日常在授权测试中常用的侦察思路、工具组合、情报收集维度以及踩过的坑系统梳理一遍，给准备往红队方向走的朋友，或者需要完善防御体系的蓝队同学一个可直接参考的路线。
1. 进攻性安全里的侦察，到底在解决什么问题
1.1 侦察在攻击链路中的位置
一次标准的授权渗透测试，流程大致是：范围界定、情报收集、漏洞发现、漏洞利用、内网横向、痕迹清理、报告输出。侦察和情报收集排在第二位，但它不是一次性动作，而是会贯穿后续阶段的持续任务。
很多人对侦察的理解停留在“扫端口、跑目录”这一步，但实际上侦察的核心目的是回答三个问题：目标有哪些资产、这些资产暴露了哪些服务、这些服务背后藏着哪些可利用的信息。这三个问题的答案，直接决定了后续攻击路径的规划。
举个例子，一个看似防护严密的主站，可能跑着WAF、装了主机加固、做了全量补丁。但在侦察阶段如果发现某个老旧的子域绑定在一个已被遗忘的测试服务器上，而这个子域还能解析到内网IP段，那这条路径的价值往往比硬刚主站高得多。这就是为什么说，侦察不是体力活，而是整个攻击链里最需要动脑子的部分。
1.2 被动侦察与主动侦察的分工
侦察手段通常分成被动和主动两类，我习惯把这两者理解成不同阶段的组合拳。
被动侦察是指不直接向目标系统发探测包，而是利用公开信息、第三方平台、历史数据来勾勒目标画像。比如证书透明性日志查询子域、通过搜索引擎和网盘搜索找文档、在代码托管平台搜索目标相关的泄露代码片段、通过DNS历史记录看曾经的解析记录。被动侦察的优势是隐蔽、不容易触发目标侧的告警，也适合在正式测试开始前做一轮摸底。
主动侦察则是直接与目标系统交互，比如端口扫描、服务识别、目录爆破、Web指纹识别。这些操作会产生大量访问日志，所以一定要在拿到授权、且明确测试时间窗口之后再做。主动侦察的数据更准确，但也更容易暴露身份和意图，需要控制节奏和频率。
两类的顺序也值得讲究。我通常先把被动侦察能拿到的信息全部落地，形成一份初步的资产表；然后基于这份资产表做主动验证，避免盲扫浪费时间和流量。
1.3 为什么侦察质量决定项目成败
有句话说得好：比别人更早找到目标在互联网上的每一个脚跟，你就已经赢了一半。进攻性安全的核心优势从来不在于某一个0day，而在于信息差。目标自己都不记得的资产，恰好是我们最容易突破的地方。
侦察阶段收集到的每一条信息，都是后续工具的输入。子域清单是目录爆破和指纹识别的起点，端口和服务版本决定了漏洞利用方向，Web技术的指纹决定了要挂哪些漏扫插件和利用EXP，人员信息则可能成为钓鱼测试的素材。这些数据一环扣一环，某一环缺失，整个链条就可能断掉。
我见过不少项目，漏洞扫描器跑得轰轰烈烈，结果输出的报告里一半资产是CDN节点的IP、三分之一是测试环境的星星点点、真正生产环境的有效资产反而被淹没在噪声里。这种问题几乎都是前期侦察图省事埋下的雷。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 侦察工具箱：常用的工具与选型逻辑
2.1 资产枚举三件套：Amass、Subfinder、OneForAll
子域名收集是侦察阶段的第一项硬任务。市面上工具很多，我常用的三个是Amass、Subfinder和OneForAll，它们各有侧重。
Amass是一款老牌工具，集成了大量被动数据源和主动枚举能力。它的优势在于数据源丰富、支持自定义API、输出格式规范。缺点是比较吃配置，如果数据源API key填得少，效果会打折扣。实际使用中，我一般先跑被动模式，再根据目标重要程度决定要不要跑主动枚举：
bash复制# 子域名被动收集
amass enum -passive -d example.com -config config.ini -o sub_passive.txt
# 子域名主动暴力枚举（配合字典）
amass enum -active -d example.com -wordlist subdomains_top5000.txt -o sub_active.txt
Subfinder则更加轻量，启动快、依赖少，尤其适合在信息收集初期快速拿到一张子域列表。它同样支持多数据源，配合API key用起来效率很高：
bash复制subfinder -d example.com -all -recursive -o subfinder_result.txt
OneForAll是国内团队维护的综合性子域收集工具，它在处理国内资产时对某些数据源的适配更好，输出的表格也很清晰，会标出解析IP、是否CDN、是否存活等信息。
三个工具的结果会有交集也会有差异，我习惯的做法是把它们的结果合并起来排序去重，再用下面的方式做一次验证。
2.2 存活探测与端口扫描的分工
拿到大量子域和IP之后，不能直接开始扫端口，那样效率太低。先做存活探测，把真正在线的资产过滤出来，再针对存活资产做端口扫描。
存活探测我用httpx和fping配合。httpx主要针对Web资产，速度快，能同时输出响应码、标题、Server头、检测到的技术栈：
bash复制# 对子域列表做Web存活探测
httpx -l all_subdomains.txt -title -tech-detect -status-code -follow-redirects -o alive_http.txt
端口扫描方面，Nmap是当之无愧的主力。不过Nmap在全网大段扫描时效率是短板，所以我习惯用Masscan做快速端口发现，再用Nmap对开放端口做服务和版本识别。两条命令配合起来，既保证速度又保证精度：
bash复制# 快速端口发现
masscan -iL ip_list.txt -p1-65535 --rate 2000 -oG masscan_output.gnmap
# 对发现的主机进行服务和版本探测
nmap -sS -sV -O -iL alive_ips.txt -p 80,443,22,3389,8080,8443,9000 -oA nmap_result
这里有个细节：Masscan的高速扫描在跨网段扫描时容易产生误报和丢包，特别是网络质量不稳定的时候。所以Masscan发现开放端口后，一定要用Nmap的TCP连接扫描或SYN扫描再做一次确认，不要直接信任Masscan的结果。
2.3 Web指纹识别与目录爆破
Web资产确认存活之后，下一步是识别Web中间件、框架、开发语言和后端组件。指纹信息决定了后续漏洞测试的方向。比如识别出是ThinkPHP，就该往框架漏洞的方向测试；识别出是Spring Boot，则要关注Actuator泄露、SpEL注入这些方向。
指纹识别我常用httpx的tech-detect参数先跑一轮，再用WhatWeb和浏览器插件Wappalyzer做辅助确认。对于复杂站点，我会直接看响应头和首页源码里的特征字段。
目录爆破是另一个重要环节。工具上ffuf和gobuster是我的首选。ffuf的灵活性和速度都很出色，配合规范的字典可以快速跑出结果：
bash复制# 目录爆破
ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dir.txt -mc 200,204,301,302,307,401,403 -t 50 -o ffuf_result.json
# 备份文件、源码泄露探测
ffuf -u https://example.com/FUZZ -w backup_files.txt -mc 200 -t 30
字典的选择对目录爆破效果影响极大。我自己的习惯是准备几类字典：通用的小字典（针对快速验证）、大字典（针对深度测试）、以及针对国内常用命名习惯的字典（比如包含拼音、年月日组合的备份文件名）。
2.4 在线情报平台：搜索语法比工具本身更重要
除了本地工具，在线情报平台也是侦察的重要助力。Shodan、Censys、FOFA这类网络空间测绘平台，可以帮我们快速找到目标暴露在互联网上的特定服务。这些平台的价值不只是“搜IP”，更重要的是它们积累了大量历史数据，可以帮我们发现目标过去暴露过什么端口、跑过什么服务、绑过什么证书。
实际使用中，我常用的搜索思路有这么几类。按组织名搜资产：org:"Example Corp"；按证书搜域：ssl.cert.subject.cn:"example.com"；按图标哈希搜：http.favicon.hash:xxx——这个方法在找同一个组织下图标相同但域名不同的资产时特别有效。
还有一类平台是证书透明性日志查询，比如crt.sh和Censys的证书查询。这是被动收集子域名的宝库，因为很多管理员配置证书时会一次性申请很多子域，这些子域往往没有全部在DNS解析中暴露，但证书日志里全部看得到。
3. 情报收集的核心维度：构成完整的攻击面拼图
3.1 域名与子域名的层层展开
侦察的第一层拼图是域名和子域名。很多人以为拿到主域名就能扫描了，实际上主域名只是冰山一角。
子域名的来源主要有几个渠道：证书透明性日志、DNS历史记录、公开的DNS数据集、搜索引擎缓存、以及前面提到的暴力枚举。不同渠道的结果有大量重合，但每个渠道都有一些独有发现。
在处理子域列表时，有一个常见陷阱：泛解析。有些目标会配置*.example.com的DNS记录，指向同一个IP。这种情况下，随便猜一个不存在的子域名也能解析成功，干扰判断。我处理泛解析的方式是，对子域列表里的每个域名解析出来的IP做一次去重，如果一个IP下面挂了特别多子域，而这个IP的Web服务又不是典型的虚拟主机配置，那很可能命中了泛解析，需要进一步验证。
3.2 IP与端口：从开放服务到漏洞入口
在IP和端口层面，我更关注的是服务版本。同样的端口，跑的是Apache 2.2还是Nginx 1.18，安全性完全不一样。Nmap的-sV参数配合版本检测库可以做到这一点，但有些服务会隐藏真实版本号，这时候可以通过响应头的细微差异来判断。
这类情况往往是测试周期内时间消耗最大的环节。更需要注意的是一些容易被忽略的服务，比如Redis、MongoDB、Memcached这类未授权漏洞大户。端口扫描时，除了常见的Web端口，6379（Redis）、27017（MongoDB）、11211（Memcached）、9200（Elasticsearch）这些端口一旦暴露，就是高风险信号。
还有一个经验是关注CDN背后的真实IP。很多站点在前面套了CDN，直接扫描域名解析到的IP只能扫到CDN节点。找真实IP的方法不少：查历史DNS记录看CDN接入之前的解析结果、发现多个子域中某个没走CDN的源站IP、借助证书透明性和SSL证书扫描找到源站证书、利用邮件服务器的SPF记录或者历史邮件头里的源IP。
3.3 Web应用层的情报细节
Web应用层的侦察，不只是跑一遍目录爆破就完事。我更关注几个具体方向：登录接口在哪里、有没有注册功能、API接口文档是否暴露、是否存在调试模式、错误页面是否泄露堆栈信息。
举个例子，很多站点会在robots.txt或注释里泄露后台路径，或者开发者在调试阶段打开了某个接口，上线时忘了关。这类信息往往不需要多么高超的技术就能发现，但价值极高。我习惯在拿到一份Web资产后，先手工看一遍首页源码，再跑自动化工具，顺序不能反过来。
另外，Web应用的版本信息分布在各处：响应头、页面底部的版权信息、静态资源的生成时间戳、第三方组件的版本号。这些东西单个看都不起眼，但汇总起来能拼出一个很清晰的技术栈画像。
3.4 组织与人员维度的OSINT
进攻性安全不只是跟机器打交道，很多时候也要跟人打交道。组织维度的信息包括组织架构、分支机构名称、供应商名单、控股关系——这些信息能帮我们扩展资产搜索的范围。比如某个大集团下面有很多子公司，子公司的域名和资产可能就不在最初的范围清单里，但它们往往是同一套IT团队在维护，安全水位参差不齐。
人员维度的信息则更多服务于社工测试：员工姓名、职位、联系方式、社交账号、个人技能栈。这些信息的收集途径基本都是公开渠道：公司官网团队介绍、招聘信息、技术博客、社交媒体公开主页。我特别关注的是招聘信息，因为招聘信息会直接暴露企业的技术栈：招Java开发说明后端是Java体系，招Kubernetes运维说明有容器化环境，招DBA说明数据库规模不会小。
这里必须插一句：情报收集的所有动作，都必须在授权范畴内进行。尤其涉及个人信息时，要把握分寸，只收集与测试目标直接相关、且通过完全公开渠道能获得的信息。这是职业底线。
4. 从情报到攻击面的分析转化
4.1 攻击面的优先级排序
情报收集不是把所有数据堆在一起就结束了，真正的价值在于分析和转化。我会把收集到的资产和信息做一个攻击面优先级排序。
第一优先级是“直接可利用”的：开放了未授权访问的Redis、存在高危版本漏洞的Web组件、暴露了管理后台且可尝试弱口令的登录页。第二优先级是“需要深入测试”的：业务逻辑复杂的核心应用、存在文件上传功能的模块、API接口文档可访问的微服务。第三优先级是“暂时用不上但要记录”的：存活的子域、历史解析记录、组织人员名单。
这个排序不是一劳永逸的，随着测试推进，很多原本排第三的资源会因为其他突破口而升级。保持动态更新的习惯很重要。
4.2 资产去重与数据规范化
侦察过程中收集到的数据来自多个渠道，格式五花八门。如果不在这一阶段做数据清洗，后续所有工具跑起来都会被各种脏数据拖慢速度。
我的标准化做法是：域名统一转小写、去除非ASCII字符；IP地址统一用标准格式，去掉前导零；URL统一加上协议头；CDN资产的直接解析IP和源站IP分开记录；每条数据尽量保留来源，方便回溯。
去重的规则也要想清楚。比如判断两个子域是不是同一个资产，不能只看域名，还要看解析到的IP、Web指纹、标题信息。有些子域看上去名字不同，实际上指向同一个应用的不同入口，这种信息如果不去重，会在后续测试中造成重复劳动。
4.3 侦察报告与过程留痕
这一节讲的是容易被新人忽略但非常重要的习惯：过程留痕。
整个侦察阶段产生的命令、数据、中间结果，我是建议全部保留的。一方面，项目周期往往有好几周，前期收集到的数据如果不归档，后面要用的时候找不到，只能重跑，非常浪费；另一方面，最终的测试报告需要证据链支撑，侦察阶段的数据也是证据的一部分。
我自己是每个项目的根目录下建几个固定文件夹：raw（原始数据）、processed（清洗后的数据）、screenshots（关键页面截图）、commands（执行过的命令记录）。命令记录我会直接保存history或者把命令写入一个md文件，方便后面写报告时引用。
5. 一个完整的侦察实操流程案例
5.1 场景设定与前置条件
这里我完整跑一遍侦察流程，用一个广义的测试域来演示（实际测试中拿到授权的目标，流程是一致的）。
假设我们拿到一个授权测试目标：example.com。前置条件：已获得书面的授权许可，测试时间窗口两周，允许主动扫描但要求避免影响业务稳定性。
先说合规：没有授权的目标，无论处于什么测试阶段，都不可以动。这是行业铁律，没有例外。
5.2 第一步：被动情报收集
先收集所有不直接触碰目标的信息。
第一个动作是查证书透明性日志：
bash复制curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u > ct_subdomains.txt
然后是Subfinder和Amass的被动模式：
bash复制subfinder -d example.com -all -recursive -o subfinder.txt
amass enum -passive -d example.com -o amass.txt
合并去重：
bash复制cat ct_subdomains.txt subfinder.txt amass.txt | sed 's/*.//' | sort -u > passive_subs.txt
接着在Shodan和FOFA上搜索目标组织相关信息。Shodan可以搜org:"Example Inc."查看该组织暴露的所有服务；FOFA可以搜domain="example.com"查看子域与绑定情况。这些在线数据导出后，和本地工具的结果合并。
5.3 第二步：存活探测与Web指纹
对合并后的子域列表做解析和存活验证：
bash复制# 批量解析子域
dnsx -l passive_subs.txt -a -resp -o resolved_ips.txt
# 从解析结果里提取IP，去重
awk '{print $2}' resolved_ips.txt | sort -u > ip_list.txt
# HTTP存活探测
httpx -l passive_subs.txt -title -tech-detect -status-code -follow-redirects -o alive_http.txt
到这一步，我们已经有了存活Web资产列表、每个站点的状态码、标题和技术栈。看这个文件时，我会先关注那些状态码是200但标题很奇怪的站点，以及技术栈里出现老版本组件的站点。
5.4 第三步：端口扫描与服务识别
对IP列表做端口扫描。这里先快速全端口发现，再对开放端口做服务识别：
bash复制# 快速全端口发现
masscan -iL ip_list.txt -p1-65535 --rate 2000 -oG masscan.gnmap
# 从masscan结果提取开放端口
grep "open" masscan.gnmap | awk '{print $2 " " $4}' | sed 's#/open.*##' > open_ports.txt
# 对特定服务的端口做详细识别
nmap -sS -sV -sC -iL ip_list.txt -p6379,27017,11211,9200,5432,3306,3389,22,80,443,8080,8443 -oA nmap_detail
重点关注的服务包括：Redis 6379、MongoDB 27017、Elasticsearch 9200、PostgreSQL 5432、MySQL 3306、RDP 3389。这些服务一旦直接暴露，且未授权访问测试很快能出结果，可以极大提升测试效率。
5.5 第四步：Web目录与敏感文件探测
针对确认存活的Web站点，逐个进行目录爆破和敏感文件探测。优先测API域名、管理后台域名和带test、dev、staging字样的子域。
bash复制# 对重点Web资产做目录爆破
ffuf -u https://target.example.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -mc 200,204,301,302,307,401,403 -t 50
# 敏感文件探测
ffuf -u https://target.example.com/FUZZ -w sensitive_files.txt -mc 200 -t 30
敏感文件字典一般包括：.git/config、.svn/entries、WEB-INF/web.xml、backup.zip、www.zip、.env、phpinfo.php等。
5.6 第五步：数据汇总与攻击面评估
将所有结果汇总，形成一份资产清单。字段包括：子域、解析IP、是否CDN、Web状态码、Web技术栈、开放端口、服务版本、指纹信息、备注。
这份清单就是后续漏洞测试的核心输入。基于它，可以快速筛选出高危目标：跑着老版本组件的、暴露管理端口的、存在未授权服务且公网可达的。这些就是整个侦察阶段的劳动成果。
6. 侦察阶段的高频问题与避坑技巧
6.1 为什么不同工具收集到的子域差异这么大
不同工具的数据源不一样，更新频率也不一样。同一个子域，有的数据源有缓存、有的已经删了，这很正常。解决方式很简单：多工具合并、多源交叉、别只依赖某一个工具。
另外，证书透明性日志的解析结果可能会有大量历史域名，这些域名可能已经不再解析。所以子域收集之后一定要做解析验证，不能把查到的都当成当前有效资产。
6.2 主动扫描触发告警怎么办
主动侦察一定会留下日志。触发了目标的安全设备告警，不代表测试就得停，但要做节奏上的调整。
常用的策略是控制扫描速率。Masscan的rate不要开太高，Nmap加--min-rate和--max-rate控制速度；目录爆破的并发线程调低一些；扫描时段分散开，避免短时间集中在同一IP段。另外，可以把不需要识别版本的端口单独扫，减少服务指纹识别带来的强交互请求。
6.3 如何区分CDN节点和真实源站
这个问题几乎是每次侦察都会遇到的。CDN节点IP的特征是：代理了很多域名、响应头部带CDN厂商标识、端口开放规律异常（比如80/443以外的端口几乎不开放）。
我的处理方式是先做一轮CDN标记，再用多种方式尝试找源站。比如通过DNS历史记录看CDN接入前的解析、通过子域中的非CDN资产反向分析、通过SSL证书扫描找到源站证书、触发目标主动发送邮件后查看邮件头里的源IP。
6.4 数据太多看不出重点怎么办
侦察阶段最怕的不是数据少，而是数据多到无法决策。几千个子域、几万个端口、上百个Web应用，一个一个测根本不可能。
我的建议是强制做优先级过滤。先只看有Web服务的资产；Web资产里先看状态码200的；200的资产里先看技术栈老旧的。这个漏斗下来，剩下的资产数量就非常可控了。
6.5 关于报告产出的一项提醒
侦察阶段的所有发现，最终都会写进测试报告。而有攻击面的信息，也是防守方需要知道的信息。所以侦察报告不只是列出资产，还要标注每个资产的风险倾向和建议关注的方向。
尤其是企业内部的蓝队同学，完全可以参考这套侦察思路来做“以攻促防”：如果攻击者能通过公开信息找到你的这些暴露资产，你自己也应比攻击者更早发现它们，并在测试授权范围内提前整改。
最后再多说一句：工具是死的，思路是活的。相同的一堆工具，不同的人用，产出的价值可能天差地别。我见过有人把Amass跑完一遍就觉得自己已完成信息收集，但真正的侦察不只是“能扫的都扫一遍”，而是把每一层数据像拼图一样拼起来，从域名到IP到端口到Web应用到人，把所有碎片连成一条可走通的路。这种能力不靠某一个工具，而靠你对数据背后逻辑的敏感度——这也是进攻性安全里最值得花时间打磨的部分。希望这篇文章的路线和经验，能让你少走点弯路，把侦察这一步真正做成后续所有动作的坚实底牌。