去年秋天，网络我帮一家做跨境电商的渗透朋友看他们刚上线的后台。他跟我说“应该没啥问题，测试我们用了某云的案例WAF”。我扫了一眼登录接口的网络返回包，HTTP 200，渗透但响应体里带了个`debug: true`。测试顺手试了个`' OR 1=1--`，案例页面直接跳进了管理面板。网络WAF没拦，渗透因为请求走的测试是内部API网关，压根没经过WAF那层。案例这事让我再次确认一个判断：绝大多数被攻破的网络系统，不是渗透败在技术对抗上，而是测试败在“以为已经防住了”。

渗透测试的本质不是炫技，是找逻辑漏洞。工具扫出来的那些CVE，修起来快，真正要命的是业务流里的裂缝。比如那个登录接口，开发图省事，把调试模式留在了生产环境。SQL注入能成功，也不是因为过滤写得差，而是他们用字符串拼接查用户表，连预编译都懒得加。

我习惯从信息收集开始。不是上来就nmap扫端口，那太吵。先看目标暴露了什么。用`curl -I`看响应头，服务器是nginx还是apache，有没有版本号泄露。再看robots.txt，有时候会写着`/admin_backup/`这种路径。有一次真让我碰上，那个目录没设权限，里面躺着整个数据库的sql文件。这种事WAF拦不住，因为请求完全合法，只是路径没配好。

拿到初步信息后，我会试几个低危但高回报的入口。比如注册功能。很多系统注册时校验邮箱格式，但登录时不校验。你可以注册一个`test@test.com'--`这种邮箱，然后登录时用SQL注入绕过。还有密码重置，token如果只跟用户ID绑定，不跟时间戳或随机数绑定，就能枚举。我见过一个站，重置链接是`/reset?uid=123&token=md5(uid)`。md5(123)算出来是固定值，直接改uid就能重置任意用户密码。

文件上传是另一个重灾区。不是看能不能传php，那太基础。要看它怎么存、怎么解析。有个案例，上传点只允许jpg，但服务器是IIS 6.0。传个`shell.jpg;.php`，IIS会把分号当参数截断，实际执行的是php。还有一次，上传后文件被重命名为`时间戳.jpg`，但返回的JSON里带了真实路径。路径里有个`/uploads/`目录，直接访问能列目录，里面还有别人传的webshell。

权限提升往往靠配置疏忽。Linux上，`sudo -l`看当前用户能跑什么。有次发现能`sudo /usr/bin/find`，那直接`sudo find / -exec /bin/sh \;`就root了。Windows上，看服务权限。用`accesschk`查可写服务，改binPath指向自己的exe，重启服务就提权。这些都不是0day，是运维偷懒。

横向移动靠凭据复用。在A机器上抓到的hash，拿到B机器上试。很多内网机器用同一套本地管理员密码。用`crackmapexec`批量试，能打下一大片。域环境里，看`net group "Domain Admins" /domain`，然后找这些人的机器。他们登录过的机器上，LSASS里可能存着域管hash。用mimikatz抓出来，整个域就跪了。

清理痕迹这事，说实话，真实攻防里没那么多讲究。但渗透测试报告里得写。删日志、清事件、改时间戳。不过现在EDR多，删日志本身就会触发告警。所以更聪明的做法是：用正常管理工具。比如用`psexec`而不是自己写的远控，用`wmic`而不是`mimikatz`。流量走443，混在正常业务里。

最后说个观察。很多甲方找渗透测试，要的是“证明我们安全”。报告里漏洞少了还不高兴。但真正的安全是知道自己哪里弱，而不是假装没有弱。那个电商后台，我最后交的报告里写了SQL注入、调试模式、权限绕过。他们CTO看完说“这些我们内部测试都没发现”。我说对，因为你们测试的时候，知道哪些功能是“不该点”的。

(责任编辑：探索)