做安全评估和渗透测试这件事很多人一上来就想着怎么“打进去”怎么拿权限。但实际上一次完整、靠谱的测试流程里信息收集所占的比重往往远超利用环节本身。我见过太多测试方案把大量篇幅放在“用什么工具打什么漏洞”上结果真到了授权测试现场连目标资产边界都没梳理清楚上线一小时后才发现扫描范围超出了授权书立刻停手。这种情况不仅尴尬还容易给测试结果带来一大堆无效噪音。我这里说的“从信息收集到权限提升完整全流程”指的并不是某一次具体的、针对真实系统的攻击行为而是这几年做授权攻防评估和红队演练时反复打磨出来的一条通用思路。它适合企业安全团队做自我检测、适合安全服务商做合规授权测试也适合刚接触安全测试的人理解一次模拟对抗到底由哪些环节组成。完整流程大致是确定授权边界、做资产与公开情报收集、梳理攻击面、找漏洞切入点、建立初步立足点、在授权范围内做权限提升、评估影响范围、最后输出可落地的修复建议。这些环节不是流水账而是一条互相咬合的分析链前面一步的产出直接决定后面一步能不能走通。1. 先把整个流程想清楚为什么信息收集决定权限提升成败很多新手拿到一个授权测试任务之后第一反应是跑扫描器看到开放端口就想要不要直接试默认口令。这种“先开枪后瞄准”的思路往往会导致两个结果要么在错误的目标上浪费了大量时间要么因为探测动作太猛直接触发了客户的业务告警。真正靠谱的做法是先在脑子里把完整链路过一遍想清楚每个阶段的输出物是什么下一步要拿这些输出物做什么。1.1 我眼里的完整链路我把一次授权测试拆成五个阶段授权与范围确认、信息收集、攻击面分析、初步立足、权限提升。授权与范围确认是隐藏在这个流程里的第零环。没有书面的授权、没有明确的测试时段、没有划定好的资产清单后面所有动作都没有合法依据。即便是在授权范围内做测试也需要和客户约定好哪些系统不能碰哪些时间段不能发包哪些操作会导致业务中断必须提前演练。这个环节看似和“技术”无关但往往决定了整个项目能不能顺利交付。信息收集阶段的核心任务是回答“我们面对的是什么东西”。这个阶段不做任何利用动作只是尽可能地把目标的数字资产、业务形态、技术栈、入口位置摸清楚。输出物是一份资产清单和攻击面地图。攻击面分析要做的是把收集到的信息转化为可测试的路径。比如发现客户有一个重要业务系统部署在内网但它的登录接口暴露在公网同时运维人员又在项目文档里泄露了技术栈信息——这就是一条值得优先投入的路径。初步立足是指在找到某个可利用的入口之后获得一个低权限的访问入口。这一步要的是“能走进门槛”不一定非要拿到多高的权限。权限提升则是在低权限的基础上寻找系统配置缺陷、服务权限误配、口令复用等问题把控制范围从“普通用户”提升到“管理员”或“系统服务”层面。整个链路的核心逻辑是没有准确的信息收集攻击面分析就是瞎猜没有攻击面分析利用环节就是乱打没有低权限入口权限提升就是空中楼阁。每一步都是下一步的地基。1.2 前期授权动手之前最重要的一道手续我最早参与这类测试时以为授权就是签个字的事。后来踩过坑才明白授权范围如果写得不够具体后面会有一系列麻烦。有一次做某电商平台的授权测试授权书里写的域名是主站域名但测试过程中通过证书透明度日志发现了几个子域其中一个子域对应的是内部订单管理后台。按道理这个后台属于客户资产测试它有助于发现风险但授权书里并没有明确把这个子域列进去。按照测试纪律我们第一时间停下来联系客户确认该资产是否纳入测试范围。客户确认后补充了授权范围我们才继续操作。这件事给我留下很深的印象。渗透测试不是“看哪里能打就打哪里”而是“在甲方明确同意的地方做测试”。每多测一个预期之外的资产都需要重新确认。这也是从业者必须养成的职业习惯。1.3 信息收集的产出物一张容易被忽视的资产清单信息收集这项工作听起来很“弱”无非是搜搜域名、扫扫端口但它的产出物比任何利用工具都更值钱。一份合格的信息收集报告至少应该包含主域名与子域名清单、IP与C段归属、Web系统指纹、常用端口开放情况、历史DNS变更记录、公开代码仓库泄露信息、员工与账号线索等。我习惯把这张清单分成“业务资产”和“影子资产”。业务资产是客户自己知道并登记过的系统影子资产是那些被遗忘、被下线但端口依然开放、被临时起用却没人维护的系统。授权测试里最有价值的发现往往藏在这些影子资产里。因为业务资产通常有常规的安全防护影子资产却常常是裸奔状态。2. 信息收集到底在收什么这节内容看起来基础但我认为它是整个流程中最体现经验的地方。同样是收集信息有经验和没经验的人产出的质量差距非常大。没经验的人收集回来一堆域名和IP有经验的人收集回来的是“目标攻击面的一张解剖图”。2.1 收集维度一公开情报与数字资产测绘公开情报收集也叫被动信息收集意思是我不直接触碰目标系统只从公开渠道获取信息。最常用的几个来源包括证书透明度日志、历史DNS记录、搜索引擎缓存、公开代码托管平台的搜索接口、网络空间测绘平台的数据。证书透明度日志是一个非常值得优先看的来源。每张公开的SSL/TLS证书都会被记录到公共日志里通过证书中的Common Name和Subject Alternative Name字段经常能顺藤摸瓜找到不少未在主域名下登记的子域名。这个方法不需要对目标发起任何请求完全是被动的合规风险接近于零。历史DNS记录同样重要。有些子域当前已经不再解析到任何IP但历史记录里可能还保留着。这些“已经没人用但可能曾被部署过服务”的域名本身就是一个高风险信号尤其是当它背后还连着老版本的管理后台时。网络空间测绘平台会把全球范围内的IP和端口信息聚合起来可以快速定位目标公司拥有的公网IP段以及这些IP段上开放的服务。面对一个比较大的目标这一步能直接把收集范围从“大海捞针”缩小到“围绕这几十个IP展开”。2.2 收集维度二Web路径、历史记录与备份文件拿到子域名之后下一步是识别每个站点的技术栈和目录结构。这里要做的是把Web路径、历史版本记录、备份文件这些“边缘资产”翻出来。很多站点在正式环境之外会意外暴露一些敏感文件。常见的有.git目录泄露、README.md、压缩包备份、.sql转储文件、带时间戳的旧备份文件。这些文件的共同特点是它们不属于正常对外服务的一部分却能让测试方直接看到源代码、配置文件和数据库结构。我曾经在一个授权目标上发现过一份残留的网站备份压缩包里面包含了完整的数据字典和几个内部接口的调用示例后面的测试效率因此提升了一大截。这类文件不需要暴力爆破大多可以通过目录字典和搜索引擎的inurl语法找到。想发现这类问题需要养成一个习惯不只看目标提供了什么页面还要想“目标可能遗漏了什么文件”。目录字典的选择也很关键。通用字典能覆盖常见路径但针对不同业务系统最好是自建一套高频路径字典。这几年我积累了不少“实战中出现概率极高的路径名”比如/api-docs、/swagger-ui.html、/actuator、/console、/backup、/temp、/test、/upload、/download、/export。这些路径往往比跑几千条大字典更高效。2.3 收集维度三登录入口与业务逻辑特征信息收集不能只关注“系统层面”还要关注“业务层面”。一个系统的登录页长什么样、使用什么前端框架、登录之后有哪些功能模块、请求接口返回的数据结构是什么这些都是后续测试的关键参考信息。我在实际测试中很看重“登录入口的质量”。如果登录页支持短信验证码那就要猜验证码是否有次数限制、是否需要校验来源IP如果支持扫码登录那就要看扫码状态的轮询接口是否存在越权风险如果支持第三方账号绑定那就要关注绑定过程中的身份验证逻辑。这些业务层面的信息不通过直接“点击—观察—分析”是拿不到的。这一步建议用浏览器开发者工具配合代理抓包工具一起看。浏览器负责展示页面表现代理负责记录请求和响应。重点收集以下内容登录接口的请求参数、返回结果状态码、Token的存储位置、Cookie的生效范围、关键业务接口的路径规则。这些信息会让后面“找漏洞”阶段少走很多弯路。2.4 把信息变成“攻击面地图”收集到的原始信息必须转化成可执行的攻击面地图否则就是一堆躺在文档里的IP和域名。我的做法是画一张资产关系图把每个域名、IP、服务、Web系统之间的关联标注清楚。比如某个子域绑定了某个IP该IP还开放了数据库端口数据库端口又只限制来源IP。这张图可能会逐渐暴露出这样的线索虽然前端Web系统防护严密但数据库端口可以直接从公网访问而数据库连接口令恰好能在某个备份文件里找到。这就是一条由信息拼凑出来的实际利用链。画攻击面地图时我习惯用一个简单分类法按“入口类型”分为Web入口、API入口、非标准服务入口、文件共享入口按“控制难度”分为低无认证、中弱认证、高强认证强校验。优先测试低难度入口但高难度入口不代表不测而是排在后面。3. 漏洞发现与初步利用找最短那块木板信息收集做扎实之后就进入了“找漏洞”的环节。正常情况下我不建议一上来就铺开大规模漏洞扫描。扫描器给出的结果只能作为参考不能直接作为判断依据。3.1 漏洞扫描为什么不能直接信主流漏洞扫描器的原理是发送大量探测请求根据响应特征判断是否存在漏洞。但它的误报率很高——很多时候只要目标系统对某个特殊参数返回了错误页面扫描器就会判定为“疑似漏洞”。无脑信任扫描结果最容易造成的后果就是浪费时间挨个验证那些根本不存在的漏洞。更关键的是扫描器的流量特征非常明显很容易触发WAF和业务监控。在授权测试中如果你一上来就触发一堆告警客户的安全团队可能会被惊动后续测试动作也会被限制。所以我的习惯是扫描器只拿来辅助定位主要靠手动测试和针对性的payload验证。扫描器还有一个典型的盲区业务逻辑漏洞。未授权访问、越权读取、订单金额篡改、验证码绕过、批量数据导出这些漏洞靠通用扫描器基本发现不了。它们需要测试人员对业务有足够理解再结合信息收集阶段拿到的接口特征才能发现。3.2 典型的盲区接口未授权与越权访问在Web应用里我最常遇见的“低垂果实”就是接口未授权和越权。这两个问题不一定需要复杂的技术利用只要能在测试过程中构造出合理的请求即可。举一个做过很多次的案例。某客户在授权范围内测试一个报表系统登录前我就在抓包里发现了几个/report/export?typexxstartDatexxendDatexx的请求。直接访问时返回“未登录”。但我发现系统对是否存在登录态的判断依赖一个请求头字段如下X-User-Role: viewer我把viewer改为admin并携带一个任意较低的登录态Token重新请求接口直接返回了全量数据。这里的关键不是这个漏洞有多高深而是它体现出典型的实战排查思路不只看页面提供了什么功能还要看接口本身是否校验了当前用户的权限。对比同一个系统中两个不同权限角色的请求往往能发现越权问题的线索。3.3 常见入口的处理顺序面对一堆候选入口我习惯按风险高低排一个处理顺序第一优先级不需要认证就能访问的接口或页面特别是数据导出、文件下载、后台登录这类敏感功能。第二优先级存在文件上传功能的模块重点看上传后的路径是否可控、文件类型校验是否完善。第三优先级登录后的业务操作重点看越权和水平权限问题。第四优先级系统本身存在的组件漏洞这个要结合指纹识别结果来选择验证方案。这个顺序并不是固定的如果信息收集阶段已经发现目标存在明显的组件漏洞那就优先走组件漏洞这条路。整体原则是优先选择“利用代价小、成功概率高、影响范围明确”的路径而不是执着于利用某个高难度的0day。4. 权限提升拿到低权限之后怎么走打下第一个入口经常只能拿到一个低权限账户。无论是Web后台的普通操作员账号还是服务器上一个被弱口令攻破的业务账户系统对它的限制都会很严格。权限提升这一步要做的就是在授权范围内利用系统配置失误或设计弱点把这个低权限扩大成对自己有利的更高权限。4.1 从“普通权限”看系统先看配置再打服务拿到低权限访问权之后第一件事不是急着跑提权工具而是先看当前环境里有哪些信息和配置是敞开的。以Linux环境为例我会按顺序检查以下内容当前用户的sudo权限执行sudo -l查看当前用户可以运行哪些命令很多时候管理员会把某些命令不当授给普通用户。环境变量与脚本目录查看/etc/crontab和/var/spool/cron/中是否存在可写脚本或可被普通用户覆盖的文件。进程与服务信息查看当前运行的进程确认是否存在以root权限运行的老旧服务。数据库配置文件很多应用会把数据库口令、消息队列口令、对象存储密钥放在配置文件中普通用户如果能读取这些文件往往能接触到底层数据。Windows环境的检查思路也类似但重点偏向服务路径权限、注册表自启动项、未及时打补丁的服务程序。先做信息收集式的排查再尝试利用比直接跑提权工具要稳妥得多。4.2 三个让我印象深刻的提权案例这里分享三个在授权测试中遇到的典型场景都来自模拟环境和合规测试不涉及任何真实攻击目标。第一个是“可写目录定时任务”组合。某测试环境里应用服务以普通用户身份运行但它的工作目录是全局可写的。管理员在crontab里配置了一个以root身份定期执行的脚本该脚本调用了应用工作目录下的一个临时文件。测试过程中我向该临时文件写入了恶意的命令脚本等待定时任务触发后成功以root身份执行命令。这类问题在真实环境中并不少见尤其是那些由“先上线再补规范”成长起来的业务系统。第二个是“配置文件中保存明文口令”的组合。某个内部工具系统把数据库口令写在了.env文件里普通用户通过对应用目录有读权限直接拿到了数据库管理账号。借助这个账号我又发现数据库所在的主机存在某个通用服务配置问题顺势就拿到了主机控制权限。这告诉我很重要的一件事权限提升不一定非得是“攻击系统漏洞”很多时候是“顺着密码和配置往前走”。第三个是“服务启动路径可被替换”的组合。某Windows测试环境中一个第三方服务以LocalSystem权限启动但服务对应的执行文件所在目录对普通用户开放写权限。把该文件替换后重启服务就能以服务权限执行任意命令。这种问题在那些安装完就不再关注第三方组件权限的企业里尤其常见。三个案例想说明的是权限提升用得最多的不是复杂的内存漏洞利用而是配置失当、权限过宽、口令复用这些“管理上的漏洞”。4.3 常说的高权限路径其实要分场景网上讨论权限提升时很多人喜欢一口气列出十几个系统漏洞编号好像每一个都能稳定提权。但实战中系统补丁修复速度通常比预期快真实环境中还能直接利用的系统级漏洞并不像理论中那么多。更多时候高权限路径藏在Web应用配置文件、数据库扩展功能、云环境的管理接口这些“上层建筑”里。一旦测试环境处于云上权限提升的思路还要加入云角色扮演和密钥接管等内容。一个应用服务如果绑定了高权限角色一旦应用出现命令注入类问题攻击面就不仅仅是服务器本身了。所以做权限提升评估时我会把视角从“单台服务器”扩到“整个云账号体系”评估当前身份是否拥有访问对象存储、管理数据库、操作其他实例的间接权限。5. 影响范围分析与收尾千万不能忽略的一步很多人做测试拿到高权限就算大功告成直接写报告了。但我认为影响范围分析才是真正体现专业度的地方。拿到服务器控制权本身只是技术上的证明更重要的是向客户说明这个漏洞会被什么业务数据受到影响攻击者可以借助这条路径走到多深应该优先修复哪些环节。5.1 为什么要做影响范围分析影响范围分析的核心是判断“攻击链最终能触及什么”。同样一个Web命令注入漏洞如果目标只是缓存服务器影响范围就小如果目标恰好是用户支付系统的核心节点影响范围就大很多。做影响范围分析时我至少会整理出以下信息当前控制节点连接的内部网段和外部暴露面。当前权限能读取的敏感数据条目个人隐私数据、订单数据、财务数据还是内部源码。是否能通过该节点访问其他核心系统例如同网段的数据库主库、备份中心、运维管理平台。现有防护措施是否能够阻止攻击者横向移动比如网络隔离策略、主机防火墙、登录告警机制。这些内容才是客户最关心的。客户往往不关心你“拿到root了”他们关心的是“如果真有人这么做会损失多少”。5.2 清理痕迹与报告输出授权测试结束后一定要做好环境清理。我在每次测试结束后都会检查上传到目标系统的文件是否删除临时创建的账号和计划任务是否移除修改过的配置是否恢复到初始状态输出到外部平台的数据是否销毁。这一步是测试纪律的一部分做不好非常败坏职业口碑。报告输出要按“可读性优先”的原则来写。每一条漏洞记录都建议包含漏洞描述、触发URL和参数、利用过程、影响范围、修复建议。修复建议要尽可能具体。例如遇到“越权访问”问题时不能只写“加强鉴权”而要给出“建议在后端统一校验当前用户身份与请求资源ID的归属关系不能依赖前端传入的角色标识”这类能落地的说明。5.3 常见问题排查实录这里把我在实际测试中遇到频率最高的几个问题整理成一个速查表方便后来者对照。常见问题产生原因排查思路扫描器大量误报默认配置、未结合指纹剔除无关检测先确认目标技术栈再选择对应检测项结合手工验证测试触发业务告警探测频率过高、未设置低速模式控制并发数避开业务高峰时段提前与客户约定告警联系人子域名收集不全依赖单一数据源叠加证书透明日志、历史DNS、搜索引擎、网络测绘多个来源拿到低权限但提权无路可走系统补丁更新及时、权限收敛较好回到信息收集检查配置文件、备份文件、环境变量、共享目录报告修复建议流于形式缺少对系统具体配置的了解修复建议必须结合测试过程中的实际触发条件避免空话这五类问题里最容易踩坑的是第一类。扫描器误报会让新手在假漏洞上消耗大量时间浪费了本来就有限的项目周期。所以我现在做测试时有一条原则扫描结果出来之后先按“技术栈匹配度”和“漏洞可利用性”两个维度排序再用手工构造请求验证一遍只有手工验证通过的才写进报告。6. 关于边界与合规我最后想说的话回到开头那句话完整流程的核心不只是“怎么打”还包括“什么能打、什么不能打、打完之后怎么交代”。我在这个行业里做了几年之后愈发觉得所谓“技术能力”和“安全判断力”相比后者更重要。有一次做某政务类系统的测试客户特别强调不能碰某个老旧数据库因为那个库虽然已经准备退役但关联系统仍在联调。我们在信息收集阶段就已经发现这个库对外暴露但如果真去测试很有可能影响联调进度。我把这个问题原样记录进报告标注为“建议在迁移完成后优先下线”客户非常认可这种“有分寸”的处理方式。给准备进入这个领域或者刚入行的朋友三个建议。第一永远拿到书面授权再动手。没有授权你在授权测试地里做的一切“技术演示”都会偏离正轨。第二把信息收集当成一个正式的阶段性产出物而不是一个“随便搜搜”的预热动作。你前期收集到的每一份信息都会在后续环节里被反复调用。第三做权限提升时多关注配置缺陷和运维疏漏少执着于花里胡哨的内存漏洞利用。真实业务环境里前者出现的概率远高于后者。我觉得完整流畅的渗透测试思路核心不在于掌握多少个攻击技巧而在于能否像解一道多层嵌套的题那样严格按照逻辑层层推进。信息收集决定你看到多少入口利用思路决定你能走通哪些路权限提升决定你能深入到哪里而合规与报告则决定这次测试能不能真正帮助客户加固防线。希望这篇内容能帮你把整套思路串起来也欢迎在评论区聊聊你遇到过最棘手的环节是什么。 
长河君 · 2026/10/19 13:54:57 · 阅读 1.2k 从信息收集到权限提升：渗透测试完整流程实战指南
做安全评估和渗透测试这件事很多人一上来就想着怎么“打进去”怎么拿权限。但实际上一次完整、靠谱的测试流程里信息收集所占的比重往往远超利用环节本身。我见过太多测试方案把大量篇幅放在“用什么工具打什么漏洞”上结果真到了授权测试现场连目标资产边界都没梳理清楚上线一小时后才发现扫描范围超出了授权书立刻停手。这种情况不仅尴尬还容易给测试结果带来一大堆无效噪音。我这里说的“从信息收集到权限提升完整全流程”指的并不是某一次具体的、针对真实系统的攻击行为而是这几年做授权攻防评估和红队演练时反复打磨出来的一条通用思路。它适合企业安全团队做自我检测、适合安全服务商做合规授权测试也适合刚接触安全测试的人理解一次模拟对抗到底由哪些环节组成。完整流程大致是确定授权边界、做资产与公开情报收集、梳理攻击面、找漏洞切入点、建立初步立足点、在授权范围内做权限提升、评估影响范围、最后输出可落地的修复建议。这些环节不是流水账而是一条互相咬合的分析链前面一步的产出直接决定后面一步能不能走通。1. 先把整个流程想清楚为什么信息收集决定权限提升成败很多新手拿到一个授权测试任务之后第一反应是跑扫描器看到开放端口就想要不要直接试默认口令。这种“先开枪后瞄准”的思路往往会导致两个结果要么在错误的目标上浪费了大量时间要么因为探测动作太猛直接触发了客户的业务告警。真正靠谱的做法是先在脑子里把完整链路过一遍想清楚每个阶段的输出物是什么下一步要拿这些输出物做什么。1.1 我眼里的完整链路我把一次授权测试拆成五个阶段授权与范围确认、信息收集、攻击面分析、初步立足、权限提升。授权与范围确认是隐藏在这个流程里的第零环。没有书面的授权、没有明确的测试时段、没有划定好的资产清单后面所有动作都没有合法依据。即便是在授权范围内做测试也需要和客户约定好哪些系统不能碰哪些时间段不能发包哪些操作会导致业务中断必须提前演练。这个环节看似和“技术”无关但往往决定了整个项目能不能顺利交付。信息收集阶段的核心任务是回答“我们面对的是什么东西”。这个阶段不做任何利用动作只是尽可能地把目标的数字资产、业务形态、技术栈、入口位置摸清楚。输出物是一份资产清单和攻击面地图。攻击面分析要做的是把收集到的信息转化为可测试的路径。比如发现客户有一个重要业务系统部署在内网但它的登录接口暴露在公网同时运维人员又在项目文档里泄露了技术栈信息——这就是一条值得优先投入的路径。初步立足是指在找到某个可利用的入口之后获得一个低权限的访问入口。这一步要的是“能走进门槛”不一定非要拿到多高的权限。权限提升则是在低权限的基础上寻找系统配置缺陷、服务权限误配、口令复用等问题把控制范围从“普通用户”提升到“管理员”或“系统服务”层面。整个链路的核心逻辑是没有准确的信息收集攻击面分析就是瞎猜没有攻击面分析利用环节就是乱打没有低权限入口权限提升就是空中楼阁。每一步都是下一步的地基。1.2 前期授权动手之前最重要的一道手续我最早参与这类测试时以为授权就是签个字的事。后来踩过坑才明白授权范围如果写得不够具体后面会有一系列麻烦。有一次做某电商平台的授权测试授权书里写的域名是主站域名但测试过程中通过证书透明度日志发现了几个子域其中一个子域对应的是内部订单管理后台。按道理这个后台属于客户资产测试它有助于发现风险但授权书里并没有明确把这个子域列进去。按照测试纪律我们第一时间停下来联系客户确认该资产是否纳入测试范围。客户确认后补充了授权范围我们才继续操作。这件事给我留下很深的印象。渗透测试不是“看哪里能打就打哪里”而是“在甲方明确同意的地方做测试”。每多测一个预期之外的资产都需要重新确认。这也是从业者必须养成的职业习惯。1.3 信息收集的产出物一张容易被忽视的资产清单信息收集这项工作听起来很“弱”无非是搜搜域名、扫扫端口但它的产出物比任何利用工具都更值钱。一份合格的信息收集报告至少应该包含主域名与子域名清单、IP与C段归属、Web系统指纹、常用端口开放情况、历史DNS变更记录、公开代码仓库泄露信息、员工与账号线索等。我习惯把这张清单分成“业务资产”和“影子资产”。业务资产是客户自己知道并登记过的系统影子资产是那些被遗忘、被下线但端口依然开放、被临时起用却没人维护的系统。授权测试里最有价值的发现往往藏在这些影子资产里。因为业务资产通常有常规的安全防护影子资产却常常是裸奔状态。2. 信息收集到底在收什么这节内容看起来基础但我认为它是整个流程中最体现经验的地方。同样是收集信息有经验和没经验的人产出的质量差距非常大。没经验的人收集回来一堆域名和IP有经验的人收集回来的是“目标攻击面的一张解剖图”。2.1 收集维度一公开情报与数字资产测绘公开情报收集也叫被动信息收集意思是我不直接触碰目标系统只从公开渠道获取信息。最常用的几个来源包括证书透明度日志、历史DNS记录、搜索引擎缓存、公开代码托管平台的搜索接口、网络空间测绘平台的数据。证书透明度日志是一个非常值得优先看的来源。每张公开的SSL/TLS证书都会被记录到公共日志里通过证书中的Common Name和Subject Alternative Name字段经常能顺藤摸瓜找到不少未在主域名下登记的子域名。这个方法不需要对目标发起任何请求完全是被动的合规风险接近于零。历史DNS记录同样重要。有些子域当前已经不再解析到任何IP但历史记录里可能还保留着。这些“已经没人用但可能曾被部署过服务”的域名本身就是一个高风险信号尤其是当它背后还连着老版本的管理后台时。网络空间测绘平台会把全球范围内的IP和端口信息聚合起来可以快速定位目标公司拥有的公网IP段以及这些IP段上开放的服务。面对一个比较大的目标这一步能直接把收集范围从“大海捞针”缩小到“围绕这几十个IP展开”。2.2 收集维度二Web路径、历史记录与备份文件拿到子域名之后下一步是识别每个站点的技术栈和目录结构。这里要做的是把Web路径、历史版本记录、备份文件这些“边缘资产”翻出来。很多站点在正式环境之外会意外暴露一些敏感文件。常见的有.git目录泄露、README.md、压缩包备份、.sql转储文件、带时间戳的旧备份文件。这些文件的共同特点是它们不属于正常对外服务的一部分却能让测试方直接看到源代码、配置文件和数据库结构。我曾经在一个授权目标上发现过一份残留的网站备份压缩包里面包含了完整的数据字典和几个内部接口的调用示例后面的测试效率因此提升了一大截。这类文件不需要暴力爆破大多可以通过目录字典和搜索引擎的inurl语法找到。想发现这类问题需要养成一个习惯不只看目标提供了什么页面还要想“目标可能遗漏了什么文件”。目录字典的选择也很关键。通用字典能覆盖常见路径但针对不同业务系统最好是自建一套高频路径字典。这几年我积累了不少“实战中出现概率极高的路径名”比如/api-docs、/swagger-ui.html、/actuator、/console、/backup、/temp、/test、/upload、/download、/export。这些路径往往比跑几千条大字典更高效。2.3 收集维度三登录入口与业务逻辑特征信息收集不能只关注“系统层面”还要关注“业务层面”。一个系统的登录页长什么样、使用什么前端框架、登录之后有哪些功能模块、请求接口返回的数据结构是什么这些都是后续测试的关键参考信息。我在实际测试中很看重“登录入口的质量”。如果登录页支持短信验证码那就要猜验证码是否有次数限制、是否需要校验来源IP如果支持扫码登录那就要看扫码状态的轮询接口是否存在越权风险如果支持第三方账号绑定那就要关注绑定过程中的身份验证逻辑。这些业务层面的信息不通过直接“点击—观察—分析”是拿不到的。这一步建议用浏览器开发者工具配合代理抓包工具一起看。浏览器负责展示页面表现代理负责记录请求和响应。重点收集以下内容登录接口的请求参数、返回结果状态码、Token的存储位置、Cookie的生效范围、关键业务接口的路径规则。这些信息会让后面“找漏洞”阶段少走很多弯路。2.4 把信息变成“攻击面地图”收集到的原始信息必须转化成可执行的攻击面地图否则就是一堆躺在文档里的IP和域名。我的做法是画一张资产关系图把每个域名、IP、服务、Web系统之间的关联标注清楚。比如某个子域绑定了某个IP该IP还开放了数据库端口数据库端口又只限制来源IP。这张图可能会逐渐暴露出这样的线索虽然前端Web系统防护严密但数据库端口可以直接从公网访问而数据库连接口令恰好能在某个备份文件里找到。这就是一条由信息拼凑出来的实际利用链。画攻击面地图时我习惯用一个简单分类法按“入口类型”分为Web入口、API入口、非标准服务入口、文件共享入口按“控制难度”分为低无认证、中弱认证、高强认证强校验。优先测试低难度入口但高难度入口不代表不测而是排在后面。3. 漏洞发现与初步利用找最短那块木板信息收集做扎实之后就进入了“找漏洞”的环节。正常情况下我不建议一上来就铺开大规模漏洞扫描。扫描器给出的结果只能作为参考不能直接作为判断依据。3.1 漏洞扫描为什么不能直接信主流漏洞扫描器的原理是发送大量探测请求根据响应特征判断是否存在漏洞。但它的误报率很高——很多时候只要目标系统对某个特殊参数返回了错误页面扫描器就会判定为“疑似漏洞”。无脑信任扫描结果最容易造成的后果就是浪费时间挨个验证那些根本不存在的漏洞。更关键的是扫描器的流量特征非常明显很容易触发WAF和业务监控。在授权测试中如果你一上来就触发一堆告警客户的安全团队可能会被惊动后续测试动作也会被限制。所以我的习惯是扫描器只拿来辅助定位主要靠手动测试和针对性的payload验证。扫描器还有一个典型的盲区业务逻辑漏洞。未授权访问、越权读取、订单金额篡改、验证码绕过、批量数据导出这些漏洞靠通用扫描器基本发现不了。它们需要测试人员对业务有足够理解再结合信息收集阶段拿到的接口特征才能发现。3.2 典型的盲区接口未授权与越权访问在Web应用里我最常遇见的“低垂果实”就是接口未授权和越权。这两个问题不一定需要复杂的技术利用只要能在测试过程中构造出合理的请求即可。举一个做过很多次的案例。某客户在授权范围内测试一个报表系统登录前我就在抓包里发现了几个/report/export?typexxstartDatexxendDatexx的请求。直接访问时返回“未登录”。但我发现系统对是否存在登录态的判断依赖一个请求头字段如下X-User-Role: viewer我把viewer改为admin并携带一个任意较低的登录态Token重新请求接口直接返回了全量数据。这里的关键不是这个漏洞有多高深而是它体现出典型的实战排查思路不只看页面提供了什么功能还要看接口本身是否校验了当前用户的权限。对比同一个系统中两个不同权限角色的请求往往能发现越权问题的线索。3.3 常见入口的处理顺序面对一堆候选入口我习惯按风险高低排一个处理顺序第一优先级不需要认证就能访问的接口或页面特别是数据导出、文件下载、后台登录这类敏感功能。第二优先级存在文件上传功能的模块重点看上传后的路径是否可控、文件类型校验是否完善。第三优先级登录后的业务操作重点看越权和水平权限问题。第四优先级系统本身存在的组件漏洞这个要结合指纹识别结果来选择验证方案。这个顺序并不是固定的如果信息收集阶段已经发现目标存在明显的组件漏洞那就优先走组件漏洞这条路。整体原则是优先选择“利用代价小、成功概率高、影响范围明确”的路径而不是执着于利用某个高难度的0day。4. 权限提升拿到低权限之后怎么走打下第一个入口经常只能拿到一个低权限账户。无论是Web后台的普通操作员账号还是服务器上一个被弱口令攻破的业务账户系统对它的限制都会很严格。权限提升这一步要做的就是在授权范围内利用系统配置失误或设计弱点把这个低权限扩大成对自己有利的更高权限。4.1 从“普通权限”看系统先看配置再打服务拿到低权限访问权之后第一件事不是急着跑提权工具而是先看当前环境里有哪些信息和配置是敞开的。以Linux环境为例我会按顺序检查以下内容当前用户的sudo权限执行sudo -l查看当前用户可以运行哪些命令很多时候管理员会把某些命令不当授给普通用户。环境变量与脚本目录查看/etc/crontab和/var/spool/cron/中是否存在可写脚本或可被普通用户覆盖的文件。进程与服务信息查看当前运行的进程确认是否存在以root权限运行的老旧服务。数据库配置文件很多应用会把数据库口令、消息队列口令、对象存储密钥放在配置文件中普通用户如果能读取这些文件往往能接触到底层数据。Windows环境的检查思路也类似但重点偏向服务路径权限、注册表自启动项、未及时打补丁的服务程序。先做信息收集式的排查再尝试利用比直接跑提权工具要稳妥得多。4.2 三个让我印象深刻的提权案例这里分享三个在授权测试中遇到的典型场景都来自模拟环境和合规测试不涉及任何真实攻击目标。第一个是“可写目录定时任务”组合。某测试环境里应用服务以普通用户身份运行但它的工作目录是全局可写的。管理员在crontab里配置了一个以root身份定期执行的脚本该脚本调用了应用工作目录下的一个临时文件。测试过程中我向该临时文件写入了恶意的命令脚本等待定时任务触发后成功以root身份执行命令。这类问题在真实环境中并不少见尤其是那些由“先上线再补规范”成长起来的业务系统。第二个是“配置文件中保存明文口令”的组合。某个内部工具系统把数据库口令写在了.env文件里普通用户通过对应用目录有读权限直接拿到了数据库管理账号。借助这个账号我又发现数据库所在的主机存在某个通用服务配置问题顺势就拿到了主机控制权限。这告诉我很重要的一件事权限提升不一定非得是“攻击系统漏洞”很多时候是“顺着密码和配置往前走”。第三个是“服务启动路径可被替换”的组合。某Windows测试环境中一个第三方服务以LocalSystem权限启动但服务对应的执行文件所在目录对普通用户开放写权限。把该文件替换后重启服务就能以服务权限执行任意命令。这种问题在那些安装完就不再关注第三方组件权限的企业里尤其常见。三个案例想说明的是权限提升用得最多的不是复杂的内存漏洞利用而是配置失当、权限过宽、口令复用这些“管理上的漏洞”。4.3 常说的高权限路径其实要分场景网上讨论权限提升时很多人喜欢一口气列出十几个系统漏洞编号好像每一个都能稳定提权。但实战中系统补丁修复速度通常比预期快真实环境中还能直接利用的系统级漏洞并不像理论中那么多。更多时候高权限路径藏在Web应用配置文件、数据库扩展功能、云环境的管理接口这些“上层建筑”里。一旦测试环境处于云上权限提升的思路还要加入云角色扮演和密钥接管等内容。一个应用服务如果绑定了高权限角色一旦应用出现命令注入类问题攻击面就不仅仅是服务器本身了。所以做权限提升评估时我会把视角从“单台服务器”扩到“整个云账号体系”评估当前身份是否拥有访问对象存储、管理数据库、操作其他实例的间接权限。5. 影响范围分析与收尾千万不能忽略的一步很多人做测试拿到高权限就算大功告成直接写报告了。但我认为影响范围分析才是真正体现专业度的地方。拿到服务器控制权本身只是技术上的证明更重要的是向客户说明这个漏洞会被什么业务数据受到影响攻击者可以借助这条路径走到多深应该优先修复哪些环节。5.1 为什么要做影响范围分析影响范围分析的核心是判断“攻击链最终能触及什么”。同样一个Web命令注入漏洞如果目标只是缓存服务器影响范围就小如果目标恰好是用户支付系统的核心节点影响范围就大很多。做影响范围分析时我至少会整理出以下信息当前控制节点连接的内部网段和外部暴露面。当前权限能读取的敏感数据条目个人隐私数据、订单数据、财务数据还是内部源码。是否能通过该节点访问其他核心系统例如同网段的数据库主库、备份中心、运维管理平台。现有防护措施是否能够阻止攻击者横向移动比如网络隔离策略、主机防火墙、登录告警机制。这些内容才是客户最关心的。客户往往不关心你“拿到root了”他们关心的是“如果真有人这么做会损失多少”。5.2 清理痕迹与报告输出授权测试结束后一定要做好环境清理。我在每次测试结束后都会检查上传到目标系统的文件是否删除临时创建的账号和计划任务是否移除修改过的配置是否恢复到初始状态输出到外部平台的数据是否销毁。这一步是测试纪律的一部分做不好非常败坏职业口碑。报告输出要按“可读性优先”的原则来写。每一条漏洞记录都建议包含漏洞描述、触发URL和参数、利用过程、影响范围、修复建议。修复建议要尽可能具体。例如遇到“越权访问”问题时不能只写“加强鉴权”而要给出“建议在后端统一校验当前用户身份与请求资源ID的归属关系不能依赖前端传入的角色标识”这类能落地的说明。5.3 常见问题排查实录这里把我在实际测试中遇到频率最高的几个问题整理成一个速查表方便后来者对照。常见问题产生原因排查思路扫描器大量误报默认配置、未结合指纹剔除无关检测先确认目标技术栈再选择对应检测项结合手工验证测试触发业务告警探测频率过高、未设置低速模式控制并发数避开业务高峰时段提前与客户约定告警联系人子域名收集不全依赖单一数据源叠加证书透明日志、历史DNS、搜索引擎、网络测绘多个来源拿到低权限但提权无路可走系统补丁更新及时、权限收敛较好回到信息收集检查配置文件、备份文件、环境变量、共享目录报告修复建议流于形式缺少对系统具体配置的了解修复建议必须结合测试过程中的实际触发条件避免空话这五类问题里最容易踩坑的是第一类。扫描器误报会让新手在假漏洞上消耗大量时间浪费了本来就有限的项目周期。所以我现在做测试时有一条原则扫描结果出来之后先按“技术栈匹配度”和“漏洞可利用性”两个维度排序再用手工构造请求验证一遍只有手工验证通过的才写进报告。6. 关于边界与合规我最后想说的话回到开头那句话完整流程的核心不只是“怎么打”还包括“什么能打、什么不能打、打完之后怎么交代”。我在这个行业里做了几年之后愈发觉得所谓“技术能力”和“安全判断力”相比后者更重要。有一次做某政务类系统的测试客户特别强调不能碰某个老旧数据库因为那个库虽然已经准备退役但关联系统仍在联调。我们在信息收集阶段就已经发现这个库对外暴露但如果真去测试很有可能影响联调进度。我把这个问题原样记录进报告标注为“建议在迁移完成后优先下线”客户非常认可这种“有分寸”的处理方式。给准备进入这个领域或者刚入行的朋友三个建议。第一永远拿到书面授权再动手。没有授权你在授权测试地里做的一切“技术演示”都会偏离正轨。第二把信息收集当成一个正式的阶段性产出物而不是一个“随便搜搜”的预热动作。你前期收集到的每一份信息都会在后续环节里被反复调用。第三做权限提升时多关注配置缺陷和运维疏漏少执着于花里胡哨的内存漏洞利用。真实业务环境里前者出现的概率远高于后者。我觉得完整流畅的渗透测试思路核心不在于掌握多少个攻击技巧而在于能否像解一道多层嵌套的题那样严格按照逻辑层层推进。信息收集决定你看到多少入口利用思路决定你能走通哪些路权限提升决定你能深入到哪里而合规与报告则决定这次测试能不能真正帮助客户加固防线。希望这篇内容能帮你把整套思路串起来也欢迎在评论区聊聊你遇到过最棘手的环节是什么。