渗透测试不是渗透拿着扫描器跑一遍就完事。去年有个客户找我，测试说他们刚做完“渗透测试”，渗透报告里全是测试漏洞列表，高危中危低危分得清清楚楚，渗透可我问了一句“攻击者能不能从外网直接拿到数据库权限”，测试对方愣住了。渗透那份报告没回答这个问题。测试扫描器只能告诉你门没锁，渗透但门后面是测试空房间还是金库，它不知道。渗透渗透测试的测试核心是模拟真实攻击者的思路，用人工判断串起工具发现，渗透最终回答“能不能打进去、测试打进去能拿什么”这两个问题。渗透

信息收集往往被低估。很多人打开目标网站，扫一下端口，看看指纹，就急着上漏洞利用工具。我习惯先花几个小时只做一件事：把目标当成一个真实公司去了解。查whois，看备案，翻招聘信息——招聘里写着“熟悉Struts2框架”，那后台大概率有相关系统。用Google搜site:target.com，找泄露的配置文件、测试页面、旧版接口。有一次从GitHub上一个员工提交的代码注释里翻到了内部测试环境的IP段，直接绕过了外网WAF。这些信息不会出现在任何自动化工具的输出里。

漏洞验证阶段最考验耐心。扫出来一个SQL注入点，别急着跑sqlmap拿数据。先手工测一下：加单引号报错吗？报错信息里有没有数据库版本？能不能用union select回显？有些点扫出来是误报，有些点扫出来是真漏洞但权限极低，只能读一张无关紧要的表。真正有价值的漏洞往往藏在业务逻辑里。比如一个密码重置功能，验证码是四位数字且没有次数限制，那就可以爆破；或者修改返回包里的用户ID，就能越权查看别人的订单。这类漏洞扫描器基本发现不了。

权限维持和横向移动是渗透测试里最像“攻击”的部分。拿到一台Web服务器权限后，别停。看它能不能连内网数据库，看它有没有挂载共享目录，看它保存了哪些配置文件里的明文密码。我遇到过一台机器，Web目录下有个config.php，里面写着数据库密码，而那个密码和运维人员的SSH密码一模一样。从Web到数据库再到核心服务器，只用了三步。这一步一步的路径，才是渗透测试报告里最该写清楚的东西。客户需要知道攻击者是怎么一步步深入，而不是只看一个漏洞列表。

清理痕迹和写报告同样重要。测试过程中上传的webshell、创建的账号、修改的配置，结束后要全部删掉。报告里别只贴漏洞名称和CVSS评分，要写清楚复现步骤、影响范围、修复建议。修复建议别写“升级到最新版本”这种废话，要具体到“把xxx文件里的xxx函数改成参数化查询”或者“在nginx配置里加上xxx规则”。最后附上攻击路径图，让不懂技术的老板也能一眼看明白风险在哪。

渗透测试的本质是攻防思维的落地。工具会过时，漏洞会修复，但攻击者的思考方式不会变。一个合格的渗透测试人员，脑子里始终在问：如果我是攻击者，我会从哪里下手？这个点能不能绕过？绕过后能拿到什么？回答不了这些问题，报告写得再漂亮也没用。