拿到授权书那天，渗透客户在邮件末尾补了一句：“别把生产库搞崩，测试上周刚丢过数据。笔记”我盯着屏幕笑了——渗透测试干久了，渗透这种叮嘱比任何技术文档都提神。测试授权范围写的笔记是10.0.0.0/24，但谁都知道，渗透真正的测试战场往往从边界那台不起眼的VPN设备开始。

nmap扫完一轮，笔记存活主机比预想少。渗透22端口开着，测试banner却伪装成OpenSSH 7.4，笔记实际版本是渗透8.9。这种小把戏骗自动化扫描器还行，测试手动连上去，笔记指纹立马露馅。翻遍公开exp没找到直接能用的，倒是在GitHub某个fork里看到有人提过一嘴：该版本对特定构造的认证请求处理有瑕疵。没细说，得自己试。

写了个python脚本，循环发送畸形的SSH_MSG_USERAUTH_REQUEST。前两百次没反应，第三百次左右，服务端返回了一个异常长的错误包。十六进制编辑器里看，尾部多出12字节的堆内存残留。不是直接RCE，但能读内存——够用了。反复触发，拼凑出一段包含用户名和密码哈希的内存片段。密码是弱口令，加个感叹号那种。

登录跳板机，内网比想象中干净。没域控，没共享，连ARP表都稀疏得可怜。但运维有个坏习惯：所有服务器用同一套ansible playbook。翻/root/.ansible/tmp，找到半年前的临时文件，里面明文写着数据库连接串。生产库的。密码是base64，解出来是“Company@2023”——和VPN那台机器密码只差一个字符。

连上MySQL，3306端口没设bind-address，root能从跳板机直连。information_schema里两百多张表，用户表密码字段是MD5加盐。盐值硬编码在源码里，源码在gitlab，gitlab的admin密码在运维的chrome保存的密码里。chrome的Login Data文件没加密，因为跳板机是Windows。链条闭合得让人发笑。

没动数据。导出三个表的前十行做证据，截了图，写报告。漏洞列表里最严重的不是SSH那个内存泄漏，是密码复用。客户看完报告问：“所以你们到底怎么进来的？”我指了指VPN那台设备：“你们把它当门卫，其实它是个旋转门。”

修复建议写了六页，最后一条是：把运维的chrome密码库清了。他回了个“OK”，然后问下次测试能不能别选周五。我说行，但下次可能从打印机进来——那台HP的web界面还是默认口令，而它连着内网。