去年秋天，渗透某电商平台在凌晨两点被拖走8GB用户数据。测试攻击者没用什么零日漏洞，大纲只是渗透利用了一个未授权的API端点。事后复盘，测试安全团队承认：他们做了漏洞扫描，大纲但没人真正模拟过攻击者的渗透思路去串联那些低危漏洞。渗透测试不是测试扫描器的替代品，它是大纲人在对抗人。

渗透测试方案的渗透第一页不该是工具列表，而是测试一张清晰的边界图。目标IP段、大纲域名、渗透云环境账号、测试甚至物理办公区门禁——哪些在范围内，大纲哪些碰都不能碰。我见过一份方案把生产数据库和测试库混在一起，结果测试人员一个注入直接打穿了线上订单表。边界模糊等于事故预埋。

授权书要单独签，明确起止时间、允许的攻击手法、紧急联系人。有人觉得这是走形式，真出事的时候，这份文件能决定你是安全顾问还是犯罪嫌疑人。某金融客户曾要求测试人员“顺便看看隔壁子公司”，被拒绝后还抱怨不灵活。灵活和坐牢之间，选前者。

信息收集阶段最容易被低估。WHOIS、子域名爆破、GitHub历史提交、甚至前台小姐姐的钉钉签名——攻击面往往藏在人的疏忽里。我习惯先花两天只做被动侦察，不碰目标一个包。有一次从一份离职员工的公开简历里，找到了内网VPN的默认口令规则，后面的事就顺了。

漏洞验证和利用要分级。高危漏洞直接拿shell，中危的尝试横向移动，低危的记录下来但不深入。别为了炫技把域控打挂，客户要的是报告，不是瘫痪。某次测试中，一个实习生用勒索软件样本测试备份系统，幸好隔离环境救了他。方案里必须写死：禁止使用破坏性payload。

后渗透阶段才是真正拉开差距的地方。拿到一台Web服务器之后，能不能读到数据库连接串？能不能通过Kerberos票据转到财务系统？能不能在日志里留下最少痕迹？这些动作要提前定义好“成功标准”。否则报告里只有一堆漏洞列表，没有攻击路径图，客户看完还是不知道风险在哪。

报告结构别套模板。执行摘要给高管看，用业务语言写清楚“如果这个漏洞被利用，会损失多少钱”。技术细节给工程师看，附上完整的请求响应、截图、复现步骤。修复建议要具体到版本号和配置项，别写“加强输入验证”这种废话。我见过一份报告建议“升级到最新版本”，但那个软件根本没有新版本。

最后，清理战场。上传的webshell要删，新建的账号要注销，修改的配置要还原。有一次测试完忘了删一个测试账号，三个月后客户自己扫出来了，尴尬。方案里加一条：测试结束后24小时内提交清理确认清单。

渗透测试的本质是受控的入侵模拟。方案写得越像攻击者的作战计划，防守方得到的价值就越大。别把它当成合规检查的作业，那是浪费双方的时间。