去年冬天，系统我帮一家做跨境电商的渗透朋友看他们的服务器。老板说“最近后台老有人半夜登录”，测试运维查了日志，系统只看见几个来自东欧IP的渗透失败尝试，觉得是测试扫描器在瞎撞，没当回事。系统我让他把SSH端口从22改掉，渗透再开个fail2ban。测试三天后他打电话来，系统声音发紧——有人已经拿到了一个低权限账号，渗透正在内网横向翻东西。测试改端口这事，系统他们拖了两个月。渗透
渗透测试不是测试拿着扫描器跑一遍就完事。那玩意儿叫漏洞扫描，跟渗透是两码事。扫描器告诉你“这扇门锁是坏的”，渗透测试要干的是“我进去看看你抽屉里放了什么，顺便证明我能把保险柜搬走”。中间差着十万八千里。
我习惯把一次完整的渗透拆成几个阶段，但别误会，真实干活的时候这些阶段是来回跳的。信息收集永远是第一步，也是最容易被忽视的一步。很多人上来就打开Burp Suite对着登录框一顿爆破，连目标用了什么框架、有没有CDN、子域名有几个都没摸清。我见过一个案例，测试者花了三天爆破后台密码，最后发现目标根本没开后台登录接口，那个页面是蜜罐。
信息收集做扎实了，后面的事会顺很多。查whois、翻GitHub提交记录、看SSL证书里的域名列表、用Shodan搜一下暴露的服务。有一次我在目标公司的招聘JD里看到他们用Jenkins做CI，顺手试了一下`/job/`路径，未授权访问，直接拿到构建脚本里的数据库密码。这种口子扫描器永远扫不出来。
漏洞利用阶段最考验耐心。不是每个漏洞都有现成的exp，很多时候得自己根据版本号去翻CVE、读源码、调payload。有一回碰到一个老版本的Struts2，公开的exp打过去没反应，后来发现是对方改了默认的OGNL表达式解析顺序。这种事没地方查文档，只能对着报错信息一点点试。
拿到shell只是开始。真正的重头戏是提权和内网渗透。普通用户权限能看的东西很有限，得想办法变成root或者SYSTEM。Linux上SUID、sudo配置、cron任务、内核漏洞，挨个试。Windows上就看服务权限、注册表、计划任务。提权成功之后，第一件事是留后门——不是恶意的那种，是确保你断线了还能回来。然后翻配置文件、找数据库连接串、看有没有存明文密码的地方。
内网里横向移动的工具有很多，Cobalt Strike、Impacket、frp，选哪个看环境。域环境里BloodHound是神器，跑一遍就能看到攻击路径。但工具再好使，也得靠人判断。有一次内网里有一台机器开着445端口，但防火墙规则只允许特定IP访问。我扫了半天没结果，后来发现那台机器同时开着RDP，用刚拿到的账号密码直接登进去了——防火墙规则只挡了SMB，没挡RDP。
报告是最后一步，也是最容易被糊弄的一步。我见过太多渗透报告，满篇都是“高危漏洞”“建议修复”，但具体怎么修、修复优先级怎么排、业务影响是什么，一个字没有。客户拿到这种报告除了焦虑没别的用。好的报告应该让运维看完就知道明天上班第一件事干什么，让老板看完就知道该批多少钱买什么设备。
说到底，渗透测试的核心不是工具，是思路。工具会过时，漏洞会修补，但“站在攻击者角度想问题”这个能力不会过时。你得像小偷一样思考，才能帮主人把门锁好。