渗透测试基本流程

客户把目标IP段发过来，渗透第一件事是测试确认授权书签了没有。没签？基本后面所有操作都别谈。这不是流程形式主义，去年有个同行没拿到书面授权就去扫客户内网，渗透结果被对方安全部门反向追踪，测试差点吃官司。基本渗透测试和黑客行为的流程唯一分界线，就是渗透那张盖了章的纸。

拿到授权后，测试信息收集才是基本真正拉开差距的环节。新手喜欢直接上扫描器，流程老手会先翻目标的渗透官网、招聘信息、测试GitHub仓库。基本我见过一个案例，某公司技术博客里贴了张Jenkins的构建截图，URL没打码，直接暴露了内网IP和端口。这种信息，扫描器扫一年也扫不出来。收集的东西包括但不限于：域名、子域名、IP段、邮箱格式、员工姓名、技术栈、甚至前台小姐姐的钉钉签名——有些人的签名里写着“运维组周三例会”，这就能推断出他们的运维节奏。

接下来是威胁建模。别被这个词唬住，说白了就是问自己：如果我是攻击者，会从哪里下手？一个电商网站，支付接口和用户数据库是重点；一个工厂的内网，PLC和ERP系统更值钱。这一步不需要多复杂，拿张纸画个草图就行。我习惯用不同颜色的笔标出“可能入口”、“高价值目标”、“绕过路径”，画完基本就有思路了。

漏洞扫描和验证是体力活。用Nmap扫端口，用Burp Suite抓包，用Nuclei跑模板。但别全信扫描结果——误报太多了。上周我扫一个站，报告说存在Struts2远程命令执行，手工验证发现是蜜罐，返回的“whoami”结果是伪造的。验证漏洞时，能手动就手动，工具只是辅助。另外，记得控制扫描速度。有次我跑目录爆破，并发设了200，直接把客户的小站打挂了，运维打电话过来骂人。后来学乖了，白天用低速模式，晚上再上强度。

拿到漏洞后，利用要克制。能读文件就别写文件，能写文件就别弹shell。客户的生产环境经不起折腾。我见过一个愣头青，为了证明漏洞存在，直接删了数据库里的一张表，结果被公司开除。利用阶段的原则是：证明危害即可，别搞破坏。如果非要提权，先问问客户能不能在测试环境复现。不能？那就写个报告说明理论风险，别硬来。

权限维持和后渗透看项目范围。有的客户只要求“证明能进内网”，那你拿到一台跳板机就够了。有的客户要求“评估内网横向移动风险”，那就得试试Pass-the-Hash、Kerberoasting这些手法。但记住，每做一步都要截图、录屏、记录时间戳。后期写报告时，这些证据能救命。我曾经因为没记录一个命令的执行时间，被客户质疑“是不是你们搞坏了服务器”，翻了两小时的终端日志才自证清白。

清理痕迹和写报告是收尾。清理不是删日志——那是黑客干的事。渗透测试的清理是指：把你上传的webshell删掉、新建的账号禁用、修改的配置还原。报告别套模板，客户看腻了“高危中危低危”的表格。我习惯按攻击路径写：从外网到内网，每一步用了什么漏洞、拿到了什么权限、影响了哪些资产。配上截图和修复建议，越具体越好。比如“建议升级Fastjson到1.2.83版本”比“建议修复反序列化漏洞”有用得多。

最后说个观察：很多团队把渗透测试当成一次性任务，扫完就完事。其实真正的价值在复测。客户修了漏洞，你得回去验证修没修好、有没有引入新问题。我见过一个客户，修了SQL注入，结果把WAF规则配错了，导致所有正常请求都被拦截。复测不是走过场，是确保安全闭环的关键一步。