渗透测试的思路

渗透测试不是渗透拿着扫描器跑一遍就完事。我见过太多人把Nessus报告直接扔给客户，测试说“你的渗透系统有高危漏洞”。客户问怎么利用，测试答不上来。渗透这活儿干得就没意思了。测试

真正开始之前，渗透得先搞清楚一件事：你是测试在模拟谁？外部攻击者、内部恶意员工、渗透还是测试供应链上的某个环节？目标不同，路径完全不一样。渗透我习惯先画一张图——不是测试那种花哨的攻击树，就是渗透白板上随手勾几笔。标出入口点、测试信任边界、渗透可能藏数据的地方。这张图会随着信息收集不断修改，有时候改到面目全非。

信息收集这一步，很多人做得太糙。打开whois查个注册邮箱就完事了？远远不够。子域名爆破、证书透明度日志、GitHub上泄露的API key、甚至目标公司员工在技术论坛的提问记录，都是线索。有次我通过一个离职员工在Stack Overflow贴的报错信息，推断出他们内部用的是某个老版本Jenkins，未授权访问直接进内网。这种信息，扫描器永远扫不出来。

说到扫描，别被工具绑架。nmap、dirsearch、Burp这些是拐杖，不是腿。我见过有人对着WAF拦截页面反复调payload，却不去想想是不是路径本身就不对。手动测试的价值在于观察异常——一个返回200但内容长度跟正常页面差几个字节的URL，可能就是个未授权接口。这种细节，自动化工具会当成噪音过滤掉。

漏洞利用阶段最忌讳贪多。找到一个SQL注入就急着sqlmap跑库？先想想这个点能不能延伸到命令执行，或者能不能读到配置文件拿到数据库密码。横向移动往往比直接拖库更有价值。有次我通过一个Redis未授权访问，没去写SSH key，而是翻了翻里面的缓存数据，发现了一个内部OA的session token，直接以管理员身份登录了后台。比硬碰硬优雅得多。

权限维持和痕迹清理，这两步在合规项目里经常被忽略。但如果你真在模拟APT，就得考虑：目标重启后shell还在吗？日志里会不会留下明显的异常记录？我一般会留两三个不同的后门，互相独立。一个被查出来，还有备用。清理不是删日志那么简单，得把时间戳、文件属性、甚至内存里的痕迹都考虑进去。

报告写作是另一个重灾区。别堆CVSS分数，客户看不懂。用他们能理解的语言描述风险：这个漏洞能让攻击者拿到什么？是客户名单、财务数据，还是能直接转账？修复建议要具体到版本号和配置项，别写“升级到最新版”这种废话。有次我写“将Spring Boot Actuator的/actuator/env端点设为denyAll”，运维直接复制粘贴就搞定了。这才叫有用。

最后说个反直觉的：渗透测试的成功标准不是拿到域控。有时候，证明某个理论上的攻击路径存在，但实际利用会触发告警或导致服务中断，那就在报告里写清楚“未进一步利用”。客户要的是风险认知，不是你炫技。我见过有人为了拿域管，把生产环境搞崩了。这不叫厉害，叫不负责任。

这行干久了会发现，技术只占三成。剩下七成是沟通、判断和克制。知道什么时候停手，比知道怎么打进去更重要。