★ FEATURED ARTICLE 信息收集这件事我见过太多人把它做成了关键词搜索大赏打开浏览器敲几个词复制粘贴一堆链接最后一问你查到了什么答不上来。真正做过完整信息收集的人都知道难点从来不在搜,而在知道自己要找什么、找到的东西怎么判断真假、怎么把碎片串成一条能用的线索。这篇就把我这些年踩坑攒下来的十个技巧完整拆开讲从零基础能上手的搜索语法到需要一点脚本能力的资产测绘和持续监控一条线走完。不管你是做安全自查、竞品调研、行业研究还是单纯想搞清楚公开信息到底能挖到什么程度下面这些方法都能直接拿去用。文章里涉及的所有工具和命令都只在自有资产或明确授权的范围内使用这是前提后面我会反复强调。1. 先画边界再动手信息收集到底在收什么1.1 三类信息三种完全不同的处理路径很多人一上手就乱是因为没给信息分类。我的习惯是先分三类静态事实类、动态变化类、关系结构类。静态事实指的是域名、IP、备案主体、组织架构、产品型号这类相对稳定的东西动态变化类指的是端口开放状态、服务版本、页面上线时间、招聘岗位变化这类会随时间漂移的东西关系结构类指的是谁是谁的子公司哪个域名属于哪个业务线这个人负责哪个项目这类关联信息。分类的意义在于决定你怎么存。静态事实适合用表格加字段管理一个资产一行字段固定动态变化适合带时间戳的追加式记录每次采集都留一条方便做差异对比关系结构则适合用图的方式表达节点和边比表格清楚得多。我早期犯的错就是把三类混在一张 Excel 里结果查一个端口状态翻了半天改一次结构全表崩。后面改成一张资产主表 一份变更日志 一张关系表三件套效率直接翻倍。这里给一个我常用的资产主表字段设计可以直接抄字段名说明示例资产标识域名或 IP主键api.example.com归属业务内部约定的一级分类门户站点解析地址当前 A 记录192.0.2.10开放端口逗号分隔80,443指纹框架与版本某 Web 框架 2.x首次发现日期2024-03-11最近确认日期2024-09-02来源从哪条线索拿到的证书日志字段不用多八个足够。多了维护不动少了后面查不动这个度是我反复调整三四次才定下来的。1.2 授权范围这件事比技术重要一百倍技术可以学边界感学不会就容易出事。我的原则很简单动手前能说清楚我凭什么查这个就动手说不清楚就停。自有资产、公司明确书面授权的资产、完全公开且不涉及任何个人隐私的公开信息这三类是安全的。反过来别人的业务系统、内部系统、任何需要绕过访问控制才能看到的东西碰都不要碰。安全自查场景下我一般会先拉一份授权清单写清楚范围域名列表、IP 段、时间窗口、允许的操作类型只做被动收集还是允许主动探测、联系人。这份清单不是形式主义实际执行时它能救你很多次——比如枚举到某个域名其实属于合作方清单一翻就知道该跳过。A 同学之前就因为没做这一步把合作方的测试环境也扫了一遍虽然最后没造成影响但解释起来非常被动。注意任何主动探测行为之前先确认授权范围和操作类型。被动收集公开信息搜索引擎、公开文档风险最低主动探测端口、路径必须严格限定在授权清单内。1.3 完整链路从一个关键词到一份可交付的报告我把整个流程拆成五步后面所有技巧都挂在这五步上定目标 → 铺面广度收集→ 收敛深度验证→ 关联拼结构→ 沉淀报告与监控。定目标阶段只干一件事把我想知道什么翻译成可执行的查询条件比如我想知道这家公司对外暴露了哪些站点翻译成该主体的域名列表 子域名枚举 端口确认。铺面阶段追求覆盖度宁可多抓不追求准收敛阶段反过来只做验证每条信息至少两个独立来源交叉确认关联阶段是把散点连成线沉淀阶段输出报告并设置监控让信息能持续更新。这个顺序不能乱我见过不少人一上来就做深度验证结果验证了半天发现方向根本不对白干。2. 技巧一到三把搜索引擎用成关系型数据库2.1 技巧一语法组合让搜索框执行查询语句大部分人用搜索引擎只会输入自然语言实际上它支持一套相当完整的查询语法。我常用的核心就四个site:限定站点、filetype:限定文件类型、intitle:限定标题、inurl:限定 URL 路径。这四个组合起来表达力已经接近一句 SQL 了。举个例子想找某个站点上所有对外公开的 PDF 文档一句site:example.com filetype:pdf就够了想找后台入口页site:example.com intitle:登录或者site:example.com inurl:admin想找暴露在外的表格文件site:example.com (filetype:xlsx OR filetype:csv)。这些查询在自有资产自查里非常好用经常能翻出一些以为已经下线其实还挂着的历史文件。但语法有个坑各大搜索引擎的支持度不完全一致filetype在某些引擎上只认少数几种格式site对子域名的覆盖也时好时坏。我的做法是同一个查询语句在至少两个引擎上跑一遍结果取并集再人工筛。另外注意搜索引擎会给结果做个性化测试时最好用无痕窗口避免历史记录影响结果。下面这张表是我常年备着的语法速查直接拿去改域名就能用目的查询语句模板备注摸清站点规模site:example.com看结果总数做粗估找文档类文件site:example.com filetype:pdf替换 pdf 为 doc/xlsx/ppt找登录入口site:example.com intitle:登录换后台管理再试找目录列表site:example.com intitle:Index of命中说明目录未做限制找特定路径site:example.com inurl:backup常见敏感路径词找关联站点example.com -site:example.com排除主站看外部引用2.2 技巧二快照与历史归档找回已经删掉的东西网页删除不等于信息消失。搜索引擎的快照、公开的网页归档服务经常能翻到几个月甚至几年前的内容。这个技巧在两类场景下特别有用一是追溯某个页面什么时候上线、什么时候改版用来判断业务节奏二是找已经被删掉的公开信息比如某份已经下架的产品说明书。实操上快照入口一般在搜索结果的折叠菜单里点进去能看到抓取时间。归档服务则需要你手动提交 URL 查询它返回的是按时间排列的历史版本列表。我用它做过一次很有意思的复盘把某站点首页近两年的快照按月拉出来能明显看出他们的业务重心从 A 方向挪到了 B 方向比任何官方公告都直观。要注意的是快照和归档都不是实时的抓取频率不稳定冷门页面可能几个月才抓一次。所以这类信息只能作为旁证不能当作当前状态来用。我的习惯是凡是来自快照的信息在报告里一律标注历史状态采集于某年某月绝不当成现状写。2.3 技巧三文档元数据被严重低估的信息富矿这是我最喜欢的一个技巧也是绝大多数人完全忽略的。任何一份由办公软件导出的 PDF、Word、Excel、PPT内部都带着一份元数据作者名、创建时间、修改时间、最后保存者、软件版本、公司名称、甚至修订历史。这些东西不在正文里但信息密度极高。提取工具用 ExifTool跨平台、命令行、一行搞定# 提取单个文档的全部元数据按组分类输出 exiftool -a -u -g1 某产品说明书.pdf # 批量处理一个目录只输出关心的字段 exiftool -csv -Author -Creator -CreateDate -ModifyDate -Producer -CompanyName ./docs meta.csv-a表示显示重复标签-u表示显示未知标签-g1按组分类这三件套一起用输出最全。导出成 CSV 之后可以直接进表格做透视比如统计哪个作者产出的文档最多哪批文件的创建时间集中在同一个晚上。这个技巧在自查场景下的价值是你会发现很多对外发布的文件里带出了内部人员姓名、内部机器名、内网路径、甚至旧版本的项目代号。这些信息本身不算漏洞但拼起来就是一张组织架构图。处理办法也很简单对外发布前统一跑一遍元数据清理ExifTool 一条命令就能批量抹掉exiftool -all -overwrite_original ./publish/*注意-overwrite_original会直接覆盖原文件操作前务必先备份。我一般是先复制一份到临时目录确认没问题再覆盖正式文件。3. 技巧四到六从域名到服务把资产画出轮廓3.1 技巧四子域名枚举字典和证书两条路并行主域名只有一个子域名可能有几百个真正的资产往往藏在这些子域名后面。枚举方法主流是两条字典爆破和证书透明度日志反查。前者靠词表穷举覆盖面取决于词表质量后者利用的是公开的证书签发记录——任何为某个域名签发的证书都会留一条公开记录里面包含完整的域名这条路的准确率极高而且完全被动。我的实际做法是两条路并行结果取并集再验证。证书日志这条先跑因为它能拿到一些字典里根本想不到的命名比如带业务代号、带地区缩写的子域名字典爆破作为补充词表我一般准备三份通用词www、mail、api、test、dev、业务词从目标公开信息里提取的产品名、缩写词地区、部门缩写。三份叠加命中率明显比单一通用词表高。给一段可以直接跑的脚本逻辑是读取词表、并发解析、只输出有解析结果的import concurrent.futures import socket BASE example.com # 换成自有或已授权域名 WORDS [www, mail, api, test, dev, admin, static, cdn] def resolve(word): host f{word}.{BASE} try: return host, socket.gethostbyname(host) except socket.gaierror: return host, None if __name__ __main__: with concurrent.futures.ThreadPoolExecutor(max_workers20) as pool: for host, ip in pool.map(resolve, WORDS): if ip: print(f{host}\t{ip})并发数别开太大20 到 30 足够开太大对本地 DNS 压力大反而容易误判成不存在。另外一定要区分解析失败和解析超时前者是真的没有后者是网络问题混在一起会把有效资产漏掉。我在脚本里加了个重试逻辑超时的单独重试两次再判定误判率降得很明显。3.2 技巧五端口与服务先确定范围再谈细节资产清单有了下一步是看每个资产对外提供了什么服务。这一步的争议最大因为它属于主动探测必须严格限定在授权范围内。我的做法是先定一个小范围验证跑通再逐步扩面先挑 3 到 5 个资产做全端口扫描摸清这个环境的端口分布规律然后根据规律确定一份常用端口清单比如 80、443、8080、8443、22、3306 这种对全量资产做定向扫描速度快、噪音小。命令示例只扫常见端口、只显示开放的、带版本探测# 仅限自有或已授权资产 nmap -sV -Pn --open -p 80,443,8080,8443,22,3306 -iL assets.txt -oX result.xml-sV做版本探测-Pn跳过主机存活判断很多设备禁 ping--open只输出开放端口-iL从文件读目标-oX输出 XML 方便后面写脚本解析。这几个参数是我反复试出来的组合比默认参数省一半时间。扫描结果不要只看开了哪些端口重点看三件事不该开的开了没有比如内部管理端口暴露在公网、版本是不是明显偏旧旧版本往往意味着缺少安全更新、同一服务在不同资产上的版本是否一致不一致说明更新不同步运维有盲区。这三点比端口列表本身有价值得多。3.3 技巧六指纹识别与版本比对把是什么变成差在哪端口告诉你这里有个服务指纹告诉你这个服务是什么、什么版本。指纹识别的方法很多最直接的是看 HTTP 响应头里的Server、X-Powered-By字段其次是看页面特征特定路径、特定静态资源命名、特定 Cookie 名再次是看报错页面的特征字符串。三层叠加准确率很高。拿到指纹之后真正有价值的是比对。我会维护一份当前主流稳定版本的对照表把扫到的版本往里一套立刻能看出哪些偏旧。这一步的意义在于把技术语言翻译成业务语言——某框架 1.x这种描述没人听得懂这个版本已经停止维护两年社区不再发布安全更新这种描述业务方一听就懂优先级立刻排上来了。指纹信息还有个用法是做资产归类。同一个框架、同一套静态资源命名规则往往意味着同一个开发团队或同一套模板。把几百个资产按指纹分组能快速看出哪些是自研的、哪些是采购的、哪些是历史遗留的后面做整改排期的时候按组处理比按个处理效率高一个量级。4. 技巧七到九代码、人员与关系的三维拼图4.1 技巧七公开代码仓库的泄露自查代码托管平台是信息泄露的高发区也是最容易被忽略的地方。常见的问题有几类配置文件里写死了访问密钥、注释里留了内部地址、测试代码里带了真实数据、提交记录里出现了内部项目名。这些内容一旦公开价值比一个端口开放大得多。自查的方法先在平台上按组织名搜一遍所有公开仓库再用关键词扫一遍代码内容。关键词清单我一般准备这些password、secret、token、apikey、access_key、jdbc:、mongodb://、redis://、内部域名后缀、内网 IP 段前缀。搜到之后逐条人工确认是测试用的占位符还是真实凭据。# 克隆下来的仓库里做一次粗糙的敏感词扫描仅用于自有仓库自查 grep -rniE (secret|token|apikey|access_key|password)\s*[:] ./repo \ --include*.py --include*.js --include*.yaml --include*.properties \ | grep -viE (example|placeholder|your_|xxxx|.*)最后那个grep -v是过滤掉明显的占位符不然结果里全是password: your_password_here这种噪音看几百条也看不到真东西。这个过滤规则是我踩了几次坑才总结出来的能砍掉八成无效命中。还要注意提交历史。很多人只清理了当前版本的代码忘了历史提交里还留着。查历史用git log -p配合关键词搜或者用git log -S关键词精确查找引入和删除某段内容的提交。这块工作量不小但真查出过东西值得做。4.2 技巧八人员与组织的公开信息梳理这条要格外小心我只讲公开、合规的部分。组织层面公开渠道能拿到的信息包括官方发布的组织架构说明、公开的招聘岗位岗位描述往往透露技术栈和业务方向、公开的新闻稿和行业会议资料。这些信息拼起来能大致还原一个组织的业务布局和技术偏好。人员层面我只做角色级梳理不做个人级挖掘。也就是说我关心的是这个项目由哪个团队负责而不是某个具体的人住哪、用什么账号。这个界限必须守住越过这条线技术问题就变成了伦理问题。实操上招聘信息是最好的切入点连续几个月在招同一个岗位说明这个方向在扩张岗位描述里点名某个技术栈说明现有系统在往那个方向迁。A 同学之前做过一次很典型的分析把某公司一年内发布的招聘岗位按时间排序能清楚看到他们的技术栈从一套方案切到另一套方案的完整过程中间有大约三个月的重叠期正好对应系统迁移窗口。这个结论完全来自公开信息没有任何越界操作但信息价值非常高。4.3 技巧九图谱化把一百条碎片压成一张图信息收集到后期最大的痛苦不是找不到而是太多、太散、理不清。这时候必须做图谱化把每条信息抽象成节点或边节点是实体域名、IP、组织、产品边是关系解析到、属于、使用、关联。做完之后你会发现原本一百条孤立记录其实只有十几个核心实体和二十几条关系。工具上不用追求复杂一张白纸加笔就能开始画规模大了再用图形化工具。关键是养成每收集一条信息立刻问它连到谁的习惯。比如拿到一个新子域名立刻问它解析到哪个 IP这个 IP 上还有别的域名吗这个 IP 属于哪个网段网段里还有哪些资产四个问题问完一条信息就变成了一个小网络。图谱化还有个隐藏好处它能帮你发现信息缺口。图上某个节点只有一条边连进来说明这个实体的信息还不完整值得再挖一轮某个区域节点密集但边很少说明这里的信息都是孤立的需要找关联线索。这种看图找洞的方式比自己拍脑袋想还该查什么高效得多。5. 技巧十持续监控让信息自己长出来5.1 监控脚本把一次性采集变成周期性对比信息是有保质期的今天扫出来的端口列表一个月后可能就过时了。所以最后一个技巧是把前面的采集动作自动化定期跑一遍只输出变化的部分。核心思路很简单每次采集结果带时间戳存一份跟上一份做 diff差异就是你要关注的。一段可以直接用的对比脚本先做归一化排序再比避免因为输出顺序不同产生假差异import sys def load(path): with open(path, encodingutf-8) as f: return sorted(line.strip() for line in f if line.strip()) old set(load(sys.argv[1])) new set(load(sys.argv[2])) for item in sorted(new - old): print(f[新增] {item}) for item in sorted(old - new): print(f[消失] {item})归一化和排序这两步千万别省。我最早没做排序每次 diff 出来几百条变化逐条看完发现全是顺序差异白折腾一晚上。加上排序之后真正的变化通常只有个位数一眼就能看完。监控频率看资产的重要程度核心资产一周一次边缘资产一月一次。告警阈值也要设比如单次新增超过 20 条就触发人工复查因为突然大量新增往往意味着环境变动或者采集出错两种情况都值得看一眼。5.2 报告怎么写才有人看收集了一堆信息最后交付如果是一份流水账等于白干。我的报告结构固定四段结论先行、证据在后、风险分级、建议可执行。第一段永远是最重要的三五条结论用业务语言写不用技术黑话第二段放支撑证据每条结论对应哪几条信息标注来源和采集时间第三段按影响面分级高优先级的不超过五条第四段给具体动作写清楚谁在什么时间做什么。有个细节特别重要每条信息都要标来源和采集时间。这不是形式主义是为了让别人能复核。我见过太多报告结论写得斩钉截铁一问这个数据哪来的答不上来整份报告的可信度就没了。标注来源还有个好处当信息过期时你能快速定位到需要重新采集的那几条。报告长度控制在五页以内超过五页没人看。详细的原始数据放附件正文只放结论和关键证据。这个取舍我调整过很多次最后发现薄正文 厚附件是唯一可行的结构。6. 踩过的坑和一张速查表6.1 十个典型问题与处理办法下面这张表是我这些年实际遇到过的坑按出现频率排序遇到问题先查这张表能省不少时间现象常见原因处理办法搜索语法没结果引擎不支持该语法组合换引擎重试拆分条件逐个验证子域名枚举漏掉很多只用了通用词表补证书日志反查加业务词词表端口扫描结果忽多忽少目标有防护设备限速降低并发分时段多次采集取并集指纹识别不准响应头被改过或为空叠加页面特征和报错页判断元数据提取为空文件已被清理过找早期版本或归档版本再试差异对比全是噪音没做归一化排序排序后比对固定输出格式快照信息误导判断把历史状态当现状一律标注采集时间只作旁证敏感词扫描误报多过滤规则不够加占位符过滤人工二次确认信息太多理不清没做图谱化抽实体抽关系先画后补报告没人看结论埋在细节里结论前置正文压到五页内6.2 几个能立刻提升效率的小习惯第一个习惯每采集一条信息立刻记下来源 时间 可信度。可信度分三档直接观测自己跑出来的、公开声明官方发布、间接推断从别的信息推出来的。这三档在报告里的分量完全不同混在一起写会出事。第二个习惯建一个待验证清单。收集过程中一定会遇到互相矛盾的信息比如两个来源对同一个 IP 的归属说法不一致。别急着下结论丢进待验证清单等有第三个来源再判。我现在的清单里常年躺着十几条有些过了半年才被证实但证实的那一刻价值极大。第三个习惯工具输出一律存原始文件。不管是扫描结果、搜索结果还是脚本输出都存一份原始的别只留处理后的。原因很简单你永远不知道后面会不会需要换个角度重新分析同一批数据有原始文件就能重跑没有就得重新采集。注意所有采集到的原始数据都要按敏感级别管理涉及内部资产的信息不要随手丢在公共网盘或聊天群里。这条看起来是常识但实际出事的大部分都是这一类。最后分享一个我自己一直在用的取舍标准当你不确定某条信息该不该收、某个操作该不该做的时候问自己一句如果这件事被完整地公开说明我能不能坦然解释。能就做犹豫就先放一放去找更合规的替代路径。信息收集这门手艺技术上限决定你能挖多深边界感决定你能走多远后者比前者重要得多。
阅读完成 · 觉得有帮助？
