文章总结： 文章强调信息收集核心在于构建资产上下文而非单纯扫描端口，主张开工前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《信息收集不是扫端口：真正决定成败的是开工前那七十二小时》