很多人以为进攻性安全项目的开场是端口扫描但真正决定一场授权测试上限的往往是侦察和情报收集阶段。侦察Reconnaissance不是扫描之前的“准备工作”它本身就是整个攻击链里最核心的决策环节。这篇文章基于我在多个授权项目里的实际经历把侦察和情报收集的完整思路、工具组合、节奏控制以及常见误区拆开讲一遍适合刚接触渗透测试的入门者也适合正在做红队对抗或企业防御侧暴露面管理的人参考。1. 侦察在进攻性安全里的真正位置不是“准备阶段”是决策阶段1.1 一次授权测试里侦察到底占多少时间先回答一个我经常被问到的问题侦察占整个项目多少时间这个比例比你想象的高得多。在一般众测平台或者中小企业授权评估里目标范围通常是几个域名加一个IP段测试周期大概一周左右。这种情况下侦察阶段往往占掉两到三个工作日比例接近30%。如果是红队演练或者大型企业整体评估侦察的时间占比会直接拉到50%往上。我参与过的一些对抗性项目前面整整三到五天基本不会发起任何“像样的攻击动作”所有人都在盯情报解析记录、资产归属、员工信息、技术栈版本、历史遗留系统——这些东西不摸清楚后面每一步都是盲打。为什么侦察这么耗时因为“扫”永远比“判断往哪里扫”快。Nmap全端口扫一个大网段可能只需要几十分钟但从几千条结果里判断出哪台机器值得动手、哪条路径是真实可达的、哪个系统大概率存在可利用缺陷这才是真正花时间的部分。还有一个容易被忽略的点侦察不是一次性的。现代企业的网络环境每周都在变新子域可能上线、旧证书可能会更新、员工可能在代码仓库里留下新痕迹。所以我在项目里通常把侦察做成一个持续运转的流程。第一天先做全量摸底之后每天开工前花半小时到一小时做增量信息收集看看有没有新出现的域名、新开的端口、新暴露的接口。这不是强迫症是因为很多突破口恰恰出现在你做完初始侦查之后的“增量”里。1.2 侦察质量与最终结果之间的三条因果链很多人对侦察有个误解觉得它只是“多收集点信息”对最终能否拿到权限影响不大。我从自己的项目经验出发总结出三条因果链你会发现侦察质量几乎决定整个项目的上限。第一条因果链侦察决定攻击面的宽度。同一个目标企业有人只拿到三个主域名就开始扫描有人通过证书日志、DNS历史和代码搜索挖出了三十个子域和十几个办公系统。后者的候选入口数量是前者的十倍哪怕单个入口成功率不高总数摆在那里项目结果就会有本质区别。很多测试做到最后没思路回头一看问题不是出在利用阶段而是子域枚举和IP关联根本没做全。第二条因果链侦察决定可利用漏洞的命中率。一个大型目标可能有上千台对外开放的主机如果目标是一台运行着老版本Tomcat的开发服务器漏洞利用的成功率和一台打了全部补丁的Nginx生产服务器完全不同。情报准确可以直接把火力集中到最薄弱的那几个系统上没有情报就只能靠端口扫描结果去撞运气效率低而且大概率打不下来。第三条因果链侦察决定暴露风险。在真实攻防对抗中蓝队会盯着异常流量、扫描日志和DNS请求记录。你前期探测的“噪音”越大被拦截和溯源的概率就越高。所以红队场景下的侦察有一个基本原则先被动、后主动能用公开数据源解决的问题绝不用扫描器去碰目标。这条纪律直接决定你后面能“活着”打多久。这里再补充一句题外话侦察思路不只对攻击方有用。企业防御团队完全可以按照同样的流程做一次“反向侦察”把自己当攻击者把公司所有公开资产摸一遍往往能找到大量被遗忘的域名、暴露的管理后台和员工无意间泄露的代码片段。这就是现在业界常说的攻击面管理本质上就是侦察方法论在防御侧的落地。2. 被动情报先行不触碰目标也能拼出完整攻击面2.1 主域、子域与IP归属证书、DNS历史和ASN的配合被动侦察的第一原则尽量不直接触碰目标甚至不让目标产生一条日志。这个阶段依赖的是公开数据源和第三方记录。拿到授权范围里的根域名之后我习惯先做一轮域名维度的信息拉取。手段包括查询注册信息whois获取注册邮箱、注册商和更新日期查询该域名的历史解析记录看它曾经解析到过哪些IP通过证书透明度日志Certificate Transparency搜索该根域下所有签发过证书的子域名。这里重点说一下证书透明度日志。这项机制本意是让CA签发的每一个证书都被公开记录方便安全审计但客观上它成了子域名枚举的宝库。因为很多企业申请证书时会把内部系统的主机名放进证书里比如vpn.company.com、gitlab.internal.company.com一旦证书签发这个域名就会被永久记录在公开日志里。我用crt.sh这类在线服务查询一个根域时经常能拉出几百条子域名记录其中相当一部分是员工自己开发环境或者历史遗留系统防护通常比正式业务系统薄弱很多。DNS历史解析记录同样有价值。假设目标当前解析到CDN节点直接扫描什么都得不到但半年前这条域名可能解析到真实源站IP。这类历史记录能从安全数据服务商的公开查询里获得。一个经验是先找历史IP再验证该IP当前是否仍运行着目标的服务。如果能确认这个真实IP就是绕过CDN的关键情报。拿到一批子域名之后要做的不是直接一个个去访问而是把它们统一解析一遍按A记录和CNAME归类。同样是子域有些解析到办公出口IP有些解析到云主机有些通过CNAME指向第三方服务——这些归属关系本身就是情报。接下来通过ASN自治系统号查询可以确认目标企业名下还登记了哪些IP段。我自己做项目时会把“域名—IP—ASN—归属组织”整理成一张关联表后面排查同一台服务器上绑定的其他域名时这张表能帮你少走很多弯路。2.2 搜索引擎、代码托管平台和公开页面里的隐形痕迹如果说证书和DNS是“域名维度”的情报那搜索引擎和代码托管平台就是“内容维度”的情报而且这两个来源经常能挖出比域名列表更致命的信息。搜索引擎方面我常用的手法是组合查询语法。比如用site:company.com filetype:pdf找公开文档用site:company.com intitle:系统登录找管理入口用inurl:/wp-admin之类的特征词找暴露的后台路径。这些操作全部通过搜索引擎完成目标服务器不会产生任何访问记录。很多公司的员工手册、机房拓扑图、内部运维规范被上传到网站目录后忘了删除这类文档对理解目标的IT架构极有帮助。代码托管平台的搜索是另一个高价值情报源。GitHub、GitLab和国内的Gitee上很多员工会把公司项目代码提交到个人仓库里或者在公司项目里留下真实的配置片段。搜索方式很简单直接用域名、内网域名、数据库连接字符串特征、员工英文ID作为关键字去搜。常见泄露内容包括.env文件里的数据库账号和密钥、application.yml里的中间件地址、前端代码里的API接口路径、甚至有测试人员在提交代码时把整个配置文件传上去的情况。开发者以为自己删掉了文件就没事了但Git历史里的每一次提交都会被永久保留这也是侦察阶段经常用的一个方向。这里有一个很重要的认知代码托管平台搜出来的信息绝大多数是“线索”不是“结论”。比如搜到一个数据库连接串里面包含内网IP和端口这个内网IP大概率现在已经不可达但泄露的IP、用户名命名习惯、数据库类型仍然可以用来辅助判断目标的内网网段规划和口令策略。真正能用的信息必须和后面在线资产的检测结果交叉验证之后才作数。2.3 互联网资产测绘平台的价值与使用边界接下来要聊的是互联网资产测绘平台比如Shodan、Censys、FOFA这类服务。它们本质上是全球扫描结果的数据库你可以通过域名、IP、端口、服务类型甚至开发框架特征去检索“这台服务器上曾经/当前开放过什么服务”。对侦察来说它们最大的价值是可以做到“全球扫描过的数据为我所用但我自己不用发出一个包”。使用上有两个典型的正面场景。第一个场景是确认资产的“历史暴露”比如目标的一个子域当前只开放了80和443端口但测绘平台的记录显示这个IP在几个月前还开放过22和3306端口。这个信息说明该服务器可能启用了防火墙策略但服务并没有真正卸载——如果有可控的通道抵达该主机这些内部服务仍可能被利用。第二个场景是直接按关键词检索目标相关资产比如搜索目标域名的SSL证书信息把同一张证书或证书链下关联的所有IP和域名全部拉出来经常能发现没被列入授权清单但又确实属于目标的其他系统。但测绘平台也经常被误用。最容易踩的坑是“拿过期数据当现状”。测绘平台无法实时同步所有端口一台服务器今天开放的端口可能三个月后才被再次扫描收录所以检索结果只能作为参考条件之一必须再通过实际连接来确认当前状态才能进入下一步。第二个坑是只依赖关键字搜索而不做资产梳理脱离域名和IP归属关系的孤立搜索会把大量无关资产引入工作流徒增噪音。所以我的习惯是先做第2.1和2.2节的域名与内容情报再用测绘平台做验证和扩展而不是反过来一上来就搜。3. 主动探测确认“可打性”而不是盲目乱扫3.1 端口扫描的正确节奏被动侦察做到位之后目标清单已经有了哪些子域存活、哪些IP属于目标、哪些系统值得进一步探测。这时候才进入主动探测阶段而且主动探测的第一个原则是——不要一上来就跑全端口。如果你的目标IP数量在五十个以内跑一次全端口扫描是合理的可以一次性确认所有开放端口和服务。但如果目标是几个C段甚至B段全端口高并发扫描基本等于在目标防火墙上拉警报。我的做法是分两步走第一步先快速确认存活主机用常见端口Top 100快速筛选第二步只对筛选出的存活IP做全端口扫描或重点端口扫描具体选择取决于目标数量级和对隐蔽性的要求。端口优先级方面我通常把这些端口放最前面Web服务端口80、443、8080、8443远程管理端口22、3389、5985数据库端口3306、5432、6379、27017以及一些开发运维常用的端口8000、8888、9090、9200。原因很简单——这些端口背后往往是利益最大的系统管理后台、数据库、容器管理面板、API网关。一次不是全端口扫描而是“按风险排列顺序”的探测方式可以在有限时间内得到最大回报。Nmap的参数也值得一提。默认速度跑大型网络太慢我一般用类似--min-rate 2000的参数提升速率但要注意——速率越高被安全设备发现的概率越大。在红队类项目中我会刻意把速率压低到一个“常时流量”的水平宁可慢一点也不要在一小时内向目标发送几十万个探测包。扫描结果的记录同样重要我习惯用一张表记录每条结果的IP、端口、服务、指纹和备注这张表会一直跟到项目后期是最好的复盘材料。3.2 服务指纹识别判断“可打性”的核心步骤端口扫描告诉你“目标开了一个端口”指纹识别告诉你“这个端口背后是什么系统什么版本”。后者才是决定能不能打、怎么打的关键。指纹识别的维度很多我简单梳理一下。端口服务层面Nmap的-sV参数可以用来识别服务版本但很多管理员会修改Banner或隐藏版本号所以不能只依赖这一个渠道。Web层面是另一个独立战场HTTP响应头的Server字段、X-Powered-By、页面底部版权信息、favicon图标Hash、登录框的HTML结构都可以作为指纹特征。除此之外登录框配套的JS文件往往会暴露前端框架类型和版本很多SPA应用能通过JS文件路径直接判断出使用的是Vue、React还是老版本Angular并从编译特征中推断开发时间。工具方面我常用的有httpx和whatweb。httpx适合批量探测一个命令就能把所有候选域名跑一遍输出状态码、标题、服务器类型whatweb更擅长抽取单页面的技术栈特征适合对少量重点页面做深度识别。我自己偶尔也会写点简单脚本来替换favicon Hash再用公开指纹库比对效果也不错。为什么指纹识别这么重要因为“技术栈新旧”直接决定系统的可打性。同一个登录框如果跑的是Nginx加Spring Boot全家桶漏洞利用难度较高但如果是一台老版本IIS加ASP.NET或者干脆是PHP 5.x加老版本ThinkPHP那么历史漏洞列表里可能就有直接可用的条目。侦察阶段判断出这两种情况的时间差可能只有几分钟但后续投入的工作量完全不同。3.3 常见噪音与干扰CDN、WAF、蜜罐和误报主动探测阶段必须学会分辨两类东西一类是目标本身用来藏真实资产的防御设施另一类是扫描结果里的误报和伪影。CDN和WAF首当其中。很多目标网站套了CDN直接扫描域名解析出来的IP看到的全是CDN节点的响应真实源站IP被藏得严严实实。这种情况下历史DNS解析记录往往能暴露源站IP或者某个没上CDN的子域会直接解析到源站。找到真实源站IP之后通过绑定Host头访问才能看到后端服务的真实响应。蜜罐是另一个需要警惕的元素。某些高交互蜜罐会把常见端口全部打开甚至返回模拟的服务Banner看起来像一台充满漏洞的服务器。判断技巧包括检查端口开放模式是否过于完美、对比各服务的Banner风格是否一致、尝试发送畸形请求看响应是否符合真实服务的特征。当然在授权范围内发现蜜罐本身也算一种成果——至少说明对方有监测意识。还有一类常见问题是扫描结果的真实性问题。端口显示开放但实际连接后立刻断开或没有响应可能是防火墙策略导致SYN包被放行但连接被丢弃。经验是每个关键端口的开放状态都以实际TCP连接验证为准不能只凭扫描器的原始输出下结论。4. 从情报到攻击路径一次完整侦察的实战推演4.1 一个典型项目的侦察起点为了讲清楚侦察到攻击路径的转化过程我虚构一个典型场景假设我们接到的授权范围是某家做SaaS的公司授权明确包含根域名和办公网段时间窗口两周。项目第一天我不会碰任何扫描器。先把根域名拿到手里之后第一轮操作是这样排的查询whois和DNS信息确认核心IP段然后去证书透明度日志里拉取该根域名下所有子域记录再把所有子域名解析到IP和授权范围里的IP段做交集验证最后用搜索语法和代码托管平台查一遍和公司名称、域名相关的公开页面和代码仓库。这一轮做完手上大概会得到这么几类信息三十来个主域和子域、三五个真实的办公网IP、七八个员工常用账号别名、一份可能包含内部API地址的GitHub仓库片段。这些都是线索还没有任何一条可以直接当作突破口。4.2 把落点收敛到可验证的入口第二步是给这些线索排序决定先验证哪些。排序依据很简单第一看资产重要性第二看防护成熟度第三看情报关联度。在刚才那个虚构项目里我发现两个看起来很有意思的子域一个叫dev-record.saascompany.com证书签发日期在两年前明显是开发环境当前解析到一个华为云IP另一个叫old-oa.saascompany.com标题直接是“XX公司OA系统”HTTP响应头里的Server字段显示是老版本Tomcat。针对这两个入口我做了最低限度的主动验证分别访问首页确认状态码和指纹信息记录页面标题、服务器版本、登录框路径。然后我去GitHub搜了该公司域名相关的代码片段发现一个开发者在半年前的提交里附了一份配置文件里面提到了old-oa.saascompany.com的服务器内网地址和管理员账号的命名规则。这份配置本身已经失效但账号命名规则和当前OA系统登录框的密码找回逻辑一对照就能推断出初始密码的可能构成方式。这个步骤叫作假设验证。侦察阶段我不会去尝试登录或利用漏洞——那属于测试阶段的工作。但这条路径的可打性已经可以在侦察阶段给出明确判断它暴露在公网、指纹显示版本老旧、且确认存在与历史配置中的系统一致的证据。有了这三个条件后续测试阶段的优先级就非常清晰了。4.3 情报交叉验证与误报排除很多新手拿到一堆情报后最容易犯的错误是“见到什么都想打”但真正确认一个入口可用的前提是完成三层交叉验证。第一层信息来源至少两个独立渠道。比如old-oa.saascompany.com这个域名我不光在证书透明度日志里看到还在代码托管平台的配置片段里看到同时在测绘平台的历史记录里有这个IP的指纹数据。三条独立来源指向同一个资产它的可信度就非常高。第二层历史信息必须与在线状态匹配。GitHub里泄露的数据库连接串指向一个内网地址这个地址当前显然不可达那就只能作为推理信息不能当入口用。凡是已下线、已失效的资产除非能通过当前在线的关联资产重新触达否则一律从验证队列里剔除。第三层域名、IP、端口、服务四个维度要一致。域名解析到的IP必须属于目标公司被解析IP上开放的服务必须与推测的业务类型一致否则就可能打到了CDN节点或者第三方的共享主机上白白浪费时间和暴露风险。5. 侦察阶段的红线、边界与应用在防御侧的价值5.1 授权范围与行为边界不管文章前面写了多少技巧有一条底线必须放在最前面所有侦察和后续测试都只能在明确授权的范围内进行。授权范围通常包括域名列表、IP段和测试时间窗口。有的项目还会单独注明是否允许钓鱼测试、是否允许社会工程学尝试但大多数授权书默认不允许这类对人的测试手段。我的建议是拿到授权书之后第一件事就是把范围整理成机器可读的IP和域名清单在侦察阶段绝不越过这条线。如果在被动侦察里发现某个域名或IP看起来属于目标但没写入授权清单正确做法是记录下来并在项目报告中单独提出来由公司方确认后再决定是否纳入测试范围。还有一类边界是“发现敏感数据后怎么做”。比如在代码仓库里找到了数据库账号和明文口令可以截图留证但绝对不能把这些账号用于超出验证目的的生产系统登录更不能批量下载、导出或破坏目标数据。这是行业通行做法也是最基本的安全素养。5.2 我总结出的五条实操纪律第一被动信息全部落地存档。侦察阶段搜索到的每一条线索都应该有一行记录包含来源、发现时间、资产名称、当前状态和备注。我见过太多项目做到一半需要回头查找一条线索结果发现记录在微信聊天记录里或者干脆找不到了。这点很影响效率。第二主动探测之前先建“白名单逻辑”。哪些IP已经确认属于目标哪些是CDN节点哪些是第三方关联资产——这需要在扫描前就划好而不是边扫边看否则很容易把扫描流量打到无关系统上。第三速度让位于隐蔽性和完整性。除非测试环境明确允许大规模扫描否则宁可多花点时间把主动探测做得轻一点、慢一点也不要因为赶进度而把整个测试暴露在目标安全设备的监控之下。第四一张关联图胜过十页文字记录。把域名、IP、系统类型、账号关联、代码仓库线索统一画成一张图项目后期无论是写报告还是调整测试路线都会非常方便。第五所有侦察工作都要回答同一个问题如果我是攻击者我现在会选择从哪里下手每收集到一批新情报就把这个问题重新问一次确保侦察方向没有偏离实战价值。5.3 防御方如何利用同一套侦察方法前面主要说的是攻击视角但侦察这套方法论用在防守侧效果同样突出。企业安全团队完全可以用相同流程做一次“暴露面体检”通过证书透明度日志和DNS历史记录找出那些已经被遗忘的域名通过代码托管平台搜索发现员工是否上传过包含敏感配置的项目通过与测绘平台的公开数据做比对确认互联网上可被检索到的资产是否全部在生命周期管理台账里。现实中有相当一部分企业的边界防护做得很好但“影子资产”问题严重——某个部门自己搭的测试系统、某个第三方遗留的API入口、某台退租但未注销的云主机这些都不在正式的资产管理范围内却真实暴露在互联网上。用攻击者视角扫一遍这些看不见的角落往往比合规扫描器更容易发现问题。这也是为什么我认为侦察能力是攻防双方共同需要的基本功而不是渗透测试人员专属的技能。写在最后的一点经验。我做了这么多年安全项目最大的体会是侦察阶段的工作质量决定了项目最终能走多远。工具链更新很快扫描器参数组合千变万化但真正拉开差距的始终是思维方式——你能不能从一条whois邮箱记录联想到历史注册信息从一段代码片段推测出运维习惯从一张证书日志里看到被遗忘的开发环境。这些能力不可能靠某个工具一步到位只能靠一次次的实战积累。如果你正准备开始自己的第一个完整测试项目建议别急着开扫描器先把被动侦察完整跑一圈把信息表建好再让扫描器上场。你会发现真正的高价值入口绝大多数时候不是“扫”出来的而是“推”出来的。
