渗透测试流程步骤

一次没做资产测绘就开扫的渗透渗透测试，跟蒙眼扔飞刀差不多。测试去年有个客户急着上线新系统，流程安全团队直接拿漏扫工具对着IP段狂轰，步骤结果打崩了一台老旧的渗透工控机，产线停了四个小时。测试后来复盘发现，流程那台机器的步骤IP根本不在项目范围内。渗透测试的渗透第一步永远不是打开工具，而是测试把目标摸清楚——域名、子域名、流程IP段、步骤开放端口、渗透中间件版本、测试甚至员工邮箱格式。流程这些信息拼出来的地图，决定了后面所有动作的边界。

信息收集做完，接下来是威胁建模。别被这个词吓到，说白了就是问自己：如果我是攻击者，会从哪进？一个对外只有443端口的网站，和一台同时开着3389、445、1433的服务器，攻击面完全不是一个量级。我习惯把资产按“暴露程度×业务权重”画成四象限，优先打那些又暴露又重要的。这一步花二十分钟，能省掉后面两天的无效扫描。

漏洞扫描是体力活，但别全交给自动化工具。Nessus、Xray、Goby各有各的脾气，误报率能差出三成。我的做法是先用工具跑一遍全量，导出结果后人工过一遍——看banner、看响应包、看版本号是否真的对应CVE。有次工具报了个Struts2漏洞，实际抓包发现目标返回的是自定义错误页，根本不解析OGNL表达式。直接提交报告？那叫制造噪音。

验证漏洞环节最考验耐心。一个SQL注入点，从报错注入到盲注到堆叠查询，能利用的深度完全不同。我见过有人扫出注入就收工，结果客户拿sqlmap一跑，发现只能读当前库的一张废表。真正有价值的验证是拿到shell或者证明能横向移动。比如某次通过文件上传拿到Webshell后，发现内网数据库密码明文写在config里，直接连上去拖了用户表——这才叫闭环。

权限维持和横向移动要看项目授权。很多渗透测试只要求证明能进内网，不要求长期驻留。这时候别画蛇添足装后门，清理掉测试账号和上传的webshell，留个文档记录路径就行。有次同行在客户内网留了三个计划任务，三个月后客户自查发现，直接投诉到甲方。技术好是一回事，规矩是另一回事。

清理痕迹常被忽略。你上传的测试文件、新建的账号、修改的配置，全部要列清单逐一还原。我习惯在开始前对关键目录做md5快照，结束后对比。有一次忘记删掉一个测试用的aspx文件，客户运维半年后翻出来，虽然没造成损失，但解释起来很尴尬。

报告写作别堆砌漏洞列表。客户老板不看CVSS评分，他关心的是“这个漏洞能造成多大损失”。把高危漏洞放在最前面，每个漏洞配一句业务影响描述，比如“攻击者可利用该漏洞获取所有用户订单信息”。修复建议要具体到版本号和配置项，别写“建议升级到最新版本”——最新版本是哪个？从哪个版本开始修复的？这些细节决定报告会不会被扔进垃圾桶。

最后说个反直觉的观察：渗透测试的质量往往取决于项目开始前的沟通。授权书里写清楚时间窗口、禁止操作（比如不能碰生产数据库）、应急联系人，比任何高级技巧都重要。我见过太多团队技术一流，却因为没确认好范围，把测试变成事故。流程不是束缚，是让你能安心把活干完的护栏。