SRC信息收集进阶：从被动收集到情报网络的实战方法论-北京尧图网络

我一直觉得SRC 信息收集做到后面拼的早就不是工具数量而是你对“资产”和“情报”这两个词的理解深度。第一集我们聊了从零开始怎么把域名、IP、子域名这些基础资产捞出来很多人照着做完一轮发现东西是收集了一堆但真正能用的、值得花时间深挖的没几个——这种情况我太熟悉了。这篇续集不打算再重复“有哪些工具”“怎么安装”这类入门内容而是想聊清楚一件事信息收集的进阶到底进在哪。进在你能把分散的子域名、IP、指纹、JS文件、备案信息串成一张有逻辑的情报网进在你看到一份资产清单时能一眼判断哪些是自建系统、哪些是外包残留、哪些是历史遗留进在你不需要等扫描器跑完几个小时就能通过几个关键信号锁定最容易出问题的目标。本篇适合那些已经跑通过一次基础信息收集流程、但觉得效率不高、思路不够系统的同学也适合准备系统整理自己SRC方法论的人。下面所有内容都是我基于大量授权测试场景下的实操经验总结出来的不涉及任何具体项目敏感信息请放心阅读。1. 先想明白信息收集到底在收集什么很多人把信息收集理解为“尽可能多地拿到域名、IP、子域名、端口”然后用工具把所有结果堆到一起指望数量取胜。这个思路在第一集还能用毕竟新手阶段需要的是广度是先把视野打开。但做到进阶阶段如果你的目标还是“多”而不是“准”那大概率会陷入一个很尴尬的境地报告写了一堆真正有价值的发现寥寥无几。1.1 从“广撒网”到“精准打点”我见过不少朋友拿几十个字典轮番扫一个门户网站目录跑了三天三夜最后扫出来的都是 404 和几个静态资源顺手还把自己本地磁盘撑满了。问题不在工具而在没有做前置研判。一个正经的SRC信息收集流程核心目标应该是找出目标单位在互联网上所有可访问的系统入口并判断哪些入口最有可能存在可利用的问题。到了进阶阶段我会把信息收集的产出分成三个层级。第一层是“资产清单”就是域名、IP、端口这些都是什么只解决“有什么”的问题。第二层是“资产关系”哪些系统是同一套代码改的、哪些是同一台服务器托管的、哪些是同一个业务团队维护的这解决的是“怎么串起来”的问题。第三层是“攻击预判”根据指纹、报错信息、目录结构、接口风格判断这套系统大概是什么框架、什么版本、哪里可能配置不当这解决的是“下一步往哪打”的问题。很多人卡在第二层觉得资产之间的关系太难梳理。其实有一个很朴素的思路凡是能通过同一个登录入口认证的凡是共用同一套静态资源路径的凡是在同一个IP段且开放端口高度相似的都值得怀疑是一个业务域。把这些信号记录下来你的情报价值立刻就不一样了。1.2 一条完整的信息收集流水线进阶信息收集不是靠某一个神级工具一步到位而是一条流水线。我习惯把它拆成五个环节资产确权、暴露面测绘、指纹识别、敏感信息挖掘、关联扩线。每个环节的输出都是下一个环节的输入。资产确权解决的是“目标到底有哪些地盘”比如主域名、子公司域名、新业务品牌、APP、小程序。暴露面测绘解决的是“这些地盘上有哪些门开着”比如子域名解析记录、端口服务、目录接口。指纹识别解决的是“门的材质和锁芯型号”比如框架类型、版本号、语言栈、容器。敏感信息挖掘解决的是“门旁边有没有藏钥匙”比如代码仓库泄露、备份文件、配置文件、文档元数据。最后一步关联扩线是拿着前面所有线索去反查看能不能找到更多此前没发现的关联资产。这条流水线不是一个串行流程而是每完成一轮就要回灌一次。比如你从小程序里挖到了一个 API 域名这个域名可能反过来带你找到一个新网段新网段里又有另一套老系统老系统的备案信息可能关联到另一个业务主体。信息收集做到最后其实是织网的过程不是线性清单的过程。1.3 用ROI思维管理收集节奏进阶阶段你一定会遇到一个现实问题客户给的测试时间有限或者你作为个人做SRC精力就那么多不可能每个目标都无限深挖。这时候必须用ROI思维给目标排序。我的习惯是给每个收集到的资产打三个标签价值标签、成本标签、风险标签。价值标签看的是这个系统是否涉及核心业务、是否有用户数据、是否承担交易功能成本标签看的是要验证它需要多少步骤比如是否需要复杂认证、是否需要特定客户端风险标签看的是这个系统是不是边缘系统、是不是外包项目、是不是已经没人维护的老古董。边缘系统、无人维护的老系统、外包项目这些通常是信息收集阶段最值得倾斜时间的。不是因为它们一定有漏洞而是因为它们的防护通常比核心系统弱而且历史包袱重。反过来说那种一打开就看到完善的WAF、强制双因子认证、前后端分离且接口全部走网关的系统你花再多时间收集也可能一无所获这时候沉没成本要果断止损。提示信息收集的终极目标是给后续测试环节提供“最有把握的入口”不是把自己累死。每个目标投入的时间要有上限我一般单个资产不超过2小时如果2小时内没发现值得深挖的信号就切下一个。2. 资产确权把目标的所有“分身”找全SRC项目里最常见的坑就是目标范围没搞清楚。甲方给了一个主域名你觉得挺清晰但实际上一查这个集团下面还有一堆子公司、关联公司、海外主体每个主体都有自己的域名和系统。这些算不算目标范围严格来说要回到授权书和项目范围说明里去确认但在信息收集阶段你至少应该先把它们全找出来再逐一对照范围。这个环节我称之为“确权”因为你不只要收集还要为后续每一个动作确认“这个资产能不能碰”。2.1 不止主域名企业关系网里的隐藏资产第一步一定是从公开的企业信息入手。目标主体通常有工商信息这些信息里能看到股东、对外投资、分支机构、主要人员。每一层节点都可能对应一个新域名、一个新系统。实操中我会把企业关系数据整理成表格一列是主体名称一列是关联方式一列是来源链接然后在每个主体后面继续做域名收集。不要小看这个方法。某次模拟测试中我从一个主目标往下一层发现它投资了一个做物流系统的子公司这个子公司的官网挂在另一个独立域名上而那个域名解析到一台托管服务器服务器上直接开着管理后台的登录页且没有任何访问控制。这一步的价值比我后续扫任何子域都要大。当然实际操作中必须确认范围这里重点分享思路。2.2 备案反查与品牌词组合的玩法中国企业域名有个特点绝大多数都要走ICP备案备案信息里包含主体名称、域名列表、备案号。反过来查就可以通过主体名称把该主体名下的域名全部拉出来。这比穷举子域名快得多因为你拿到的是“官方注册”的域名往往就是核心业务入口。除了备案反查还要关注品牌词组合。很多大公司会注册一堆和主品牌相近、容易混淆的域名这些域名不一定在备案列表里但确实解析到业务系统。常见的注册习惯包括加上“test”“dev”“staging”“demo”“old”“new”“v2”这类后缀或者使用不同的顶级域比如.com之外还有.cn、.net、.org甚至.io。信息收集阶段我会把目标品牌的拼音、英文名、缩写整理成字典用批量查询的方式看哪些域名被人注册过、哪些解析到了真实服务器。2.3 APP和小程序手机端的资产别漏了现在很多业务的入口早就不在网页端了特别是面向消费者的业务主力产品是APP还配套一堆小程序和公众号。信息收集如果把APP资产漏掉相当于只摸了一半暴露面。APP层面的信息收集要从应用商店开始。在商店里能找到开发者主体名称这个名称可以用来反查这个开发者还发布过哪些其他APP。下载安装后我会把APP的安装包存起来后面用于提取代码中的接口地址和配置信息这个环节我放到后面敏感信息部分细说。小程序方面微信搜索、支付宝小程序搜索都能定位官方小程序小程序包的拉取和源码分析现在已经有不少成熟的辅助工具但我这里不展开讲具体工具链重点是思路凡是你能在手机上下载到的应用都是潜在的攻击面都不要漏。3. 域名与DNS层信息收集的黄金入口子域名收集是信息收集的经典项目第一集应该已经覆盖了基础的暴力枚举和证书透明日志。这里我想聊的是更深一层的东西哪些子域名收集手段是真正的高性价比哪些数据值得你持续维护3.1 证书透明日志的价值与用法证书透明日志CT日志是我个人最喜欢的子域名情报源。因为CA在签发证书时会把证书记录到公开日志里任何人通过查询就能知道某个域名下最近签发了哪些证书。对于SRC信息收集来说CT日志有两个独特优势第一它能收集到很多没有公开发布的内部子域名第二它有时间戳你可以看到某个子域名是最近才被创建证书的这往往意味着背后有新的业务系统上线。光靠一个CT日志查询服务不够实战中要把多个CT源的数据合并去重。我自己维护了一个简单的定时任务每天把关注域名的CT数据拉一遍存到本地这样当目标系统新上线一个内部工具时我能第一时间知道。这种“数据积累”的玩法比临时扫一轮要强太多。3.2 DNS历史解析和被动收集子域名收集还有一个维度值得关注它不是静态的。很多子域名的A记录会变化旧地址可能指向云服务器现在迁移到了新的云服务商有些子域名长期没有解析记录但历史上有过意味着这台服务器曾经存在过。DNS历史查询在信息收集阶段的作用是帮你找到那些下线但可能仍在内网存活的系统线索或者找到曾经的云资产归属网段。被动收集方面除了常规的证书透明我还会关注一些公开的被动DNS数据源和搜索引擎的缓存结果。整体思路是主动枚举你能想到的名字被动收集你没想到但真实存在的名字两条腿走路才能覆盖得全。实操时我会把主动枚举的子域名和被动收集到的子域名分别标记后续做指纹识别时优先看被动收集的因为它们往往更冷门、更可能缺乏维护。3.3 favicon图标哈希与图标检索这是一个非常实用但经常被忽略的技巧。很多系统的favicon图标是独有的把favicon文件做哈希处理后可以用公开的搜索引擎查询同一个哈希值在其他哪些域名上也出现过。这个方法特别适合用来找同一套图标体系下的“兄弟系统”。举例来说一个主域名用的是公司Logo图标那你拿这个图标哈希去检索很可能找到一堆旁边没被人注意过的关联资产——可能是某个内部系统的登录页用的图标跟官网完全一致。这类资产往往不在备案信息里也不在CT日志里只有通过图标这种“指纹”才能把它们从海量数据里挖出来。类似的思路还能扩展到页面标题、首页关键词、页面版权声明这些特征。4. 主动探测与接口发现从“知道有什么”到“找到能打的”子域名和IP收集得差不多之后下一步自然就是探测这些资产上到底跑着什么服务、有哪些目录和接口。这个环节如果只靠扫描器跑效率和准确率都不会太理想。我习惯把主动探测分成几个阶段来做。4.1 目录字典别只用一份通用字典很多人跑目录扫描时喜欢直接用一个几万条的大字典从头跑到尾。不是说这不行但如果目标明确知道自己是什么框架你就可以定制一套“高命中率”的字典速度更快、结果更干净。举个例子目标系统如果是Java系的老系统那常见路径就有actuator接口、druid监控页、swagger文档页、WEB-INF目录这类特征路径如果目标系统是ThinkPHP那跑一些PHPIDE路径和备份文件路径更有意义。关键是根据指纹来决定字典的侧重点。我的做法是准备几套基础字典再准备一个“叠加字典”里面全是各框架特有的敏感路径拿到指纹后把对应部分并进基础字典再跑。4.2 从JS文件和源码注释里挖接口主动探测目录扫到的东西终究有限真正的接口宝藏常常藏在JS文件里。现在的Web应用基本都是前后端分离前端JS文件会写明API的路径、请求方法、参数结构甚至偶尔还会出现写死的密钥和测试账号。我的做法是在拿到目标站点的页面之后把当前页面用到的所有JS文件列表拉出来逐个下载保存然后做关键词匹配。重点关注的关键词包括api、admin、list、upload、download、config、token、key、secret、internal、debug、test。匹配到结果后把完整的接口路径还原出来然后手动访问或批量请求观察返回的数据格式和状态码。这个过程中最常出现的惊喜就是找到了没有加鉴权的管理接口或者内部查询接口。4.3 授权范围内的403绕过思路主动探测时遇到403是很常见的事很多人直接跳过其实403页面恰恰值得停下来想想。403本质上是说“服务器知道资源存在但你当前这个身份不被允许访问”这透露了一个关键信息资源可能真实存在。在授权测试场景下可以尝试一些非破坏性验证思路。比如从域名访问改成IP访问或者反过来把路径的大小写转换一下在URL后面加一个合法参数让请求命中不同的处理逻辑尝试用POST请求替代GET请求看看是不是方法限制。这些操作的目的不是绕过访问控制去做未授权操作而是为了判断目标是否存在“访问控制配置不当”这类值得上报的风险。每做完一种尝试都必须记录请求的方法、路径、返回码方便后续写报告时复盘。特别要强调的是所有操作都必须严格遵循授权范围超出范围的一律不做。注意403绕过的核心价值在于确认“资源存在但访问控制缺失”而不是鼓励无限制地突破边界。如果尝试过程中发现已经进入需要特定授权才能访问的数据区域请立即停止并记录时间点交给项目负责人判断。5. 指纹识别与技术栈研判指纹识别是整个信息收集环节里最能拉开差距的部分之一。同样看到一个登录页新手会直接开始跑弱口令而熟练的人会先判断这套系统是什么框架、什么版本、有没有历史公开漏洞、默认配置是否改过。这些判断的依据就来自指纹信息。5.1 指纹识别的几个维度技术栈指纹不光是看首页返回的响应头至少可以从五个维度去判断。第一是响应头比如Server字段、X-Powered-By字段、Set-Cookie的名称第二是页面结构比如特定框架的报错页风格、默认登录框DOM结构、特定版权声明第三是静态资源路径比如常见框架的默认JS/CSS文件名第四是URL风格比如ThinkPHP的index.php路由形式Java Spring的/api路径风格第五是Cookie行为有些框架生成的会话Cookie名称是固定的。把这五个维度的信息汇总起来基本就能判断出目标用的具体框架和大致版本。这时候再去查这个版本的公开漏洞方向就会非常清晰。我经常说指纹识别做得好后面省的不只是时间更是你盲目的精力消耗。5.2 常见指纹的实战意义每种指纹背后都对应一套后续打法。比如识别到目标使用了某种开源CMS且版本较老那就可以直接去查该版本的历史漏洞库重点看有没有前台RCE或SQL注入如果识别到目标用的是某种微服务网关那重点看路由配置是否可改写、是否存在未授权访问如果识别到后端是Node.js且接口返回里有特定报错格式那可以关注一下依赖组件是否存在已知CVE。我习惯把指纹信息记在一个简单的表格里字段包括目标URL、指纹来源、判断结果、置信度、下一步建议。积累到一定数量后你会发现很多目标之间其实有共性的技术栈而这些共性往往说明它们来自同一家外包开发商或者同一套内部框架一个点打穿其他点可以复用同一套思路。这就是信息收集进阶真正的价值不是单点收集而是形成体系预判的能力。6. 敏感信息与历史痕迹挖掘信息收集到了这个阶段已经不只是收集“活跃资产”了而是要把目光放到那些可能被遗忘、被忽略的信息痕迹上。老话说“百密一疏”很多系统上线时很安全但开发过程中留下的痕迹往往没有清理干净这些痕迹就是信息收集阶段最有价值的产出来源。6.1 代码仓库泄露开发人员习惯把代码放到公开代码托管平台上有些是私有仓库但也总有意外泄露的情况。信息收集阶段我会用目标的域名、品牌名、核心产品名作为关键词在公开代码平台上搜索。重点关注仓库名里带目标品牌、描述里带官网域名、代码里出现目标API地址的仓库。如果真找到了目标相关的代码仓库先别急着高兴要按重要程度排序去检查。第一优先看配置文件包括数据库连接、云服务密钥、第三方API Token第二看部署脚本里面可能写有服务器地址和账号信息第三看近期提交记录提交信息里可能包含内网地址或测试账号。在授权测试项目里发现代码仓库泄露本身就是一条可以直接上报的安全问题因为代码中往往包含大量关于系统的内部信息。6.2 云存储与公开文档国内很多企业都在使用云存储服务经常出现配置不当的情况。判断的依据很简单如果访问一个对象存储的URL能直接以目录形式列出文件列表那就是配置不当。信息收集阶段可以用目标的域名、品牌拼音、业务关键词去拼可能的存储桶名称或者通过公开的接口搜索引擎来检索。公开文档也是容易被忽视的一块。网上搜索目标的域名或者品牌名经常能搜到一些内部培训PPT、运维手册、业务流程图。这些文档里偶尔会出现内网IP、服务器命名规则、系统架构图甚至直接附带了部分账号密码。文档类信息虽然不算直接的漏洞但能大幅提升你对目标内部架构的理解帮你更精准地做后续收集。6.3 把零散信息拼成一张情报网单条敏感信息看起来没有特别大的价值但把它们拼起来就是一张完整的情报网。比如你从一个公开仓库里拿到了内网IP段又从一篇文档里知道了服务器命名规则再从APP的JS文件里挖到了一个内部API域名这几个信息合在一起你就能推测出目标大概的部署架构哪些系统在前端哪些系统在内网哪些接口是内部专用的。信息收集到这一步才算完整。我自己的做法是每拿到一条新线索就问自己三个问题它能不能帮我找到新的资产它能不能帮我判断某个系统的重要性它能不能帮我省掉后续测试的某些步骤如果三个问题的答案都是否那这条线索就先放到备选池里不急着现在用。信息收集的时间是有限的一定要把精力放在能产生连锁反应的信息上。7. 常见问题与避坑实录信息收集看起来是体力活但实际操作中的坑非常多。我踩过的坑估计比很多新手扫过的目录还多这里整理几个典型的问题和排查思路供你参考。7.1 信息收集阶段常见的5个问题第一个问题是“收集结果过多筛选困难”。扫了几万个URL最后没法判断哪些值得看。解决思路是在收集阶段就加入过滤条件比如先按响应码过滤只保留200和301的再按标题过滤去掉静态页面最后按指纹分组把同类的放一起抽查。第二个问题是“目标范围跑偏”收到一个没在授权范围的资产上去了。这个没有别的办法只能靠收集之前把资产范围表做扎实每新增一个资产就先对照范围表。第三个问题是“重复扫描”同一批子域名被多个工具反复扫浪费时间。解决办法是收口所有收集结果统一走一个汇总每个目标只做一轮标准扫描。第四个问题是“工具报错看不懂”比如依赖缺失、权限不足。多数时候是环境问题先把工具链用容器化管理能省很多时间。第五个问题是“报告数据不完整”测试做完了信息收集阶段的证据却找不全。这个要靠流程规范每验证一个点就立刻截图存档。7.2 合规与边界收集不等于越权信息收集是SRC流程中离“边界”最近的一个环节因为主动扫描、目录枚举、接口探测本质上都在和目标系统交互。这里必须有一个清晰且不可逾越的底线所有操作都只能作用于你获得授权、且明确写入项目范围的目标。任何超出范围的探测哪怕只是扫描一个“看起来关联”的IP都可能构成越权这不是技术问题是合规问题。另外还要注意数据最小化。信息收集阶段可能接触到目标系统中的敏感数据比如测试账号、内部人员信息、客户信息。这些数据只能在项目范围内使用不能留存超过必要时间不能复制到个人设备上更不能在工作交流群里传播。我自己的习惯是每个项目结束之后会专门清理一次本地缓存和备份文件确保没有项目数据残留。这块意识要放到和技术同等重要的位置。7.3 收尾工作证据固化与报告整理信息收集阶段结束之后至少要输出三类成果。第一类是资产清单包含所有确认过的域名、IP、指纹、归属状态并标注哪些是核心资产、哪些是边缘资产。第二类是测试路线图就是从所有收集结果中筛选出的下一步测试重点每个重点都要写清楚理由。第三类是证据包包括发现敏感信息时的截图、响应包、请求记录按编号整理好。证据的规整程度直接影响后续漏洞报告的质量。我见过太多报名因为时间紧张、证据零散而显得不专业的情况。实操中我会给每个待测点建一个文件夹里面放好描述、证据、请求包和处置建议。这些材料看起来只是信息收集的副产品但等到项目结束或者需要回溯时你就知道这套习惯有多重要了。最后聊几句写了这么多最想传达的一个观点是SRC信息收集的进阶本质上是情报思维的进阶。工具永远是执行层的东西真正值钱的是你拿到一堆原始数据之后能不能把它们组织成有逻辑、有优先级、能指导行动的结构化情报。我自己早期也走过弯路总以为收集得越多就越接近成功结果大量时间浪费在无限扩大的信息海洋里。后来换了思路每一次收集都带着明确问题去比如“我想证明这个系统是否有配置不当”“我想判断这个域名是否值得深挖”“我想把这条线索扩成新的关联资产”效率一下子提升了很多。信息收集不是一个体力活干完就结束的它是一个需要不断回看、修正、沉淀的过程。希望这篇延续第一集的分享能帮你少走一些我走过的弯路。

SRC信息收集进阶：从被动收集到情报网络的实战方法论

相关推荐

用代码生成PPT：内容与样式分离的自动化实践

基于python-pptx的PPT自动化生成方案：模板引擎与数据驱动实践

AI大模型自动化测试实战：全流程智能测试设计与落地

更多资讯

Ingress Nginx 高性能调优：从内核参数到 10 万 QPS 的完整实践

dart_scope鸿蒙适配实战：作用域驱动Flutter依赖生命周期治理

扩散语言模型技术全解析：并行生成、可控性与工程实践

YOLO11双模态改进源码解析：红外与RGB特征融合的目标检测实践

Ray 分布式对象溢出调优：应对千万级长上下文的跨存储治理

基于Python的网络小说分析系统：爬虫、文本挖掘与可视化实战

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？