文章总结: 文章强调信息收集核心在于构建资产上下文而非单纯扫描端口,主张开工前72小时应优先翻查代码托管历史、文档及身份命名规则,重点关注历史资产与变化差异,并严格遵循授权边界与合规记录,将线索结构化落盘以支撑后续渗透测试。
综合评分: 92
文章分类: 实战经验,渗透测试,WEB安全,安全开发,安全建设
信息收集不是扫端口:真正决定成败的是开工前那七十二小时
原创
Sink
Sink
船山信安
2026年9月28日 23:14
湖南
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
实战笔记 · PENTEST
信息收集不是扫端口:真正决定成败的是开工前那七十二小时
外网渗透 · 写给一上来就开扫描器的人
七十二小时,是我在外网项目里划给信息收集的上限。不是因为它刚好三天,是因为再往上加,产出的新东西会明显变少。这篇文章写的不是工具清单,是这七十二小时里先做什么、后做什么、什么时候必须停。
周三上午十点,扫描器的进度条停在 62%,刷出来三个端口:80、443、22。有人已经在报告草稿里写下第一行——”开放端口较少,暴露面收敛良好”。
我看着那行字,知道这次交付已经坏了一半。
不是扫描错了。是那三个端口什么都没告诉我们。
新手对信息收集的理解,通常就等于”跑一遍端口扫描”。这不能怪谁,教程都是这么开头的:扫端口、识别服务、对版本、查漏洞库。流程跑熟之后,一小时能出一份很漂亮的清单。问题在于,这份清单回答的是”有哪些门”,而真正决定你能不能进去的,是”哪些门后面住着人、谁在管、多久没人看过”。
这两件事的差别,在项目收尾时会变成报告厚度的差别。前者写一句”暴露面收敛良好”就结束了。后者能写出:这个后台是三年前外包做的,开发负责人去年离职后没人接手,还在用当时那套默认口令,并且和主站共用同一套 LDAP。后面这半句,才是甲方愿意付钱的东西。
弯路我也走过。早年接过一个项目,两天全花在全端口扫描和服务指纹上,交了一份二十七页的端口表。复盘时甲方问了一句:这些我用资产平台十分钟也能拉出来吧。那句话我记到现在。
01端口扫描回答的是”有哪些门”
| | |
| — | — |
| 端口扫描 | 有哪些门开着、跑的是什么、版本大概是几 |
| 信息收集 | 门后住着谁、谁在管、最后一次有人动它是什么时候 |
| 差别 | 前者写成”暴露面收敛良好”,后者写成”这个后台两年没人登录过” |
端口扫描不是不重要,是位置太靠后了。它的正确角色是”验证”,不是”发现”。你已经怀疑那个子站是外包做的老系统,扫描器帮你确认它确实还开着、确实跑着两年前的中间件。这个顺序里,扫描器是最后一道工序。
反过来做会怎样?你会拿到一份漂亮的清单,和一份很薄的报告。因为清单里的每一条都是”待解释对象”,需要上下文才能变成结论。没有上下文,一个开着的 8080 端口就只是 8080。
具体到什么程度算够?举个例子:扫描器告诉你有个子站开着 8080,标题是”系统登录”。到此为止。信息收集要继续回答的是:这个名字是谁起的、是给内部用还是给经销商用的、域名注册在谁名下、证书什么时候签的、有没有还在维护的迹象。这五个问题答完,你才知道该不该在它身上花时间。
还有一点容易被忽略:信息收集的产出不是”更多资产”,是”给资产排序”。同样二十个子域,哪个是核心业务、哪个是外包遗留、哪个是临时搭的演示环境,排完序你才知道前三天该打哪三个。没排序的清单,长度只会让人焦虑。
我的时间分配一直很粗暴:七十二小时里,端口扫描不超过半天。剩下的是人的活——查、翻、比对、记。
扫描器给你的是清单,信息收集给你的是上下文。清单谁都能生成,上下文不能。
02先翻代码托管与文档面,再碰端口
| | |
| — | — |
| 看什么 | 公开仓库、历史 commit、README、接口文档、脚手架默认页、错误堆栈 |
| 为什么值 | 这里的线索是白送的,几乎不需要技术含量,只需要耐心 |
| 时间预算 | 第一天整个下午,八小时左右,比端口扫描枯燥但命中率高得多 |
说一个反复出现的模式:公开代码托管平台上一个三年前的仓库,README 里写着”测试环境账号 admin/admin123″,而那个测试环境和生产共用同一套 LDAP。这类东西不需要任何技巧,只需要你愿意花两个小时把公开仓库翻一遍——包括 fork、包括已经归档的、包括开发者个人账号下那些没打 tag 的项目。
历史 commit 比当前代码值钱。当前代码里的密钥通常已经被清理过,历史 commit 里的没有。在 Git 里删掉一个文件只是新增一次提交,不是抹掉历史。很多人知道这件事,但真正去翻的人不多,因为翻起来确实无聊。
文档面同样重要。自动生成的接口文档会告诉你系统里有哪些模块、字段叫什么、哪些接口没在前台暴露;脚手架默认页和错误堆栈会告诉你框架和版本;一个没关掉的调试入口会告诉你开发时的路径习惯。这些都是”设计者没打算藏、只是忘了收”的东西。
翻的顺序也有讲究。先看组织下的公开仓库列表,再按最近提交时间倒序看,然后专门看那些 stars 最少、最像原型的——冷门仓库通常保留着最多没清理的东西。这一步很枯燥,我一般设个四十分钟的闹钟,到点就换下一件事,避免自己陷进去。
边界说清楚:翻到疑似凭证,先记下来,别先试。授权书里没写”允许口令验证”之前,把一条线索变成一次登录尝试,是把合规风险往自己身上揽。
端口扫描问”门开没开”,代码和文档直接把钥匙放在桌上了。
03身份侧:名单、命名规则、供应商关系链
| | |
| — | — |
| 收什么 | 员工姓名与岗位、部门结构、邮箱命名规则、供应商与外包关系 |
| 干什么用 | 决定社工与钓鱼场景的可信度,也决定后续口令类动作的覆盖率 |
| 产出形式 | 一张表:规则、样本数、置信度。置信度必须写,别让三个月后的自己猜 |
命名规则这件事,三个样本就能推出来。是姓名全拼,还是名的拼音加点加姓,还是工号。推出来之后你才有一份能用的名单;推不出来,你手里的名单就是错的,后面所有依赖名单的动作都跟着偏。
被忽略最多的是供应商关系链。一家公司的系统常常有一半不是自己做的——外包开发商、运维托管方、行业软件厂商。关系链的价值在于:这些人的账号往往不在甲方那一套统一的强认证策略之下,而他们手里有生产环境的权限。找到”谁在替这家公司维护系统”,比找到一百个员工邮箱有用。
部门结构同样别跳过。研发、运维、财务、客服用的系统不一样,暴露方式也不一样:客服系统常有对外的工单入口,财务系统常有独立的接入控制和白名单逻辑,运维系统常留着批量操作接口。知道这家公司分几块,你才知道该往哪个方向问、问谁。
这一块我给半天。它最无聊,也最容易被跳过。我跳过它的那几次,后面都后悔了——因为在报告评审时被问”这个系统谁在维护”,我答不上来。
资产告诉你打哪里,身份告诉你为什么那里有人会信你。
04历史资产比现行资产更值钱
| | |
| — | — |
| 证书透明日志 | 目标曾为哪些名字签过证书。crt.sh 是公开查询入口之一 |
| 被动 DNS | 历史解析记录:这个域名曾经指向过哪些 IP |
| 空间搜索引擎 | fofa、shodan、censys 用来确认某一类特征资产的范围,不当唯一来源 |
现行资产有人管,历史资产没人管。这是外网项目里最稳定的一条判断,比任何技巧都可靠。三类东西值得专门找:
下线没关的服务。域名还在解析,机器还在跑,只是没人记得它。监控摘了,补丁停了,登录记录里最后一次访问是半年前。
忘了续费被别人捡走的域名。旧域名已经不属于原主,但它的证书日志和被动 DNS 里还留着当年的子域结构。那份结构就是一张旧地图。
老版本还在跑的子站。主站升了三次级,那个角落里的子站一次没升。名字通常很随意:test、old、api2、带年份的那种。
工具在这一步的位置要摆正。amass、subfinder 这类东西做的是”汇总”——把证书日志、被动 DNS、公开收录这些来源跑一遍,省的是人的重复劳动,不是人的判断。跑完之后你仍然要自己看:哪些名字是活的,哪些只是历史残留,哪些属于授权范围之外。这一步没法自动化。
下面这条查询思路是被动的、公开的,只读取已经公开的签发记录,前提是目标在你手里的书面授权范围内:
从公开的证书透明日志里列出该域名曾签发过的证书名
curl -s “https://crt.sh/?q=%25.target.example&output=json” \
| jq -r ‘.[].name_value’ | sort -u
捞出来的名单里,真正要盯的是那些带环境前缀和年份的名字。它们大概率不在对方的资产台账上——台账上没写的东西,也就没人给它配基线。
台账里有的资产有人守,台账里没有的资产只有运气在守。
05隔两周再跑一次,差异本身就是情报
| | |
| — | — |
| 单次测绘 | 一次快照,回答”现在有什么”,不回答”刚上了什么” |
| 两次对比 | 新增的优先看,消失的也要看——消失往往意味着迁移,迁移常留下旧地址 |
| 我的节奏 | 进场跑一次、中段跑一次、交付前跑一次,间隔一到两周,每次不超过半小时 |
新上线的系统通常是最薄弱的。不是因为它写得更差,是因为它还没被纳入任何流程:基线没配、监控没接、负责人还没定、临时开的测试账号还没删、应急预案里还没有它。这个窗口期一般只有几周。
做 diff 不需要复杂工具。两次的域名清单各自排序去重,比一下就行。真正需要的是”你确实做了第二次”——大多数项目只做第一次,所以大多数项目永远看不到那个窗口。
消失的那一半也要留个心眼。一个名字从清单里消失,通常不是被关掉了,是换了名字或者迁了地址。旧地址如果还在解析,那台机器多半还在跑,而且它已经同时从资产台账和巡检清单里被划掉了。这种被划掉两次的东西,是历史资产里最没人管的一类。
上次就是这么捡到的:第一次测绘没有,第二次多了一个名字里带年份的子域,点进去是还没配完的后台,登录页的初始化提示语都还在。它上线十一天,台账上没有它,也没有人知道该谁负责。
资产会变,而变化的那一刻,是它最没有防备的一刻。
06结构化落盘,不然三天后你自己都找不到
信息收集最大的浪费不是没找到,是找到了没记下来。翻到过一个很有意思的东西,当时心想”这个肯定记得住”,没写。三天后写报告想起来,花了一个半小时重新找回来。那一个半小时本来能用在别处。
别把所有东西塞进一个文件。按资产、身份、代码、时间线分开,目录树示意如下:
target-name/
├── 00-scope/ # 授权范围原文、窗口期、联系人
├── 01-assets/
│ ├── domains.md # 主域、子域、历史域名
│ ├── ips.md # IP 段、CDN 前后、云厂商归属
│ └── services.md # 每个资产:谁开发、谁运维、最后一次更新
├── 02-identity/
│ ├── naming.md # 邮箱命名规则、样本数、置信度
│ └── vendors.md # 供应商 / 外包关系链
├── 03-code/
│ ├── repos.md # 公开仓库、fork、可见范围
│ └── findings.md # README / commit / 配置里捞到的线索
├── 04-timeline/
│ ├── 20260921-snapshot.md
│ └── 20261005-snapshot.md
└── 05-leads.md # 每条线索:来源、日期、验证状态、下一步
记录粒度怎么把握?我的标准是:写完这条,另一个人拿着它能在十分钟内复现。达不到就补。举个反例,”某仓库里有配置文件”是无效记录,三个月后你也不知道是哪个仓库、哪个文件。写成”组织 org-x 下的 repo-y,config 目录,2026-09-21 时仍可见,连接串字段未脱敏”才是能用的。
三个约定值得坚持。第一,每条线索写清三件事:来源、日期、验证状态。验证状态只有三种——未验证、已确认、已排除,它是防止你把猜测当成结论写进报告的唯一保险。第二,快照文件名带日期,别叫 latest,latest 在两周后就是一个谎。第三,一条线索一个条目,不要合并,合并是清理时丢东西的源头。
这套结构还有一个附带好处:交付时把 01 和 04 直接整理一下,就是甲方能拿去对台账的东西。收集成果不只是给自己用的。
没落盘的线索等于没找到,只是你暂时还不知道。
07收益递减:什么时候必须收手
| | |
| — | — |
| 信号一 | 连续两小时,新增的未重复线索为 0 或 1 |
| 信号二 | 开始收藏”也许有用”的东西,并且说不出它可能用在哪 |
| 信号三 | 资产清单已经稳定,但你还舍不得开始测——因为”再查查说不定还有” |
信息收集永远做不完。一条线索会引出三条,三条再引出九条,永远有下一个仓库没翻、下一个子域没确认。所以问题不是”还有没有”,是”下一个小时值不值这一个小时”。
我的判断方法很机械:每小时结束时数一次,这一小时新增了几条未重复的线索。连续两个小时是 0 或 1,就停。机械的好处是不用跟自己谈判——人在”再查五分钟”这件事上的自制力,远低于自己以为的水平。
硬线是七十二小时。到点就产出资产基线,把未验证的线索作为附录移交下一阶段。这不是放弃,是把猜测明确地标注为猜测,交给有更多上下文的人(可能是下一阶段的你自己)去处理。
ONE LINE
收集阶段的失败不是漏掉了什么,是停不下来。
合规前提得单独说。上面这些东西全部来自公开渠道,但”公开”不等于”可以使用”,更不等于”可以拿来打”。三条边界我写在每个项目的开工清单里:一,测绘与验证只在书面授权的范围和窗口期内做,范围外的域名哪怕一眼看上去就是同一家,也先去问;二,拿到的员工姓名、邮箱、手机号属于个人信息,只作为项目内的条目存在,不外传、不留存到项目结束之后;三,疑似凭证先记录不先使用,能不能做口令验证,看授权书里有没有写。
开工前那七十二小时不产出漏洞。
它决定后面七天有没有漏洞可写。
参考来源
· OWASP Web Security Testing Guide(WSTG):OWASP 维护的 Web 安全测试方法学,v4.2 于 2021 年发布,其中 Information Gathering 章节系统列出了指纹识别、公开信息检索与搜索引擎发现等测试项
· MITRE ATT&CK:MITRE 自 2013 年起公开维护的对抗行为知识库,其中侦察战术 TA0043 覆盖主动扫描、收集受害者身份信息、收集受害者网络与组织信息等技术与子技术
· NIST SP 800-115《Technical Guide to Information Security Testing and Assessment》(2008):美国国家标准与技术研究院发布的信息安全测试与评估技术指南,对发现(Discovery)与攻击阶段的划分与产出有明确描述
· PTES(Penetration Testing Execution Standard):业内志愿者维护的渗透测试执行标准,将情报收集(Intelligence Gathering)作为独立阶段,强调其产出要服务于后续威胁建模与漏洞分析
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:船山信安 Sink
Sink《信息收集不是扫端口:真正决定成败的是开工前那七十二小时》